+1 on all points.
Ned
> --On Wednesday, 03 September, 2008 15:32 -0700 The IESG
> <[EMAIL PROTECTED]> 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf
