ned(_dot_)freed(_at_)mrochek(_dot_)com wrote:
I think you worry too much. The fact of the matter is that people, including
quite a few major vendors, implement internet-drafts all the time. Heck,
they
even implement _unapproved_ internet-drafts all the time. (IMO sometimes
this
is justified but often it isn't.) But AFAIK there have been no sightings of
the
protocol police swooping down and making arrests.
Sure, there's no enforcement -- but I still want to do the right thing w.r.t.
not citing drafts as references.
If you really believe this you're completely missing the point of the IETF
process. There are drafts and then there are drafts. Referencing a random draft
that Joe Blow put out there is one thing, referencing a draft that has been
approved for publication as an RFC is quite another. An approved draft in
effect _is_ a standard; it just hasn't completed the publication process yet.
I note in passing that it is easy to determine the status of any draft;
this is what the datatracker is for.
Now, you may argue that there's some chance that a document may change or even
be withdrawn between the time it is approved and the time it comes out as an
RFC. But the validity of this concern doesn't stand up when you examine the
publication record -- there have only been a couple of times this sort of thing
has happened. There have been many more cases where something that was approved
as proposed standard was substantially changed when the document was revised
and republished, so if you're going to get tense about stuff changing on you,
you'd best not touch anything that hasn't made it to standard status.
My case is perhaps a bit unusual (the
implementation is a validating parser, which can emit a message including
references when there's a standards violation or potential interoperability
issue).
I see nothing unusual about it, nor do I see any problem with such an
implementation being based on an approved draft.
It creates a situation where additional steps are necessary. IANA has more
than
enough to do as it is, and experience has shown that adding considerable
coordination overhead just to achieve an _extremely_ slight increase in
coherency is almost never a good idea.
It seems to me that having IANA update the registry *twice* (once with the
media
type and a bogus pointer to a non-RFC, and then again when the RFC is
published)
would be more work than updating it *once*.
Performing several separate actions that require no special coordination is
much, much easier than performing even one action that would have to be tightly
coordinated.
Alternatively, since the registry
is in HTML format, the incomplete information could be commented out until RFC
publication; if I recall correctly, it's not at all difficult to do in Adobe
PageMill 3.0 (which is apparently what IANA uses).
Sorry. The goal here is to get things checked, checked, and rechecked; a
commented out registration entry isn't readily visible for authors to check and
approve. So, while this might be easy for IANA to do, doing so breaks a much
more important aspect of the process.
The msgtrk issue isn't the first or only (or even the worst) problem; sometime
last November, IANA also introduced message/CPIM, and after 8 months or so,
there
still isn't any RFC reference -- and the draft had already passed its
expiration
date by last November (the cpim draft expired about a year ago, in July 2003).
First, draft-ietf-impp-cpim-msgfmt-08.txt was approved as a proposed standard
back in October, 2003. (I again note that you could have determined this by
checking the datatracker.) Drafts approved for publication do not expire; the
notion that this registration was based on a draft that has now expired is
totally bogus.
Second, this document is currently in 48 hour author review (a fact you could
have easily determined by checking the RFC Editor queue), so its publication is
imminent.
Now I'm not sure exactly what you meant earlier by "The actual RFC then gets
published in fairly short order after IANA actions are completed", but I think
we probably have a different idea of what constitutes "fairly short order".
The editing process for most documents is pretty quick. However, there are
sometimes exceptions - a document will have some issue or other that prevents
its publication as an RFC from occurring in a timely fashion.
If memory serves, draft-ietf-impp-cpim-msgfmt-08.txt was delayed due to
some normative references not being available. This sort of thing
happens from time to time.
I don't want to belabor the point; message/CPIM with no RFC was an annoyance,
but
was until recently the only unresolved entry in the message media type
registry.
With the addition of message/tracking-status -- with message/CPIM still
unresolved --
I hope I'm not seeing the continuation of a trend.
If the trend you refer to is the immediate appearance of IANA registrations of
stuff that appears in approved drafts, it is a trend I for one would love to
see continue, regardless of the time it takes for the drafts the registry
refers to to complete the publication process.
Ned