Subject: re: draft-ietf-ids-dirnaming-03.txt

From: John_Dale/SSW/[email-masked]
Date: Sat, 27 Dec 1997 20:13:07 -0500

This note contains suggested clarifications to
draft-ietf-ids-dirnaming-03.txt.  I think the proposal is good and should
progress, with or without these clarifications.  Briefly, I'd like to see
it clarified that (1) there may be ou levels below the domainComponent
levels, and (2) that neither this plan nor  X.500 require that auxiliary
object classes be used to support this naming scheme.  I'd also like to see
this plan (3) define the X.500 name forms for country, organization, and
organizationalUnit entries named using domainComponent, and for
organizationalPerson entries named with uid.  This is because servers
following the X.500 model must use name forms to implement this scheme, and
having each server implementing this scheme use a different OID for the
name forms cannot be better than providing standard name form definition.
Detailed suggestions are appended.

Thanks for considering these.

John Dale

- - - - - - -

Changes to 1.0 Executive Summary

Add to end of third paragraph (which begins "The plan"): "The plan also
allows for the use of traditional X.500 naming at the leaf level, and in
the middle portions of the naming hierarchy (e.g., organizational unit)."

Add at end sixth paragraph (which beings "Organizations can add"), after
"dc=corporate, dc=acme, dc=com": Additional directory structure can also be
implemented using traditional X.521 naming, e.g., the domain "acme.com"
might contain the directory name "ou=corporate, dc=acme, dc=com" even if
there is no DNS subdomain "corporate.acme.com".

Add to the list of DNs at the end of section 1.0:
  uid=[email-masked], ou=IS, dc=acme, dc=com

Changes to 4.1 Domain Component

Add to end of fourth paragraph, which begins "The subordinates" and ends
"in section 5.2.": This plan does not require that any objects be named
using domainComponent.

Changes to 5.2 Directory Schema Implications

Modify the second paragraph to read:   "So as to continue to use existing
structural object classes to the extent possible, two new auxiliary object
classes are provided, dcObject and uidObject.  These object classes may be
useful, especially with servers that do not support the notion of DIT
content rules as defined by X.500-1993."

Replace the fifth paragraph, which beings "In a pure X.500 context" with

For X.500 servers or LDAP servers following the X.500 model, our schema
would require the definition of new name forms, structure rules, and DIT
content rules.  Structure rules and DIT content rules are locally defined,
and do not involve a globally significant object identifier.

The following name forms are defined:

( OID-TBD domainNameForm
 NAME domainComponent OC domain MUST dc )
( OID-TBD dcOrganizationNameForm
 NAME domainComponent OC organization MUST dc )
( OID-TBD dcOrganizationalUnitNameForm
 NAME domainComponent OC organizationalUnit MUST dc )
( OID-TBD uidOrganizationalPersonNameForm
 NAME uid OC organizationalPerson MUST uid )