Subject: RE: Unique identifiers for LDAP attributes

From: "Ramsay, Ron" <[email-masked]>
Date: Fri, 14 Jul 2000 14:42:36 +1000

David,

I agree with the philosophy. However, there may be a middle course. Where
the attribute has been standardised by appearing in an IETF standard, the
name used in the standard could be considered standardised. For all other
attributes, an OID is required. There may be other publication methods which
can standardise attribute names, eg informational RFCs.

Ron.

-----Original Message-----
From: David Chadwick [mailto:[email-masked]]
Sent: Friday, 14 July 2000 0:03
To: [email-masked]
Subject: Unique identifiers for LDAP attributes

Folks

I was at a Middleware meeting a few weeks ago where some guys 
from Internet 2 were talking about outstanding problems with LDAP. 
One of the points raised was the lack of a unique name for attribute 
types, and that two LDAP servers could have the same name for 
different attributes or different names for the same attribute. They 
were wanting to create a group that could standardise on the 
names of LDAP attribute types. When I pointed out to them that we 
already have unique identifiers for each attribute type in the shape 
of OIDs, that do not have the multilingual and character set 
problems that strings have, they seemed convinced that this could 
work.

However, we have the situation that some LDAP servers do not 
require OIDs to be defined for attribute types, and the LDAP spec 
deprecates the use of OIDs in protocol in preference to strings.

Given that many LDAP clients now map the attribute type strings 
from protocol into a user friendly language dependent display string, 
the string representation in protocol has about had its day and 
served its purpose. Isnt it about time that we altered the LDAP 
spec to recommend that OIDs be the preferred way of transferring 
attribute types in protocol, and that the OIDs become the globally 
unique way of identifying attribute types.

(Firewalls up to protect from flames)

David

***************************************************

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351  Fax +44 161 745 8169
Mobile +44 790 167 0359
Email [email-masked]
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************

---

From: "David Chadwick" <[email-masked]>
Date: Fri, 14 Jul 2000 13:15:39 +0100

Date forwarded: 	Thu, 13 Jul 2000 21:42:39 -0700 (PDT)
From:           	"Ramsay, Ron" <[email-masked]>
To:             	[email-masked], [email-masked]
Subject:        	RE: Unique identifiers for LDAP attributes
Date sent:      	Fri, 14 Jul 2000 14:42:36 +1000
Forwarded by:   	[email-masked]

> David,
> 
> I agree with the philosophy. However, there may be a middle course.

true

> Where the attribute has been standardised by appearing in an IETF
> standard,

or other recognised standard (e.g. ITU-T or EN etc)

> the name used in the standard could be considered
> standardised. For all other attributes, an OID is required. There may
> be other publication methods which can standardise attribute names, eg
> informational RFCs.

not informational, I think they would need to be standards track, but 
minor point

David

> from Internet 2 were talking about outstanding problems with LDAP. One
> of the points raised was the lack of a unique name for attribute
> were wanting to create a group that could standardise on the names of
> LDAP attribute types. When I pointed out to them that we already have
> unique identifiers for each attribute type in the shape of OIDs, that
> do not have the multilingual and character set problems that strings
> have, they seemed convinced that this could work.
> 
> the string representation in protocol has about had its day and served
> its purpose. Isnt it about time that we altered the LDAP spec to
> recommend that OIDs be the preferred way of transferring attribute
> types in protocol, and that the OIDs become the globally unique way of
> identifying attribute types.
> 

David Chadwick

---

From: Mark Wahl <[email-masked]>
Date: Fri, 14 Jul 2000 10:31:06 -0500

Its RFC 2252 section 4.2:

>   Schema developers MUST NOT create attribute definitions whose names
>   conflict with attributes defined for use with LDAP in existing
>   standards-track RFCs.

Mark Wahl, Directory Architect, Service Provider/Infrastructure
Sun Microsystems, Inc. iPlanet Alliance

---

From: "Steven Legg" <[email-masked]>
Date: Mon, 17 Jul 2000 13:32:31 +1000

Mark,

> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Mark Wahl
> Sent: Saturday, 15 July 2000 1:31
> To: [email-masked]
> Cc: [email-masked]; Ramsay, Ron
> Subject: Re: Unique identifiers for LDAP attributes
> 
> 
> 

The problem is not that schema designers are using standard defined
attribute names in new definitions but rather that schema
designers are unwittingly using the same names in new definitions
where those new definitions are different (different OIDs or different
syntaxes or different equality matching, etc). And there is no
guarantee that an unused attribute name I choose today isn't going to be
commandeered by some future standard.

Regards,
Steven
Adacel Technologies

---

From: "Steven Legg" <[email-masked]>
Date: Mon, 17 Jul 2000 14:23:17 +1000

Ron,

We have customers with 100+ locally defined attribute types in their
schemas so most of the attribute types would be flowing back and forth
as OIDs under the "middle course". This doesn't look substantially
different to me than deprecating the use of type names for all attribute
types, even the standard ones. If a significant number of attributes
are known only by OID then they might as well all be.

A creeping list of recognized attribute names sounds like more trouble
than if we just fixed the list of attribute names as they stand now.

Regards,
Steven

> From: Ramsay, Ron [mailto:[email-masked]]
> Sent: Friday, 14 July 2000 14:43
> To: [email-masked]; [email-masked]