Editor's note: These minutes have not been edited.
From: Tim Howes <
[email protected]>
Subject: ASID Minutes from Dallas
Date: Tue, 19 Dec 1995 09:58:08 -0500
Access and Searching of Internet Directories
Meeting Minutes
What: Access and Searching of Internet Directories
When: Wednesday, December 6, 1530-1730
- Agenda review/changes
The chair apologized for getting the agenda out so late, and
for not producing a proper document archive.
The proposed agenda was reviewed and accepted without changes.
- WHOIS++ status
Patrik Falstrom gave a brief status report on the WHOIS++ query
protocol documents. They have been submitted to the ADs for
proposed standard status, and should be reviewed at the next
IESG meeting.
ACTION: Harald to submit WHOIS++ documents for proposed at
the next IESG meeting.
- CIP status
A new working group (FIND) is forming to define the Common
Indexing Protocol, and the BOF met just before the ASID
meeting. ASID will drop this item from its charter.
- LDAP status
LDAP has been at draft standard status since last March, and
the group discussed whether LDAP is ready to progress to full
standard. There are multiple independent interoperable
implementations. There was a question raised as to whether the
Kerberos BIND credentials were supported by any implementation
other than the one from University of Michigan. The group
agreed that this question should be resolved before LDAP goes
forward, and Tim agreed to try and find out. There was another
question raised as to whether LDAP had seen enough operational
experience. The consensus of the group is that it has.
There was some confusion in the group about the difference
between the LDAP protocol and the widely-used University of
Michigan implementation of LDAP. The LDAP protocol has had one
version change. It went from version 1 to version 2 when the
MODRDN operation changed. There have been several versions of
the U-M implementation of LDAP released, the most recent of
which is version 3.2. Earlier U-M releases had some bugs in the
BER encoding that were hampering interoperability with
conformant LDAP implementations. These bugs have been fixed,
and the implementations now interoperate, though there are
still some old implementations out there.
There was also some confusion as to what exactly was being
proposed for full standard. Again this appeared to stem from
confusion between the LDAP protocol as a front-end to the
X.500(88) directory as defined in RFC 1777 and RFC 1778, and
the University of Michigan implementation of LDAP, which
includes some experimental extensions transparent to existing
LDAP clients for doing stand-alone LDAP, passing back
referrals, indexing information, etc. It is only the former
that is being considered for standardization. The latter are
only useful experiments that will hopefully feed into the
design of the next version of LDAP.
ACTION: Tim to check on implementations of kerberos LDAP BIND
credentials, and put LDAP up for full standard if there
are others that interoperate.
- LDAP URL format draft
At the last meeting, the LDAP URL format draft was approved by
the group, provided that it be passed by the URI working group
for review. This was done, to little comment, and the group
now suggests that the draft be progressed as proposed standard,
after it is passed by Harald's URI checklist.
ACTION: Tim to submit LDAP URL format draft to ADs for
progression as proposed standard.
- labeledURI draft
At the last meeting, changes to Mark Smith's labeledURI draft
were discussed. The group consensus was that both labeledURI
and labeledURL attributes were useful. Mark changed the draft
to incorporate both attributes. The group agreed that with
these changes the draft should be progressed as proposed standard.
ACTION: Tim to submit labeledURI draft to ADs for progression
as proposed standard
- LDAP/X.500 caching draft
The group agreed that the caching draft was useful, but that
the function would be better served by creating an operational
attribute, rather than a user attribute to hold the TTL
information. Some reservation was expressed about the work,
since this is an area the X.500 standard has intentionally
avoided. The group agreed that this draft should be revised
and progressed as experimental.
ACTION: Tim to revise caching draft and circulate to the
list for comment.
- application/directory MIME type draft
Several comments on the application/directory MIME type draft
since the last meeting have been incorporated, but a new version
of the draft has not yet been submitted. Changes include the
addition of a home fax number and change to using multipart/related
rather than multipart/mixed.
There was some discussion of potential uses for this draft, from
the straightforward carrying of directory information in email
from a simple directory query responder, to use as a method of
carrying directory synchronization information, to the provision
of directory information over HTTP. There was general agreement
the draft was useful.
Concern was expressed that the draft defines both a general
framework for carrying directory information and the specific
content relating to a person. The issue is that the person
information implies some schema which should be harmonized
across all directory services, if this draft is to be useful as
a general mechanism for carrying information. This schema
harmonization is already being tackled by the IDS group. The
suggestion was made, and the group agreed, that the draft be
split into two. One draft would define the MIME type and general
framework for carrying directory content of different types.
The other draft would define the content for person directory
information.
A third draft was proposed to define the necessary content for
handling directory synchronization applications.
ACTION: Tim to split the application/directory MIME type draft
into two drafts (one framework, one person information).
ACTION: Greg Vaudreil and Ed Reed to write an application/directory
MIME type content draft for directory synchronization.
- leaf/nonleaf draft
This draft was withdrawn by the authors (with the blessing of
the group), since it had been pointed out on the list that
the main function of distinguishing leaf from non-leaf objects
could be done by using an already defined X.500(93) operational
attribute.
- String encoding of presentation address draft
The string encoding of presentation address draft has been
revised by Steve Kille to support the new IPv6 addressing scheme.
The group agreed that the draft should go forward, provided
that it be circulated to the ASID list for comment. The document
is a product of the TOSI group, so not directly in the ASID
charter.
ACTION: Steve to circulate the presentation address draft to
the list.
- Storing PGP attributes in the directory draft
Roland Hedberg gave a brief presentation on his draft defining
an object class and attributes for storing PGP certificates in
the LDAP/X.500 directory. The presentation prompted much
discussion.
The debate focused on whether it is better to store
certificates in the directory directly, or to store a URL
pointing to the certificate in a PGP key server. The primary
advantage of the latter method is one of easier maintenance. If
the user needs to maintain their key(s) in a PGP key server
anyway, the added administration and potential for
inconsistency introduced by storage in the directory is a bad
thing. On the other hand, storing only a pointer in the
directory places an extra burden on clients, which will have to
implement an additional access protocol to retrieve the key
from the PGP key server.
The group was fairly evenly divided between the two approaches,
prompting the suggestion that the draft be changed to define
attributes appropriate for both solutions. The market could
then decide which was better.
ACTION: Roland to revise the PGP draft to incorporate both
solutions, and post the revised draft to the list.
- SUM500 draft
Vincent Berkhout gave a brief presentation of his SUM500 draft,
which defines a method of mining the Web and other information
services for X.500 information. Vincent's idea involves using
standard HTML pages that, if present on an organization's web
server, could be read and parsed to produce organization and
people entries for the X.500 directory.
The group thought the draft useful, and there was discussion
of Vincent's proposal to rewrite the draft to use the
application/directory MIME type as the standard format.
ACTION: Vincent to revise the draft to reference the MIME
type draft, and post the revised draft to the list.
- LDAP API RFC 1823
Tim announced that informational RFC 1823 was available that
documented the University of Michigan LDAP API. The information
was presented to the group for informational purposes only,
though a short discussion ensued about the appropriateness of
doing API work in the IETF.
- LDAPv2 presentations and discussion
Dave Horvath of Chromatix gave a presentation on the US Navy's
work to produce a secure version of LDAP. The Navy's approach
was to implement MDAP (Minimal DAP - essentially full DAP
PDUs over some other transport mechanism) as extensions to
LDAP. Their implementation is called SLDAP (Secure LDAP), and
it supports strong authentication and end-to-end digital
signing of search operations and results.
Dave described how they produced a new Windows LDAP DLL that
implemented the protocol extensions and used the Fortezza
card for signing. The DLL approach means that existing Windows
LDAP clients can be used unmodified with the new DLL and still
receive the benefits of strong authentication and signed
operations.
Kevin Jordan gave a brief description of the extensions that
CDC has made to their implementation of LDAP to support some
X.500(93) operations. The extensions include the addition of
a ModifyDN operation, an operation to add a context prefix,
and the ability to set new operational parameters, such as
the dontUseCopy service control.
There were general apologies from the chair and several other
working group members because of the general lack of progress
made since the last meeting on the LDAPv2 document. More
promises were made for a draft by the next meeting.
ACTION: LDAPv2 volunteers to get cracking and produce a draft
by the next IETF.
- AOB
No other business was presented, so the group adjourned almost
on time, agreeing to meet again at the next IETF in Los Angeles.
