Subject: RE: DN "a published table" clarification

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 22 Dec 2000 10:02:59 -0800

At 09:24 AM 12/22/00 -0500, Salter, Thomas A wrote:
>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.

I believe the reference is intended to provide a description of an
"attribute type associated with LDAP".

>Thus the names for all attributes defined in RFC2252 can be used.

The names of all attribute types defined in RFC2252 are:

  createTimeStamp, modifyTimeStamp, creatorsName, modifiersName,
  subschemaSubentry, objectClasses, matchingRules, matchingRuleUse,
  namingContexts, altServer, supportedExtension, supportedControl,
  supportedSASLMechanisms, supportedLDAPVersion, ldapSyntaxes,
  nameForms, ditStructureRules, and ditContentRules.

None of these attribute types are commonly used for naming.
The intersection with the 2.3 published table is null.

One could argue that the 2252 reference is meant to imply that
all attribute types of "section 5 of [12] (RFC2256)" are also
in the table.  As a direct reference was not made in RFC2252
to RFC2256, I do not believe can possibly be the case.  But
anyways, this argument would cause the following attributes to
be included in the table:

  objectclass, aliasedObjectName, knowledgeInformation, cn, sn,
  serialNumber, c, l, st, street, o, ou, title, description, searchGuide,
  businessCategory, postalAddress, postalCode, postOfficeBox,
  physicalDeliveryOfficeName, telephoneNumber, telexNumber,
  telexTerminalIdentifier, facismileTelephoneNumber, x121address,
  internationaliSDNNumber, registeredAddress, destinationIndicator,
  preferredDeliveryMethod, presentationAddress, supportedApplicationContext,
  member, owner, roleOccupant, seeAlso, userPassword, userCertificate,
  cACertificate, authorityRevocationList, certificateRevocationList,
  crossCertificatePair, name, givenName, initials, generationQualifier,
  x500UniqueIdentifier, dnQualifier, enhancedSearchGuide, 
  protocolInformation, distinguishedName, uniqueMember, houseIdentifier,
  supportedAlgorithms, deltaRevocationList, dmdName.

Note that the intersection with the table in 2.3 doesn't include
the complete set of attributes listed in the 2.3 table.  So even
this argument is weak.

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

Are you saying that the exhaustive list is all the attribute types names
listed above?

---

From: "Ryan Moats" <[email-masked]>
Date: Fri, 22 Dec 2000 12:36:58 -0600

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 mention this because folks seem to be concentrating on the table
only.

Ryan

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Kurt D. Zeilenga
Sent: Friday, December 22, 2000 12:03 PM
To: Salter, Thomas A
Cc: [email-masked]
Subject: RE: DN "a published table" clarification

---

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

>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

---

From: "Ryan Moats" <[email-masked]>
Date: Fri, 22 Dec 2000 14:41:49 -0600

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: [email-masked]
[mailto:[email-masked]]On Behalf Of Kurt D. Zeilenga
Sent: Friday, December 22, 2000 2:34 PM
To: Ryan Moats
Cc: Salter, Thomas A; [email-masked]
Subject: RE: DN "a published table" clarification

Kurt

Kurt

---

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

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.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 23 Dec 2000 10:02:18 -0800

>Can't I define naming rules in the schema?

You may.

>Once I define a naming rule haven't I extended the list
>implementation?

Yes.

Note that the DN specification fully supports use of
arbitrary naming attributes.  The question is not
which attributes may or may not be used in naming,
but how attributes which are used in naming are to
represented in the string

>Or are you going to take this

I am not sure I understand the approach... but if it
relies upon schema discovery or other information held
in a directory, it sounds like it has a catch-22 problem.

Kurt

---

From: "Ryan Moats" <[email-masked]>
Date: Tue, 26 Dec 2000 09:57:51 -0600

I THINK that works for me.  Of course, it follows that
interoperability needs to be verified.

Ryan

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Kurt D. Zeilenga
Sent: Friday, December 22, 2000 3:13 PM
To: [email-masked]
Subject: RE: DN "a published table" clarification (a solution?)

---

From: "Ryan Moats" <[email-masked]>
Date: Tue, 26 Dec 2000 10:00:45 -0600

One of my points in here is how will LDAPv3 in its
DS form deal with the whole naming rule, stucture rule and
content rule stuff.  If we keep them in the DS specs
(with implementation records) then I think I have my
escape clause as well.

As to my others, I seem to not have them in my head anymore,
but that' probably due to the cold that has taken up residence.

Ryan

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]]
Subject: RE: DN "a published table" clarification

You may.

Yes.

Kurt