PICS Developers' Workshop Summary

Held June 20-21, MIT

Notes by Paul Resnick (presnick@research.att.com)


9:10		Welcome and Introductions
10:00		PICS History (Weitzner and Miller)
10:15		PICS Spec Overview (Resnick)
11:00		Break
11:15		Standards Process (Miller)
11:30		Afternoon Preview (Resnick, Schloss, Miller, Kotok)
12:00		Lunch (provided)
1:30		Breakout sessions:
          1)  Operating with PICS-1.1
          2)  Protocol evolution  
3:30		Break
4:00		Reports back
5:00		Adjourn

Introductions and briefings on the current status of the specifications and the public policy process took most of the morning. More than 40 people attended the first PICS developers' workshop, representing xx companies and organizations. Danny Weitzner discussed ramifications of the Philadelphia court injunction against enforcing the CDA. It is likely that the government will appeal to the Supreme Court. It is also possible that the New York court, hearing a similar case, may come to a different conclusion than the Philadelphia court. Further legislation in the U.S. is also a possibility, once the current CDA status becomes final. Catherine Soubeyrand summarized a recently passed French law that requires Internet Service Providers to do two things: 1) filter materials deemed illegal by a Government labeling body that was appointed; 2) give subscribers access to filtering technology so that they can choose what else they want to block.

I walked the group through the specs. Many questions came up, but since I was presenting, I don't have notes (anyone who took notes, please send them and I'll link them in here.) Several questions were redirected to the afternoon breakout session on operating with the 1.1 specs. A few points of terminology kept tripping us up, so here's a quick glossary that we agreed to follow as best we could for the rest of the day:

Jim Miller discussed options for moving PICS from de facto to de jure standard, including IETF, ISO, and IEEE. Most participants felt that it was not worth the effort, though there were a few dissenters. The group voiced confidence in W3C to make appropriate decisions about when and whether to forward the work to an official standards body.

In the afternoon, we split into two breakout groups. One discussed the current state of implementations, the other future protocol evolution.

Working With the 1.1 Specs

The current implementations group surveyed what features are currently being implemented, decided to create several web pages to keep tabs on the developer community's progress, and identified several areas where additional work is needed.


Keeping in mind that not all developers were present (regrettably, the invitations went out only 3 weeks prior to the workshop), the following appears to be the current status:

New Resources

We agreed to keep lists of resources that will be useful to developers. To spread the burden, these lists will be maintained by various people, with the PICS page linking to them. Since the people maintaining these pages may need to include links to competitors' products, those who are maintaining the pages all agreed to be: "fair, equitable, and speedy." If you are on this list, please send me a URL as soon as possible, and I will make the links. On the page that you create, please indicate submission instructions so that people can send you additional links. Please indicate also that pics-ask@w3.org is a good place to send an "appeal" if anyone feels that the page is not being run fairly, equitably, and speedily.

There will be lists of:

More Work Needed

We identified several areas where additional work is needed:

Protocol Extensions

(Slightly edited version of summary provided by Alan Kotok)

Jim Miller discussed the question of whether there needed to be a way of asking a rating bureau for lists of documents matching certain ratings. The initial conclusion was, no, not yet. But this turned around later, since a subcommitte was solicited to develop this idea.

Jim Miller then discussed the question of whether the protocol needed to allow arbitrary text strings as values of ratings. He pointed out that all known justifications for this requirement could be met in other ways. It was agreed to postpone this for a more compelling argument. However, in the discussion, a problem with text strings being language-specific was identified. Proposed solutions to that problem were (1) including language identifiers to tag the strings (where one or more such string was provided), and (2) having multiple "ratings" retrieved using the yet-to-be-widely-adopted language preference part of HTTP.

In the discussion about interfacing PICS to Search Services, we discussed both sending the filtering criteria to the Search Service, and the Search Service supplying enough information for the browser to do filtering.

We agreed that latter was better for the strict purpose of filtering, but the former was required for other reasons, as well: PICS may well convey many kinds of "ratings", some of which have nothing to do with filtering, but which may well be useful as search criteria. Therefore it is desirable that there be a standard protocol to convey PICS-based criteria to search services, both for use in guiding searches, and avoiding the problem of "here's the first 10 responses, but 9 of them were censored by your browser."

Some issues raised:

pics-profiles working group

A new working group was formed, with work to be conducted by mailing list. If you would like to be on the mailing list, send email to Kevin Fink saying why you'd like to participate. The pics-profiles working group will specify a format for describing a PICS preference profile. A preference profile indicates what labels are required in order for a URL to be "acceptable" for a particular user. The profile will have to indicate which services' labels should be consulted, and what constitutes an acceptable label. It may also include information such as the user name and password associated with the profile, or rules about which profiles apply to which users. Details are still to be determined. It is believed that the preference profile will also be sufficient for communicating queries to label bureaus, such as "find all labels above 3 on scale A and between 2 and 4 on scale B." Enough people had this hunch that we decided to make a single working group for both functions. We'll watch carefully to make sure the eventual preference profile format also is adequate as a query language. The work of this group will be carried out exclusively by email, at least for the time being. Jonathan Brezin from IBM has agreed to take primary responsibility for creating an initial proposal that we can all respond to. Anyone else is also welcome to suggest options or full proposals.