Subject: Last Call: RFC2183 to obsolete RFC1806

From: The IESG <[email-masked]>
Date: Wed, 3 Sep 2008 15:32:23 -0700 (PDT)

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.  Please
send substantive comments to the [email-masked] <mailto:[email-masked]>
mailing lists by 2008-10-03. Exceptionally, comments may be sent to
[email-masked] <mailto:[email-masked]> instead. In either case, please
retain the beginning of the Subject line to allow automated sorting.

----------

_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: John C Klensin <[email-masked]>
Date: Mon, 08 Sep 2008 08:06:34 -0400

--On Wednesday, 03 September, 2008 15:32 -0700 The IESG
<[email-masked]> wrote:

> 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

---

From: [email-masked]
Date: Mon, 08 Sep 2008 09:02:56 -0700 (PDT)

+1 on all points.

				Ned

---

From: Lisa Dusseault <[email-masked]>
Date: Wed, 10 Sep 2008 13:37:29 -0700

> input or demonstrations of community consensus are actually

Perhaps an announcement specifically calling out the approval of the  
errata would have been better.  I was trying to make sure there was a  
public record of the intent or fait accompli of obsoleting RFC1806 --  
since errata don't normally have IETF-announce postings associated.

Thanks,
Lisa

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 15 Sep 2008 01:17:52 +0200

> since errata don't normally have IETF-announce postings associated.
FWIW, I think it's better to err on the side of too many last calls.

If we can make the simple assertion that anything which changes the 
status of a standards-track document requires a last call, at least that 
class is addressed - this was apparently about altering the status of an 
Experimental document, so it's still a judgment call.

Perhaps the feedback can be seen as encouraging writing up an IESG 
statement/ guideline saying "we send out a Last Call when...."?

(that guideline should then also include "..... and when we think we 
need one".... don't eliminate the ability to use judgment....)

                Harald

---

From: "TS Glassey" <[email-masked]>
Date: Sun, 14 Sep 2008 20:36:19 -0700

I think its better to have a more formally defined process that doesn't take 
a vote to advance but rather a pre-defined set of milestones which may have 
been set by a vote, but which by its very nature is something that requires 
a formal commitment in.

I also suggest that this process as its defined has been abused in way to 
many instances such that some level of thought of the IETF's Standards 
Process is warranted. Its time people were accountable for their actions and 
that the process which allows the IETF and IESG to award standards based on 
a whim needs to be tightened down so that personalities are no longer 
stumbling blocks to achieving IETF standards.

Todd Glassey
----- Original Message ----- 
From: "Harald Alvestrand" <[email-masked]>
To: "Lisa Dusseault" <[email-masked]>
Cc: "John C Klensin" <[email-masked]>; <[email-masked]>; "Keith Moore" 
<[email-masked]>
Sent: Sunday, September 14, 2008 4:17 PM
Subject: Re: Last Call: RFC2183 to obsolete RFC1806

> need one".... don't eliminate the ability to use judgment....)

--------------------------------------------------------------------------------

No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.169 / Virus Database: 270.6.21/1671 - Release Date: 9/14/2008 
7:16 AM