PICSRules 1.1

Abstract

This document defines a language for writing profiles, which are filtering rules that allow or block access to URLs based on PICS labels that describe those URLs. This language is intended as a transmission format; individual implementations must be able to read and write their specifications in this language, but need not use this format internally.

Introduction

The purposes for a common profile-specification language are:

• Sharing and installation of profiles. Sophisticated profiles may be difficult for end-users to specify, even through well-crafted user interfaces. An organization can create a recommended profile for children of a certain age. Users who trust that organization can install the profile rather than specifying one from scratch.  It will be easy to change the active profile on a single computer, or to carry a profile to a new computer.
• Communication to agents, search engines, proxies, or other servers. Servers of various kinds may wish to tailor their output to better meet users' preferences, as expressed in a profile. For example, a search service can return only links that match a user's profile, which may specify criteria based on quality, privacy, age suitability, or the safety of downloadable code.
• Portability betwen filtering products. The same profile will work with any PICSRules-compatible product.

This language complements the two existing PICS specifications, which provide a machine-readable format for describing a rating service and provide a format for labels and three ways to distribute them. In particular, a PICSRules rule can specify one or more PICS rating services to use, one or more PICS label bureaus to query for labels, and criteria about the contents of labels that would be sufficient to make an accept or reject decision. PICSRules does not explicitly include constructs that deal with the verification of DSIG digital signatures, but there are hints to implementors about where to leave hooks for expected future extensions to the PICSRules language to accommodate signature verification.

Translator's Annotation: The above text refers to concepts which ...

Definitions

This specification uses the same words as RFC 1123 [RFC1123] for defining the significance of each particular requirement. These words are:

MUST

This word or the adjective "required" means that the item is an absolute requirement of the specification.

SHOULD

This word or the adjective "recommended" means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before choosing a different course.

MAY

This word or the adjective "optional" means that this item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because it enhances the product, for example; another vendor may omit the same item.

An implementation is not compliant if it fails to satisfy one or more of the MUST requirements for the protocols it implements. An implementation that satisfies all the MUST and all the SHOULD requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the MUST requirements but not all the SHOULD requirements for its protocols is said to be "conditionally compliant." User-agents which process PICSRules are free to choose any interpretation they wish for constructs which fail to meet one of the MUST requirements.

This document assumes that the reader has a working knowledge of PICS-1.1. All labels referred to here are assumed to be PICS-1.1 compliant labels. See references [PicsServices] and [PicsLabels] for details.

The PICSRules language: examples

....