ldapbis meeting notes
IETF 57, Vienna, Austria
2003-07-15
submitted by:  RL "Bob" Morgan


The co-chairs, Kurt Zeilenga and RL 'Bob' Morgan, called the meeting to 
order at 14:15.


Kurt noted that the WG charter has been updated to reflect current plans, 
which call for all remaining documents to go through WG Last Call in 
July/August, and (assuming consensus) for revised documents to be 
submitted to the IESG by September.  It is expected that the WG will not 
need to meet at IETF in Minneapolis.


Jim Sermersheim spoke about the protocol document.  The "attribute 
descriptor length" issue has received much discussion on the WG list, and 
was discussed at length at this meeting.


Ted Hardie, the WG's Area Director, spoke for ("channeled") Chris Apple, 
saying that the issue is that designers of LDAP-based applications and 
schema need interoperable LDAP implementations to support them, and need to 
know what limits they can design to.  


Kurt responded that there are two separable issues.  One, the one that 
started the email thread, is that an implementation was observed to 
truncate short names; this is just a bad implementation, it may be useful to 
clarify the doc to make it clear this isn't permitted.  The other is that 
LDAP can be used in many contexts, so not all features are required or 
appropriate for all contexts.  Applicability statements are the IETF 
documents that say which features are required for particular 
applications.


Rick Huber observed that the problem is a protocol 
interoperability problem, hence should be addressed by the protocol spec.  
John Strassner observed that lots of schema designers are writing schema 
with long attribute descriptors (names), and are depending on 
implementations supporting this.  Kurt observed that other 
requirements like matching rules will lead to a need for 
application-specific AS.


Ted said applicability statements would be fine, and suggested a "basic" one 
on which variations can be based.


Leif Johansson asked if implementation-specific limits need to be 
discoverable?  Ted said that would follow but isn't necessary.


Rick observed that requiring an application statement per app is a lot of 
work for app developers.  Kurt said it might be feasible to define a 
"general-purpose" LDAP AS, but might be hard to get consensus.


Ted said it seems byzantine to have protocol limits defined 
separately from the protocol.  Kurt responded that it seems 
inappropriate to clutter a general-purpose protocol spec with 
considerations of only one application scenario.


It was observed that this discussion needs to move back to the mailing 
list.


Jim requested that people look at the protocols and models documents 
together for potential overlaps or gaps.  He also encouraged a review of the 
use of MUST/SHOULD/MAY in the docs.


Kurt said that since it now appears that our documents will have to be 
again at Proposed Standard level, interoperability reports can wait until 
after this, when we prepare to go to Draft Standard.


Vithalprasad Gaitonde presented for Roger Harrison regarding the 
authmeth document.  Draft -06 was produced.  It lists various fixes since 
the previous version in its appendix.  Some issues were discussed.


Is password protection needed regardless of the use of authzid?


Is the SASL PLAIN method prohibited in LDAP?  No, just "not typically 
used".


In the TLS server name check function, should the use of the CN RDN in the 
Subject DN to hold the server DNS hostname be documented?  RL "Bob" 
observed that other app-TLS specs have not done this, even though the 
method is commonly used, because it is such a clumsy mechanism.


Must the SASL EXTERNAL operation immediately follow completion of 
STARTTLS?  No, the first operation after STARTTLS should be another check of 
server capabilities.  The TLS-complete-but-not-bound state may not be in the 
authentication state diagram.


Use of derived DNS names OK in the TLS server name check function?  RL 
"Bob" said that this would be a change from the current RFC, but is 
consistent with the original intent.


It was observed that the description of DIGEST authentication in the 
authmeth doc is too detailed, and may conflict with other specs, so it was 
suggested to modify it to reduce this.


Kurt wrapped up the session by noting that once all documents have been 
through Last Call, there will be a Last Call on the Roadmap document and one 
more pass over the whole document set for consistency.


The session concluded at