[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: present IANA "directory system names" list (aka "short attribute names")
At 02:30 PM 12/19/00 -0800, Michael Helm wrote:
>What is the plan for this repository?
It is not clear what relationship this registry has to
LDAPv3 DNs. This registry establishes keywords which
may be used instead of attribute type OIDs only within
LDAPv2 DNs (RFC1779). Note that LDAPv2 does not allow
attribute type names to be used within a DN.
The RFC2253 specification is similar. It also relies on
a table to provide DN keywords, but describes them
as 'type name strings' and does not provide an IANA
registry for the these strings. However, like LDAPv2,
the specification is quite clear that attribute types
appearing in the table must be identified by the string
in the table and all other attribute types must be
identified by OID in dot-decimal form.
If RFC2253 were to be progressed without significant
change, the IANA registry established by RFC1779 would
be become historical as RFC2253 obsoletes RFC1779.
>Is there a need for this kind of thing in order to
>prevent some kind of interoperability problem due
>to collisions?
There is a need for implementations to agree on an
unambiguous representation of DNs which are intended
to be globally unique (like DNS, there might be multiple
globes but there is only one internationally recognized
globe).
Note that RFC2253, like RFC1779, offers no chance for
attribute type naming collisions as attribute types are
specified either by OID, which are globally unique,
or centrally managed set of keywords associated with
attribute types.
A problem which has been voiced is that many implementations
do not adhere to RFC2253, 2.3, restrictions for primarily
historical reasons. Per discussions at IETF#49, this
issue needs further list discussion. For this reason, I don't
intend to address this problem (as well as the RFC2253, Section
4. problem) in the next revision of this DN update draft
(which I should be able to submit within a day or two).
Kurt