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
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
Proposed Updates to the PICS Label Distribution
- 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
- 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
- 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
When this page changes, the following mailing lists will be notified:
email@example.com, firstname.lastname@example.org, email@example.com
- 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
- 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
- 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
- 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
Comments to Jim Miller.
Created 3 January 1996 by Jim Miller
Last updated 3 March 1996