Comments for PICS Developers

Date: March 1, 1996
From: Jim Miller and Paul Resnick, co-chairs, PICS Technical Committee

1. Bob Schloss (IBM research) suggested that it would be very nice to have a way, in a rating system description, of saying "If you don't find one of my labels, you can use labels from the following other system instead." This seems like a very good idea, but it raises some issues about the evolution of independent rating systems that we didn't want to have to address in version 1.0.

   On the other hand, this seems like a perfect candidate for an optional extension to the existing rating system description; all that is needed is for someone to write up the details and publish it as a URL that can be referenced. I'd be willing to set up something like "http://www.w3.org/PICS/MRD/Extensions/AlsoTrust" if someone (Bob?) wants to write up the details.

2. Another idea that someone suggested (I've lost track of who) was that there be a way to specify a location where an alternate (presumably less likely to be censored) version of a document is located. This, again, is a nice optional extension. If anyone wants to write up the details, I'll provide a permanent URL.
3. Bob suggested, as he had at our original meeting, that it would be nice to be able to provide information about the rating of a link before attempting to retrieve it. This can be done in PICS 1.0 by parsing the document to find the embedded references and then querying a label bureau. But this can be quite inefficient. By using a mandatory extension (which will cause the label to be ignored by browsers that don't understand the extension) it is possible to embed labels for referenced objects within the document containing the reference.
4. There have been suggestions for two additional query syntaxes for label bureaus. We believe both of these are very good ideas and can be done in a way that is fully upward compatible with PICS 1.0 (i.e. a PICS label bureau could implement them without disturbing its ability to be used by clients unaware of the additiona capability). The first is to allow "reverse queries" like "send me labels for all the URLs that rated below 3 on abc's xyz scale." [This was discussed during the design of PICS 1.0 and rejected for public relations reasons: it also allows queries that we wouldn't like to call to the attention of Congress.] The second (which was an oversight pointed out only recently by Safesurf) is to allow queries of the form "do you have labels from abc's system, and do you have their machine-reachable description?" This would fill the obvious (and originally intentional) hole in the PICS specifications about how a parent can locate the machine-readable description files.
5. Brenda Baker (Bell Labs) suggested that, since it isn't possible to embed PICS labels in datatypes other than HTML, it would be good if there were a convention that could be used to retrieve a label from a server that isn't PICS-compliant. For example, there might be a convention that the URL of the label for http://somewhere.org/file.name would be http://somewhere.org.label. While this is a good idea, we didn't feel that it was really within the scope of the PICS committee to suggest how a content provider should structure its web site.
6. Brenda also points out that it can be confusing to novices if a rating applies only to a document and not to the images it includes. On the other hand, there are certainly documents where the text (say) is innocuous but a related image might be considered unacceptable to certain audiences. We're clarifying the language to indicate that in-lined objects (IMG or the proposed OBJECT tag) should have their labels checked separately from the main document. At the same time, we believe that good label authoring tools would be an effective solution to the problem.
7. Finally, Ray Soular (SafeSurf) made a suggestion which we will include as part of a new "advice to implementors" section of the specifications. He recommends that administrators of sites that embed labels directly into documents include a generic label in the index document of every directory. Browser vendors could make use of this by retrieving documents as usual and, if the document itself had no label, going to the enclosing directory and retrieving the index page (i.e. just drop off the part of the URL after the last "/" and ask the same server for this new URL). This would then return the index page's label -- and the generic label would be applicable to the original document retrieved.