RE: Last Call: Naming Plan for Internet Directory-Enabled Applic ations to Proposed Standard

Chris Weider <> Tue, 30 December 1997 01:08 UTC

Delivery-Date: Mon, 29 Dec 1997 20:08:32 -0500
Received: from (cnri []) by (8.8.7/8.8.7a) with ESMTP id UAA22122 for <>; Mon, 29 Dec 1997 20:08:30 -0500 (EST)
Received: from ( []) by (8.8.5/8.8.7a) with ESMTP id UAA02986 for <>; Mon, 29 Dec 1997 20:11:18 -0500 (EST)
Received: from ( []) by (8.8.7/8.8.7a) with ESMTP id UAA22119 for <>; Mon, 29 Dec 1997 20:08:28 -0500 (EST)
Received: by with Internet Mail Service (5.5.1960.3) id <ZSG9NJ9K>; Mon, 29 Dec 1997 17:08:30 -0800
Message-ID: <>
From: Chris Weider <>
To: "''" <>,
Subject: RE: Last Call: Naming Plan for Internet Directory-Enabled Applic ations to Proposed Standard
Date: Mon, 29 Dec 1997 17:08:28 -0800
X-Mailer: Internet Mail Service (5.5.1960.3)

I have to agree with Jeff here, and with some comments that Bruce Greenblatt
made in his earlier message to this list.

The current document (draft-ietf-ids-dirnaming-03.txt) really contains two
main threads: the use of DC= naming, and the suggestion that entry RDNs be
only cn or uid, with a specific format. Let's examine each of these

The use of the DC naming convention is a Good Thing. It allows more rapid
directory setup, somewhat easier navigation given certain types of starting
information, and leverages an existing unique name space (why should we have
two?). If anything should be kept out of this document in the absence of
requirements, this is it.

However, the second suggestion is much more problematic. As Jeff points out,
the requirements are fuzzy. Is it a requirement that we be able to locate an
entry from someone's email address? In which case, examples 2, 3, and 4 in
section 1.0 show that the authors expect this to be used in a way that
directly contradict this requirement. Is it a requirement that we help
administrators 'uniquify' their RDNs? Given most LDAP implementations, they
are forced to uniquify it, and no one way of uniquification is clearly
better than any other.

Taking out the RDN recommendation gives us a document that covers
requirements a, b, c, and d in section 4 (note that RFC 822 addresses do not
really constitute an 'existing Internet name registry' beyond their use of
DNS). Requirement e is where the fuzziness comes in: user-friendly *FOR
WHICH USES AND USERS?*. The examples are almost completely drawn from White
Pages (specifically human client) operations. And the examples are
completely in English, as well. Minimally useful public directories, even
for the types of applications listed above, may vary wildly depending on the
data available, the organizational restrictions on public exposure of data,
the expected user base, and so on. Just as a single example of how this can
go awry, which of my multiple email addresses should I use as my RDN?
Frankly, requirement e is content-free. And given that, why is the RDN
approach the optimal solution when you haven't even detailed how this is
supposed to be used?

Speaking from the vendor perspective, restricting my customer's ability to
pick their own naming techniques for RDNs needs to have a damn good payoff,
which I don't get from either this document or from any of the statements
the authors have made on the list. In my opinion, progressing the current
document as it stands will cause the document to be widely ignored. And
that's a shame, as I do think that the IETF needs to really get behind the
DC naming. I recommend that the document be split into a DC naming document
and an RDN document, and that we should really look carefully at the RDN
requirements in LSD or another appropriate group. 

> -----Original Message-----
> From:	Jeff.Hodges@Stanford.EDU [SMTP:Jeff.Hodges@Stanford.EDU]
> Sent:	Wednesday, December 24, 1997 4:49 PM
> To:
> Cc:
> Subject:	Re: Last Call: Naming Plan for Internet Directory-Enabled
> Applications to Proposed Standard
> I don't feel that draft-ietf-ids-dirnaming-03.txt should presently go
> forward 
> on the standards track because, as it is presently written, the
> requirements
> section (sec 3.0) is vague and not thoroughly presented -- thus the
> problem 
> space definition is fuzzy. Additionally, dirnaming-03.txt presents a
> specific
> solution to the problem space, built on top of the fuzzy requirements 
> analysis. My understanding of the IESG's stated position is that we must
> have 
> well-defined requirements before we can devise reasonable solutions, 
> especially in complex, subtle, and far-reaching problem spaces, such as 
> directories.
> I believe that the we need to agree on the requirements before moving
> forwards 
> on implementations (i.e. specific plans). A DN requirements document 
> (draft-hodges-ldap-dir-dn-reqs-00.txt) is being currently discussed on the
> LDAP Service Deployment distribution list <IETF-LSD@LISTSERV.UMU.SE> and
> will 
> be added to the LSD charter.
> It seems to me that when the IESG has accepted that or another
> requirements 
> document, then it's appropriate for drafts describing specific naming
> plans 
> based upon those requirements to go forward. Until then, I feel the
> dirnaming 
> draft is premature and unlikely to meet the our long-term needs.
> thanks,
> Jeff