Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

Would it be possible to get an overview diff for what is (proposed to 
be) changing? (I think such a diff should always be provided for 
proposals for charter updates.)

Regards,   Martin.

On 2010/09/15 7:26, IESG Secretary wrote:
> A modified charter has been submitted for the Hypertext Transfer Protocol
> Bis (httpbis) working group in the Applications Area of the IETF.  The
> IESG has not made any determination as yet.  The modified charter is
> provided below for informational purposes only.  Please send your comments
> to the IESG mailing list (iesg@ietf.org) by September 21, 2010.
>
> Hypertext Transfer Protocol Bis (httpbis)
> ---------------------------------------------------
> Current Status: Active Working Group
>
> Last modified: 2010-09-02
>
> Chairs:
>    Mark Nottingham (mnot@pobox.com)
>
> Applications Area Director(s):
>    Alexey Melnikov (alexey.melnikov@isode.com)
>    Peter Saint Andre (stpeter@stpeter.im)
>
> Applications Area Advisor:
>    Alexey Melnikov (alexey.melnikov@isode.com)
>
> Mailing Lists:
>    General Discussion: ietf-http-wg@w3.org
>    To Subscribe:ietf-http-wg-request@w3.org
>    Subject: subscribe
>    Archive: http://lists.w3.org/Archives/Public/ietf-http-wg/
>
> 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
>
>

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:duerst@it.aoyama.ac.jp

Received on Wednesday, 15 September 2010 01:31:23 UTC