Hypertext Transfer Protocol Bis
charter-ietf-httpbis-06

The information below is for an older approved charter
Document Charter HTTP WG (httpbis) Snapshot
Title Hypertext Transfer Protocol Bis
Last updated 2007-10-18
State Approved
WG State Active
IESG Responsible AD Barry Leiba
Charter Edit AD (None)
Send notices to (None)

Charter
charter-ietf-httpbis-06

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 an 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, which have been identified as hampering performance and encouraging
  misuse of the underlying transport.
  
  As such, there is an opportunity to create a new major
  (non-wire-compatible) version of HTTP.
  
  To do this, the Working Group will solicit candidates for this work from
  the community, to be submitted as Internet-Drafts. Expected focus areas
  for candidates include:
  
  * Significantly improved perceived performance in 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.
  
  Although proposals are not required to meet all of these goals, it is
  expected that the resulting work (if undertaken) will be chartered to
  meet them (and therefore, selecting one that meets the majority of them
  as a starting point is in everyone's interest).
  
  The Working Group will then select a starting point for the new work
  based upon the following criteria:
  
  * Compatibility with HTTP/1.1 semantics; i.e., it must be possible to
    pass through a HTTP/1.1 message with reasonable fidelity
  * Broad implementer interest (e.g., from Web browsers, "back-end"
    or "web api" uses of HTTP, servers, intermediaries, CDNs, etc.)
  
  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 resulting effort may define new semantics to
  further the goals above, along with suitable extensibility mechanisms
  for defining additional semantics.
  
  If the Working Group forms consensus around a proposal to use as a
  starting point, it is expected it will re-charter to begin work on that
  document (or set of documents). The resulting work will be known as
  "HTTP/2.0", unless the Working Group determines that this isn't suitable
  (e.g., for interoperability).
  
  Although work on this new version will begin in parallel with completion
  of work on HTTP/1.1, the Working Group will prioritize HTTP/1.1 work
  until it is complete.