RE: DN "a published table" clarification

["Timothy Hahn" <hahnt@us.ibm.com>]

Kurt,

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

You probably won't care for this idea, but I will put it here anyway just in case :-)

You have asserted in the past that any approach that relies upon schema discovery has a "catch-22" problem.  I don't quite understand this - as long as the names of the namingContext values and subschemasubentry(ies) values are built from attributes of a more limited set, why couldn't we use a root DSE search to locate namingContext values, then a base search to locate the subschemasubentry value, then, with the schema discovered, be able to handle attribute in DNs that are defined by the schema?

>One approach might be to add to the end of 2.3.
>
>  Note: A closed deployments of LDAP [1] MAY prescribe an
>    alternative table of attribute type name strings
>    to be used a local string representation of the
>    distinguished names.  This specifications do not
>    ensure the interoperability of local string
>    representations nor that a particular local string
>    unambiguously represents a distinguished name nor
>    does this specification detail security considerations
>    related to the use of alternative tables.
>    The use of alternative tables is NOT RECOMMENDED.
>
>Note that I offer this without any opinion (yet) as to
>its appropriateness for inclusion in the I-D.

If no other alternatives can be agreed to, I am comfortable with the statement above bein added to the draft.  At least there will be some way to allow other attribute type names to be used in DN strings.

Regards,
Tim Hahn

Internet: hahnt@us.ibm.com
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681

Sent by:        owner-ietf-ldapbis@OpenLDAP.org

To:        "Ryan Moats" <rmoats@coreon.net>
cc:        "Salter, Thomas A" <Thomas.Salter@unisys.com>, <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