Subject: HTTP/2 has been approved

From: Jari Arkko <[email-masked]>
Date: Wed, 18 Feb 2015 23:36:20 +0200

See

  https://mailarchive.ietf.org/arch/msg/ietf-announce/9-o6D0GfSGUwHqG2QVgAiAEjQLE

for the approval announcement and 

  http://www.ietf.org/blog/2015/02/http2-approved/ 

for Mark’s and Barry’s blog article.

I believe this is a big milestone for web technology, and I wanted to thank everyone who has been involved in this effort. It has been very important work, and I am so glad to see such a good end result. Also, I wanted to highlight the importance of code in developments like this, to understand what we could do, to build confidence that the specifications work, and, of course, to employ the results. I think the future is very bright for HTTP/2.

Thanks,

Jari Arkko
IETF Chair

---

From: Michael Richardson <[email-masked]>
Date: Thu, 19 Feb 2015 10:16:20 -0500

I'm very concerned about this part:

> A key point in the protocol development process was the iteration the
> working group did between protocol updates, and implementations and
> testing. Certain draft protocol versions were labelled by the working group
> as "implementation drafts", and the participants -- many web browser and
> web server providers -- updated their implementations and tested out the
> protocol changes. Most of the interim meetings included part of a day spent
> on hands-on interoperability testing and discussion. The result is a
> thoroughly validated protocol that has been shown to interoperate and that
> meets the needs of many major stakeholders.

It sure seems to me like those "implementation drafts" are what used to be
called proposed standards.

What I see is a new step in the standardization process, along with a view
that the step after internet-draft seems to include proven interoperability.

I propose that this document skip PS, and go straight to Internet Standard to
accurately reflect the status of this document.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Yoav Nir <[email-masked]>
Date: Thu, 19 Feb 2015 17:35:57 +0200

> On Feb 19, 2015, at 5:16 PM, Michael Richardson <[email-masked]> wrote:
> 
> 

Proposed standards also have to go through working group last call, AD review, IETF last call, IESG review, SecDir review, GenArt review, a six-week waiting period in the RFC editor’s queue, and AUTH48. I don’t think we can afford to do that for a single document every 4-6 months, like httpbis did for HTTP/2.

> that the step after internet-draft seems to include proven interoperability.

Running code has always been part of the deal, at least as something we would like to have. Besides, the process continued even when some implementations did not interoperate.

> accurately reflect the status of this document.

There is currently pretty close to zero deployment in the real world. A bunch of lab implementations that managed to interoperate in a bake-off is not an indication of something ready for Internet Standard. But don’t you agree that publishing a document with the bunch of lab implementations is better than publishing it without them?

Yoav

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 19 Feb 2015 10:42:06 -0500

> accurately reflect the status of this document.

Yep, this change was one of the reasons we went from the three step process
to two. The requirement for getting a proposed standard published in 2005
was way higher than getting to DRAFT status in 1995.

Not sure about short cutting from Proposed Standard to Standard. I think
the process is still bjorked but in a different way.

One problem is that we have a bunch of RFCs that have widely varying
quality and status but to the rest of the world an RFC is an RFC. But the
bigger problem is that the levels are mostly static.

BEEP was rushed through IETF process and is still PROPOSED STANDARD despite
the fact nobody has ever used it or expressed an interest in doing so.

HTTP/2 is really a maintenance effort on an existing IETF standard. Only I
don't think it ever got that status (would check the ietf.org site is down
right now).

STANDARD should mean that a specification is current. So if HTTP/2 is the
best HTTP specification then it should have the STANDARD designation.

There is a little complication though. HTTP/2 is optimized for Web
browsing. Which is fine. HTTP/1.1 is also used as a presentation layer for
Web Services and for Web Sockets. So this isn't a case where HTTP/2 is a
straight upgrade. It is an upgrade for the original intended purpose of
HTTP but not necessarily advantageous for non browsing applications.

I think we probably want to think about bifurcating the HTTP moniker to
reflect that. HTTP/T for Web Sockets (which establish transport over HTTP)
and HTTP/P for a stripped down version for use as a presentation layer for
Web Services maybe.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 19 Feb 2015 10:59:13 -0500

{I've changed the subject}

Yoav Nir <[email-masked]> wrote:
    >>> testing. Certain draft protocol versions were labelled by the working
    >>> group as "implementation drafts", and the participants -- many web
    >>> browser and web server providers -- updated their implementations and
    >>> tested out the protocol changes. Most of the interim meetings
    >>> included part of a day spent on hands-on interoperability testing and
    >>> discussion. The result is a thoroughly validated protocol that has
    >>> been shown to interoperate and that meets the needs of many major
    >>> stakeholders.
    >>
    >> It sure seems to me like those "implementation drafts" are what used
    >> to be called proposed standards.

    > Proposed standards also have to go through working group last call, AD
    > review, IETF last call, IESG review, SecDir review, GenArt review, a
    > six-week waiting period in the RFC editor’s queue, and AUTH48. I don’t
    > think we can afford to do that for a single document every 4-6 months,
    > like httpbis did for HTTP/2.

Thank you, you see to have found a list of things that we could "not do"
prior to PS, and that would reduce a huge amount of work.

    >> What I see is a new step in the standardization process, along with a
    >> view that the step after internet-draft seems to include proven
    >> interoperability.

    > Running code has always been part of the deal, at least as something we
    > would like to have. Besides, the process continued even when some
    > implementations did not interoperate.

Running code is usually the bar between PS and IS.
Of course, we like running-code, and the earlier the better.

    >> I propose that this document skip PS, and go straight to Internet
    >> Standard to accurately reflect the status of this document.

    > There is currently pretty close to zero deployment in the real world. A
    > bunch of lab implementations that managed to interoperate in a bake-off
    > is not an indication of something ready for Internet Standard. But
    > don’t you agree that publishing a document with the bunch of lab
    > implementations is better than publishing it without them?

Of course; I also worry that we are our own worst enemies: we raise the bar
very high, and then we become overworked, and can't find superheroes that can
do everything.

I get the impression that SPD has had a lot of real world use.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 19 Feb 2015 18:33:16 +0200

> On Feb 19, 2015, at 5:59 PM, Michael Richardson <[email-masked]> wrote:
> 
> 

I think you expect implementors to work with documents that has had no review outside the working group, specifically no security review, no review about the use of SHOULD vs MUST, no thought necessarily given to interaction with other parts of the Internet technologies. Worst of all, drafts with not enough attention given to appropriate use of language and clarity. The HTTP/2 draft is very well-written, partially because all the authors speak very good English. This perhaps was the norm in the “good old days’, but it is often an exception today.

For the most part, intermediary drafts are good enough for implementers within the working group, but not so much for people outside the “inner circle”.

> Of course, we like running-code, and the earlier the better.

We’ve had running code and shipping products for RFC 4306/5995 long before Sean got the idea to advance them to full standard. The working group should be commended for producing a document that has some interoperating lab implementations, but that does not mean that it has proven itself well enough for Internet Standard. I’d like to see some real deployment and shipping products before that.

> very high, and then we become overworked, and can't find superheroes that can

And yet we manage to produce many hundreds of RFCs a year.

Yoav

---

From: Sean Turner <[email-masked]>
Date: Thu, 19 Feb 2015 13:09:03 -0500

> accurately reflect the status of this document.

Six months after it gets an RFC# I’d completely support this.

spt

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 19 Feb 2015 10:32:28 -0800

> Six months after it gets an RFC# I’d completely support this.

Good god, no. HTTP/2 is quite complex, and it is likely that at least some parts will turn out to be non-optimal. Please give the HTTPBIS WG at least a year to shake out the protocol after wide deployment and constant use. Rushing the WG just so we can feel good about slapping a near-meaningless feel-good label on the spec is not a good process.

Counter-proposal: we let the people closest to the protocol, the WG that created it, decide when to ask for STD status.

--Paul Hoffman

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 19 Feb 2015 19:50:46 +0100

* Paul Hoffman wrote:
>Good god, no. HTTP/2 is quite complex, and it is likely that at least 
>some parts will turn out to be non-optimal. Please give the HTTPBIS WG 
>at least a year to shake out the protocol after wide deployment and 
>constant use. Rushing the WG just so we can feel good about slapping a 
>near-meaningless feel-good label on the spec is not a good process.
>
>Counter-proposal: we let the people closest to the protocol, the WG
>that created it, decide when to ask for STD status.

Indeed. And I note that some participants preferred Experimental status
for the document for the time being.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de
 Available for hire in Berlin (early 2015)  · http://www.websitedev.de/

---

From: Jari Arkko <[email-masked]>
Date: Thu, 19 Feb 2015 21:30:52 +0200

Michael,

> accurately reflect the status of this document.

As others have noted, once there is real-world deployment and
not just implementations, we should consider that. Status of
various specifications should be accurately reflected.

But I want to take this discussion back to possibly more
relevant question of how we make standards. I think you
are asking if this level of ‘validation’ is a requirement or
even a desirable property of the standards process. And
I think we can immediately respond to the first question,
and respond indirectly to the second question.

There is absolutely no requirement anywhere that something
like this should be done in a particular standards effort. However,
I think it made in this particular case, and the WG chose to go
through this effort. I think that was a reasonable decision. In
general, I actually prefer to see more code and development
mixed as a part of the process of getting to standards. However,
it should not be a requirement, and whether that even make
sense in a particular situation should be up to the WG
and evaluated on a case-by-case basis.

Jari

---

From: Eliot Lear <[email-masked]>
Date: Thu, 19 Feb 2015 11:47:51 -0800

I agree with Paul- to a point.

But first, CONGRATULATIONS to the httpbis working group, Martin Thomson,
and Mark Nottingham in particular.  These people have worked quite hard
to produce a specification.

There was some discussion in the working group about including various
versioning bits in various places.  At the end of the day, my
recollection was that the group chose not to include versioning WITHIN
the protocol because they would prefer to rev the protocol instead. 
After all, ALPN ids are cheap.  While I doubt that any of the current
developers really want to think past HTTP2 today, there are built-in
deployment assumptions in every protocol, and on-the-ground
considerations will dictate when and how to update.  The developers in
the WG today are in the best position to make this call, and keeping
them together in some form would be useful (be that a WG, a mailing
list, or some other construct).

Eliot

---

From: David Morris <[email-masked]>
Date: Thu, 19 Feb 2015 12:02:31 -0800 (PST)

On Thu, 19 Feb 2015, Paul Hoffman wrote:

> > Six months after it gets an RFC# I?d completely support this.
>
> Counter-proposal: we let the people closest to the protocol, the WG that
> created it, decide when to ask for STD status.

There are at least two design choices I wouldn't accept as final w/o real
world experience. I don't want to open that discussion now but I will be
watching deployement results and feedback from 'outside' implementers.
No way should we jump to 'standard' now.

Dave Morris

---

From: [email-masked]
Date: Thu, 19 Feb 2015 15:22:50 -0800 (PST)

> Counter-proposal: we let the people closest to the protocol, the WG that created it, decide when to ask for STD status.

+1.

More generally, this all an attempt to solve a nonproblem. Essential documents
that have huge amounts of industry backing and where there's value seen in
progressing don't have any problem moving up the standards track. And HTTP/2 is
definitely such a document.

The problem is with smaller, arguably less essential documents, documents which
are important to their constituencies but which don't have the broad backing of
something like HTTP/2. That's where the road has proved to be too difficult to
travel.

				Ned

---

From: Larry Masinter <[email-masked]>
Date: Fri, 20 Feb 2015 03:30:59 +0000

>When httpbis was chartered, my suggestion for the charter

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

was not accepted. But I think the work I called for still need to be done: 
defining clearly how HTTP/2 is or isn’t a big improvement for different 
applications, and what you have to do to use it effectively, evaluating 
the tradeoffs for various sent-over-HTTP services, etc.

---

From: Julian Reschke <[email-masked]>
Date: Fri, 20 Feb 2015 16:12:08 +0100

On 2015-02-19 16:42, Phillip Hallam-Baker wrote:
> ...
> HTTP/2 is really a maintenance effort on an existing IETF standard. Only
> I don't think it ever got that status (would check the ietf.org
> <http://ietf.org> site is down right now).
> ...

It seems that you are confusing the HTTP/1.1 revision documents (RFC 
723*) with HTTP/2.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 20 Feb 2015 16:16:26 +0100

> There is currently pretty close to zero deployment in the real world. A bunch of lab implementations that managed to interoperate in a bake-off is not an indication of something ready for Internet…

5% of the HTTP requests seen by Google is very different from "close to 
zero" (source: <http://daniel.haxx.se/blog/2015/02/10/http2-is-at-5/>).

The HTTP/2 implementations in Firefox, Chrome and a bunch of highly used 
sites (such as Google and Twitter) are *not* "lab implementations".

Other than that, I agree that the we continue to have a too-high-bar for 
Proposed Standards.

Best regards, Julian