Subject: Preliminary agenda for Dallas

From: Mark Nottingham <[email-masked]>
Date: Tue, 10 Mar 2015 14:30:32 +1100

... is at:
  https://github.com/httpwg/wg-materials/blob/gh-pages/ietf92/agenda.md

As always, suggestions, etc. welcome.

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

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 10 Mar 2015 07:03:46 +0000

--------
In message <[email-masked]>, Mark Nottingham wri
>As always, suggestions, etc. welcome.

Who is going to open issues based on Bob Briscoes critique ?

-- 
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: Mark Nottingham <[email-masked]>
Date: Tue, 10 Mar 2015 19:47:00 +1100

Hi PHK,

> On 10 Mar 2015, at 6:03 pm, Poul-Henning Kamp <[email-masked]> wrote:
> 
> --------

Martin will apply editorial suggestions as he’s able (constrained by where we’re at in the process); anything more will need to be an errata, or held for the next update.

We (the IETF) don’t have a “living standard” process, for better or worse. One of the things we as a WG might discuss is how we can collect suggestions / issues for our specs, outside of the errata system (which has some widely-recognised limitations that people are working on now, but even after that it’s likely to be limited). 

This might be as simple as keeping a repo issues list open for collecting those issues, as we’ve done for h1.

Cheers,

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 10 Mar 2015 08:53:15 +0000

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

>Martin will apply editorial suggestions as he's able 
>(constrained by where we're at in the process); anything more 
>will need to be an errata, or held for the next update.

In other words: The WG is going to totally ignore the substance of
the first competent, comprehensive and thorough outside review
HTTP/2.0 has ever received.

Show of hands:  How many think that is the wrong thing to do ?

---

From: Eliot Lear <[email-masked]>
Date: Tue, 10 Mar 2015 12:03:05 +0100

> HTTP/2.0 has ever received.

I don't think that's a fair statement.  Bob's review is excellent, but
many of the concerns he raised were well trodden ground.  Still, those
that aren't deserve to be addressed, and the question is really how best
to proceed.  Now Bob's biggest concern is the one that we are really
talking about, in this context, which is extensibility.  We made a
decision in the working group that we would keep extensibility within
the protocol to a minimum with an understanding that ALP IDs are cheap. 
The question from a process perspective is how to get to the next one.

Eliot

---

From: Julian Reschke <[email-masked]>
Date: Tue, 10 Mar 2015 12:02:09 +0100

> HTTP/2.0 has ever received.

The WG is going to follow the IETF process.

> Show of hands:  How many think that is the wrong thing to do ?

It's the only thing we can do right now short of stopping the process of 
publishing the HTTP/2 spec.

We *could* start work on a -bis document right away, though.

Best regards, Julian

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 10 Mar 2015 11:14:45 +0000

--------

>publishing the HTTP/2 spec.

Considering the severity of the critique, that would be the only
intellectually defensible thing to do.

---

From: Ryan Hamilton <[email-masked]>
Date: Tue, 10 Mar 2015 07:48:06 -0700

> intellectually defensible thing to do.

​That doesn't seem reasonable to me. As mentioned upthread, most of the
details that Bob brought up were discussed thoroughly in the working group.
If he had, say, exposed a critical security flaw then that we be a
reasonable course of action. But if we had to stop the process any time
someone had complaints about a spec, no spec would ever be completed.​

---

From: Larry Masinter <[email-masked]>
Date: Tue, 10 Mar 2015 16:39:56 +0000

Before HTTPbis was rechartered to include HTTP/2

https://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep/0840.html

 I had called for the working group to _first_ come to agreement on what “substantial and measurable improvement” meant.

I think this work still needs to be done. In fact, I think it’s the only work remaining that is in scope within the current charter:

https://datatracker.ietf.org/wg/httpbis/charter/

Larry
—
http://larry.masinter.net

---

From: Yoav Nir <[email-masked]>
Date: Tue, 10 Mar 2015 21:19:17 +0200

> On Mar 10, 2015, at 10:53 AM, Poul-Henning Kamp <[email-masked]> wrote:
> 
> --------

I’m keeping my hand down.

The HTTP/2 standard was written by a relatively small bunch of people. There have probably been around two dozen active participants in the process. Nor is this group representative of all implementers or HTTP or of anything but a small subset of deployers. Furthermore, if Bob Briscoe had joined in earlier, some things might have been different, although I don’t really think so. There were other people pushing for more extensibility. Testing of this protocol have been done at some scale, but only on a few websites, that collectively are not representative of “the web”.

A new version of HTTP is bound to come from such a small and non-representative group. The web is just too big. As time went by, the discussions in the group became less fruitful. That is inevitable. With the small group and small pool of test subject, we ran out of new information to act on. The next stage for this and any other protocol is to try it in different environments. And that is facilitated by publishing a “Proposed Standard”.

In a year’s time, we’ll have several independent clients and a lot of servers. People with personal blogs, CDNs, firewalls, home routers, news sites, blogs and online businesses will attempts to use HTTP/2. Not all of them, but a much more representative sample than we have today. And it’s not like a failure of HTTP/2 will break the Internet. We have a safety net in HTTP/1. HTTP/1 is fine. It works great. It works so great, that it supplanted many protocols such as FTP.

In a year’s time, we might get some “war stories” from people who have tried HTTP/2. Maybe they’ll love it. Maybe they’ll think it needs to be extended. Maybe they’ll think we need something like an interactive bias so that the first bytes of a stream are given higher priority, which will allow web pages to settle in size faster. Maybe they’ll revert to HTTP/1 and have good explanations about why HTTP/2 was inappropriate. 

I think that kind of input is what we need to consider before starting work on a -bis document or HTTP/3 or whatever. I don’t think that thought experiments are going to add new useful insights. So IMO the best course of action is to publish HTTP/2 as is, and wait for feedback from the field, especially the parts of the field that were not represented in this discussion.

Yoav

---

From: Cory Benfield <[email-masked]>
Date: Wed, 11 Mar 2015 09:15:58 +0000

> I think that kind of input is what we need to consider before starting work on a -bis document or HTTP/3 or whatever. I don’t think that thought experiments are going to add new useful insights. So…

Agreed. I have seen real-world examples of HTTP/2 providing
substantial performance improvements, so I'm convinced that *at least
some of the time* H2 represents a substantial improvement over
HTTP/1.1. I am willing to participate in further improvements, but we
should get some concrete examples of problems and limitations before
we jump down that rabbit hole again.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 11 Mar 2015 10:43:08 +0100

> we jump down that rabbit hole again.

Right.  This is the "running code" part of "rough consensus and running
code" that we say we believe in.  But that doesn't mean we should lose
track of real concerns, of course.

Eliot

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 12 Mar 2015 10:34:14 +1100

On 11 March 2015 at 20:15, Cory Benfield <[email-masked]> wrote:

> we should get some concrete examples of problems and limitations before we
> jump down that rabbit hole again.
>

IMNSHO it is the rabbit hole that is the problem.   If/when HTTP needs
significant reworking again (and I think that it will need it sooner that
we'd like), I think we need to find a better rabbit hole!

I do not doubt the good will, technical expertise or dedication to process
of those who were active in the working group, but the fact remains that a
thorough (if a little rushed) application of the IETF process has produce a
proposed standard that contains a lot of good, bad, ugly and unknown
aspects.

The WG has essentially been design by committee when there were multiple
diametrically opposed views as to what the goals and requirements were, let
alone what the best technical solutions were.    Considering the different
view points expressed in the process it is a  near miracle that a rough
consensus was obtained - no matter how flawed it is!

I think the draft is probably the best that can be produced by the WG
acting in the current process with the charter as defined.   While Bob's
critiques raise valid questions, they are substantially on subject matters
that have already been deeply debated (although I think Bob's clarity of
thought/expression would have been very much appreciated!).    I don't see
that restarting the same process with the same charter will come up with
anything substantially different or more importantly any better!

Thus I reluctantly find myself if the the ship-it-and-see-what-happens
camp.   We do need to gather more experience of how aspects of this
protocol will work in the real world and how developers will use (and
misuse!) them.

However, whilst we are all off gathering that experience, I think the
IETF/WG should also be reviewing how a better charter can be written and if
there is anything in the process that could be improved.   Personally I
think that too much design work was done within the WG and that we should
have seen a more competitive tender approach, with the WG
analysing/critiquing/comparing more complete proposals that are submitted
by teams that share an architectural vision.  Ie the working code should
come before the rough consensus!

regards

-- 
Greg Wilkins <[email-masked]>  @  Webtide - *an Intalio subsidiary*
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.