Subject: Re: some outstanding items for clarification

From: "Jim Sermersheim" <[email-masked]>
Date: Thu, 21 Dec 2000 15:49:04 -0700

>>>> "Timothy Hahn" <[email-masked]> 12/12/00 6:33:32 AM >>>
>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?

My take is that this is generaly implicitly allowed (except where disallowed 
as in country), and explicitly called out in at least one case (namingContexts 
in 5.2.1.of 2252).

Unfortunately, LDAP doesn't have any way of conveying a minimum length 
(only a suggested max) in the schema for 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.

This is more of an education issue right? The specification doesn't mandate the 
name of the entry. I think one vendor chose cn=schema, and everyone else just 
followed. If I remember right, client writers that hard code to cn=schema will be 
dismayed when they try to run against OpenLDAP.

<snip>

I think the other topics are being/have been discussed in other threads

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 21 Dec 2000 15:15:51 -0800

>as in country), and explicitly called out in at least one case (namingContexts 

Whether or not a value may be empty is per syntax.
Note that the directoryString does not allow empty values
whereas octetString does.

>dismayed when they try to run against OpenLDAP.

It our intent to support multiple subschemas which requires
clients be able to discover schema by read the appropriate
subschemaSubentry value.  I specifically choose a different
DN so as to discourage hard coding within clients.

I don't believe there needs to be any clarification as to
where implementations may locate subschema entries (or
subentries).

However, I do note that the schema discovery section needs to
be revised in that the Root DSE subschema discover mechanism
is flawed (see my 2252 I-D for a suggested change, see LDAPext
archives for prior discussion).

Kurt