Subject: Straw-man for our next charter

From: Mark Nottingham <[email-masked]>
Date: Wed, 25 Jul 2012 17:53:53 +1000

Next week in Vancouver, we'll discuss both the candidate proposals for HTTP/2.0 and whether we should re-charter to begin that work, confirming consensus on the list afterwards. 

Assuming we do choose one, we'll also need to discuss the charter itself. To facilitate that, I've pasted a straw-man of what such a charter might look like below.

Please familiarise yourself with it. We can discuss on-list beforehand, of course, but please realise that we need to do this step-by-step, so don't get too far ahead of the conversation. 

Note -- this currently JUST covers the protocol discussion, not the authentication half; I've omitted it because there are a few different ways that work might end up, and it's going to need discussion before we can write even straw-man charter text.

Cheers,

---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 XXX as a starting point; all proposals are to be expressed
in terms of changes to the that document.

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.
* Not require multiple connections to a server to enable parallelism.
* Require no more configuration or tuning than current HTTP deployments; 
   preferably, less.
* 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), Web serving (at a variety of scales), and intermediation (by proxies,
corporate firewalls, "reverse" proxies and Content Delivery Networks).

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 protocols. Note that it
  is expected that the Working Group will define how the protocol is used
  with the TLS protocol.
* Specifying new semantics for HTTP (whether specific to HTTP/2 or not). 
  However, the Working Group may request a re-charter to start work on such
  items (during or after work on HTTP/2.0), provided there is consensus to
  do so, and it does not interfere with work on the "core" (both HTTP/1.x and
  HTTP/2.0).
    
The Working Group will prioritize HTTP/1.1 work until it is complete.

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
Sep 2012	Working Group Last Call for HTTP Security Properties
Sep 2012	Working Group Last Call for HTTP/1.1 Revision
Sep 2012	First WG draft of HTTP/2.0, based upon XXX
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
Dec 2013	Working Group Last call for HTTP/2.0
Apr 2014	Submit HTTP/2.0 to IESG for consideration as a Proposed Standard
--->8---

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

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 25 Jul 2012 08:16:05 +0000

In message <[email-masked]>, Mark Nottingham wri
tes:

>Assuming we do choose one, we'll also need to discuss the charter 
>itself. To facilitate that, I've pasted a straw-man of what such a 
>charter might look like below.

>* Substantially and measurably improve end-user perceived latency[...]

I miss something about general efficiency (ie: loosing the non
length-prefixed fields):

  * Be optimized for computers efficiency, rather than human readability.

DoS-resistance should be an explicit goal too:

  * Provide stronger DoS resistance than HTTP/1.1, without impacting user
    perceived performance.

And I think we should aim for message protection rather than
connection protection, in order to avoid the HTTP->HTTPS upgrade
needing a new connection, and to make life easier for HTTP routers:

  * Use message based cryptographic protection, rather than connection
    based cryptographic protection.

>  is expected that the Working Group will define how the protocol is used

Given that HTTP/2.0 primarily will be an alternate transport protocol,
I find this bullet needs a rewrite:

  * Specifying transport protocols other than TCP and possibly TLS.

-- 
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: Julian Reschke <[email-masked]>
Date: Wed, 25 Jul 2012 11:45:45 +0200

> * A document cataloguing the security properties of HTTP/1.1

If we are serious about that one, we'll need to restart work on it :-)

> ...

+1000

> ...

This one appears to be very optimistic.

 > ...

Best regards, Julian

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 26 Jul 2012 00:02:32 +1200

> in terms of changes to the that document.

I just think I'll throw a spanner in the general direction of the works 
here....

How realistic is it to expect the HTTPbis 1.1 draft documents fill that 
role? At least we can guarantee that modifications to adjust them for 
2.0 specifics will not loose or add any features unintentionally that 
could affect HTTP/1.1 compatibility.

>    cases, over HTTP/1.1 using TCP.

"measureably ... perceived" does not stack up.
Surely we can aim for actual measurable efficiency rather than just 
perceived.

Possibly also improvement over *optimized* 1.1 would be a good aim.

> * Not require multiple connections to a server to enable parallelism.
+1.

> * Require no more configuration or tuning than current HTTP deployments;

What do you means by this?

>    where appropriate, header fields.

see above regarding "XXX as a starting point".

> * Clearly identify any new extensibility points and policy for their

+1.

>    do so, and it does not interfere with work on the "core" (both HTTP/1.x and

+1. Although I predict that having multiplexing on the table will bring 
up the need for new hop-by-hop features on 2.0 connections. Specifically 
flow control features.

Amos

---

From: James M Snell <[email-masked]>
Date: Wed, 25 Jul 2012 07:13:32 -0700

On Wed, Jul 25, 2012 at 12:53 AM, Mark Nottingham <[email-masked]> wrote:

> [snip]

[snip]

I do not believe new semantics should be entirely out of scope within the
new charter. Particularly in that there are opportunities to..

A) Utilize the transport more efficiently through the use of
binary-encodings of header fields
B) Improve internationalization support by requiring UTF-8 in
character-based header values
C) Improve intermediary support through the introduction of protocol-level
routing tokens that can begin to replace the clumsy and hackish use of
cookies
D) Explore the possibility of in-stream encryption and integrity mechanisms
such as my proposed SPDY KEY_NEGO frame.
E) Provide for millisecond-level resolution within date headers,
particularly Last-Modified and If-Modified-Since
F) Require support for trailing headers

And I'm sure there are others that simply aren't coming to mind at the
moment. Yes, each possible change or addition to existing semantics would
need to be carefully considered with backwards compatibility in mind, and
we would need to carefully consider each individual change.

---

From: "Eric J. Bowman" <[email-masked]>
Date: Wed, 25 Jul 2012 13:36:40 -0600

Mark Nottingham 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), Web serving (at a variety of scales), and
> intermediation (by proxies, corporate firewalls, "reverse" proxies
> and Content Delivery Networks).
> 

Please change "CDNs" to "caches" to avoid confusion over whether we're
talking about a new architectural style.  "Caches" can include CDNs,
but CDNs does not include the shared-cache architecture which got the
Web where it is.

-Eric

---

From: "Ludin, Stephen" <[email-masked]>
Date: Thu, 26 Jul 2012 13:26:58 -0500

>but CDNs does not include the shared-cache architecture which got the

If we want to refine Mark's text that then equating a CDN to a cache is
not accurate.  Today's CDNs do cache, but they more importantly provide
acceleration, optimized routing, security, edge logic, content assembly,
and content modification just to name a few.  Rather than open that can of
worms, I think keeping CNDs in the proposed straw-man text would be
better.  

Alternatively, we drop the parenthetical list and just go with
'intermediation'.

-stephen

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 27 Jul 2012 15:23:20 +1000

> If we are serious about that one, we'll need to restart work on it :-)

That's another thing that's likely to be discussed in Vancouver.

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 27 Jul 2012 15:27:30 +1000

Hi Amos,

On 25/07/2012, at 10:02 PM, Amos Jeffries <[email-masked]> wrote:
> I just think I'll throw a spanner in the general direction of the works here....
> 
> How realistic is it to expect the HTTPbis 1.1 draft documents fill that role? At least we can guarantee that modifications to adjust them for 2.0 specifics will not loose or add any features unintentionally that could affect HTTP/1.1 compatibility.

I'm not sure what your concern is here... 

> Surely we can aim for actual measurable efficiency rather than just perceived.
> 

Yes; there's some interesting discussion to be had here, I imagine.

> +1. Although I predict that having multiplexing on the table will bring up the need for new hop-by-hop features on 2.0 connections. Specifically flow control features.

Yes, and I think that's OK; what I want to avoid (and we can work on language around this) is making material changes to the abstraction that HTTP presents to applications; i.e., necessitating changes in HTTP APIs. Of course, abstractions are leaky (e.g., optimisations around connections leak through), and we can't prevent that.

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 27 Jul 2012 15:42:57 +1000

On 26/07/2012, at 12:13 AM, James M Snell <[email-masked]> wrote:

> I do not believe new semantics should be entirely out of scope within the new charter. Particularly in that there are opportunities to..
> 
> A) Utilize the transport more efficiently through the use of binary-encodings of header fields
> B) Improve internationalization support by requiring UTF-8 in character-based header values
> C) Improve intermediary support through the introduction of protocol-level routing tokens that can begin to replace the clumsy and hackish use of cookies
> D) Explore the possibility of in-stream encryption and integrity mechanisms such as my proposed SPDY KEY_NEGO frame.
> E) Provide for millisecond-level resolution within date headers, particularly Last-Modified and If-Modified-Since
> And I'm sure there are others that simply aren't coming to mind at the moment. Yes, each possible change or addition to existing semantics would need to be carefully considered with backwards compatibility in mind, and we would need to carefully consider each individual change. 

Without going into the specific issues, I'm going to push back strongly on anything that changes the abstraction of HTTP, or that could be layered onto HTTP/1 and /2 as an extension.

We need to stay focused.

That said, note that there is an option in there to expand scope *cautiously* when we think it's worthwhile.

Cheers,

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 27 Jul 2012 18:10:10 +1200

> I'm not sure what your concern is here...

concern 1) is the feature parity between the HTTP/1 drafts and any other 
document that gets picked. ie workload to get the new doc completed.

concern 2) is the politcal battle to get document X to meet the WG goals.

Much like what I said in my expression of interest summary. The HTTP/2 
drafts on the tables (own one included) do not come up to scratch for 
HTTP/2 starting points.

I know a lot of people have interest in SPDY, but to make that the 
HTTP/2 base doc there are a fair chunk of things which will need pruning 
out - if only because they are new semantics. It is probably not a good 
idea for the WG to start off facing that political battle to ensure its 
semantically seamless to HTTP/1.1. The other documents are bare-bones 
with specific focus on framing improvement over WG drafts part1-2.

However taking the HTTPbis draft documents and replacing sections of 
them with SPDY mechanisms, frame design, etc as we agree on particulars 
- that has a clear chance of faster success.

Amos

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 27 Jul 2012 16:14:44 +1000

On 27/07/2012, at 4:10 PM, Amos Jeffries <[email-masked]> wrote:

> concern 1) is the feature parity between the HTTP/1 drafts and any other document that gets picked. ie workload to get the new doc completed.
> 
> Much like what I said in my expression of interest summary. The HTTP/2 drafts on the tables (own one included) do not come up to scratch for HTTP/2 starting points.
> 
> I know a lot of people have interest in SPDY, but to make that the HTTP/2 base doc there are a fair chunk of things which will need pruning out - if only because they are new semantics. It is probably not a good idea for the WG to start off facing that political battle to ensure its semantically seamless to HTTP/1.1. The other documents are bare-bones with specific focus on framing improvement over WG drafts part1-2.

Aha. I was assuming that would come up; please discuss (details would help).

> However taking the HTTPbis draft documents and replacing sections of them with SPDY mechanisms, frame design, etc as we agree on particulars - that has a clear chance of faster success.

That's an interesting approach. 

Cheers,

---

From: Rob Trace <[email-masked]>
Date: Fri, 27 Jul 2012 21:30:08 +0000

+1.  Starting from 1.1 is an interesting approach and worth discussing.

Thanks!!

-Rob

-----Original Message-----
From: Mark Nottingham [mailto:[email-masked]] 
Sent: Thursday, July 26, 2012 11:15 PM
To: Amos Jeffries
Cc: [email-masked]
Subject: Re: Straw-man for our next charter

On 27/07/2012, at 4:10 PM, Amos Jeffries <[email-masked]> wrote:

>>>> Work will begin using XXX as a starting point; all proposals are to 
>>>> be expressed in terms of changes to the that document.

Cheers,

---

From: Larry Masinter <[email-masked]>
Date: Fri, 27 Jul 2012 21:34:49 -0700

I'd suggest the HTTP/2.0 work would be best served by first focusing on documenting "substantial and measurable improvement".
I suggest the charter not be extended to accept proposals and start on development of the protocol itself until this is done.

There are conflicting characterizations of SPDY performance results (the results aren't in conflict as much as whether you could summarize the results as "better"). 
    http://www.ietf.org/proceedings/83/slides/slides-83-httpbis-3.pdf  said  "Google recently reported that SPDY over SSL is now faster than HTTP without SSL" plus "BoostEdge paper confirms Google numbers", which I'd take to mean that it's always faster.

   but  http://www.guypo.com/technical/not-as-spdy-as-you-thought/  it isn't as SPDY as you (Someone) thought, and noted many circumstances where it didn't help.

Unless there's agreement on what "improvement" is, it's hard to even discuss features for how well they "improve".

What can site administrators depend on, expect from a SPDY upgrade? 

I'm still concerned about head-of-line blocking that comes from multiplexing and doing flow control at two levels of the protocol stack. It seems intrinsically a likely problem, for which the only solution is proper management and control of performance of all of the sources of data ("scheduling").  I think getting an agreement on why that isn't a problem here (or at least, how to minimize the problem) first would help, too.
With head-of-line blocking, the latency has spikes, and averages won't suffice if what you care about is common-worst-case.

Larry
--
http://larry.masinter.net

-----Original Message-----
From: Amos Jeffries [mailto:[email-masked]] 
Sent: Wednesday, July 25, 2012 5:03 AM
To: [email-masked]
Subject: Re: Straw-man for our next charter

+1.

+1.

Amos

---

From: Yutaka OIWA <[email-masked]>
Date: Sun, 29 Jul 2012 16:13:30 +0900

Dear Mark,

Regarding http authentication,
do we have some specific materials to prepare for the Tuesday's session?
Just a discussion?

I'm looking forward to seeing all of you in Vancouver.

-- 
Yutaka OIWA, Ph.D.              Leader, Software Reliability Research Group
                             Research Institute for Secure Systems (RISEC)
   National Institute of Advanced Industrial Science and Technology (AIST)
                     Mail addresses: <[email-masked]>, <[email-masked]>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Sun, 29 Jul 2012 00:14:02 -0700

Without re-hashing what's already been said, I'll point out that the "Not
as SPDY as You Thought" isn't a test of "what performance do we get in a
world of SPDY" but rather "What performance do we get in a world of partial
SPDY deployment." Mike has a nice in-depth writeup at
http://www.belshe.com/2012/06/24/followup-to-not-as-spdy-as-you-thought/

-Ian

On Fri, Jul 27, 2012 at 9:34 PM, Larry Masinter <[email-masked]> wrote:

> I'd suggest the HTTP/2.0 work would be best served by first focusing on
> documenting "substantial and measurable improvement".
> I suggest the charter not be extended to accept proposals and start on
> development of the protocol itself until this is done.
>
> There are conflicting characterizations of SPDY performance results (the
> results aren't in conflict as much as whether you could summarize the
> results as "better").
>     http://www.ietf.org/proceedings/83/slides/slides-83-httpbis-3.pdf said  "Google recently reported that SPDY over SSL is now faster than HTTP
> without SSL" plus "BoostEdge paper confirms Google numbers", which I'd take
> to mean that it's always faster.
>
>    but  http://www.guypo.com/technical/not-as-spdy-as-you-thought/  it
> isn't as SPDY as you (Someone) thought, and noted many circumstances where
> it didn't help.
>
> Unless there's agreement on what "improvement" is, it's hard to even
> discuss features for how well they "improve".
>
>
> I'm still concerned about head-of-line blocking that comes from
> multiplexing and doing flow control at two levels of the protocol stack. It
> seems intrinsically a likely problem, for which the only solution is proper
> management and control of performance of all of the sources of data
> ("scheduling").  I think getting an agreement on why that isn't a problem
> here (or at least, how to minimize the problem) first would help, too.
> With head-of-line blocking, the latency has spikes, and averages won't
> suffice if what you care about is common-worst-case.
>
> Larry
> --
> > Next week in Vancouver, we'll discuss both the candidate proposals for
> HTTP/2.0 and whether we should re-charter to begin that work, confirming
> consensus on the list afterwards.
> >
> itself. To facilitate that, I've pasted a straw-man of what such a charter
> might look like below.
> >
> > Please familiarise yourself with it. We can discuss on-list beforehand,
> of course, but please realise that we need to do this step-by-step, so
> don't get too far ahead of the conversation.
> >
> > Note -- this currently JUST covers the protocol discussion, not the
> authentication half; I've omitted it because there are a few different ways
> that work might end up, and it's going to need discussion before we can
> write even straw-man charter text.
> >
> > Cheers,
> >
> > ---8<---

---

From: Larry Masinter <[email-masked]>
Date: Sun, 29 Jul 2012 10:45:07 -0700

Your post is consistent with the assertion that there isn't agreement yet about what "faster than HTTP/1.1" means, or how to compare proposals for improvement. And neither measured worst case latency or real network traffic with buffer bloat, or situations that would detect the impact of HOL blocking.

Features like sniffing where the receiver needs to look at initial segments of traffic before dispatching exacerbate the impact of uneven latency by imposing an otherwise unnecessary serialization constraint.

deployment issues are in scope... they are what drive the push for SSL in the first place.

And if sites wont see improvement  (or even a performance hit) in a world of partial deployment of HTTP 2.0, who (that isn't already using SPDY as is) would deploy it?

-----Original message-----
From: "[email-masked]" <[email-masked]>
To: Larry Masinter <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: Sun, Jul 29, 2012 07:14:02 GMT+00:00
Subject: Re: Straw-man for our next charter

Without re-hashing what's already been said, I'll point out that the "Not as SPDY as You Thought" isn't a test of "what performance do we get in a world of SPDY" but rather "What performance do we get in a world of partial SPDY deployment." Mike has a nice in-depth writeup at http://www.belshe.com/2012/06/24/followup-to-not-as-spdy-as-you-thought/

-Ian

On Fri, Jul 27, 2012 at 9:34 PM, Larry Masinter <[email-masked]<mailto:[email-masked]>> wrote:
I'd suggest the HTTP/2.0 work would be best served by first focusing on documenting "substantial and measurable improvement".
I suggest the charter not be extended to accept proposals and start on development of the protocol itself until this is done.

Larry

-----Original Message-----
From: Amos Jeffries [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, July 25, 2012 5:03 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: Straw-man for our next charter

+1.

+1.

Amos

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 29 Jul 2012 11:55:32 -0700

So, we need to have some more detail here.

My take is that we're already implicitly starting from HTTP/1.1. I.e., I'd be very surprised (and concerned) if we found ourselves rewriting any of parts 2-7; all of our changes *should* be confined to part 1. 

And, while I can imagine starting from part 1 and changing it section-by-section, I do wonder if it offers significant benefit over writing something that just aims to replace p1.

All of that said -- it's pretty clear that the current proposals are not written as analogues to p1, and probably need to move in that direction.

Cheers,

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

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 29 Jul 2012 11:56:36 -0700

Hello,

At this point, I think it's just discussion; I'm still talking to the Security ADs and others about how to get the most benefit from our time together. 

Cheers,

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

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 29 Jul 2012 12:25:48 -0700

> Unless there's agreement on what "improvement" is, it's hard to even discuss features for how well they "improve".

The short answer is that we'll know that it's good enough when we have rough consensus that it's good enough. 

Now, if someone wants to propose a set of measurements that are openly defined with an open implementation that anyone can run repeatably, we can try to get consensus around including those as exit criteria. 

However, no one has yet produced them, and I'm wary of doing that kind of work post-charter; we'll get caught up in an endless debate.

Hence, rough consensus.

> I'm still concerned about head-of-line blocking that comes from multiplexing and doing flow control at two levels of the protocol stack. It seems intrinsically a likely problem, for which the only…

Proving a negative is notoriously difficult; can you prove it *is* a problem? I think this needs discussion, but the easiest way to move it forward is to demonstrate the issue.

Regards,

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

---

From: Amos Jeffries <[email-masked]>
Date: Mon, 30 Jul 2012 11:36:28 +1200

On 30.07.2012 06:55, Mark Nottingham wrote:
> My take is that we're already implicitly starting from HTTP/1.1.
> I.e., I'd be very surprised (and concerned) if we found ourselves
> rewriting any of parts 2-7; all of our changes *should* be confined 
> to
> part 1.
>

I do see us writing an "HTTP 1.1 and 2.0 translation" document though 
which updates P2-7.

> And, while I can imagine starting from part 1 and changing it
> section-by-section, I do wonder if it offers significant benefit over
> writing something that just aims to replace p1.
>
> All of that said -- it's pretty clear that the current proposals are
> not written as analogues to p1, and probably need to move in that
> direction.
>
> Cheers,

+100. Ack.

AYJ

---

From: Mike Belshe <[email-masked]>
Date: Mon, 30 Jul 2012 21:04:36 -0700

On Sun, Jul 29, 2012 at 10:45 AM, Larry Masinter <[email-masked]> wrote:

> Your post is consistent with the assertion that there isn't agreement yet
> about what "faster than HTTP/1.1" means, or how to compare proposals for
> improvement. And neither measured worst case latency or real network
> traffic with buffer bloat, or situations that would detect the impact of
> HOL blocking.
>

While SPDY leaves a tiny HOL issue, it fixes the massive one from HTTP/1.1,
which can only load a couple of resources in parallel per domain (2 by
spec, 6 by implementation best practices).  The tradeoff turns out to be a
boon in terms of reduced latency while also using fewer network resources.

I haven't seen any data that suggests otherwise.  Did I miss something?

For bufferbloat, using 1 TCP connection is strictly better than many - TCP
implementations don't throttle with multiple connections in mind; so while
HTTP systematically circumvents slow start by way of more and more
connections, SPDY embraces TCP's throttling and enables future enhancements
at the transport layer.

> Features like sniffing where the receiver needs to look at initial
> segments of traffic before dispatching exacerbate the impact of uneven
> latency by imposing an otherwise unnecessary serialization constraint.
>

> And if sites wont see improvement  (or even a performance hit) in a world
> of partial deployment of HTTP 2.0, who (that isn't already using SPDY as
> is) would deploy it?
>

We should expect that on the road to full deployment of HTTP/2.0 we will
see partial deployment of HTTP/2.0.  It seems perfectly fine to me that as
you deploy it more completely the benefit increases.

Mike

> *From: *"[email-masked]" <[email-masked]>*
> To: *Larry Masinter <[email-masked]>*
> Cc: *"[email-masked]" <[email-masked]>*
> Sent: *Sun, Jul 29, 2012 07:14:02 GMT+00:00
> *
> Subject: *Re: Straw-man for our next charter
>
> On Fri, Jul 27, 2012 at 9:34 PM, Larry Masinter <[email-masked]>wrote:
>

---

From: Julian Reschke <[email-masked]>
Date: Tue, 31 Jul 2012 09:08:14 +0200

On 31.07.2012 06:04, Mike Belshe wrote:
>
>
> On Sun, Jul 29, 2012 at 10:45 AM, Larry Masinter <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Your post is consistent with the assertion that there isn't
>     agreement yet about what "faster than HTTP/1.1" means, or how to
>     compare proposals for improvement. And neither measured worst case
>     latency or real network traffic with buffer bloat, or situations
>     that would detect the impact of HOL blocking.
>
>
> While SPDY leaves a tiny HOL issue, it fixes the massive one from
> HTTP/1.1, which can only load a couple of resources in parallel per
> domain (2 by spec, 6 by implementation best practices).  The tradeoff
> turns out to be a boon in terms of reduced latency while also using
> fewer network resources.
> ...

"By spec" in RFC 2616, but not in HTTPbis (this has been fixed a LONG 
time ago!).

Best regards, Julian

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 31 Jul 2012 05:40:26 -0700

On Jul 31, 2012, at 00:08, Julian Reschke <[email-masked]> wrote:

> "By spec" in RFC 2616, but not in HTTPbis (this has been fixed a LONG time ago!).

... and that after another year of discussion, apparently:

  HTTPBISt131:
    title: increase connection limit
    target: http://trac.tools.ietf.org/wg/httpbis/trac/ticket/131
    seriesinfo:
      'HTTPBIS ticket': '#131, closed 2009-12-02'
    date: 2008-09-01
  HTTPBISc715:
    target: http://trac.tools.ietf.org/wg/httpbis/trac/changeset/715
    title: Changeset 715
    date: 2009-10-21

(Why I wrote this up: This appears to be news to quite a few people.
In the CoAP review process, we are running into the desire to have the equivalent of a connection limit of 1.)

Grüße, Carsten

---

From: Mike Belshe <[email-masked]>
Date: Tue, 31 Jul 2012 13:19:36 -0700

> "By spec" in RFC 2616, but not in HTTPbis (this has been fixed a LONG time

Alright :-)  spec fine, but still a practical issue in all major browser
implementations today.

mike

---

From: Julian Reschke <[email-masked]>
Date: Wed, 01 Aug 2012 00:17:54 +0200

On 31.07.2012 22:19, Mike Belshe wrote:
>
>
> On Tue, Jul 31, 2012 at 12:08 AM, Julian Reschke <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     On 31.07.2012 06 <tel:31.07.2012%2006>:04, Mike Belshe wrote:
>
>
>
>         On Sun, Jul 29, 2012 at 10:45 AM, Larry Masinter
>         <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>

It's not a spec problem anymore, it's an implementation problem. Adding 
a new spec doesn't solve *that* problem.

Best regards, Julian