CURRENT MEETING REPORT Minutes of the Voluntary Access Control BOF (vac) Reported by Roxana Bradescu, AT&T Bell Laboratories These are the minutes from the Voluntary Access Control BOF held at the Dallas IETF. The BOF was co--chaired by Roxana Bradescu and Sally Hambridge, minutes were taken by Roxana Bradescu (who apologizes in advance for any mispelled names). As per the agenda, the Administrivia and Intro out of the way, the group discussed the charter which had been drafted on the list. Comments were made that the charter wording was too neutral or not strong enough and that more examples regarding usage were needed. Not everyone agreed with these comments and it was agreed that this could be further discussed on the list. An additional comment was made that the charter should address interoperability between rating systems (such as a common registry). It was agreed that this was a good idea and will be added to the charter. Next on the agenda, Ted Hardie presented the Scenarios/Requirements document he had written and which had been discussed on the list. In relation to the scenarios section of the document, comments were made by Larry Masinter that the distinction between interactive and user-- retrieved objects is blurry. There was agreement and it was suggested that the categorizing by protocol would be a better alternative. Steve Knowles also suggested that it would be appropriate to discuss the "unpleasant" scenarios as well, such as someone setting up an x--rated service or a government service that only allows access to government approved resources. Paul Resnick also suggested that "permit" versus "deny" list would be better than "white" versus "black" list since the latter has negative connotations. Chris Weider also made the general point that the document does not sufficiently address how access control is tied to or associated with the resource. On the requirements section of the document, the following comments were made: o 4.1 implies order o 4.1 "unambiguous" syntax v. format o 4.2 implies part of objects--don't want to get into that o 4.2 interactive v. static o 4.3 strike unordered--if request in order then want in order o 4.4 human language? (PICS uses indirection => strikes requirement) o strike 4.5 and 4.6 -- let market decide o should standardize labels o format and transport include design and should only be requirements o strike inclusion/exclusion because client implementation issue o separate doc to discuss usage If clarification of these comments is needed, please contact anyone requires further clarification, Roxana Bradescu. Next on the agenda, Jim Miller and Paul Resnick presented the W3C PICS effort. Comments were made regarding the ISO date format versus RFC822 format, the choice of UTF7 versus UTF8 for internalization, the use of version numbers v. extension tokens. Additionally, it was suggested given the potentially very long URLs that the POST method might be more appropriate than GET due to the size limits associate with GET. At this point, John Klensin asked in light of the W3C PICS effort, why should IESG make this a group? What would value--add would the IETF provide? Additonally, Jim Miller stated that the W3C would not give up revision to the IETF until the PICS specs were complete sometime early 2Q. These topics were not anticipated by the group since there had been no prior mention of these issues on the list. What followed was a general discussion regarding potential areas for the IETF/this group to work on such as an interoperable registry for rating systems, alternative solutions (PICS is only one example), simpler self- -rating solutions (comments were made that PICS is too complex), security, binding resources with ratings (seemed to be the URC problem), CA services, etc. There did not seem to be clear consensus around any one specific area. However, there was consensus that the group did not want to work on/review PICS without revision control. Thus, it seemed that more discussion on the focus of the group needs to happen on the list before a formal working group is chartered. Additionally, it was suggested that the group wait until PICS is completed to define its focus especially since there may be additional issues regarding PICS compatibility with other standards that are being worked on (e.g. http and URCs). One option suggested by John Klensin is that once PICS is published as an Informational RFC, the group could do its work and either propose PICS (with potentially minor revisions) as a Standards RFC or propose an alternative. The mailing list will be kept open and any comments to the PICS list can be cross--posted to the VAC list (since the PICS list is not a reflector) for additional discussion. If folks are still interested in working in this area, another BOF can be held at the next IETF.