[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: [ldapext] URN namespace for ldap/X.509 schema elements?
Choosing to base URNs on anything other than OIDs seems to me to
inevitable lead to having to maintain a registry of such names, in
parallel with OID registries. I can't see anyone wanting to do that.
Is there some problem with using urn:oid: ?
I guess readability suffers a bit ;-) But seriously I don't understand
the need for a separate registry if only schema elements published in
RFC:s are handled...
The existence of the descriptor registry only proves my point, that using
a namespace other than urn:oid requires a registry. But this registry,
rather than being completely delegated and distributed, is centralized,
and requires "expert review" for new entries to be created. These are
among the reasons why the flat descriptor space is just a bad idea, as has
been discussed very often on ldap lists. The fact that we are stuck with
descriptors in LDAP doesn't mean we should adopt them for URN-based
attribute names, in fact it means we should learn from the experience and
stay far away from them.
Also, how could it possibly be useful to put into practice a URN space for
X.500/LDAP attribute types that excludes large numbers of already-defined
types (ie, those whose descriptors aren't registered with IANA)? If I
wanted to use my organizationally-assigned attribute types, I couldn't
until I registered them with IANA? In fact what people would do (and
we've seen this already with a one-off Internet2 URN space we made up for
this purpose) is use URNs of urn:ietf:param:ldap-parameters:foo without
registering the descriptor, resulting in collisions etc.
Another serious problem, the inverse of the one brought up by Michael
Liben, is (from RFC 3383):
Multiple names may be assigned to a given OID.
eg CN and commonName. If I'm sending this attribute, which
descriptor-based URN would I use? Do you really think it would be a "best
common practice" to promote the use of a URN space that defines multiple
names for the same thing?
Using urn:oid forces clients to be schema-aware which has good and bad
side-effects.
Choosing URNs based on the assumption that it's useful for clients simply
to splat those URNs in front of users (which I assume is what you would
mean by "not schema-aware") also seems like less than best practice. If
clients are simply using them as opaque identifiers and comparing against
values in tables etc, then it doesn't matter what they look like.
Perhaps I have made my position clear ...
- RL "Bob"
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext