+1 on all points. Ned > --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 mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf