+1 on all points.
Ned
--On Wednesday, 03 September, 2008 15:32 -0700 The IESG
<iesg(_at_)ietf(_dot_)org> wrote:
An errata has been submitted to update the RFC Index such that
RFC2183, "Communicating Presentation Information in Internet
Messages: The Content-Disposition Header Field", is marked as
obsoleting RFC1806, "Communicating Presentation Information
in Internet Messages: The Content-Disposition Header", rather
than as updating the same document.
- http://www.rfc-editor.org/errata_search.php?rfc=2183&eid=1457
- http://tools.ietf.org/html/rfc2183
- http://tools.ietf.org/html/rfc1806
Since the approval of this errata would mark an RFC as
obsoleted, the IESG solicits final comments on this errata
approval.
...
Folks, while I generally favor the IESG asking the community for
input when it needs community consensus on something, this seems
excessive. 2183 is a Proposed Standard. 1806 is Experimental.
The third paragraph (!) of the Abstract to 2183 reads:
"This document is a revision to the Experimental
protocol defined in RFC 1806. As compared to RFC 1806,
this document contains minor editorial updates, adds new
parameters needed to support the File Transfer Body
Part, and references a separate specification for the
handling of non-ASCII and/or very long parameter values."
Now, that combination, plus a quick examination of some of the
rest of the text of 2183, leads me to believe that the
classification of "updates" rather than "obsoletes" in the RFC
index is a pure clerical error and the appropriate subject of a
erratum.
I fear that we are, with the best of intentions, once again
getting bogged down in procedures that unreasonably delay
getting the right thing to happen.
More specifically:
(1) In general, if an Experimental document is replaced
(or "revised") by a Standards Track one, that should
constitute "obsoleting" the old one.
(2) Given the general tone of the review requirements in
2026 (even though we never follow them), the IESG should
be able to obsolete _any_ thirteen-year-old Experimental
document that has not been replaced or supplemented by
(i) a standards-track document (ii) a new experimental
document, or (iii) a report on the experiment unless the
experiment has clearly turned into common practice.
Given "Internet time", the necessary window should be a
lot shorter than 13 years. I believe and hope that we
can trust the IESG's discretion on this subject.
(3) Just for the record, I believe that the _correct_
action here, albeit one that the IESG clearly cannot
take on its own, is to issue a Draft Standard document
that obsoletes both documents. This is, after all, a
13-year-old header field and an 11-year-old standards
track protocol. The latter is widely deployed and many
MUAs depend on it. The last decade has, IMO, shown up
some completely predictable interoperability issues that
2183 mostly dodges with "MUA might" or other MUA
discretion language. I believe that we've now got
enough experience to offer better guidance and maybe
even identify more traps and that doing so should not be
a lot of effort (unless the IESG insists on a complete
document restructuring to conform to some current
convention). But so it goes.
I do not believe that either of the first two cases above
require or justify a Last Call, even though a significant change
in the status of a Standards-Track document almost certainly
should. I would suggest that, in general, the IESG simply issue
a Document Action notice on such things and see if anyone
protests. For the second case, where an Experimental
specification is the only published specification of something
that is in wide use, consulting the community is probably
desirable (although an updated, non-Experimental, document would
be better). But, if there is not sufficient expertise in the
IESG to make at least a preliminary determination as to whether
an Experimental Protocol is in wide use, I suggest we have much
broader problems than the classification of a document.
Please reserve Last Calls for situations in which community
input or demonstrations of community consensus are actually
needed.
john
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf