Subject: Moving forward with HTTP/2.0: proposed charter

From: Mark Nottingham <[email-masked]>
Date: Fri, 3 Aug 2012 15:06:06 -0500

In the second Vancouver session, we discussed the proposals, expressions of interest in them, and the proposed charter text sent to the list earlier. 

The result of those discussions has been captured in the charter proposal below.

Please have a look and discuss, express your support or concern, and of course make proposals for any changes that you believe will be able to gain consensus. Barring serious problems, I'd like to get it to the ADs in the next week.

---8<---

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 as
 the definition of HTTP/1.1 and move RFC 2817 to Historic status
* A document cataloguing the security properties of HTTP/1.1
* A document (or set of documents) that specifies HTTP/2.0, an improved
 binding of HTTP's semantics to an underlying transport.

HTTP/1.1
--------

HTTP/1.1 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.

The Working Group will produce a specification of a new expression of HTTP's
current semantics in ordered, bi-directional streams. As with HTTP/1.x, 
the primary target transport is TCP, but it should be possible to use
other transports.

Work will begin using draft-mbelshe-httpbis-spdy-00 as a starting point;
proposals are to be expressed in terms of changes to that document. Note that
consensus is required both for changes to the document and anything that
remains in the document.

As part of that work, the following issues are explicitly called out for
discussion:
* A negotiation mechanism that is capable of not only choosing between
 HTTP/1.x and HTTP/2.x, but also for bindings of HTTP URLs to other
 transports (for example).
* Header compression (which may encompass header encoding or tokenisation)
* Server push (which may encompass pull or other techniques)

It is expected that HTTP/2.0 will:
* Substantially and measurably improve end-user perceived latency in most
 cases, over HTTP/1.1 using TCP.
* Address the "head of line blocking" problem in HTTP.
* Not require multiple connections to a server to enable parallelism, thus
 improving its use of TCP, especially regarding congestion control.
* Retain the semantics of HTTP/1.1, leveraging existing documentation (see
 above), including (but not limited to) HTTP methods, status codes, URIs, and
 where appropriate, header fields.
* Clearly define how HTTP/2.0 interacts with HTTP/1.x, especially in
 intermediaries (both 2->1 and 1->2).
* Clearly identify any new extensibility points and policy for their 
 appropriate use.

The resulting specification(s) are expected to be meet these goals for common
existing deployments of HTTP; in particular, Web browsing (desktop and
mobile), non-browsers ("HTTP APIs"), Web serving (at a variety of scales), and
intermediation (by proxies, corporate firewalls, "reverse" proxies and Content
Delivery Networks). Likewise, current and future semantic extensions to
HTTP/1.x (e.g., headers, methods, status codes, cache directives) should be
supported in the new protocol.

Note that this does not include uses of HTTP where non-specified behaviours
are relied upon (e.g., connection state such as timeouts or client affinity,
and "interception" proxies); these uses may or may not be enabled by the final
product.

Explicitly out-of-scope items include:
* Specifying the use of alternate transport-layer protocols. Note that it
 is expected that the Working Group will define how the protocol is used
 with the TLS Protocol.
* Specifying how the HTTP protocol is to be used or presented in a specific
 use case (e.g., in Web browsers).

The Working Group will coordinate this item with:
* The TLS Working Group, regarding use of TLS.
* The Transport Area, regarding impact on and interaction with transport
 protocols.
* The HYBI Working Group, regarding the possible future extension of HTTP/2.0
 to carry WebSockets semantics.

The Working Group will prioritize HTTP/1.1 work until it is complete.

Other HTTP-Related Work
-----------------------

The Working Group may define additional extensions to HTTP as work items,
provided that:
* There is clear consensus to do so, and
* It does not, in the judgement of the Chair(s), interfere with the work 
 described above, and
* The Area Director(s) give consent, and add corresponding milestones.

Additionally, the Working Group will not start work on any extensions that 
are specific to HTTP/2.0 until that work is completed.

Goals and Milestones

Done	First HTTP/1.1 Revision Internet Draft
Done	First HTTP Security Properties Internet Draft
Done	Call for Proposals for HTTP/2.0
Aug 2012	Working Group Last Call for HTTP/1.1 Revision
Sep 2012	Working Group Last Call for HTTP Security Properties
Sep 2012	First WG draft of HTTP/2.0, based upon draft-mbelshe-httpbis-spdy-00
Oct 2012	Submit HTTP/1.1 Revision to IESG for consideration as a Proposed Standard
Oct 2012	Submit HTTP Security Properties to IESG for consideration as Informational RFC
Apr 2014	Working Group Last call for HTTP/2.0
Nov 2014	Submit HTTP/2.0 to IESG for consideration as a Proposed Standard
--->8---

Regards,

--
Mark Nottingham   Systems Architect, Cloud Standards and APIs
[email-masked]    http://www.mnot.net/

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

---

From: James M Snell <[email-masked]>
Date: Fri, 3 Aug 2012 13:52:52 -0700

On Fri, Aug 3, 2012 at 1:06 PM, Mark Nottingham <[email-masked]> wrote:

> [snip]

I want to just clarify that the proposed language does leave the room open
for potentially non-backwards compatible changes to be made within HTTP
2.0. Specifically, the way I read this, it should be possible for us to
tunnel a 1.1 message through a 2.0 request, as well as reasonably translate
a 2.0 message into a 1.1, but the charter also allows for the introduction
of mechanisms within 2.0 that do not necessarily translate directly into
1.1 so long as those are clearly spelled out within the specification (In
particular I'm thinking of things like the binary optimized header
encoding, UTF-8 support, etc). I see nothing in the draft spec language
that rules non-backwards compatible changes as being out of scope. If
that's correct, then I'm +1 on the revised charter.

- James

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 3 Aug 2012 16:05:17 -0500

On 03/08/2012, at 3:52 PM, James M Snell <[email-masked]> wrote:
> 
> I want to just clarify that the proposed language does leave the room open for potentially non-backwards compatible changes to be made within HTTP 2.0. Specifically, the way I read this, it should be possible for us to tunnel a 1.1 message through a 2.0 request, as well as reasonably translate a 2.0 message into a 1.1, but the charter also allows for the introduction of mechanisms within 2.0 that do not necessarily translate directly into 1.1 so long as those are clearly spelled out within the specification (In particular I'm thinking of things like the binary optimized header encoding, UTF-8 support, etc). I see nothing in the draft spec language that rules non-backwards compatible changes as being out of scope. If that's correct, then I'm +1 on the revised charter.

It does not prohibit optimisations, but the combination of the requirements for supporting current use cases, current extensions and 1.x<->2.0 does constrain things quite a bit. 

Any such scheme is going to have to balance the concerns and gain consensus; e.g., telling people that new headers have to be defined twice (as HTTP/1.x and HTTP/2.x) probably isn't going to fly, because of the burdens that places on new headers as well as intermediaries.

Cheers,

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

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 03 Aug 2012 21:10:38 +0000

In message <[email-masked]>
, James M Snell writes:

>2.0.

Where does 2.0<-->1.1 conversion _realistically_ come into play ?

Given the premise that we will not get rid of 1.1 for a looong time
under any circumstances, we can either make the answer "everywhere"
(to get as much traffic upgraded as possible) or "nowhere" (leaving
1.1 traffic alone and using it as fallback, as long as needed.)

This is a question we should decide in the abstract, because it
greatly influences protocol design with respect to 1.1/2.0 interop
and upgrades.

For reasons of simplicity I'm partial to "nowhere", since it saves
a lot of verbiage about the conversions, and would give us more
free hands to make HTTP/2.0 actually be better.

If the consensus is "everywhere", we should bite the bullet up front,
and decide to do both "HTTP/2.0-reduced" which can be mapped to
1.1, and "HTTP/2.0-full" which cannot, so that we have a path to
eventually get rid of HTTP/1.1.

If we have that modality in our vocabulary, it becomes very easy
to explain things like:

	In HTTP/2.0-reduced headers are in ASCII
	In HTTP/2.0-full headers are in UTF8 

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Barry Leiba <[email-masked]>
Date: Fri, 3 Aug 2012 17:15:07 -0400

> The Working Group will prioritize HTTP/1.1 work until it is complete.

Just a small bit of wording quibbling.  "Prioritize" means arranging in
priority order... it does not mean "make its highest priority".  I'd prefer
this:

"The Working Group will make HTTP/1.1 work its highest priority until that
work is complete."

Barry

---

From: Jonathan Ballard <[email-masked]>
Date: Fri, 3 Aug 2012 14:18:56 -0700

That makes it easier to require, and say, the first message of any new HTTP
pipeline always has ASCII headers.

On Friday, August 3, 2012, Poul-Henning Kamp wrote:

> In message <
> [email-masked]<javascript:;>
> >
> , James M Snell writes:
>

---

From: James M Snell <[email-masked]>
Date: Fri, 3 Aug 2012 14:31:56 -0700

On Fri, Aug 3, 2012 at 2:05 PM, Mark Nottingham <[email-masked]> wrote:

> [snip]
>
> Any such scheme is going to have to balance the concerns and gain
> consensus; e.g., telling people that new headers have to be defined twice
> (as HTTP/1.x and HTTP/2.x) probably isn't going to fly, because of the
> burdens that places on new headers as well as intermediaries.
>
>
Indeed. What would be far more likely (and useful) is to define *new*
headers strictly in HTTP/2.x terms and provide a canonical translation of
those into 1.1. Implementors that care about the new headers will make it
work; implementors who don't could easily ignore them.

Regardless, thank you for the clarification

- James

---

From: Julian Reschke <[email-masked]>
Date: Sat, 04 Aug 2012 11:42:45 +0200

On 03.08.2012 23:15, Barry Leiba wrote:
> priority order... it does not mean "make its highest priority".  I'd
> prefer this:
>
> "The Working Group will make HTTP/1.1 work its highest priority until
> that work is complete."
>
> Barry

+1

---

From: Eliot Lear <[email-masked]>
Date: Sat, 04 Aug 2012 12:19:28 +0200

Mark,

One change:

> * A negotiation mechanism that is capable of not only choosing between

I suggest striking the word "negotiation".  Perhaps it will be a
negotiation mechanism, but given that HTTP itself has no banner, other
approaches may be appropriate.

Eliot

---

From: Julian Reschke <[email-masked]>
Date: Sat, 04 Aug 2012 13:12:44 +0200

Does taking SPDY as a base imply that what we'll be doing is a delta 
spec to HTTP/1.1, essentially adding one new TCP binding / 
serialization, and potentially some new options?

In that case I believe we should plan to maintain the HTTP/1.1 specs; 
both incorporating fixes for errata, and also doing editorial 
improvements so that the existing bits integrate well with the new stuff.

That would mean that we revise HTTPbis in parallel, and submit it for 
Full Standard at the same time the HTTP/2.0 go to Proposed.

Best regards, Julian

---

From: Eliot Lear <[email-masked]>
Date: Sat, 04 Aug 2012 13:37:18 +0200

Julian,

> Full Standard at the same time the HTTP/2.0 go to Proposed.

The alternative would be to do something like what we did in Calsify
where we respecified ALL of the primitives in what was a major cleanup. 
That's not necessary here.  Arguably 2.0 doesn't even update 2616, let
alone obsolete it.

Eliot

---

From: Henrik Frystyk Nielsen <[email-masked]>
Date: Sat, 4 Aug 2012 20:22:09 +0000

Mark

Thanks for sending this out! Based on the discussion at the Vancouver meeting and on the mailing list I think there are four items that need explicitly to be clarified in the proposed charter:

1) Clarify the relationship to SPDY, especially the ongoing work on SPDY 3 and the upcoming 4. We don't want to get in a situation with dueling specifications so we have to be clear on there the WG and the SPDY community stand on this. My sense is that as the SPDY spec is used as a starting point we have to roll all new development in under HTTP/2.0 as otherwise we don't know where we stand.

2) Clarify the point made during the WG meeting in Vancouver that because something is in the starting point it doesn't mean that there is consensus around it. That is, there shouldn't be a perception that because something is in that we have to argue whether it should be taken out. It is just as much an argument as to whether something should say in.

3) Clarify that it is the intent of HTTP/2.0 to function as a functional replacement of HTTP/1.1, part 1. That is, it should be possible (in practical and realistic, not theoretical terms) to use HTTP/2.0 in the same scenarios where HTTP/1.1 (and HTTP/1.0) is used today. One group that is missing from the below is embedded systems in which HTTP has a huge role.

4) State that, while not part of the deliverables, given the focus on performance, the WG will continue work on performance evaluation so that we can determine whether something actually improves performance and by how much within the scenarios we are looking at.

I have appended comments to clarify these issue in the below text (look for text between $...$)

Thanks,

Henrik

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.

The Working Group will produce a specification of a new expression of HTTP's current semantics in ordered, bi-directional streams. As with HTTP/1.x, the primary target transport is TCP, but it should be possible to use other transports.

Work will begin using draft-mbelshe-httpbis-spdy-00 as a starting point; proposals are to be expressed in terms of changes to that document. Note that consensus is required both for changes to the document and anything that remains in the document.

$Because something is in the initial document does not imply that there is consensus around the feature or how it is specified.$

$The outcome of this WG is HTTP/2.0, not SPDY. It is important that there is no confusion about the relationship between HTTP/2.0 and SPDY as we do not want to have dueling specifications in this area.$

As part of that work, the following issues are explicitly called out for discussion:
* A negotiation mechanism that is capable of not only choosing between  HTTP/1.x and HTTP/2.x, but also for bindings of HTTP URLs to other  transports (for example).
* Header compression (which may encompass header encoding or tokenisation)
* Server push (which may encompass pull or other techniques)

$Note that this doesn't mean that no other issues should be brought up. The discussion can and should cover the entire HTTP/2.0 spec$

It is expected that HTTP/2.0 will:
* Substantially and measurably improve end-user perceived latency in most  cases, over HTTP/1.1 using TCP.
* Address the "head of line blocking" problem in HTTP.
* Not require multiple connections to a server to enable parallelism, thus  improving its use of TCP, especially regarding congestion control.
* Retain the semantics of HTTP/1.1, leveraging existing documentation (see  above), including (but not limited to) HTTP methods, status codes, URIs, and  where appropriate, header fields.
* Clearly define how HTTP/2.0 interacts with HTTP/1.x, especially in  intermediaries (both 2->1 and 1->2).
* Clearly identify any new extensibility points and policy for their  appropriate use.

The resulting specification(s) are expected to be meet these goals for common existing deployments of HTTP; in particular, Web browsing (desktop and mobile), non-browsers ("HTTP APIs"), Web serving (at a variety of scales), and intermediation (by proxies, corporate firewalls, "reverse" proxies and Content Delivery Networks). 

$as well as embedded systems$

Likewise, current and future semantic extensions to HTTP/1.x (e.g., headers, methods, status codes, cache directives) should be supported in the new protocol.

$That is, in functional terms, one should consider the goal of this work to address parts of HTTP/1.1 part 1 in terms of how the HTTP protocol is mapped to message structures as well as to the underlying transport.$

Note that this does not include uses of HTTP where non-specified behaviours are relied upon (e.g., connection state such as timeouts or client affinity, and "interception" proxies); these uses may or may not be enabled by the final product.

Explicitly out-of-scope items include:
* Specifying the use of alternate transport-layer protocols. Note that it  is expected that the Working Group will define how the protocol is used  with the TLS Protocol.
* Specifying how the HTTP protocol is to be used or presented in a specific  use case (e.g., in Web browsers).

$While not a direct deliverable of the WG, given the focus on performance, it is critical that the WG evaluates how well the proposed features in HTTP/2.0 perform within a common set of scenarios. It is expected that the WG will take such data into consideration when discussing features.$

The Working Group will coordinate this item with:
* The TLS Working Group, regarding use of TLS.
* The Transport Area, regarding impact on and interaction with transport  protocols.
* The HYBI Working Group, regarding the possible future extension of HTTP/2.0  to carry WebSockets semantics.

Other HTTP-Related Work
-----------------------

The Working Group may define additional extensions to HTTP as work items, provided that:
* There is clear consensus to do so, and
* It does not, in the judgement of the Chair(s), interfere with the work  described above, and
* The Area Director(s) give consent, and add corresponding milestones.

Additionally, the Working Group will not start work on any extensions that are specific to HTTP/2.0 until that work is completed.

-----Original Message-----
From: Mark Nottingham [mailto:[email-masked]] 
Sent: Friday, August 03, 2012 1:06 PM
To: [email-masked] Group
Subject: Moving forward with HTTP/2.0: proposed charter

---8<---

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

HTTP/1.1
--------

HTTP/1.1 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.

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.

The Working Group will produce a specification of a new expression of HTTP's current semantics in ordered, bi-directional streams. As with HTTP/1.x, the primary target transport is TCP, but it should be possible to use other transports.

Work will begin using draft-mbelshe-httpbis-spdy-00 as a starting point; proposals are to be expressed in terms of changes to that document. Note that consensus is required both for changes to the document and anything that remains in the document.

As part of that work, the following issues are explicitly called out for
discussion:
* A negotiation mechanism that is capable of not only choosing between  HTTP/1.x and HTTP/2.x, but also for bindings of HTTP URLs to other  transports (for example).
* Header compression (which may encompass header encoding or tokenisation)
* Server push (which may encompass pull or other techniques)

It is expected that HTTP/2.0 will:
* Substantially and measurably improve end-user perceived latency in most  cases, over HTTP/1.1 using TCP.
* Address the "head of line blocking" problem in HTTP.
* Not require multiple connections to a server to enable parallelism, thus  improving its use of TCP, especially regarding congestion control.
* Retain the semantics of HTTP/1.1, leveraging existing documentation (see  above), including (but not limited to) HTTP methods, status codes, URIs, and  where appropriate, header fields.
* Clearly define how HTTP/2.0 interacts with HTTP/1.x, especially in  intermediaries (both 2->1 and 1->2).
* Clearly identify any new extensibility points and policy for their  appropriate use.

The resulting specification(s) are expected to be meet these goals for common existing deployments of HTTP; in particular, Web browsing (desktop and mobile), non-browsers ("HTTP APIs"), Web serving (at a variety of scales), and intermediation (by proxies, corporate firewalls, "reverse" proxies and Content Delivery Networks). Likewise, current and future semantic extensions to HTTP/1.x (e.g., headers, methods, status codes, cache directives) should be supported in the new protocol.

Note that this does not include uses of HTTP where non-specified behaviours are relied upon (e.g., connection state such as timeouts or client affinity, and "interception" proxies); these uses may or may not be enabled by the final product.

Explicitly out-of-scope items include:
* Specifying the use of alternate transport-layer protocols. Note that it  is expected that the Working Group will define how the protocol is used  with the TLS Protocol.
* Specifying how the HTTP protocol is to be used or presented in a specific  use case (e.g., in Web browsers).

The Working Group will coordinate this item with:
* The TLS Working Group, regarding use of TLS.
* The Transport Area, regarding impact on and interaction with transport  protocols.
* The HYBI Working Group, regarding the possible future extension of HTTP/2.0  to carry WebSockets semantics.

Other HTTP-Related Work
-----------------------

The Working Group may define additional extensions to HTTP as work items, provided that:
* There is clear consensus to do so, and
* It does not, in the judgement of the Chair(s), interfere with the work  described above, and
* The Area Director(s) give consent, and add corresponding milestones.

Additionally, the Working Group will not start work on any extensions that are specific to HTTP/2.0 until that work is completed.

Goals and Milestones

Regards,

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

---

From: Mike Belshe <[email-masked]>
Date: Sat, 4 Aug 2012 17:23:58 -0700

On Sat, Aug 4, 2012 at 1:22 PM, Henrik Frystyk Nielsen <
[email-masked]> wrote:

> Mark
>
> Thanks for sending this out! Based on the discussion at the Vancouver
> meeting and on the mailing list I think there are four items that need
> explicitly to be clarified in the proposed charter:
>
> 1) Clarify the relationship to SPDY, especially the ongoing work on SPDY 3
> and the upcoming 4. We don't want to get in a situation with dueling
> specifications so we have to be clear on there the WG and the SPDY
> community stand on this. My sense is that as the SPDY spec is used as a
> starting point we have to roll all new development in under HTTP/2.0 as
> otherwise we don't know where we stand.
>
> 2) Clarify the point made during the WG meeting in Vancouver that because
> something is in the starting point it doesn't mean that there is consensus
> around it. That is, there shouldn't be a perception that because something
> is in that we have to argue whether it should be taken out. It is just as
> much an argument as to whether something should say in.
>
> 3) Clarify that it is the intent of HTTP/2.0 to function as a functional
> replacement of HTTP/1.1, part 1. That is, it should be possible (in
> practical and realistic, not theoretical terms) to use HTTP/2.0 in the same
> scenarios where HTTP/1.1 (and HTTP/1.0) is used today. One group that is
> missing from the below is embedded systems in which HTTP has a huge role.
>
> 4) State that, while not part of the deliverables, given the focus on
> performance, the WG will continue work on performance evaluation so that we
> can determine whether something actually improves performance and by how
> much within the scenarios we are looking at.
>

> Thanks,
>
> Henrik
>
> 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
> The Working Group will produce a specification of a new expression of
> HTTP's current semantics in ordered, bi-directional streams. As with
> HTTP/1.x, the primary target transport is TCP, but it should be possible to
> use other transports.
>
> proposals are to be expressed in terms of changes to that document. Note
> that consensus is required both for changes to the document and anything
> that remains in the document.
>
> $Because something is in the initial document does not imply that there is
> consensus around the feature or how it is specified.$
>

I think this was already covered by "consensus is required both for changes
to the document and anything that remains in the document".

>
> $The outcome of this WG is HTTP/2.0, not SPDY. It is important that there
> is no confusion about the relationship between HTTP/2.0 and SPDY as we do
> not want to have dueling specifications in this area.$
>

There are no dueling specifications.  This working group is working on
HTTP/2.0.  We can say it again, but it probably doesn't decrease the
paranoia ;-)

> $Note that this doesn't mean that no other issues should be brought up.
> The discussion can and should cover the entire HTTP/2.0 spec$
>

I think Mark was trying to confine our goals more than this.   Of course it
is true that things will come up as we go, but it is better if we can
identify the areas to work on up front.

>  above), including (but not limited to) HTTP methods, status codes, URIs,
> and  where appropriate, header fields.
> The resulting specification(s) are expected to be meet these goals for
> common existing deployments of HTTP; in particular, Web browsing (desktop
> and mobile), non-browsers ("HTTP APIs"), Web serving (at a variety of
> scales), and intermediation (by proxies, corporate firewalls, "reverse"
> proxies and Content Delivery Networks).
>

I think you're looking for 'reasonableness' - such that HTTP/2.0 works with
most existing systems.  I am too.

I don't think we need to callout 'embedded systems', as it is already
covered in "expected to meet these goals for common existing deployments of
HTTP".  Embedded systems are common today and will naturally be a big part
of HTTP/2.0.  If we call them out, do we need to start listing all the
other common uses of HTTP? :-)

>
> Likewise, current and future semantic extensions to HTTP/1.x (e.g.,
> headers, methods, status codes, cache directives) should be supported in
> the new protocol.
>
> $That is, in functional terms, one should consider the goal of this work
> to address parts of HTTP/1.1 part 1 in terms of how the HTTP protocol is
> mapped to message structures as well as to the underlying transport.$
>
> Note that this does not include uses of HTTP where non-specified
> behaviours are relied upon (e.g., connection state such as timeouts or
> client affinity, and "interception" proxies); these uses may or may not be
> enabled by the final product.
>
> * Specifying how the HTTP protocol is to be used or presented in a
> specific  use case (e.g., in Web browsers).
>
> $While not a direct deliverable of the WG, given the focus on performance,
> it is critical that the WG evaluates how well the proposed features in
> HTTP/2.0 perform within a common set of scenarios. It is expected that the
> WG will take such data into consideration when discussing features.$
>
> In the second Vancouver session, we discussed the proposals, expressions
> of interest in them, and the proposed charter text sent to the list earlier.
>
> Please have a look and discuss, express your support or concern, and of
> course make proposals for any changes that you believe will be able to gain
> consensus. Barring serious problems, I'd like to get it to the ADs in the
> next week.
>
> ---8<---
>
> * A document (or set of documents) that is suitable to supersede RFC 2616
> as  the definition of HTTP/1.1 and move RFC 2817 to Historic status
> Additionally, after years of implementation and extension, several
> ambiguities have become evident, impairing interoperability and the ability
> to easily implement and use HTTP.
>
> 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.
>
> There is emerging implementation experience and interest in a protocol
> that retains the semantics of HTTP without the legacy of HTTP/1.x message
> The Working Group will produce a specification of a new expression of
> HTTP's current semantics in ordered, bi-directional streams. As with
> HTTP/1.x, the primary target transport is TCP, but it should be possible to
> use other transports.
>
> proposals are to be expressed in terms of changes to that document. Note
> that consensus is required both for changes to the document and anything
> that remains in the document.
>
>  above), including (but not limited to) HTTP methods, status codes, URIs,
> and  where appropriate, header fields.
> The resulting specification(s) are expected to be meet these goals for
> common existing deployments of HTTP; in particular, Web browsing (desktop
> and mobile), non-browsers ("HTTP APIs"), Web serving (at a variety of
> scales), and intermediation (by proxies, corporate firewalls, "reverse"
> proxies and Content Delivery Networks). Likewise, current and future
> semantic extensions to HTTP/1.x (e.g., headers, methods, status codes,
> cache directives) should be supported in the new protocol.
>
> Note that this does not include uses of HTTP where non-specified
> behaviours are relied upon (e.g., connection state such as timeouts or
> client affinity, and "interception" proxies); these uses may or may not be
> enabled by the final product.
>
> * Specifying how the HTTP protocol is to be used or presented in a
> specific  use case (e.g., in Web browsers).
>

---

From: James M Snell <[email-masked]>
Date: Sat, 4 Aug 2012 17:41:12 -0700

On Aug 4, 2012 5:27 PM, "Mike Belshe" <[email-masked]> wrote:
[Snip]
>>
>> $Because something is in the initial document does not imply that there
is consensus around the feature or how it is specified.$
>
>
> I think this was already covered by "consensus is required both for
changes to the document and anything that remains in the document".
>
>>
>>
>> $The outcome of this WG is HTTP/2.0, not SPDY. It is important that
there is no confusion about the relationship between HTTP/2.0 and SPDY as
we do not want to have dueling specifications in this area.$

The paranoia is well justified I think given how other notable specs have
developed recently. I think it would be great to know if the existing SPDY
folks are intending to continue parallel development on SPDY or go all in
working on http 2.0.

- James

---

From: Jonathan Ballard <[email-masked]>
Date: Sat, 4 Aug 2012 18:02:49 -0700

Embedded systems is easier stated than direct reference or incorporation of
all listed areas. It made sense for highly scalar processors where each
core unit has its own vectors. In that sense we can then specify at which
level remains stateless or how that paradigm shifts.

On Saturday, August 4, 2012, Mike Belshe wrote:

> [email-masked] <javascript:_e({}, 'cvml',
> [email-masked]');>> wrote:
>
>> Mark
>>
>> 1) Clarify the relationship to SPDY, especially the ongoing work on SPDY
>> 3 and the upcoming 4. We don't want to get in a situation with dueling
> I think Mark was trying to confine our goals more than this.   Of course
> it is true that things will come up as we go, but it is better if we can
>> * Not require multiple connections to a server to enable parallelism,
>> thus  improving its use of TCP, especially regarding congestion control.
>> * Retain the semantics of HTTP/1.1, leveraging existing documentation
>> (see  above), including (but not limited to) HTTP methods, status codes,
>> URIs, and  where appropriate, header fields.
> I think you're looking for 'reasonableness' - such that HTTP/2.0 works
> with most existing systems.  I am too.
>
> Finally, it will incorporate relev
>
>
>

---

From: "Adrien de Croy" <[email-masked]>
Date: Sun, 05 Aug 2012 23:20:21 +0000

------ Original Message ------
From: "Poul-Henning Kamp" <[email-masked]>
>Where does 2.0<-->1.1 conversion _realistically_ come into play ?

You mean where are we most likely to see 2.0 down-graded to 1.1?

I think this will be extremely common for a very long time.

2.0 client talks to 2.0 local proxy talking to 1.1 internet.

So the proxy is going to have to handle the discovery of server 
protocol support.  What fun!

Adrien

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 06 Aug 2012 07:11:35 +0000

In message <emc0d9c202-4de9-42a4-afcd-3e0714b94f4b@reboist>, "Adrien de Croy" w

>2.0 client talks to 2.0 local proxy talking to 1.1 internet.

That's not a terribly interesting use-case is it ?

The RTT to a local proxy is not prohibitive, so running HTTP/2.0
on that path will gain you very little performance, and insisting
on running both 2.0 and 1.1 would cost very little, since the
link is very likely a LAN.

So yeah, you have a shiny new protocol, but it doesn't do anything
for you...

(The GET https://... thing can be done as extension to 1.1 also,
so that is not a deciding factor)

The RTT performance gain of 2.0 only happens once 2.0 deploys on
the far (ie: server) side of things.

So I think the interesting use-case is the opposite of what
you suggest: 1.1 to proxy, 2.0 to server.

About the only other place I see a credible case for conversion
is a 1.1+2.0 load-balancer and a 1.1- or 2.0- only server.

The 2.0->1.1 case I can conceiveably see, in a somewhat strange set
of circumstances, but the 1.1->2.0 case seems entirely speculative
for the next many years.

Given how much simpler it will be for everybody, I still see a
"same version, end to end" model as very attractive.

Of course 1.1 and 2.0 must still interoperate, in particular we
need to be able to upgrade (and later downgrade ?) on port 80.

But I really have a hard time seeing the a business-case for
specifying conversion of individual requests and responses between
1.1 and 2.0.

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 6 Aug 2012 10:37:54 +0200

> link is very likely a LAN.

This use case should prevail in mobile environments. Your smartphone
should have an explicit proxy configured (instead of passing via an
interception proxy) that will also save it from round trips caused
by DNS requests. I really think that the biggest savings we could
expect from 2.0 and by far is to have smartphones communicate via
their operator's explicit proxies.

Regards,
Willy

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 06 Aug 2012 08:45:36 +0000

>by DNS requests.

But is 1.1 vs. 2.0 proxy really going to make that much of a difference ?

---

From: Robert Collins <[email-masked]>
Date: Mon, 6 Aug 2012 20:51:22 +1200

> But is 1.1 vs. 2.0 proxy really going to make that much of a difference ?

Yes, absolutely.

The key bits are:
 - Fix HoL blocking
 - Only require one TCP connection
 - Define a mechanism for advising clients of the proxy to use

Transparent proxies pay TCP setup and window opening etc on each site.
Non-transparent proxies aren't trivially offered today.
Head of line blocking affects mobile significantly, and even a 2.0
proxy doing 1.1 conversion could support client driven prioritisation
amongst the N backend connections *it* is making. [BTW: this seems
like yet another reason to have clients drive the HoL prioritisation
stuff].

-Rob

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 6 Aug 2012 10:57:16 +0200

> But is 1.1 vs. 2.0 proxy really going to make that much of a difference ?

The 1.1 to 2.0 proxy is not going to help a lot, but the 2.0 client to 2.0
proxy to 1.1 internet that Adrien was talking about above is going to be
the biggest immediate win. I predict that we will see them appear before
the protocol is finalized. With a 300ms RTT on the air medium and around
10ms on the wire, you can safely expect that if a client is able to send
all requests at once so that the proxy parallelizes them to 1.1 hosts on
"infinite bandwidth" links, it would be foolish not to deploy it.

Willy

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 06 Aug 2012 08:56:58 +0000

In message <CAJ3HoZ05gRkZz_i-=[email-masked]>

> - Only require one TCP connection

So how does that work for protected content ?

Is this assuming per-message protection (at least when you talk to
a proxy) or does these advantages only extend to unprotected content ?

---

From: Roberto Peon <[email-masked]>
Date: Mon, 6 Aug 2012 09:05:12 -0700

That (http2 client  -> http2 proxy -> http1 server) could be beneficial for
mobile devices in terms of both latency and battery life, so it isn't
something we should dismiss.

-=R

---

From: James M Snell <[email-masked]>
Date: Mon, 6 Aug 2012 10:14:17 -0700

On Mon, Aug 6, 2012 at 9:05 AM, Roberto Peon <[email-masked]> wrote:

> That (http2 client  -> http2 proxy -> http1 server) could be beneficial
> for mobile devices in terms of both latency and battery life, so it isn't
Indeed. There certainly is a very reasonable case for protocol
translation... what I'm not convinced of is just how automatic and
transparent that translation needs to be considering the various use cases.

For instance, I would wager that the overwhelming majority of "normal" web
traffic -- that of browsers accessing your typical web site -- is generally
predictable and static. There are generally a known, limited set of
headers, a known set of authentication schemes, a known set of patterns
that can be easily translated to and from, at scale, at the proxy level.
These are things that we can optimize the hell out of.  For the more exotic
kinds of traffic, things that are specific to individual services or apis,
the client side developer will typically be in lock step with the server
side development. There will be older downlevel client applications that
are hard coded to use HTTP 1.1 and won't ever be changed (so even if those
are forced through an explicit proxy, they'll still be talking 1.1 end to
end). If the server side of an HTTP API still requires 1.1, there's going
to be extremely little motivation on the part of the client side developer
to change the client side to 2.0 *until the server side also changes*. In
fact, I would wager to say that client application developers simply will
NOT change their side until the server side changes. For such cases,
protocol translation is likely going to be unnecessary.

There are ways of making this more explicit tho.  If I, as a client using
HTTP/2.0 send a message to the proxy that includes a :version=1.1 header in
the request, what I'd basically be saying is that this HTTP Request
conforms to the semantics and the basic rules of HTTP 1.1, meaning that it
should be directly and easily translatable into an HTTP/1.1 message. If,
however, I include :version=2.0 in the request, I'm explicitly stating that
I'm using 2.0 semantics that may or may not be directly translatable into
an HTTP/1.1 message... in which case, unless I know I'm definitely talking
to an HTTP/2.0 server, I fully recognize and accept that things might
break. By default, Web browsers can be configured to operate with this
"compatibility mode" for a while, sending :version=1.1 by default for all
general requests; while allowing applications the option of sending
:version=2.0.

That would seem to be a perfectly reasonable approach.

- James

---

From: Mike Belshe <[email-masked]>
Date: Mon, 6 Aug 2012 11:30:19 -0700

On Sat, Aug 4, 2012 at 5:41 PM, James M Snell <[email-masked]> wrote:

> >> Work will begin using draft-mbelshe-httpbis-spdy-00 as a starting
> point; proposals are to be expressed in terms of changes to that document.
> Note that consensus is required both for changes to the document and
> anything that remains in the document.
> >>

Firefox and Chrome are committed to HTTP/2.0, it will happen.  But, Mark's
current outline for HTTP/2.0 is a 2 year effort.  There are research areas
in progress today which aren't ready for standardization yet (so they don't
belong in HTTP/2.0) and that research will continue.  It's not competing
specs - its just ongoing research.

mike

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 8 Aug 2012 10:14:24 +0300

> interception proxy) that will also save it from round trips caused
I agree,
however to be honest the fact that a smartphone does not have an explicit
proxy configured and instead it use an interception proxy is only
due to the 3GPP spec or to me more correct on how the 3GPP spec is 
implemented
in mobile environments

> I really think that the biggest savings we could
right,
and for this we need to make sure that also in 2.0 will be possible
to discover and configure an explicit proxy to use

br
Salvatore

-- 
Salvatore Loreto, PhD
www.sloreto.com

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 8 Aug 2012 10:26:18 +0300

On 8/6/12 7:05 PM, Roberto Peon wrote:
>
> That (http2 client  -> http2 proxy -> http1 server) could be 
> beneficial for mobile devices in terms of both latency and battery 
> life, so it isn't something we should dismiss.
>
indeed it is an area I would like we explicitly call out within the 
*charter* with the two following distinct bullets

* define a 2.0 mechanism for advising clients of the proxy to use

* http2 -> http1 interaction

/Sal

-- 
Salvatore Loreto, PhD
www.sloreto.com

> -=R
>
> On Aug 6, 2012 12:14 AM, "Poul-Henning Kamp" <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     >>From: "Poul-Henning Kamp" <[email-masked]
>     <mailto:[email-masked]>>
>     >>

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 8 Aug 2012 13:51:27 +0300

On 8/5/12 3:23 AM, Mike Belshe wrote:
>
>     The resulting specification(s) are expected to be meet these goals
>     for common existing deployments of HTTP; in particular, Web
>     browsing (desktop and mobile), non-browsers ("HTTP APIs"), Web
>     serving (at a variety of scales), and intermediation (by proxies,
>     corporate firewalls, "reverse" proxies and Content Delivery Networks).
>
> covered in "expected to meet these goals for common existing 
> deployments of HTTP".  Embedded systems are common today and will 
> naturally be a big part of HTTP/2.0.  If we call them out, do we need 
> to start listing all the other common uses of HTTP? :-)

this is something that perhaps the charter should define clearly 
removing all the ambiguities:
what are the "common existing deployments" the wg will take in 
consideration?
The current charter tries to clearly list what will be considered.

I don't have a strong opinion on this,
but I don't think we should consider "all the other common uses of HTTP" 
for 2.0, they are to many that are common to different degrees

Salvatore

-- 
Salvatore Loreto, PhD
www.sloreto.com

---

From: David Morris <[email-masked]>
Date: Wed, 8 Aug 2012 15:19:35 -0700 (PDT)

> * define a 2.0 mechanism for advising clients of the proxy to use

I see this as a system configuration issue and not really a problem
to be solved by the HTTP working group. It is very much a chicken/egg
problem.

Beyond that, this problem is nearly solved for iPhones with the provision
for defining a proxy in APNs. VPN mobile configs also provide for
definition of a proxy. I don't know other devices, but APNs look
like they might be a general solution which transcend the iPhone.

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 09 Aug 2012 14:59:54 +1200

>> * define a 2.0 mechanism for advising clients of the proxy to use

+1.

> like they might be a general solution which transcend the iPhone.

Right now we have the usual industry-driven mess of a half dozen *not 
quite working* semi-proprietary methods. Admin wanting to setup an 
explicit proxy have to implement most of them. Client developers wanting 
to add proxy support have to implement most of them - just in case. And 
few people can really be bothered with that much work.

The APN method you point at being specific to iPhones makes it yet 
another vendor-specific variant to implement alongside UNIX "http_proxy" 
environment setting, Windows Group Policy proxy settings, WPAD DHCP 
lookup, WPAD DNS lookup, manual editing of config settings for hundreds 
of apps per user machine ... "bugger it just MITM port 80 and be done".

   See the problem there?

The WG needs to do something such as:
* picking up the WPAD draft and making it a proper standard,
* defining a standard SRV record,
* defining multi/broad-cast IP for proxies to listen on a port there,
* defining a standard proxy port (IANA registers a few dozen 
proprietary ports)
* a _standard_ mix of the above?
* something else?

The key thing being that we end up with a simple standard way to do it. 
When that happens we have one more axe to chip away at the MITM 
desirability.

All fine and dandy using APN on cellular networks. So long as it works 
dependably across device vendors, and the delivery of the details to the 
application software also has a standard interface for developers to use 
(libproxy is helping here but still not widely used).

Sure, we can't force everybody to follow the standard. But at least 
there will be an agreed standard to work from and point at when things 
go wrong.

Amos

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Thu, 09 Aug 2012 03:22:13 +0000

------ Original Message ------
From: "Amos Jeffries" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Sent: 9/08/2012 2:59:54 p.m.
Subject: Re: Moving forward with HTTP/2.0: proposed charter

+1
>explicit proxy have to implement most of them. Client developers 
>wanting to add proxy support have to implement most of them - just in 
>case. And few people can really be bothered with that much work. 
>
>another vendor-specific variant to implement alongside UNIX 
>"http_proxy" environment setting, Windows Group Policy proxy settings, 
>WPAD DHCP lookup, WPAD DNS lookup, manual editing of config settings 
>for hundreds of apps per user machine ... "bugger it just MITM port 80 
>and be done". 

there's also UPnP :)

It's a mess.  From a proxy vendor POV, it's a bit of a nightmare.

However, most discovery mechanisms don't use HTTP, at least not for 
everything.

However, if we had a new status code to indicate that intercepted 
connections were not permitted, then the client could go off and do 
discovery.

The response could even include a URL for a WPAD config script.

And before people suggest this opens huge holes to redirect people via 
nasty proxies over the internet...

well, any browser author that wrote code that blindly used a proxy they 
discovered through this method, without any sort of check to see if 
it's valid (e.g. should only be on their LAN), should be put up against 
the wall.

This is why I think the argument against 305, which caused it to be 
deprecated I think were a bit bogus.  They ignored the fact that the 
browser still gets to choose, and can do something a bit smarter.  Not 
that any client implemented 305 support though, but if it had been 
properly scoped out, I think it could have been more palatable, and 
therefore usable.

Adrien
>The key thing being that we end up with a simple standard way to do 
>it. When that happens we have one more axe to chip away at the MITM 
>desirability. 
>
>
>dependably across device vendors, and the delivery of the details to 
>the application software also has a standard interface for developers 
>to use (libproxy is helping here but still not widely used). 
>

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 09 Aug 2012 15:52:45 +1200

On 09.08.2012 15:22, Adrien W. de Croy wrote:
>>>Beyond that, this problem is nearly solved for iPhones with the 
>>> provision for defining a proxy in APNs. VPN mobile configs also 
>>> provide for definition of a proxy. I don't know other devices, but 
>>> APNs look like they might be a general solution which transcend the 
>>> iPhone.
>>
>>

Urrr.

> And before people suggest this opens huge holes to redirect people
> via nasty proxies over the internet...
>
> well, any browser author that wrote code that blindly used a proxy
> they discovered through this method, without any sort of check to see
> if it's valid (e.g. should only be on their LAN), should be put up
> against the wall.
>

305 sounds fine until you get to that "single request" statement.

Other requests for even other files on the same server are not to be 
fetched from the proxy by default. I don't really see the usefulness for 
that limitation. Ootherwise as you say its just a server negotiating use 
of a proxy, the browser is free to do whatever it needs in the way of 
security or alternatives.

The big stickler is that to operate, it does require an MITM. Which is 
a bit like mandating MITM in an IETF document.

An ICMP rejection code or some such which can be trivially sent by 
firewalls on the TCP SYN without MITM of the HTTP layer would be a much 
better implementation for this type of bounce. It would also work for 
both HTTP and HTTPS without breaking either ones security model.

Amos

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 9 Aug 2012 09:51:12 +0300

On 8/9/12 6:22 AM, Adrien W. de Croy wrote:
> From: "Amos Jeffries"<[email-masked]>
> To:"[email-masked]"  <[email-masked]>
>>> >>provision

I concur that Mobile telecom networks have to provide a standard way for 
advising clients
of the proxy to use i.e. in APNs or during DHCP lookup

perhaps the wg should liaise with e.g. 3GPP  on this issue .

Having said that,
I do think the wg should also work (in its 2.0 effort)
on a standard mechanism to easily discover and setup an explicit proxy

/Sal

> there's also UPnP:)