Sent by: owner-ietf-ldapbis@OpenLDAP.org
To: "Jim Sermersheim" <jimse@novell.com>
cc: <ietf-ldapbis@OpenLDAP.org>, Timothy Hahn/Endicott/IBM@IBMUS
Subject: Re: some outstanding items for clarification
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