CURRENT_MEETING_REPORT_ Reported by Ken Rossen/SHL Systemhouse Minutes of the Internet White Pages Requirements Working Group (WHIP) Agenda Review The agenda was accepted. Erik Huizer was adamant that work on the draft and the business of the working group be completed before the next IETF. Access Control An approach has been proposed that does not allow for modification of data through the interactions with the White Pages service. There will be no modification allowed by the user on any entries in the IWPS. Therefore, no access control or authentication will be needed. The group generally agreed to this. Conceptual Model Joan Gargano and Paul-Andre Pays contributions were used as the conceptual model in the document. Chris Weider inquired as to requirements imposed on legacy systems, and whether information object template support will be a prerequisite to participate in the White Pages service. It was also noted that such support seemed to require incorporation of ASN.1 and BER encoding capability, and there was some question as to how feasible this is for such systems as finger and netfind. Tim Howes noted that such systems cannot be expected to be retooled to accommodate structured information objects. He proposed that an unstructured element be added to the object format to catch unstructured ``legacy'' data such as finger output. In such an example, users would be able to read the output, but programs (due to the lack of structure) would not (at least necessarily). Richard Huber inquired as to whether the use of URLs made such a mechanisms redundant---the URL philosophy should embody the assumption that the client decides how to present information based on the construct of the URL. Chris Weider suggested clarifying in the document that the use of structured information objects was not required, but rather that it was encouraged to facilitate searching. Erik took the opportunity to note that requirements and the specification of mechanisms should be kept separate, and encouraged that a document yet to come be used to retain requirements. Tony inquired as to whether RFC 1588, already produced, was perhaps the requirements document, but Erik noted that the requirements are rather hidden in that document. There was agreement to distill the requirements from the discussion into another documents. Allan Cargille concurred with this view, and wondered how the current document fits into this taxonomy. Erik responded that the current document should be a mechanisms document that answered (yet-to-be-written) requirements. Erik further suggested that the Appendix of RFC 1588 be used as a starting point for documenting requirements. Allan Cargille volunteered to be responsible for the proposed requirements document. Erik requested that the rationale for choosing a newly proposed WPI/WPN over URL/URNs be articulated for the purpose of the meeting. Tony explained that the WPI/WPN approach was chosen to respond to the need for concise, unique names as well as names that can be used to guess or navigate the IWPS. WPIs were to be used as unique identifiers, and WPNs were to be user-friendlier, more intuitive constructs. Inquiry by WPI would yield exactly one object, whereas WPNs were to potentially yield one or more objects. A WPI would be resolved to a URC which may contain several information sources, since one WPN might have several instances. Chris Weider raised a question about the proposed naming, noting that it was based on the UFN definition proposed years ago by Steve Kille. Chris wondered how location-dependent navigation information related to naming. After some discussion, Chris asserted that navigational information needed to be tied to some specific attribute or another in order not to imply unbounded searches. As part of the discussion, Tony pointed out that typing of attribute information, i.e., how information is collected from the user and presented, was intended to be the province of the client, and Tim Howes asserted that this needs to be clarified in the document. Russ Wright suggested that specifications for name presentation should be made explicit for such known services as WHOIS++, X.500, SOLO, and others. Tony suggested making this part of an appendix to the document. Russ further asserted that the URN/URC concept needs to be made generally clearer and more explicit in the document. Synchronization/``Data Integrity'' Issues Andrew raised issues of synchronization, and Tony noted that synchronization should be added to the requirements document to be produced. Tim Howes requested a clarification of what ``synchronization'' means in this context, asserting that true synchronization of disparate directory technology in the Internet context was an impossibility. After some further discussion, the group still required a definition for synchronization, as well as what has (at times) been referred to as synchronization in the White Pages context, which can be described as reconciliation of information about a real-world object residing in disparate systems. One element of the latter (which Tony came to refer to as ``data integrity'') was described as expression of a preferential ordering of services on a per-object basis. This could be added to the URC. The URC/URN mapping was discussed, although the current URC specification in this area had not been broadly reviewed among the group. Chris noted that no one service was likely to be best in all cases for making this mapping, and as a result Tony suggested that implementation of this mapping might be a valuable topic for a third document. Russ Wright suggested that this might be a topic for the ASID Working Group. Joan Gargano put forth a clarifying assumption that the current document will describe the syntax of a value field associated with each service in the URC, but the semantics will be described in another document yet to be identified. This was generally agreed to, although Joan tentatively agreed to write it. Reg Quinlan objected to the set of assumptions that led to this. He suggested that if an organization has a highest-value service it wants to encourage, it should list only one in the URC. Russ Wright noted that there is value in listing several, because some clients are less capable than others, and may need something less heavy weight than the highest-value service. Support for Other Information Objects Should other information objects be defined? Chris Weider was concerned that doing so may be straying from the White Pages problem. Tim Howes agreed. Tony asserted that a URC object could be added, but that documents and other objects need to be discussed more. Security Certificates (RFC 1588) Chris Weider asserted that certificates must be in the White Pages to make it useful for interpersonal communication, and further asserted that putting them in is not hard. It was asked whether this was compatible with the decision not to address access control, and this was answered with a general sense that such certificates as public-key certificates were intended to be as public as possible. Rick Huber and others noted that this is a new attribute, rather than another object class. Chris noted some differences between types of certificates, with PGP certificates not as self-contained as PEM certificates, by which it is meant that PGP certificates may have a greater or lesser degree of ``trustedness'' based on which server the certificate is retrieved from. Erik objected that such issues pertinent to access control are local matters not to be addressed in the White Pages mechanisms. Making the certificates available was enough. Rick Huber suggested that the discussion which had just ensued implied a need to document the environment in which these mechanisms were to be used. Template Registration Chris Weider brought up the matter of template registration, and requested that a URL-based identifier, rather than an OID-based one (per page 12 of the current draft) be allowed for. Tony explained the motivation for OIDs and there was general concurrence that it was acceptable to use OIDs. Chris also expressed concern that the expression of the template as an object class might lead to the belief that further templates would have to be defined through X.500-style subclassing. Tony noted that this was not the intention, but rather the use of Object Class syntax was shorthand to a broadly understood definition. Chris suggested that this explicit clarification be added to the text.