[[[
With reference to:
http://www.ietf.org/internet-drafts/draft-klyne-hdrreg-mail-05.txt
which contains the changes I have proposed.
]]]
Charles,
I think this is one of those small details that came out in the execution
(ala "running code") which wasn't fully mapped out when the registry
procedure document was drafted. In preparing the mail header registration
document, it seemed to be more appropriate (and more honest regarding some
of the headers' actual status in the IETF process) to me to specify
not-yet-standard headers as "standards-track" rather than "standard". The
wiggle room in the registry spec that allows me to justify this is "or some
other appropriate value according to the type and status of the primary
document". I used the term "standards-track" rather than "Proposed-" or
"Draft-" because that's what appears on the standards-track RFCs; e.g.
[[
Network Working Group P. Resnick, Editor
Request for Comments: 2822 QUALCOMM Incorporated
Obsoletes: 822 April 2001
Category: Standards Track
]]
I concede that consistency might suggest "Proposed-" or "Draft-", but I
don't see any added value in having such fine detail in the registry.
I think my approach is entirely in the intended spirit of the registry,
which is to help prospective designers and users (a) find information about
the variety of headers in use, and (b) to record any additional information
about their suitability for use, rather than to attempt to provide detailed
information that is available elsewhere.
Having said all the above, I think this is a small matter, probably not
deserving of too many debating cycles.
(more comments below...)
At 20:35 14/05/04 +0000, Charles Lindsey wrote:
In <5(_dot_)1(_dot_)0(_dot_)14(_dot_)2(_dot_)20040430145623(_dot_)025c0938(_at_)127(_dot_)0(_dot_)0(_dot_)1> Graham Klyne
<gk(_at_)ninebynine(_dot_)org> writes:
>In response to an off-list comment, I'm making a small revision of the mail
>message header registry draft [1] to mark header fields defined in RFC822
>(as well as RFC2822) as standard rather than just "standards-track". This
>raised two questions:
On looking into this further, I find myself confused :-( .
In the IETF scheme of things, a standards-track document can be either
"proposed astandard", "draft standard" or (full) "standard".
However, in draft-klyne-msghdr-registry-07.txt (which I presume is the
final approved draft) I find, under the registration template in 3.2.1:
Status:
Specify "standard", "experimental", "informational", "historic",
"obsoleted", or some other appropriate value according to the type
and status of the primary document in which it is defined. For
non-IETF specifications, those formally approved by other
standards bodies should be labelled as "standard"; others may be
"informational" or "deprecated" depending on the reason for
registration.
This seems to suggest that all the varieties of standard-track document
are to be lumped together and assigned the status "standard".
Which would actually make things simpler and avoid possible confusions
when the latest document is proposed/draft but is intended to supersede an
earlier full standard.
It also means that ALL your "standards-track" statuses in
draft-klyne-hdrreg-mail-03.txt should be changed to "standard" (note that
you have currently changed some of them to "standards", which is not
quite the same thing :-( ).
Oops, good catch! Was a typo. I found Keywords and Resent-to having this
error. I think that's all. Absent any major issues with this -05
revision, I propose to request a last call and fix this later.
Note that, in the IANA Considerations section of USEFOR, I have followed
the registration template as written, and used "standard" throughout.
Methinks it is high time that the IESG appointed a "designated expert" as
required by the now-accepted-draft.
I assume, in the scheme of things, this would happen as the RFC editor,
IANA and IESG interact during the RFC publication process. I guess it's
the IESG's call how to play this now you raise it.
#g
------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact