Re: [ldapext] URN namespace for ldap/X.509 schema elements?

[Leif Johansson <leifj@it.su.se>]

RL 'Bob' Morgan wrote:
> > > 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.

I both agree and disagree. I agree that LDAP would have benefited from
using OIDs on the wire. Had that been the case I would not have
initiated this thread. However that is not the world we live in.
Short-names on the wire are a fact of life.

> 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 

That is a valid point but imo only representing a subset of the schema
elements in a given urn "arc" does not invalidate the idea itself. Those
groups who define schema not registered with IANA can just as easily
define and use private URN (or god forbid URI) namespaces for those
schema. Put another way: local use of schema implies local use of urn:s.

> 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?

Another valid point but equaliy valid for LDAP itself and we are able
to use LDAP anyway. In practice one of the aliases will be used, the
other less so.

> > 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 

Absolutely not! My application does not involve users directly in any
way. Introducing oids is quite possible but requires a separate mapping
(i.e the schema) to be maintained.

> 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 ...

You have some very good arguments. I would agree with you fully if it
weren't for the existence of the ldap-parameters IANA registry. Imo that
makes it useful (and 'cost efficient') to have these urn:s around.

>  - RL "Bob"

	MVH leifj

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext