--On Wednesday, 03 September, 2008 15:32 -0700 The IESG <iesg@xxxxxxxx> 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf