CURRENT_MEETING_REPORT_

Reported by Tim Howes/University of Michigan

Minutes of the Access, Searching and Indexing of Directories
Working Group (ASID)

ASID met once at the 33rd IETF on Tuesday, 18 July.


Agenda Review/Changes

The agenda was reviewed and accepted without changes.


Review/Discuss Revised Charter

The proposed charter previously sent to the list was reviewed and
accepted without changes.  Tim will submit it to the Applications Area
Directors for approval.

[Reporter's note:  Subsequent to this decision, the responsible Area
Director expressed a desire to form a separate working group to do the
common indexing protocol work, which is currently in the ASID charter.
If this happens, the ASID charter will need revising again.]


LDAPv2

Bob Cooney of the US Navy presented their design and implementation of
MDAP, the Minimal Directory Access Protocol.  MDAP is full DAP run
directly over TCP, without the OSI stack.  This allows digital signature
information to be carried end-to-end from LDAP client to X.500 server to
ensure operation integrity.  MDAP messages are packaged within newly
defined LDAP messages to provide some compatibility with existing LDAP
implementations.  SLDAP is the Navy's implementation of MDAP, and is
based on the freely available U-M LDAP distribution.

John Myers presented his proposal for adding strong authentication to
LDAPv2 based on the IMAP authentication work.  A new Bind2Request
LDAPMessage is defined to hold an IMAP4 authentication mechanism as
defined by RFC 1731.  Two new operations, a Bind2Response and a
Bind2Continuation are also defined, allowing different authentication
mechanisms to be negotiated as well as protection mechanisms (i.e.,
integrity or privacy), to be used subsequently on the session.  There
was some discussion of this approach and how it might or might not map
onto X.500 strong authentication.

Tim Howes gave a brief report of the approach taken by the Zoomit
company to implement a 93-like paged results feature in LDAP. There was
general agreement that this feature should be supported in a more
standard way in LDAPv2.

Tim also gave a brief report of the stand-alone LDAP work going on at
U-M (LDAP without X.500).  The work currently avoids orphaning
stand-alone LDAP servers by using the existing LDAPResult error message
field to return a ``referral'' to knowledgeable clients.  The clients
can then chase the referral to an X.500-aware LDAP server, another
stand-alone server, etc.  The group agreed that the referral capability
was useful and should be incorporated in LDAPv2 in a more standard way.

There was a short discussion of how to handle multiple character set and
language issues in LDAPv2, though no conclusion was reached.  Proposals
should be sent to the list.

At Danvers, various people promised to help produce an LDAPv2 draft by
this meeting.  But for various reasons, the work was not done, a fact
the chair could not complain about too loudly, since he was one of the
main culprits.  The group agreed to redouble their efforts and produce a
draft by Dallas.



WHOIS++

Patrik Falstrom led a discussion of the WHOIS++ portion of the agenda,
first describing the recently-released Bunyip implementation of WHOIS++,
called DIGGER. The two WHOIS++ RFCs (query language and architecture)
have been progressed to Proposed Standard.  The remaining WHOIS++ RFC on
the centroid indexing mesh is being held back pending the resolution of
issues raised by the Area Director and others.

The issues raised included:


  1. The document does not address scaling issues well enough.
     Experiments are ongoing, and the group proposed to produce a
     document by the Dallas meeting documenting the results of these
     experiments.

  2. The meaning of ``word'' is not clear.  The group proposed that a
     word be defined using the reserved WHOIS++ tokens.

  3. The character set issue was not addressed adequately.  The group
     proposed to limit character sets to unicode and ISO-8859-1, with
     every implementation required to support both.


The proposed MODE command was also discussed.  The MODE command allows a
WHOIS++ session to temporarily escape to another protocol.  The group
expressed some misgivings about the need for this command, though some
situations in which it would be useful were raised.

The current WHOIS++ server handle syntax was proposed to be replaced by
an object identifier (OID). OIDs already have a distributed registration
procedure.  The group agreed this was a good idea.

Patrik is to produce a draft by Dallas detailing results of the ongoing
WHOIS++ pilot's scalability.



CIP

The WHOIS++ discussion led into the common indexing protocol discussion,
where several issues were raised.  First, the group felt that the
current CIP draft still has some WHOIS++ dependencies that should be
removed.  These include the QUERY part of the centroid selection, which
allows a WHOIS++ query, and the <handle,host,port> tuple used to
identify the server from which a centroid came.  It was suggested, and
the group agreed, that this tuple be replaced by a URL, pointing to the
server.

On the subject of CIP use in non-WHOIS++ protocols, the group felt that
a separate draft should be produced for each protocol specifying how it
should use CIP.

There was some discussion of scaling issues with CIP, and the consensus
of the group was that the only way to resolve the issues is to pilot the
service and gain some experience with it as it grows.  A draft should be
produced detailing the results of these experiments.

Chris Weider is to revise the CIP draft by Dallas



X.500

Roland Hedberg presented his draft for storing PGP information in the
X.500/LDAP directory.  There was general agreement that this was a good
thing to do, and the group agreed, based on discussion on the list, that
the syntax for the pGPKey should be IA5String, which would allow
ASCII-armored PGP Keys to be stored in the directory exactly as they are
produced by the PGP software.  Roland is to revise his draft and
experiment with the new format.

Ed Reed of Novell was not able to attend the meeting and raise the X.500
issues he wanted addressed.  But the group did have a brief discussion
on the problem of storing 93 schema information in the tree.  Ed had
found the administrative area restriction too confining.  The group
suggested creating sub-administrative areas that could, in turn, have
their own sub-schema definitions.  Without Ed there, it was not clear if
this addressed his needs.  He needs to post his questions to the list
again if he wants more discussion.


Any Other Business

There was no other business, and we ran a little over, so the meeting
was adjourned.  The next meeting of ASID will be at the December IETF in
Dallas, Texas, USA.


Summary of Action Items

   o Tim to submit a charter to the Applications Area Directors for
     approval.

   o LDAPv2 volunteers to get cracking and produce a draft by Dallas.

   o Patrik is to produce a draft by Dallas detailing results of the
     ongoing WHOIS++ pilot's scalability.

   o Chris Weider to revise the CIP draft by Dallas.

   o Roland to revise his draft, for storing PGP information in the
     X.500/LDAP directory, and experiment with the new format.

   o Ed to post his questions, concerning X.500 issues, to the list
     again if he wants more discussion.