WG Action: RECHARTER: Hypertext Transfer Protocol Bis (httpbis)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



The Hypertext Transfer Protocol Bis (httpbis) working group in the Applications Area of the IETF has been rechartered.  For additional information, please contact the Area Directors or the working group Chairs.

Hypertext Transfer Protocol Bis (httpbis)
-----------------------------------------
Status: Active Working Group

Current Status: Active Working Group

Chair(s):
    Mark Nottingham  <mnot@mnot.net>

Applications Area Director(s):
    Pete Resnick  <presnick@qualcomm.com>
    Peter Saint-Andre  <stpeter@stpeter.im>

Applications Area Advisor:
    Peter Saint-Andre  <stpeter@stpeter.im>

Mailing Lists: 
    General Discussion:ietf-http-wg@w3.org
    To Subscribe:      ietf-http-wg-request@w3.org
        In Body:       subscribe
    Archive:           http://lists.w3.org/Archives/Public/ietf-http-wg/

Description of Working Group:

This Working Group is charged with maintaining and developing
the "core" specifications for HTTP. 

The Working Group's specification deliverables are:
* A document (or set of documents) that is suitable to supersede RFC 
 2616 (HTTP/1.1) and move RFC 2817 to Historic status
* A document cataloguing the security properties of HTTP/1.1
* A document that specifies HTTP/2.0 an improved binding of HTTP's semantics
 to the underlying transport.

HTTP/1.1
--------

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

HTTP/2.0
--------

There is emerging implementation experience and interest in a protocol that
retains the semantics of HTTP, without the legacy of HTTP/1.x message framing
and syntax. The Working Group will leverage this to create new major version
of HTTP.

Particular goals of this effort include:

* Significantly improved perceived performance for common use cases
 (e.g., browsers, mobile)
* More efficient use of network resources; in particular, reducing the
 need to use multiple TCP connections
* Ability to be deployed on today's Internet, using IPv4 and IPv6, in the
 presence of NATs
* Maintaining HTTP's ease of deployment
* Reflecting modern security requirements and practices

With regard to security requirements, in the initial phase of work on 
HTTP/2.0, new proposals for authentication schemes can be made.  The WG
will have a a goal of choosing at least one scheme that is better than 
those available for HTTP/1.x.  However, the WG might select zero schemes.
In addition, non-selected schemes might be discussed with the IETF 
Security Area for further work there.

In documenting this protocol, the Working Group must:

* Meet the goals specified above
* Make it possible to pass through a HTTP/1.1 message with reasonable
 fidelity; i.e., to implement a gateway to or from HTTP/1.1
* consider the needs of a variety of HTTP implementers and users
 (such as "back-end" or "web api" uses of HTTP, servers and intermediaries)
* Address HTTP proxy and CDN infrastructure requirements

Changes to the existing semantics of HTTP are out of scope in order to
preserve the meaning of messages that might cross a 1.1 --> 2.0 --> 1.1
request chain. However, the effort may define new semantics to further the
goals above, along with suitable extensibility mechanisms for defining
additional semantics.

This work will be known as "HTTP/2.0", unless the Working Group
determines that this isn't suitable (e.g., for interoperability).


Goals and Milestones:

Done        First HTTP/1.1 Revision Internet Draft 

Done        First HTTP Security Properties Internet Draft 

Jan 2012    Request Last Call for HTTP/1.1 Revision 

Jan 2012    Request Last Call for HTTP Security Properties 

Apr 2012    First HTTP/2.0 Internet Draft

Apr 2012    Submit HTTP/1.1 Revision to IESG for consideration as a 
              Proposed Standard 

Apr 2012    Submit HTTP Security Properties to IESG for consideration as 
              Informational RFC

Apr 2013    Request Last Call for HTTP/2.0

Jul 2013    Submit HTTP/2.0 to IESG for consideration as a Proposed
              Standard



[Index of Archives]     [IETF]     [IETF Discussion]     [Linux Kernel]

  Powered by Linux