[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