At the current time, the PICS specifications are "frozen" waiting for reference implementations to detect potential problems. A new version is likely to be released in mid-March based on this implementation experience. At that time, an updated specification will be released and PICS will consider surrendering change control to a standardization body.

Both specifications will be rewritten (including the BNF grammars) to be both simpler to understand and more complete. Many of these revisions are based on questions raised by developers who have implemented according to the current specifications. Several of the changes are corrections of errors in the examples contained in the specifications.

Proposed Updates to the PICS Label Distribution Document

Change from Accept-Protocol: to Protocol-Request: header name.
Feedback from six months of presenting the details of the PEP specifications has convinced the W3C that the name of this header field is confusing to potential implementers. In order to allow PICS to remain PEP-compatible, we are asking that PICS implementations change to this new header name if at all possible. The details of PEP are now sufficiently well worked out that it seems highly unlikely there will be further changes that would affect PICS; and W3C has agreed that (since PICS roll-out has now begun in earnest) any future changes to PEP will "grandfather" the current PICS usage.
Allow URLs as transmission names.
The W3C expects that the annotation community may wish to adopt the use of PICS parsers and label bureaus for use in their applications. In order to do so they must either employ a number of custom extensions (and supply corresponding parsing software) or use full URLs where PICS currently uses simple transmission names. Since it does not impact any existing protocols, this modification is straightforward: "alphanumpm" in both the machine-readable description and the label list syntax must be extended to include a number of additional characters: /:?;$_@.&!*"'(),%~ In addition, transmission names must now be treated as case sensitive, since URLs are case sensitive.
POSTing a query to a label bureau.
This was an oversight in the original document. For long query strings, it is better to use the HTTP POST method than the GET method specified by PICS. Most existing servers will support both mechanisms, so this should have little actual impact.
Modification to SERVICE-UNAVAILABLE error message.
All other errors share a common syntax: 'error' '(' error-name <string>* ')'. We will convert this error to that same format.
Specification of both label signatures and message digests.
Early PICS implementations will be under a good deal of public scrutiny and are likely to attract severe attempts to "crack" the system. While PICS will not be invulnerable, these two precautions will provide a good deal of assurance under moderate forms of attack.
Recommended client algorithm to support replicated label bureaus.
There is a serious concern that, if PICS label bureaus become popular, they may become a severe impediment to system-wide performance. Prof. David Karger has recommended a simple algorithm for clients that will distribute the load between replicated label bureaus without requiring additional changes to the Internet infrastructure.

Proposed Updates to the PICS Service Description Document

Allow all characters legal in URLs in transmission names.
This corresponds to the change in the label distribution document.
Add general extension mechanism to the machine-readable description.
The PICS label format has an extension facility that allows for both optional and mandatory extensions, designed to allow future modifications to the system. The machine-readable descriptions have a simpler rule that allows extensions, but they are all considered optional. At the request of some developers, we would like to adopt the label extension mechanism for machine-readable descriptions. Extensions would be allowed at both the PICS service description level and the individual category description level.
Add the boolean attribute "unordered" to category description.
At the request of developers, we would like to be able to explicitly mark categories whose values are not to be considered an ordered set. The user interface for such categories may be considerably different from those in which an ordering is inherent (unordered categories with only labelled values might be shown as buttons, while ordered categories would be a slider pointing in one direction or the other). Examples of ordered categories are the RSAC and Safesurf categories for language and profanity (respectively). An example of an unordered category is one consisting of the primary classifications of the Dewey Decimal System.
Clarify the reason for allowing defaults for only some category information.
Most, but not all, of the information about a category can be set to a default value through the use of a default clause in the rating service description. We propose to explain how the decision is made: an option is defaultable if and only if it can be overridden in the subsequent detailed description of the category. Thus, the list of named values is not defaultable, because there is no way to say "don't name this value" in the category description.
When this page changes, the following mailing lists will be notified: w3c-labels-tech@w3.org, pics-supporters@w3.org, pics-developers@w3.org and pics-info@w3.org.
Comments to Jim Miller.
Created 3 January 1996 by Jim Miller
Last updated 3 March 1996