RE: DN "a published table" clarification

["Ryan Moats" <rmoats@coreon.net>]

Hmm let's try a different tack...

Can't I define naming rules in the schema?
[I'll leave off the question of interoperable
implementations of this until later] Once I
define a naming rule haven't I extended the list
of naming attribute types for my particular
implementation? Or are you going to take this
approach away as well under because it 
involves "schema discovery"?

Your point is well taken, but any DS document that
is useless to the non-white-pages world is a BAD THING,
and the current table list is definitely skewed to the
white-pages world.  Since LDAP and directories are
being used in more than just the white-pages world,
we should wake up to that fact.

Ryan

-----Original Message-----
From: owner-ietf-ldapbis@OpenLDAP.org
[mailto:owner-ietf-ldapbis@OpenLDAP.org]On Behalf Of Kurt D. Zeilenga
Sent: Friday, December 22, 2000 2:34 PM
To: Ryan Moats
Cc: Salter, Thomas A; ietf-ldapbis@OpenLDAP.org
Subject: RE: DN "a published table" clarification


At 12:36 PM 12/22/00 -0600, Ryan Moats wrote:
>I will repeat my assertion that "whatever" the final table becomes,
>if there isn't an escape clause to allow other attribute types
>to be specified as the RDN (and thus a example of two independent
>implementations that allow that), the whole concept is DOA because
>you are taking away functionality from folks who are using directories
>as well as hamstringing other working groups.

I will repeat my assertion any DN specification which does not
provide an unambiguous string representation of a distinguished
name which can be encoded and decoded with ease is DOA.

RFC 2253 and RFC 1779 place significant restrictions upon their
use of attribute type name strings because attribute type name
strings are, by their very nature, ambiguous.  Both of these
specifications rely on exhaustive published tables to ensure
the use of attribute type names does not result in an
unambiguous DN representation.  This approach is widely
believed to be sound.

There may be other approaches which are technically better.
If there is a better approach for providing unambiguous
string presentations, I would suggest that someone provide
a description of the approach.  In particular, the description
should state how provide for unambiguous use of attribute types
names.

Kurt

Kurt