Subject: Re: some outstanding items for clarification

From: "Timothy Hahn" <[email-masked]>
Date: Fri, 22 Dec 2000 09:37:01 -0500

Jim and Kurt,

Thanks for the clarifications.  As long as we're all comfortable that the 
revised RFCs are clear enough that these things are allowed, then I'm 
happy.

Regards,
Tim Hahn

Internet: [email-masked]
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681

Sent by:        [email-masked]
To:     "Jim Sermersheim" <[email-masked]>
cc:     <[email-masked]>, 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" <[email-masked]> 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