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

From: Leif Johansson <[email-masked]>
Date: Fri, 22 Apr 2005 13:49:03 +0200

Does anyone know if such a beast exists? What I would
like is a URN namespace (other than the oid namespace)
containing all (names of) ldap schema elements, possibly
limited to those published in RFCs.

My application is Roland Hedbergs meta-directory framework
which uses RDF as the intermediary data format.

The urn:ietf:param namespace doesn't seem to fit the bill
since schemas don't live in IANA registries.

	Cheers Leif

_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Fri, 22 Apr 2005 08:55:48 -0700 (PDT)

We confronted this question when considering a convention for 
representation of X.500/LDAP attributes as SAML Attributes, and decided on 
using the OID URN namespace.  See section 8.2 of the SAML 2.0 Profiles 
spec,

   http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf

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

  - RL "Bob"

---

From: Leif Johansson <[email-masked]>
Date: Fri, 22 Apr 2005 21:43:44 +0200

RL 'Bob' Morgan wrote:
> representation of X.500/LDAP attributes as SAML Attributes, and decided 
> on using the OID URN namespace.  See section 8.2 of the SAML 2.0 
> Profiles spec,
> 

Good reference, thanks.

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

Using urn:oid forces clients to be schema-aware which has good and bad
side-effects.

	MVH leifj

---

From: Leif Johansson <[email-masked]>
Date: Fri, 22 Apr 2005 22:15:39 +0200

Kurt D. Zeilenga wrote:
> At 04:49 AM 4/22/2005, Leif Johansson wrote:
> 
> But the object identifier descriptors (short names) are registered.
> See <http://www.iana.org/assignments/ldap-parameters>.
> 

Thanks Kurt! I guess that means that

urn:ietf:params:ldap-parameters:object-identifier-descriptors:A:mail

(or something along those lines) could exists but the specification
for the ldap-parameters registry URN would have to be written up as
and RFC as per 3553?

	MVH leifj

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 22 Apr 2005 12:59:53 -0700

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 22 Apr 2005 13:32:41 -0700

>for the ldap-parameters registry URN would have to be written up as

Might make a good appendix for BCP64bis.  You might
take this up with LDAPBIS.

Kurt

---

From: Leif Johansson <[email-masked]>
Date: Fri, 22 Apr 2005 23:15:53 +0200

> take this up with LDAPBIS.

Good idea. I will.

	MVH leifj

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Fri, 22 Apr 2005 15:56:25 -0700 (PDT)

> the need for a separate registry if only schema elements published in

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

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"

---

From: Leif Johansson <[email-masked]>
Date: Sat, 23 Apr 2005 11:36:20 +0200

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

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

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.

	MVH leifj

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Sat, 23 Apr 2005 23:43:02 -0700 (PDT)

> to use LDAP anyway. In practice one of the aliases will be used, the

The fact that with we live with this problem in LDAP certainly doesn't 
mean we would choose to recreate the problem in a new space.  In fact it 
means that we learn from our mistake and choose not to recreate the 
problem in the new space.

>> to splat those URNs in front of users (which I assume is what you 
>

Then I really don't understand what you mean by this point.  If there are 
no users involved then what could be the difference between

   urn:oid:2.5.6.2

and

   urn:ietf:param:ldap-parameters:objectidentifierdescriptors:country

as they're both just strings that identify an attribute type?  Why does 
one require some sort of mapping and the other not?

  - RL "Bob"

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 24 Apr 2005 04:43:17 -0700

At 11:43 PM 4/23/2005, RL 'Bob' Morgan wrote:
>Then I really don't understand what you mean by this point.  If there are no users involved then what could be the difference between
>
>  urn:oid:2.5.6.2
>
>and
>
>as they're both just strings that identify an attribute type?

Because some implementations are too stupid to map
'2.5.6.2' to 'country' (or vice versa).

Kurt

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Sun, 24 Apr 2005 22:27:42 -0700 (PDT)

On Sun, 24 Apr 2005, Kurt D. Zeilenga wrote:

> Because some implementations are too stupid to map '2.5.6.2' to 
> 'country' (or vice versa).

But *why* does an implementation have to map 2.5.6.2 to anything at all, 
if there are (as Leif said) no end-users who might want to see the string 
"country" (or the appropriate string in their preferred language)?  Y'all 
seem to be assuming that the native representation of attribute type names 
in implementations is the descriptors.

  - RL "Bob"

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 24 Apr 2005 22:34:49 -0700

At 10:27 PM 4/24/2005, RL 'Bob' Morgan wrote:
>>Because some implementations are too stupid to map '2.5.6.2' to 'country' (or vice versa).
>
>But *why* does an implementation have to map 2.5.6.2 to anything at all, if there are (as Leif said) no end-users who might want to see the string "country" (or the appropriate string in their preferred language)?  Y'all seem to be assuming that the native representation of attribute type names in implementations is the descriptors.

Because in some implementations, this is the case.  Hence,
in other implementations, if they don't map, they don't get
what they expect.  That is, asking for return of '2.5.6.2'
may not cause values of the 'country' attribute to be
returned because the server might not regard 2.5.6.2 and
'country' as being equivalent.

Kurt

---

From: Leif Johansson <[email-masked]>
Date: Mon, 25 Apr 2005 09:40:38 +0200

> Then I really don't understand what you mean by this point.  If there 
> are no users involved then what could be the difference between
> 
>   urn:oid:2.5.6.2
> 
> and
> 

I can do $e->get_value((split /':'/,$urn)[5])

	MVH leifj

---

From: Leif Johansson <[email-masked]>
Date: Mon, 25 Apr 2005 09:42:41 +0200

> 'country' as being equivalent.

In fact I know of no ldap-libraries that does this... (or maybe I just
don't know my ldap libraries :-) )

	MVH leifj