Scott Hollenbeck wrote:
IANA made the assignment because this document:
http://www.ietf.org/internet-drafts/draft-ietf-msgtrk-trkstat-05.txt
was approved for publication as a Proposed Standard by the IESG on
2004-03-23 and the document is now in the RFC Editor's queue. The IANA
actions have to be completed before the document can be finished by the RFC
Editor.
While I can understand the rationale, it does pose some difficulties for
implementors; lacking an RFC, implementors are at somewhat of a loss to
provide justification for handling the MUST, MUST NOT, REQUIRED, etc.
provisions of the applicable specification ("Under no circumstances
should an Internet-Draft be referenced [...[ nor should a vendor claim
compliance with an Internet-Draft" -- RFC 2026). Some coordination
between the rfc-editor and IANA would be helpful to implementors.
Bruce, I'm sorry, but this is simply absurd. The IANA and the RFC Editor
already work together closely to coordinate this sort of thing. Specifically,
the editing process has a phase during which the relevant registrations are
completed. The actual RFC then gets published in fairly short order
after IANA actions are completed.
The notion that having dangling reference in the registry for the very short
period of time while the publication process is completely is a problem does
not pass the laugh test. I doubt very much that implemetors are going to to
waste time prowling the registries looking for MIME types to support, and even
if some people have taken sufficient leave of their senses to do this sort of
thing it is not a practice we should condone.
Having
the RFC first (which includes the registration template information for
the relevant media type) would not be a problem, as I see it.
I'm afraid you're dead wrong about this. The reality is that registration
problems often don't turn up until the registration has been completed and
reviewed as part of the publication process. Failure to perform these action
prior to publication can and does lead to errors that have required
republication in the past.
The approach that's currently used is both practical and has not produced the
many operational problems other approaches we've used in the past have had.
whereas
the current situation (registered media type with no document that can
be referenced) does pose problems.
I disagree.
Ideally the RFC and IANA registration
would happen simultaneously; RFC first seems workable, but registration w/o
RFC causes difficulties.
Ideally, perhaps, but it isn't practical.
The msgtrk working group will be closed once the remaining documents (all of
which are in the RFC Editor's queue) are published as RFCs.
It's a shame that the draft in question (16 months old) has a number of
oddities -- being based on RFC 1894 -- which have been corrected in RFC 3464
(e.g. reference to "xtext", which would by analogy be equivalent to me
pointing out that dictionaries provide a definition of the word "rhinoceros",
which is otherwise not used anywhere in this message).
So presumably comments such as the "xtext" issue would have to be directed to
the RFC editor/authors once the RFC is published.
The RFC Editor routinely checks for references to documents that have been
obsoleted. So this is almost certainly going to be caught by the editing
process. Of course you can always drop the RFC Editor or the authors a note to
make sure it gets dealt with.
Ned