Subject: RE: Unique identifiers for LDAP attributes

From: "Lloyd, Alan" <[email-masked]>
Date: Fri, 14 Jul 2000 01:15:03 +1000

David - as we know ... Thats why we had OIDs in the first place - isnt
it...ownership, organised registration, unique identification and the
ability to interpret for human users - eg language.. and managed under the
ISO/ITU..Not to mention the use of ASN.1 compilers that automate OID based
information processing code....

Mind you that is all too "complex"..eh...

When are you going to let the XML world know about ASN.1 and OIDs after all,
centre and center are similar but different arnt they..Now doubt the XML
world will hit this issue to.

Flames David - I doubt it...

regards alan

PS - are you sending the beer!

-----Original Message-----
From: David Chadwick [mailto:[email-masked]]
Sent: Friday, July 14, 2000 12:03 AM
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: Thu, 13 Jul 2000 18:57:43 +0100

> Though I agree with the general notion of moving toward the use of
> unique OIDs, there's a minor flaw with this statement.
> 
> objectIdentifierFirstComponentMatch uses the OID syntax which can
> either be a numericoid (1.2.3.4) or the descr form (cn), so it's still
> usable with short names as it stands today.

You have now hit on a bit of rfc2252 which is particularly hard to 
understand, viz:
From 8.1  
If the client supplies a filter using an 
objectIdentifierMatch whose
   matchValue oid is in the "descr" form, and the oid is 
not recognized
   by the server, then the filter is Undefined.

David

> Jim

David Chadwick

---

From: "Lloyd, Alan" <[email-masked]>
Date: Mon, 17 Jul 2000 16:18:32 +1000

I think the basic issue again comes down to discipline.. The OSI and OID
stuff was considered all too hard and long winded, registration, formality,
etc as opposed to quick fix - cut the code, see it works stuff..
X.500 defined 15 or so OCs and about 40 attributes as its base information
set... with OIDs  we all know that.

So where we (in the directory world) build systems for online customers we
go through the formal schema design processes and where required, OIDs
registration under our national bodies. Just to ensure these orgs who spend
a lot of money on these systems - we are always concened that commercial
work does not get  undermined by "an experimental document" out of
somewhere..

We cannot change history - but would should learn that the issue with
directories is not one of protocols - but one of information standardisation
and identification. Simply because commincation protocols can go through
gateways, but transforming information - is a real pain (synrax, semantic,
naming, etc.

If there are no engineering or doctrinal rules applied - how is it a
standards process?

XML will hit this issue .. but is anyone concerned?  XML - a simple
Ebusiness solution.. seen that before eh!

using OIDs means that the author and the standards organisation under which
they are registered are taking some care - it isnt perfect but it does mean
existing systems should not be compromised.

regards alan
-----Original Message-----
From: Steven Legg [mailto:[email-masked]]
Sent: Monday, July 17, 2000 1:33 PM
To: 'Mark Wahl'
Cc: [email-masked]
Subject: RE: Unique identifiers for LDAP attributes

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

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

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