Re: Fw: Last Call: Naming Plan for Internet Directory-Enabled App lications to Proposed Standard

[Al Grimstad <[e-mail]>]

...
> Maybe I shoudn't have used "normative", since it drags in the ISO usage.
> 
> My objection was that it isn't clear, IF one wants to interoperate using
> this spec, what one MUST do. (The spec as a whole can still be optional to
> implement.) That's the sense in which I was using normative. In particular,
> I don't think that things which one MUST do to interoperate belong in a
> section labelled "Implementation Issues". I'm open to the argument that I
> misread that section, and that what it says isn't really required for
> interoperation, but it sure seemed that way to me.
> 
> In other words, I think it is highly desirable that the spec use the
> language in RFC 2119 to indicate precisely the requirements for
> interoperability. (RFC 2119 is where the meanings of MUST, SHOULD, etc. that
> have traditionally been used in Internet RFCs are now inscribed for shared
> use.)
> 
> Paul

I understand you now. I think this is a fair comment.

I'll answer you what the intent is. A full response, I think, calls
for a careful review of the document. Since I'm not familiar with RFC
2119, I have no idea if the language of the ID is in line with this
spec, but I assume not. I guess it should be. I'll look into this.

Anyway, the intent of the ID is to extend the practical possibilities
in DN construction. In theory, LDAP (and X.500) don't constrain
DNs. In practice, there is a lot of hard-coding of name schema out
there that tends to force one to use o= and cn= naming, even in cases
when they don't really work. We want to enable (re)use of naming
elements that will work in such cases.

The constraint the ID will provide is not to the theoretically
open-ended naming possibilities of LDAP (and X.500) but to the
practically limited implementations (clients or servers) that refuse
to support any naming attributes other than c, l, o, ou and cn.

-- al

--- Begin Message ---

A comment on the issue of "normative" is embedded below. Comments on other
issues to follow.

> ----------
> From: 	Al Grimstad[SMTP:[e-mail]]
> Sent: 	Thursday, January 08, 1998 12:33 PM
> To: 	[e-mail]; [e-mail]
> Subject: 	Re: Fw: Last Call: Naming Plan for Internet
> Directory-Enabled Applications to Proposed Standard 
> 
> > 3. It is not clear which sections are normative. For example, schema
> > definitions which seem to be needed for interoperabilty are defined in
> > section 5, which is entitled "Implementation Issues". The same section
> also
> > describes requirements on the subject name DN in SSL certificates that
> is in
> > conflict with existing defacto standards. If the described mechanism is
> > desirable, then it assuredly must be clearly declared to be normative to
> > have any hope of effecting a change in the existing procedures.
> 
> First, I'm a bit confused as to the consistency of your position. Do
> you want "near complete freedom" or "normative" specifications? In any
> case, in the area of naming, what is normative is a very delicate
> issue. Recall that the current source for guidance in this area, X.521
> Annex B is officially "not a part of the standard,", i.e. not
> normative. This document describes additional ways to construct names
> to solve problems encountered using the X.521 Annex B (and NADF)
> structure of DNs. It does not mandate that everyone use them to the
> exclusion of anything else; rather, it extends in a public way the
> options in DN construction. Those wanting "near-complete freedom" are
> always in a position to define any schema and naming plan they
> want. What we are shooting for here is an interoperable extension.
> 
Maybe I shoudn't have used "normative", since it drags in the ISO usage.

My objection was that it isn't clear, IF one wants to interoperate using
this spec, what one MUST do. (The spec as a whole can still be optional to
implement.) That's the sense in which I was using normative. In particular,
I don't think that things which one MUST do to interoperate belong in a
section labelled "Implementation Issues". I'm open to the argument that I
misread that section, and that what it says isn't really required for
interoperation, but it sure seemed that way to me.

In other words, I think it is highly desirable that the spec use the
language in RFC 2119 to indicate precisely the requirements for
interoperability. (RFC 2119 is where the meanings of MUST, SHOULD, etc. that
have traditionally been used in Internet RFCs are now inscribed for shared
use.)

Paul

--- End Message ---