[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: RFC2253bis: "a published table"

At 02:18 PM 11/1/00 -0500, hahnt@us.ibm.com wrote:

>Kurt, 
>
>If you are stating that attribute type names that are NOT in the table MUST NOT be used in DNs, rather, that the associated OBJECT IDENTIFIER be used, I think that this would break many existing implementations.

I am stating that I concur with Mark W as to the intended interpretation
of RFC 2253.  I note that this interpretation is consistent with RFC 1779
of which this I-D, when published as a Draft Standard, will obsolete.


>Further, it all but requires that LDAP "clients" hold onto a "name" <-> OID mapping table of their own in order to build "proper" DNs for communication over "the wire".

Basically, yes, all implementations of RFC 1779 and RFC 2253 (as
interpreted "as intended") would likely have such table.

>The OS/390 LDAP server has this issue today because it already supports multiple naming contexts, each of which is backed by a different data base implementation - and each implementation has its own, specific, schema.  We have found that the "subschemasubentry" attribute in the rootDSE, even though it is multi-valued, provides "ambiguous" data if multiple values are in that attribute - which value corresponds to which namingContext? 

Having a "table" avoid making DN construction dependent on the controlling
schema.  That is, the parent of entry indicated by the DN may be controlled
by a different schema than that of entry indicated by the DN.

>In the current OS/390 implmentation, the server "chooses" what, in general, is the "more complete" schema, in order to "normalize" incoming distinguished names and determine which "namingContext/database" the request is really destined for. 

I don't not believe DN generation should be dependent upon the
schema controlling the entry indicated by the DN:
        1) the DN may not refer to an entry or that entry may not
        be accessible by the client (or server),
        2) the client (or server) may not have access to the schema
        controlling the DN,
        2) a client (or server) cannot reliably obtain the schema
        controlling an entry without generating an LDAP DN

[Note that I say "or server" as the entry indicated by the DN
can be used in servers other than those which hold the entry).

I believe the table approach avoids all of these issues and staying
with it only breaks those implementations which didn't adhere to
the existing specifications (RFC 1779/RFC 2253).

>I would like to see the issues of multiple namingContexts and differing schemas between them addressed much better in follow-on work to RFC 2251.

I believe this needs to be addressed as well.  Preferably in
another thread.  Of quick note, you might read my (somewhat
dated) suggestions in this area: draft-zeilenga-ldapv3bis-rfc2251-00.txt.

Kurt