some outstanding items for clarification

["Timothy Hahn" <hahnt@us.ibm.com>]

Greetings,

In reading the latest drafts I found the following items either not
specified or under-specified.  I believe that these were not adequately
covered in RFC 2251-2256 and since we're looking to move these forward in
this group, I would like to see clarifications on these with the goal of
better interoperability across implemenatations.

1) Null attribute values.  Some implementations are known to accept
zero-length values for attributes.  I found no information in the RFCs or
drafts that dis-allows this.  Could someone clarify whether the LDAP data
model allows zero-length attribute values?

2) Some implementations always "publish" schema at "cn=schema".  Right or
wrong, some applications have assumed that there will always be a subschema
entry in every server named "cn=schema".  My interpretation of the RFCs and
drafts is that "publishing schema" at a "fixed" DN is NOT required and
should not be relied upon by clients.  I assert that we should not disallow
publishing schema at a subschema entry named "cn=schema" - but it should
not be required either.

3) The RFCs do not mandate an objectclass for the root DSE.  With the
revisions being done by this group, should we take the time to create an
object class for the root DSE and use the new subentry object class as
well?  This would allow an organized approach to be used when adding
information to the root DSE (i.e. create an auxiliary object class with the
added attributes).

4) In draft-zeilenga-ldapbis-rfc2253-01.txt, I would like to see a note
regarding the use of caseExactMatch attribute types in distinguished names.
Historically, distinguished names have been made up of attributes that only
contain attribute types that are caseIgnore match.  A note indicating that
attribute types that are defined with caseExactMatch matching rule CAN be
used in distinguished names would be helpful to implementors.  Further, a
note regarding the equivalence of RDNs containing multiple attribute value
assertions (but in different orders) would be helpful as well.  This
information is inferrable from the X.500 standards and the definition of
distinguishedNameMatch in the X.500 standards.  However, a clarification in
the LDAP RFCs would clarify this for LDAP servers.

Thanks,
Tim Hahn

Internet: hahnt@us.ibm.com
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681