Subject: Unique identifiers for LDAP attributes

From: "David Chadwick" <[email-masked]>
Date: Thu, 13 Jul 2000 15:02:41 +0100

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: Mark Wahl <[email-masked]>
Date: Thu, 13 Jul 2000 09:57:22 -0500

FWIW there are a number of interesting problem areas for improving schema 
management in the directory.  For example, how to support schema which changes
over time, separating schema which is 'experimental' from 'recommended' in 
a single DIT, or publishing more hints of the DIT and schema structure to 
help clients.  I requested a BOF at the Pittsburgh IETF on Evolving LDAP 
Schema Entries, and I should find out within a few days whether the Area 
Directors have scheduled it.  Your issues might be a suitable topic for 
discussion at this BOF.

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 13 Jul 2000 08:00:58 -0700

At 03:02 PM 7/13/00 +0100, David Chadwick wrote:
>require OIDs to be defined for attribute types,

Which implies they cannot properly publish schema...
Which implies they must be read-only servers...

>and the LDAP spec 

RFC2251 recognizes that names are non-unique but requires servers
to use them.  This does seem quite odd.

>unique way of identifying attribute types.

Maybe then clients would actually discover (and make use) of
published schema...

I would support lifting the MUST use short names requirement.
This requirement is not needed to support interoperability and
hence, per RFC2119, it shouldn't be a MUST.

I would support stating that servers MUST use a non-ambiguous
identifier.  That is, they must either ensure that NAME of given
schema elements are non-ambiguous (with a subschema subentry)
or use OIDs.

---

From: "David Chadwick" <[email-masked]>
Date: Thu, 13 Jul 2000 18:00:43 +0100

Date sent:      	Thu, 13 Jul 2000 08:00:58 -0700
To:             	[email-masked]
From:           	"Kurt D. Zeilenga" <[email-masked]>
Subject:        	Re: Unique identifiers for LDAP attributes
Copies to:      	[email-masked]

> Which implies they cannot properly publish schema...

Correct

There is another interesting problem that you may be interested in 
related to the non-use of OIDs. The matching rule used to select a 
subschema definition is, wait for it....

 objectIdentifierFirstComponentMatch

Thus the client needs to know the OID of the schema definition it 
needs to selectively fetch it. But if LDAP never passes an OID to 
the client, how does the client know which subschema definition it 
needs? In order to solve this, it means we really need  a 
"nonUniqueStringSecondComponentMatch" matching rule to be 
defined for LDAP.

> Which implies they must be read-only servers...

Why? Sorry,  I dont follow this one. LDAP updates dont need to use 
OIDs.

--snip--
> schema elements are non-ambiguous (with a subschema subentry)

Sort of agree, however making NAME only unambiguous within a 
subschema subentry solves the problem for one administration, but 
not for interworking between domains. Thus NAME needs to 
globally unambiguous - which brings us full circle around to the 
problem that the Internet 2 guys are trying to solve. To my mind, 
OID is the only sensible way forward.

David

David Chadwick

---

From: "David Chadwick" <[email-masked]>
Date: Thu, 13 Jul 2000 18:00:45 +0100

Date forwarded: 	Thu, 13 Jul 2000 07:58:29 -0700 (PDT)
Date sent:      	Thu, 13 Jul 2000 09:57:22 -0500
From:           	Mark Wahl <[email-masked]>
Subject:        	Re: Unique identifiers for LDAP attributes
To:             	[email-masked]
Copies to:      	[email-masked]
Forwarded by:   	[email-masked]

> 
> FWIW there are a number of interesting problem areas for improving
> schema management in the directory.  For example, how to support
> schema which changes over time, separating schema which is
> 'experimental' from 'recommended' in a single DIT, or publishing more
> hints of the DIT and schema structure to help clients.  I requested a
> BOF at the Pittsburgh IETF on Evolving LDAP Schema Entries, 

was this fortunate timing on our parts, or pre-destination, or just 
plain old coincidence? Lets hope the ADs agree to your request

David

>and I
> should find out within a few days whether the Area Directors have
> scheduled it.  Your issues might be a suitable topic for discussion at
> this BOF.
> 

David Chadwick

---

From: Mark Wahl <[email-masked]>
Date: Thu, 13 Jul 2000 12:09:39 -0500

There was a presentation at the last IETF LDAPEXT meeting on schema updating 
issues.

---

From: Julio Sánchez Fernández <[email-masked]>
Date: Thu, 13 Jul 2000 19:19:50 +0200

RFC2251, section 3.2.2:

> A server
> which masters entries and permits clients to modify these entries
> MUST implement and provide access to these subschema entries,

Julio

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 13 Jul 2000 10:30:35 -0700

>Why? Sorry,  I dont follow this one. LDAP updates dont need to use 

RFC 2251, 3.2.2:
   A server which masters entries and permits clients to modify these entries
   MUST implement and provide access to these subschema entries, so that
   its clients may discover the attributes and object classes which are
   permitted to be present.

---

From: "David Chadwick" <[email-masked]>
Date: Thu, 13 Jul 2000 20:31:21 +0100

Date sent:      	Thu, 13 Jul 2000 10:30:35 -0700
To:             	[email-masked]
From:           	"Kurt D. Zeilenga" <[email-masked]>
Subject:        	Re: Unique identifiers for LDAP attributes
Copies to:      	[email-masked], [email-masked]

>    A server which masters entries and permits clients to modify these
>    entries MUST implement and provide access to these subschema
>    entries, so that its clients may discover the attributes and object
>    classes which are permitted to be present.

thanks, missed that bit
David

David Chadwick