Subject: DN "a published table" clarification

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 21 Dec 2000 14:54:52 -0800

I believe that RFC 2253, Section 2.3 was unclear when it
referred to "a published table".  I fully concur with Mark
Wahl's 11/1/2000 post that the table being referred to is
the table published within the section.  In the revision DN
I-D, I offer a clarification to this effect.  If others
believe RFC2253 was actually referring to some other table,
please speak up.  The type name string restrictions remains
as specified in RFC2253, 2.3.

I acknowledge that many, but not all, implementations generate
DNs which is not allowed by RFC2253 (when using LDAPv3) and/or
RFC1779 (when using RFC1779).  However, unless there is specific
lack of completeness or clarity or technical weakness of within
the specification which someone can point out, I cannot offer
any edit.

Kurt

---

From: "Salter, Thomas A" <[email-masked]>
Date: Fri, 22 Dec 2000 09:24:59 -0500

Well, I interpret it differently.

RFC2253, 2.3 says,

"If the AttributeType is in a published table of attribute types associated
with LDAP [4], ...".

I take that to mean the table is the entire reference [4], namely RFC2252.
Thus the names for all attributes defined in RFC2252 can be used.

The table in section 2.3 is introduced as,
 "As an example, strings for a few of the attribute types frequently seen in
RDNs include:"

The table is clearly identified as an example, not as an exhaustive list of
all allowed attribute names.

 > -----Original Message-----
 > From: Kurt D. Zeilenga [mailto:[email-masked]]
 > Sent: Thursday, December 21, 2000 5:55 PM
 > To: [email-masked]
 > Subject: DN "a published table" clarification
 > 
 >

---

From: "Salter, Thomas A" <[email-masked]>
Date: Fri, 22 Dec 2000 13:07:19 -0600

I agree that the attributes in 2252 are uninteresting as naming attributes.

I think the exhaustive list should be any attribute (or perhaps any
attribute with DirectoryString syntax) defined in the schema.  What is the
rationale behind limiting naming attributes to such a very small list?

(Back in v2, the names in this table didn't even match attribute names.  The
v3 definition sorted out issues like "cn" and "commonName" both identifying
the same attribute.)

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 22 Dec 2000 12:04:31 -0800

At 01:07 PM 12/22/00 -0600, Salter, Thomas A wrote:
>attribute with DirectoryString syntax) defined in the schema.

Which schema?

DN generation should not require schema discovery as schema
discovery requires DN generation.

>What is the rationale behind limiting naming attributes to such a very small list?

To provide an unambiguous string representation of a distinguished
name which can be encoded and decoded with ease.

>(Back in v2, the names in this table didn't even match attribute names.

Yes, they were keywords.  In v3, one can also view the attribute type
name strings provided in the table as being independent of the
attribute type short names provided in schema.  Where as the schema
can be extended such that commonName is recognized not only be the
short name "cn" but other names (such as "commonName" and "cname"),
but RFC2253 requires that the name "CN" be used for this attribute
type in the DN representation.

>The

No. The v3 DN spec says you must use "CN" for commonName.

---

From: "Timothy Hahn" <[email-masked]>
Date: Wed, 27 Dec 2000 07:10:41 -0500

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: [email-masked]
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681

Sent by:        [email-masked]
To:     "Ryan Moats" <[email-masked]>
cc:     "Salter, Thomas A" <[email-masked]>, <[email-masked]> 
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