RE: DN "a published table" clarification

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

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: owner-ietf-ldapbis@OpenLDAP.org
[mailto:owner-ietf-ldapbis@OpenLDAP.org]On Behalf Of Kurt D. Zeilenga
Sent: Friday, December 22, 2000 12:03 PM
To: Salter, Thomas A
Cc: ietf-ldapbis@OpenLDAP.org
Subject: RE: DN "a published table" clarification


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?