Subject: Required OIDs in DNs

From: Hallvard B Furuseth <[email-masked]>
Date: Fri, 15 Nov 2002 23:05:33 +0100

As you may have realized, I've finally noticed that the LDAP standard is
being updated:-) I suppose I'm beating a dead horse here, but could
someone explain the points below or point me to an explanation?

Why were DNs changed to require numeric OIDs instead of names for other
attribute types than those in the table in [LDAPDN] paragraph 2.3?  I
have read some of the discussions on the mailinglist but I still don't
understand.

- The same name can have different OIDs in different servers:
OK, but that does not apply to the attributes in [SCHEMA].  Why
not allow all attributes defined there, at least?

- The attributes could have different syntax on different servers:
That still doesn't apply to those in [SCHEMA].  userCertificate was used
as an example, was that because it has been removed from [SCHEMA]?  Or
if there is some other reason which could happen because a syntax might
not be implemented in both servers or something, how about restricting
the list to attributes with EQUALITY match caseIgnoreMatch or
caseIgnoreIA5Match?  Then both client and server could compare string-
encoded DNs as if they were UTF-8 strings without knowing the syntax.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 15 Nov 2002 16:27:48 -0800

Presently, we're exploring whether or not it would be possible
to use a registry approach instead of a static table approach.

If the registry approach doesn't work out, we might want to
consider other static table approaches... but, for now, I
rather focus on determining whether the registry approach
is workable.

While I'm going to duck your specific static table
suggestions, I do have a few general comments to make.

>attribute types than those in the table in [LDAPDN] paragraph 2.3? 

In my view, [LDAPDN] is not significantly different from
[RFC2253].  We've clarified that the "published table" is
the table is published in the specification.

Obviously, we have many DNs in use which don't conform to
this clarified specification.  And, so, the issue becomes,
how do we change [LDAPDN] so not to invalidate too many in
use DNs while continuing to preserve the DN properties
necessary to support Internet-scale directory service.

Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Sat, 16 Nov 2002 13:28:35 +0100

Thanks.

-- 
Hallvard