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.
I guess we're going to have to agree to disagree about this. I do pay
attention
to the IANA registries, and I have implemented message/tracking-status
including
provision for 2.1.9 extended status, the extended action keywords, and the
relevant REQUIRED, MUST, and MUST NOT provisions. But I am at a loss to
provide
a reference justifying doing so. Since the implementation is open source and
is not sold, I suppose I could weasel out of the RFC 2026 "vendor" clause, but
there is still the "Under no circumstances" clause that is troubling.
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.
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.
Is the registration template in the draft of a document intended to become a
Proposed Standard not reviewed by the IESG?
Of course it is. But if review were the same as actually performing an action,
we wouldn't have implementation requirements for progression along the
standards track. The fact of the matter is that there can be problems that
aren't apparent at the review stage and which only turn up during the
registration process.
Doesn't registration in the IETF
tree require IESG review and publication as an RFC [RFC 2048 section 2.1.1]?
Of course it does. But again, review != actually performing an action.
What about RFC 2048 [2.3.1] -- was this proposed registration posted to the
ietf-types mailing list for review (I looked at the mailing list archives, but
couldn't find anything in the past 4 months-- but there seems to be an awful
lot of spam)?
I doubt it, but this step is optional in any case.
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.
In principle, it doesn't seem to me to be a big deal to withhold publication
(review is a separate issue) in the registry until the RFC is published...
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.
Even granting that such coordination wouldn't cause more problems than it
solves, you're letting the costly best be the enemy of the much cheaper plenty
good enough.
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.
In this case it seems that the specific issue mentioned arises because text
from RFC 1894 was cloned, and when 1894 was obsoleted, it wasn't updated.
It's not a case of "cite by reference", which might have avoided the issue,
but of copying of text.
Again, means exist to correct this sort of thing as part of the editing
process.
Ned