Subject: Charter revision

From: Mark Nottingham <[email-masked]>
Date: Wed, 25 Aug 2010 12:21:00 +1000

After some discussion with the ADs and Editors, I'm looking at asking the IESG for a *small* charter revision, to:

 - Explicitly move the authentication framework from RFC2617 (as discussed)
 - Take some components of RFC2817 and move it to Historic (as discussed)
 - Update our milestones
 - Fix typos in the charter

See below for the proposed new charter. For reference, our current charter is at <http://datatracker.ietf.org/wg/httpbis/charter/>.

Comments appreciated.

---8<---
Description of Working Group

HTTP is one of the most successful and widely-used protocols on the Internet today. However, its specification has several editorial issues. Additionally, after years of implementation and extension, several ambiguities have become evident, impairing interoperability and the ability to easily implement and use HTTP.

The working group will refine RFC2616 to:
* Incorporate errata and updates (e.g., references, IANA registries, ABNF)
* Fix editorial problems which have led to misunderstandings of the specification
* Clarify conformance requirements
* Remove known ambiguities where they affect interoperability
* Clarify existing methods of extensibility
* Remove or deprecate those features that are not widely implemented and also unduly affect interoperability
* Where necessary, add implementation advice
* Document the security properties of HTTP and its associated mechanisms (e.g., Basic and Digest authentication, cookies, TLS) for common applications

It will also incorporate the generic authentication framework from RFC 2617, without obsoleting or updating that specification's definition of the Basic and Digest schemes.

Finally, it will incorporate relevant portions of RFC 2817 (in particular, the CONNECT method and advice on the use of Upgrade), so that that specification can be moved to Historic status.

In doing so, it should consider:
* Implementer experience
* Demonstrated use of HTTP
* Impact on existing implementations and deployments

The Working Group must not introduce a new version of HTTP and should not add new functionality to HTTP. The WG is not tasked with producing new methods, headers, or extension mechanisms, but may introduce new protocol elements if necessary as part of revising existing functionality which has proven to be problematic.

The Working Group's specification deliverables are:
* A document (or set of documents) that is suitable to supersede RFC 2616 and move RFC 2817 to Historic status
* A document cataloguing the security properties of HTTP

Goals and Milestones

Done	First HTTP Revision Internet Draft
Done	First HTTP Security Properties Internet Draft
Nov 2010	Request Last Call for HTTP Revision
Nov 2010	Request Last Call for HTTP Security Properties
Apr 2011	Submit HTTP Revision to IESG for consideration as a Draft Standard
Apr 2011	Submit HTTP Security Properties to IESG for consideration as Informational
--->8---

--
Mark Nottingham     http://www.mnot.net/

---

From: Barry Leiba <[email-masked]>
Date: Wed, 25 Aug 2010 13:01:00 -0400

> See below for the proposed new charter.

To be on the record with this:  It's good; ship it.

Barry

---

From: Henrik Nordström <[email-masked]>
Date: Wed, 25 Aug 2010 19:39:56 +0200

> See below for the proposed new charter. For reference, our current charter is at <http://datatracker.ietf.org/wg/httpbis/charter/>.

All good.

Regards
Henrik

---

From: "William A. Rowe Jr." <[email-masked]>
Date: Wed, 25 Aug 2010 13:42:17 -0500

> After some discussion with the ADs and Editors, I'm looking at asking the IESG for a *small* charter revision, to:

To promulgate an STD, which it really appears the 2616bis is ready to become,
is it necessary to instigate this in the charter?  If so, is this a good time
to submit such a change?

---

From: Julian Reschke <[email-masked]>
Date: Thu, 26 Aug 2010 09:26:40 +0200

> is it necessary to instigate this in the charter?  If so, is this a good time

To get to Full Standard, we either need to change our references to MIME 
to be informative (they may be, after all), or argue that the downrefs 
are ok.

That being said, the amount of *editorial* changes we made is so huge 
that it would be tricky to also advance on the standards track. My 
proposal would be to stay at Draft, and to consider advancing in 
something like ~2 years, in case that at that point we still have three 
levels.

Re 2617: RFC 2617 is a Draft standard (as 2616), so I don't see how this 
would be a problem. After all, we are just rearranging content. Also, I 
would argue that the separation in 2616/2617 simply was a bug (status 
codes and headers in 2616, framework in 2617) that needs to be fixed anyhow.

For CONNECT, things look a *bit* differently, agreed.

Finally: why do you think this is not a good time?

Best regards, Julian

---

From: "William A. Rowe Jr." <[email-masked]>
Date: Thu, 26 Aug 2010 15:51:18 -0500

> Finally: why do you think this is not a good time?

Didn't mean to imply the timing for merging 2616/2617 was wrong.  I was only
asking if STD tracking was appropriate now.

---

From: Julian Reschke <[email-masked]>
Date: Fri, 27 Aug 2010 08:15:02 +0200

> asking if STD tracking was appropriate now.

I see.

 From a pragmatic point of view, I don't think that many consumers of 
the spec care a lot about the standards level.

 From an IETF point of view, I really would like to be able to advance 
it. But I wouldn't be surprised if the IESG sees that differently, given 
the amount of reorganization, and also current discussion about revising 
the standards levels.

Best regards, Julian