ietf-822
[Top] [All Lists]

Re: Message Header Field Registry - revised proposal

2002-02-27 07:11:07

Charles,

Thanks for your comments. I accept most of them and will take them into account for the next revision. I note below a few responses and small differences of view:


At 10:59 AM 2/27/02 +0000, Charles Lindsey wrote:
>    Author/Change controller:
>       For internet standards-track or experimental specifications, state
>       "IETF".  For other open standards, give the name of the publishing
>       body (e.g.  ANSI, ISO, ITU, W3C, etc.).  For other specifications,
>       give the name, email address, and organization name of the primary
>       specification author Postal address, home page URI, telephone and
>       fax numbers may be included.
>
I would have expected experimental specs to refer to the author(s) just
like the informational ones.

Maybe ... I was presuming an experimental RFC here, which has IETF consensus for publication. I don't feel strongly either way.


>    Specification document(s):
>       Reference to document that specifies the header for use with the
>       indicated protocol, preferably including a URI that can be used to
>       retrieve a copy of the document.  An indication of the relevant
>       sections MAY also be included, but is not required.
>
>    Related information:
>       Optionally, citations to additional documents containing further
>       relevant information.  (This part of the registry may also be used
>       for IESG comments.)
>
Would this cover the case where, say, USEFOR defines a header that has a
minor difference from RFC2822 (e.g. msg-id where we forbid a SP, even
after a '\').  Would the Spec then say USEFOR, but the related say "based
on RFC 2822"?

That seems to fit the general intent. I think the primary specification in this case would be USEFOR, but it would be helpful to cite RFC2822 since it contains material incorporated by reference. Inevitable, there will be some judgement calls here.


>    Author/Change controller:
>       The name, email address, and organization name of the submission
>       author, who may authorize changes to or retraction of the
>       repository entry.  Postal address, home page URI, telephone and
>       fax numbers may be included.
>       If the proposal comes from a standards body working group, give
>       the name and home page URI of the working group, and an email
>       address for discussion of or comments on the specification.
>
I still maintain there MUST always be a discussion forum (whether by mailing
list or otherwise).

There is a forum for discussion of new registrations (see section 3.3. and reference [43]).

I can imagine some specific cases of registration for which a separate forum does not exist -- e.g. a proprietary design that is widely used in the wild. How about SHOULD?


>    Specification document(s):
>       Reference to document that specifies the header for use with the
>       indicated protocol.  The document MUST be an RFC, a current
>       Internet-draft or the URL of a publicly accessible document (so
>       IANA can verify availability of the specification).  An indication
>       of the relevant sections MAY also be included, but is not
>       required.
>
I think you have got to allow purely paper documents. There may still be
some standards bodies whose committees meet in oak-panelled rooms and
write out their minutes on parchment in long hand :-) . Certainly, for
example, ISO standards are NEVER available via a URL (they still have
delusions about generating income from selling paper).

Hmmm... tough one. This is a requirement for the provisional repository, and I was trying to make sure it was easy for IANA to check whether they were authorized to remove an entry (c.f. section 3.5). I would suggest that a placeholder document that refers to the offline specification would satisfy this criterion. (In which case, some words here would be appropriate.)


> 3.3 Submission of registration
>
>
>    o  Send a copy of the template to the designated email discussion
>       list [43].  Allow a reasonable period - at least 2 weeks - for
>       discussion and comments, then send the template to IANA at the
>       designated email address [44].  IANA will publish the template
>       information if the requested name and the specification document
>       meet the criteria noted, unless the IESG or their designated
>       expert have requested that it not be published (see next section).
>
I doubt IETF will want to set up a special discussion list just for these
templates, and I doubt many people would subscribe to such a list. Better
to use the existing ietf announce mailing list, with discussion on the
existing discussion list. Or maybe make use of the ietf-822 list.

Fine.  I guess that would be a matter for discussion with IESG.


> 3.4 Objections to registration
>
>    Listing of an entry in the provisional repository should not be
>    lightly refused.  An entry MAY be refused if there is some credible
>    reason to believe that such registration will be harmful.  In the
>    absence of such objection, IANA SHOULD allow any registration that
>    meets the criteria set out above.  Some reasonable grounds for
>    refusal might be:
>
>    o  There is IETF consensus that publication is considered likely to
>       harm the Internet technical infrastructure in some way.
>
>    o  Disreputable or frivolous use of the registration facilities.
>
>    o  The proposal is sufficiently lacking in purpose, or misleading
>       about its purpose, that it can be held to be a waste of time and
>       effort.
>
I think you need to include conflict with other ongoing work within the
IETF as a valid ground.

This list was intended to be illustrative rather than exhaustive. Ultimately, blocking is a matter for IETF consensus, via the IESG, so I'd rather not grow the list unless you feel strongly about mentioning this particular point.


> 3.5 Change control
>
>
>    It is intended that entries in the Permanent Message Header Field
>    Registry may be used in the construction of URNs (per RFC 2141 [15])
>    which have particular requirements for uniqueness and persistence
>    (per RFC 1737 [4]).  Therefore, once an entry is made in the
>    Permanent Message Header Registry, the combination of the header name
>    and applicable protcol MUST NOT subsequently be registered for any
>    other purpose.  (This is not to preclude revision of the applicable
>    specification(s) within the appropriate IETF Consensus rules, and
>    corresponding updates to the specification citation in the header
>    registration.)
>
But you need to allow that a future standard may obsolete or reinstate a
header, or even change its meaning so that it bears no resemblance at all
to its former self.

If the IETF decides that that's the right thing to do, then I agree the registry would track that change. I would hope that one effect of the registry would be to prevent such changes from happening by accident. It seems a sufficiently unlikely case that it can reasonable be covered by the guiding principle of IETF consensus for control of this registry. I think the parenthesized comment is enough here.


>
> 4. IANA considerations
>
>
>    Initial header registrations are provided by the following companion
>    documents:
>
I think you should only specify the initial permanent registry. Let people
come forward with their own provisional registrations.

I agree.  Did I say otherwise?

>    o  For mail message headers: Registration of mail header fields [41]
>
It might be better as an appendix to this RFC. In any case, we need to
have a good look at [41] (does it exist yet?) before finalising this
present draft. There is nothing like looking at real cases to spot the
situations you have failed to cover. In fact, perhaps that should be our
next business.

Also, you need to do something for Netnews. RFC 1036 would do for a start,
assuming USEFOR is not ready in time.

First, my expectation was that the initial registry documents would be brought forward at the same time as this document ... if this goes to RFF publication, I'd hope for a consecutive sequence for registry, email, news, http.

Second, these companion documents are intended to contain registration templates as described here. I think volunteers are ready to do the email and http parts -- would you be prepared to do one for news?

Third, no they don't exist yet, but work has started on them.

    o  For HTTP message headers: Registration of HTTP header fields [42]
>
Isn't RFC 2616 enough?

See above: the plan is to have registration templates that IANA can use. Also, to demonstrate/check use of the registry procedures.

#g


------------------------------------------------------------
Graham Klyne                    Baltimore Technologies
Strategic Research              Content Security Group
<Graham(_dot_)Klyne(_at_)Baltimore(_dot_)com>    <http://www.mimesweeper.com>
                                <http://www.baltimore.com>
------------------------------------------------------------