Re: some outstanding items for clarification

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 03:49 PM 12/21/00 -0700, Jim Sermersheim wrote:
>>>>> "Timothy Hahn" <hahnt@us.ibm.com> 12/12/00 6:33:32 AM >>>
>>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).

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

>>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.

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