HTTPbis WG

This is the wiki home of the IETF HTTPbis Working Group. We're ​chartered to revise and clarify RFC2616 -- the HTTP 1.1 specification -- to improve interoperability and security.

Additionally, we're starting to look at proposals for a protocol that could become HTTP/2.0, along with evaluating proposals for new authentication schemes.

1. HTTP/1.1 Deliverables
2. HTTP/2.0 Deliverables
3. Issue Handling
4. Participate
5. People

HTTP/1.1 Deliverables

The HTTP/1.1 specification has been split up into several drafts for readability and modularity; see the ​Drafts directory for a current snapshot of all HTTP-related drafts.

• WGLC: ​p1: Messaging - low-level message parsing and connection management (​work-in-progress in HTML format)
• WGLC: ​p2: Semantics - methods, status codes and headers (​work-in-progress in HTML format)
• WGLC: ​p4: Conditional Requests - e.g., If-Modified-Since (​work-in-progress in HTML format)
• WGLC: ​p5: Range Requests - getting partial content (​work-in-progress in HTML format)
• WGLC: ​p6: Caching - browser and intermediary caches (​work-in-progress in HTML format)
• WGLC: ​p7: Authentication - HTTP authentication framework (​work-in-progress in HTML format)

Additionally, we're publishing:

• ​Security Properties - an explanation of the security properties of HTTP
• WGLC ​Method Registrations - a document establishing the HTTP method registry's initial contents
• WGLC ​Authentication Scheme Registrations - a document establishing the HTTP authentication scheme registry's initial contents

WGLC indicates a document in Working Group Last Call. p3 was folded into p2.

Past work includes:

• ​RFC6266 - Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (​test cases)

Related material includes:

• ​Subversion repository
• ​Document changes, also in ​RSS and on ​Twitter

Currently, the group doesn't officially work on new HTTP features, as that's outside the scope of ​our charter. However, they are often discussed informally on our list, because there are a large number of interested HTTP implementers, and because we may take on new work with a recharter in the future. We track these as PotentialWork.

HTTP/2.0 Deliverables

We're also chartered to work on a replacement for how HTTP is expressed "on the wire." This effort is known as "HTTP/2.0", although it is not a ground-up rewrite of the protocol.

The basis of the work is ​SPDY. However, we will be collecting issues against this document, as well as confirming consensus over individual portions.

See also ​Tickets related to HTTP/2.0.

Issue Handling

Issues with the specifications are kept in our ​ticket tracker.

We have two basic types of issues; Design (​open issues) and Editorial (​open issues).

Design issues need to be discussed by the Working Group to reach consensus. This generally happens on the mailing list when the issue is raised, but the editors sometimes incorporate a proposed resolution to a design issue in a draft, so that the WG can see it in-situ. Such tickets aren't fully closed until the group confirms the proposal after it is published; you can see ​a list of such tickets here.

Editorial issues can be resolved by the editors without consultation with the group, although sometimes an editor will poll the group for advice.

New issues can be raised by sending e-mail to the list (see below). It helps to call attention to them in the Subject line (e.g., "NEW ISSUE: ...").

Finally, for those documents in Working Group Last Call, we have a summary of ​WGLC issues.

TicketStats( height=250,daterange=36m,res_days=30)?

Participate

As with all IETF Working Groups, almost all discussion and decisions are made on our ​mailing list. Joining this list is "joining" the Working Group, and is the best way to participate.

We meet at least twice a year at ​IETF meetings; see also ​materials from past meetings.

During our official meetings, we use an XMPP (Jabber) channel at xmpp://httpbis@jabber.ietf.org?join (​archives) provided by the IETF.

ALL contributors and participants in the Working Group (i.e., on the mailing list and in physical meetings) MUST read and understand the ​NOTE WELL statement.

People

Many people have contributed to HTTP's development over the years, and likewise there are many people participating in HTTPbis. The people holding official positions in this effort are:

• ​Mark Nottingham - Working Group Chair, editor for p6 Caching
• ​Julian Reschke - Editor, p1-p7, Method Registrations, Content-Disposition, Authentication Scheme Registrations
• ​Roy Fielding - Editor, p1-p7
• ​Yves Lafon - Editor, p5
• ​Jeff Hodges - Editor, Security Properties
• ​Barry Leiba - our current Area Director, who oversees the WG for the ​IESG