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.
From the point of view of being able to say RFC NNNN section W.X.Y.Z says
foo is prohibited/required, a draft is a draft and there is no RFC until
there is an assigned RFC number.
But there is a document that has been approved at some standard level. Standard
!= RFC.
I note in passing that it is easy to determine the status of any draft;
this is what the datatracker is for.
I have no idea who this Darth Racker person is :-). I know about the
rfc-index on the isi.edu ftp site. If RFC 3232 hadn't superseded
the Assigned Numbers RFC with the IANA web-based "database" that prompted
this discussion, I'd still be checking RFC XX00 (RFC 1700 successor)
for the relevant assigned numbers. I haven't looked at the IESG home
page in probably a year or more -- why should I; I haven't seen any RFC
listed in the rfc-index declaring the rfc-index obsolete.
Sigh. Nobody ever claimed that the RFC Index is obsolete, only that it
doesn't tell the whole story. Reductio ad absurdum weakens your
argument, it does not strengthen it.
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.
Change isn't the problem, it's having (or not having) a stable
document which can be referenced w.r.t. specific requirements and/or
prohibitions (recommendations, etc.).
You're missing the point. An approved draft is a document that isn't
supposed to change in any significant way prior to publication as
an RFC. Cases where changes have occurred are much rarer than cases
where an RFC is obsoleted by something that's substantially different
than the original.
Since "published RFCs never
change" (except when they're revised via errata), an RFC may be
referenced, whereas referring to a draft is verboten.
And if this concerns you you should wait until the RFC is out.
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.)
Again, I know nothing about "datatracker", and judging by recent comments
here, I'm not the only one. [And putting a link on some obscure web page isn't
likely to change that.]
The other comments, such as they are, were from people concerned that it was
hard to find the tracker page. They most certainly weren't ignorant of its
existance, as apparently you were.
If the draft was approved, what is its RFC number?
You are being absurd again. Approval of documents has never coincided with RFC
publication for at least as long as I've been a participant in the IETF - that
is, since 1989. Maybe it did before that - I wouldn't know.
Drafts approved for publication do not expire; the
notion that this registration was based on a draft that has now expired is
totally bogus.
So drafts expire after six months except when they don't. Okaaaaay...
It most certainly is OK, your sarcasm notwithstanding. And when the document is
published the draft is replaced with a tombstone pointing at the published RFC.
And when something suddenly appears in the IANA registry with no reference
in the rfc-index, all there is is (maybe) some draft which nobody is
supposed to refer to because "drafts are not standards". No RFC number to
refer to.
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.
I see no mention of any "queue" in the rfc-index.
Your ignorance of the process the RFC Editor has been using for quite a while
now doesn't do your argument any good.
And today, well over 48
hours after your message, I still see no RFC corresponding to either the
CPIM or msgtrk drafts in the latest rfc-index. So not only do we apparently
have a different concept of "fairly short order", but also of "48 hours"
and/or "imminent".
Once the RFC is complete the RFC Editor asks authors for review. The review is
supposed to be done within 48 hours. However, since this is a volunteer
organization the RFC Editor has no ability to insist on timely review. Rather
than published something that the authors haven't had a chance to look at
(which has been shown over and over and over again to result in documents full
of errors), the RFC Editor generally will extend the period as needed.
Additionally, if the author finds typographical errors in the draft the token
goes back to the RFC Editor to deal with the errors. So the final step can take
longer in some cases.
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.
The trend is the departure from the situation prior to the discontinuation
of the Assigned Numbers RFC, where the assigned numbers could be easily
referenced back to a published RFC. The change to a web-based conglomeration
has happened, and I have adapted -- despite many seemingly irrelevant changes
to formatting, inconsistencies (text files for some items, HTML for others,
etc.), spurious changes to the modification dates with no substantive change
to the content, etc. However, the appearance of registered magic "numbers"
prior to publication of an RFC that can be referenced is a great departure
from the situation that existed when the Assigned Numbers RFC was periodically
published.
Bruce, I'm afraid I find your position to be totally without merit,
preposterous, and absurd. I also find your apparent ignorance of the IETF
process and the tools used to support that process to be nothing short of
appalling. Things like the RFC Editor queue and the datatracker were introduced
years ago with not inconsiderable fanfare. They have also been discussed at
great length on various lists.
In any case, I no longer have time to waste on this silly arugment, so this
will be my final message on the topic.
Ned