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

Paul Leach <paulle@microsoft.com> Thu, 08 January 1998 21:44 UTC

Delivery-Date: Thu, 08 Jan 1998 16:44:33 -0500
Message-ID: <5CEA8663F24DD111A96100805FFE65872038EF@red-msg-51.dns.microsoft.com>
From: Paul Leach <paulle@microsoft.com>
To: ietf-ids@umich.edu, iesg@ns.ietf.org, 'Al Grimstad' <alg@qsun.ho.att.com>
Subject: RE: Fw: Last Call: Naming Plan for Internet Directory-Enabled App lications to Proposed Standard
Date: Thu, 08 Jan 1998 13:44:17 -0800

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

> ----------
> From: 	Al Grimstad[SMTP:alg@qsun.ho.att.com]
> Sent: 	Thursday, January 08, 1998 12:33 PM
> To: 	ietf-ids@umich.edu; iesg@ns.ietf.org
> 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

RE: Fw: Last Call: Naming Plan for Internet Direc… Paul Leach