Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/whip/whip-minutes-94jul.txt

Text File | 1994-11-01 | 9KB | 189 lines

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.