ned(_dot_)freed(_at_)mrochek(_dot_)com wrote:
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'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? Doesn't registration in the IETF
tree require IESG review and publication as an RFC [RFC 2048 section 2.1.1]?
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)?
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...
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.