Subject: Re: short names, in general (Re: Comment on I-D ACTION:draft-ietf-ldapbis-dn-08.txt)

From: "Timothy Hahn" <[email-masked]>
Date: Wed, 28 Aug 2002 13:36:53 -0400

Kurt,

I can't tell what others "want", but I do know that "overlapping attribute
type names" (and object class names for that matter), is very real
"deployment" problem.

Every vendor/directory exploiter has come up with some set of "mitigating"
approaches - most of them based on Microsoft's Active Directory attribute
naming recommendations (i.e. prefix the attribute name with "company-", use
something specific to product within that, etc.)  But these are by no means
administered and/or followed and/or enforced.

Object identifiers are "nice" in that they allow for uniqueness and
de-centralized administration/management.  But they're particularly poor
with respect to user-friendliness.

Yes, I've heard all the arguments about "what flows on the wire is not what
people have to see".  But for every "transformation" that's required or
implied, it puts just a bit more weight on the shoulders of the, so-called,
"lightweight" client.  Unfortunately, "client" implementations that are
fully "schema aware" are few and far between - if they exist at all.  Add
to the problem the "feature" that depending on the area of the "tree"
you're "in", the schema to use may be different.  At this point, "client"
code throws in the towel.  More often, the "client" is merely a "conduit"
to get at what's flowing on the wire.

I guess I'd like to see either schema element naming recommendations,
guidelines, or a IETF best practice on the subject, along with room left
open for the so-called "extendable table" to be extended with new values as
appropriate.  If this means IANA should maintain such a table, then so be
it.

Regards,
Tim Hahn

Internet: [email-masked]
Internal: Timothy Hahn/Endicott/IBM@IBMUS
phone: 919.224.1565     tie-line: 8/687.1565
fax: 919.224.2540

                      "Kurt D. Zeilenga"                                                                                                  
                      <[email-masked]>         To:       David Chadwick <[email-masked]>                                   
                      Sent by:                    cc:       [email-masked]                                                     
                      owner-ietf-ldapbis@O        Subject:  short names, in general (Re: Comment on I-D                                   
                      penLDAP.org                  ACTION:draft-ietf-ldapbis-dn-08.txt)                                                   

                      08/28/2002 01:07 PM                                                                                                 

At 08:13 AM 2002-08-28, David Chadwick wrote (in part):
>I would like 5.3 to be edited as follows
>
>5.3. Use of Other Names
>
>  Attribute type names are not unique unless recorded in an
>internationally agreed document (such as an IETF standard like this one)
>or registry (such as IANA).

No.  RFC 2251 says:
   Attribute type textual names are non-unique, as two different
   specifications (neither in standards track RFCs) may choose the same
   name.

This means that there cannot be two "foo" on the Standard Track.
But there can be a "foo" on the Standard Track and multiple "foo"s
defined otherwise.

We'd actually have to mandate that only registered short names
(and private use names, e.g. x-name) be used in LDAP to eliminate
the possibility that a future registered name doesn't conflict
with preexisting names.

Is that what you want?  What do others think?

Kurt

---

From: Michael Ströder <[email-masked]>
Date: Thu, 29 Aug 2002 18:13:34 +0200

> with respect to user-friendliness.

And especially there's not always a user-friendly name available.

> "lightweight" client.

Never expected anybody here to make such a true statement!

I had hell of a time implementing schema support in recent 
web2ldap preserving user-friendly presentation, stick to local 
schema, resolve ambigous naming if possible, optional definitions, 
seriously flawed schema definitions and incomplete schema 
references in recent server products, abused OIDs, presenting 
short names vs. OIDs....... and all of that with reasonable 
performance.

<rant>
Frankly, if I would tell my customers what they have to consider 
when implementing a really LDAPv3 compliant application also 
interoperable with recent LDAP server products they would laugh at 
me and do not pay attention to LDAP anymore.
</rant>

>  Unfortunately, "client" implementations that are
> fully "schema aware" are few and far between - if they exist at all.

Feel free to check it out. It's not complete yet regarding syntax 
handling.

http://sites.inka.de:8002/web2ldap

Directly jump into browsing schema of e.g OpenLDAP's demo server:

http://sites.inka.de:8002/web2ldap/oid?ldap://ldap.openldap.org/dc=openldap,dc=org

>  Add
> code throws in the towel.

My client always requests the subschemaSubentry attribute for each 
DN. A reasonable performance is achieved by maintaining an entry 
-> subschemaSubentry cache and maintaining a cache of parsed 
schema data strutures.

BTW: Most of the default installations of other LDAP servers have 
around 200-400 kBytes of rarely needed but pre-installed bloat in 
it. LDAP server vendors, please create admin tools for your server 
product which encourages directory admins to select a sub-set of 
schema definitions needed for the data they want to store.

Ciao, Michael.

---

From: Michael Ströder <[email-masked]>
Date: Thu, 29 Aug 2002 22:10:36 +0200

> code throws in the towel.

Add to the problem that sub schema sub entry also might be subject to 
access control => cached sub schema sub entry data must be tied to a 
bind DN.

Ciao, Michael.