Editor's Note: These minutes have not been edited.
Access and Searching of Internet Directories WG Meeting
Meeting Minutes
Wednesday, April 9, 1545-1800, 2000-2100
Reported by: Tim Howes and Patrik Faltstrom
- Introduction of new co-chair
Patrik Faltstrom was welcomed as the new co-chair of ASID.
- Agenda review/changes
The proposed agenda was accepted without change.
- Hour 1 1545-1700: LDAPv3 core documents
The following documents were discussed, with the goal of
making any minor changes needed, issuing a last call, and
putting the documents forward for proposed standards status.
There was some discussion of the master/slave designation
added to the LDAP url draft draft-ietf-asid-ldapv3-url-00.txt.
The group felt that this was not a good thing, in the
absence of a replication model, and since it did not fit
well into the general URL concept.
ACTION: Tim to revise the URL draft to remove this feature.
There were no revisions proposed to the filter draft
draft-ietf-asid-ldapv3-filter-00.txt.
Chris Newman commented that the string dn format draft
draft-ietf-asid-ldapv3-dn-00.txt needed some revision
of its ABNF.
ACTION: Chris to send proposed ABNF revisions to Mark (DONE).
ACTION: Mark to produce a new DN draft.
The following comments were made on the attributes draft
draft-ietf-asid-ldapv3-attributes-04.txt. The draft needs a
keyword index, to make it easier to find things. The keyword
index, though thought generally useful, was not a must-have at
this time. The userPassword syntax should be deprecated and
discussed in the security considerations section. The audio
syntax, which currently refers to the "SunOS 4.x format" should
either be updated to reference audio/basic, or removed.
ACTION: Mark to produce a new attributes draft with these
changes incorporated.
There was a fair amount of discussion on the protocol draft
draft-ietf-asid-ldapv3-protocol-04.txt. Most of the discussion
centered around the use of SASL in the document and whether
it was correct. The following concensus was arrived at:
- The SASL credentials should be OPTIONAL
- No SASL mechanism name should be included on the BindResponse
- Some language was needed advising that changing the SASL
authentication layer during an LDAP session is allowed, but
changing the SASL security layer is not allowed.
An additional point was raised by Nick Emery about the handling
of unknown filter components in searches. The current draft
says such components are to be treated as though they match no
entries. This leads to the undesirable result that a filter
searching for (!(unknown component)) returns all entries. After
some discussion, the group agreed to adopt the tri-state logic
used by X.500.
Jeff Hodges suggested a number of clarifications in the text
describing subschema subentries and extensible matching.
Another discussion topic involved the lack of protocol
encoding examples in the draft. Examples of on-the-wire
client/server interactions were thought to be very useful,
and a pretty standard part of many other Internet protocol
specifications.
Mark Wahl stated that he is working on a separate document
explaining the basics of BER encoding needed by LDAP. This
document will contain somewhere between 8 and one hundred
examples. Since BER encoding is (unfortunately) more complicated
than many of the simple text encodings used by other protocols,
a separate document (or perhaps appendix to the protocol
document) was thought to be the best approach.
To avoid holding back LDAPv3 at this time, the group agreed
that the document should go forward, with examples being
added when the document goes from proposed to draft.
The group also discussed the fact that the LDAPv3 drafts
referenced the SSL specification, which is not an Internet
standard. The group agreed that the goal is to reference
the TLS specification when it becomes available. The status
of TLS was not known, but it was thought that it should be
moving forward soon. The group agreed to change the LDAPv3
reference to TLS in anticipation of the TLS specification
being progressed along with LDAPv3.
There was further discussion of the relationship between
SASL and TLS, and that the lack of clarity on that relationship
is contributing to the slow progression of SASL. The group
agreed that this relationship should be clarified ASAP.
There was also discussion about the fact that the LDAP
documents reference the X.500 standard in many places,
and that X.500 is not freely available on the net. The
question was whether this would prevent the drafts from
progressing. Based on precedents set by SNMP and other
IETF work, the group did not feel this should be a problem.
ACTION: John Myers to work with the security area director
and the TLS group to clarify the SASL and TLS specs.
ACTION: Mark to produce a new protocol draft with these
changes incorporated.
ACTION: Tim and Patrik to ensure that examples are included
before LDAPv3 goes to draft standard.
The group agreed that after the documents were revised
(estimated time to revise: 1 week), last call should be
issued on the ASID list. At the conclusion of a successful
ASID last call, the documents should be given to the
area directors for approval of the IESG.
ACTION: Tim and Patrik to issue last call to ASID on revised
documents.
ACTION: Tim and Patrik to request progression of the documents
pending successful ASID last call.
- Hour 2 1700-1800: MIME-DIR and WHOIS++
- WHOIS++ drafts
Patrik reported that new WHOIS++ drafts have been produced
with no protocol changes, only revisions and clarifications
from operational experience implementing the protocol.
One example of a such clarification is the addition of a
grammar for the output from a Whois++ server to the existing
grammar for the input to a Whois++ server.
The group agreed that a last call should be issued on the
revised documents, after which they should be put forward
for draft standard status.
ACTION: Patrik and Tim to issue last call on the revised
WHOIS++ documents and progress to the area directors.
- application/directory framework
There was much fruitful discussion of the application/directory
framework document. The first issue discussed was whether the
content-type should be changed to text/directory. The argument
for is that the information is primarily textual in nature and
the desired behavior is to have the content-type displayed to
users even if the type is unknown. After a brief struggle, the
group agreed to change the content-type to text/directory.
A more conetentious issue surrounded the use of the "lang"
parameter defined in the draft. The values of the "lang" parameter
are currently defined to be language tags from RFC 1766. Patrik
argued that an additional tag (he proposed calling it "default")
was needed to support the use of text/directory in WHOIS++.
The tag is needed so that applications (like WHOIS++) may
determine which (if any) attributes to return in the event
that the language requested by the client is not present.
After much debate, misunderstanding, and confusion, it was
decided not to add this to the spec. The argument was made
that 1) the default solution is not entirely correct, since
it does not also provide a way to determine the type of the
default language returned, and 2) the parameter set is already
extensible, so something could be defined later to solve
this problem.
The final issue discussed was the use of the "charset"
attribute parameter, allowing the character set to be set on
individual values within a text/directory content-type.
This was felt to be a Bad Thing and contrary to the MIME
way of doing things and contrary to the IAB character set
proclamation (thou shalt use UTF-8) by several people.
After a bit of debate, the group decided to remove the "charset"
attribute parameter and require the UTF-8 "charset" MIME header
parameter be specified by default on text/directory content-types.
The result of this is the loss of ability to switch charsets
on a per-value basis within a text/directory component, but
this was thought to be a good thing.
ACTION: Tim to produce a new MIME-DIR draft with the agreed
on changes.
ACTION: Tim and Patrik to progress the revised draft to the area
directors.
- vcard profile
One comment received prior to the meeting was the use of
English as the default language in the vCard profile. The
group agreed that this statement should be removed, and that
there should be no default language associated with the
vCard profile.
Two additions to the vCard profile had been proposed to the
ASID list by the MOPA consortium (Mobile Office Promotion
Association). The additions were for a CLASS attribute and a
PCS property on the TEL attribute.
The CLASS attribute would identify the class of the information
contained in the profile (e.g., PRIVATE or PUBLIC).
The PCS property would identify a TEL attribute as referring
to a PCS telephone.
The group considered these additions useful, but there was
some discussion of where we should draw the line before
putting vCard forward as a proposed standard. After a bit of
discussion, the group agreed to allow these two additions
and then progress the draft to proposed standard.
ACTION: Frank Dawson to revise the vCard draft with these
changes.
ACTION: Tim and Patrik to progress the revised draft to the area
directors.
- Hour 3 2000-2100: Various LDAP documents
This hour began with the daunting task of listing the 15
(count them 15) documents submitted for the group's consideration.
The documents were:
draft-ietf-asid-ldapv3-lang-00.txt
use of language codes in LDAPv3
draft-ietf-asid-ldapv3-strong-00.txt
SASL authentication mechanism for X.500 authentication
draft-ietf-asid-ldapv3schema-x500-00.txt
LDAPv3 definitions of X.500 schema
draft-ietf-asid-schema-pilot-00.txt
LDAPv3 definitions of pilot schema
draft-ietf-asid-ldapv3-simple-paged-01.txt
LDAPv3 extension for simple paged results
draft-ietf-asid-ldapv3ext-03.txt
LDAPv3 extension for dynamic directories
draft-ietf-asid-replica-selection-00.txt
How to use SRV records to select LDAP servers
draft-ietf-asid-ldapv3-sorting-00.txt
LDAPv3 extension for sorting results
draft-ietf-asid-ldapv3-referral-00.txt
referrals and knowledge references in LDAPv3
draft-ietf-asid-ldapv3-api-00.txt
Update of RFC 1823 for LDAPv3, etc.
*draft-ietf-asid-ldap-mult-mast-rep-00.txt
Multi-master replication proposal
*draft-ietf-asid-ldif-00.txt
LDAP text directory interchange format
*draft-ietf-asid-changelog-00.txt
LDAP text changelog format
draft-ietf-asid-email-routing-su-00.txt
draft-ietf-asid-email-routing-ns-00.txt
Two email routing using LDAP proposals
The group started by agreeing not to try and discuss
all the documents, but rather to spend the first part
of the meeting deciding what to discuss. The group first
decided that the two email routing documents were outside
the scope of ASID, so they were crossed off the list.
The group next decided that replication was the topic of most
interest, with replica selection a close second. So, discussion
began on replication with an attempt to answer three questions:
1) Should we be working on directory replication?
2) What group should do the work?
3) What should be the scope of the work?
There was much debate on these topics, mixed together with
debate about the future of the ASID group. The latter topic
was raised with the idea (put forward off-line by the area
directors) of splitting ASID into two groups: one for LDAP
and one for text directory stuff (WHOIS++, MIME-DIR, etc).
The group thought this was basically a good idea.
Debate on question 1) quickly consensized on a decision
that replication is definitely a problem that we should be
tackling.
Debate on question 2) was somewhat tangled up with the scope of
the work. Some people felt that replication was a big and
separable enough problem that a separate working group was
required. Others felt that replication would soon drag in other
problems (e.g., access control, schema) that really need to be
considered by the entire group. Consensus on this issue was
rough, at best, but the group seemed to be leaning towards
handling replication in ASID (or the as-yet-unformed LDAP
group), for the reasons given above.
Question 3) generated lots of discussion. The proposals
ranged from a general replication solution, to a general
LDAP-only solution, to an LDAP-only solution specific to
either multi-master or single-master models. There was much
concern that to make any progress we should try to focus
the problem as narrowly as possible. After much discussion,
the group consensificated that we should narrow our focus to
LDAP replication, and not try to solve the more general
problem.
After much further debate with little progress, the group
decided to switch gears and discuss one of the other documents.
The replica selection document was chosen. Paul Leach
described the draft briefly, which defines a method of locating
LDAP servers, given a domain name, based on SRV records. The
group thought the concept useful, but very similar to a general
procedure outlined in a draft from the DNS group for using
SRV records. The group agreed that Paul should talk to the
DNS group to ensure that they two documents did, in fact,
overlap, and that everything needed in Paul's document was
present in the DNS SRV record document.
ACTION: Paul Leach to follow-up with the DNS group.
ACTION: Tim and Patrik to chase the group-splitting issue
with the area directors.
- Any Other Business
Noting the lateness of hour, the general glazed look of the
participants, and the fact that another meeting's attendees
begain filing into the room, the ASID meeting concluded, about
on time.
The next ASID meeting will be in August in Munich, Germany.
