Bootstrapping WebSockets with HTTP/2
draft-ietf-httpbis-h2-websockets-07

[Ballot comment]
Thanks to the author and working group for the work that has been done on this
mechanism. I have only minor editorial comments.

---------------------------------------------------------------------------

General: This document uses the terms "header" and "pseudo-header" in several
places where "header field" and "pseudo-header field" is meant. Please find and
fix these.

---------------------------------------------------------------------------

§1:

>  HTTP/2 does not allow connection-wide headers and
>  status codes such as the Upgrade and Connection request headers or
>  the 101 response code due to its multiplexing nature.

Suggestion: "...the 101 (Switching Protocols) response code..."

---------------------------------------------------------------------------

§5:

>  The HTTP/2 stream closure is also analogous to the TCP connection of
>  [RFC6455].

I think this means to say "TCP connection closure of [RFC6455]." Either that
or "...stream handling is analogous to the TCP connection handling of..."

---------------------------------------------------------------------------

Section 10.2 seems redundant. Consider removing it.

[Ballot comment]
One high level question: You say in the intro that a mechanism to transition from http to TCP is needed while the proposed mechanism does actually not "transition" but use websockets OVER http. Was just opening a second TCP connection considered as an alternative?

[Ballot comment]
Just a couple of minor comments:

Substantive:
§5: Is the scheme pseudo-header expected to match the security status of the existing connection?


Editorial:
§4, first bullet: This sort of deep link into the IANA registries makes it hard for them to evolve their registry organization over time. Please consider referencing the registry by name.

[Ballot comment]
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D5180



COMMENTS
S 4.
>        indicating the desired protocol to be spoken on the tunnel created
>        by CONNECT.  The pseudo-header is single valued and contains a
>        value from the HTTP Upgrade Token Registry defined by [RFC7230].
> 
>      o  On requests bearing the :protocol pseudo-header, the :scheme and
>        :path pseudo-header fields MUST be included.

You should say what the path means.


S 4.
> 
>      o  On requests bearing the :protocol pseudo-header, the :authority
>        pseudo-header field is interpreted according to Section 8.1.2.3 of
>        [RFC7540] instead of Section 8.3 of [RFC7540].  In particular the
>        server MUST NOT make a new TCP connection to the host and port
>        indicated by the :authority.

I was sort of able to make sense of this, but it's kind of confusing.
Perhaps you could say a word about it.




S 5.
>      the GET-based request in [RFC6455] and is used to process the
>      WebSockets opening handshake.
> 
>      The scheme of the Target URI [RFC7230] MUST be "https" for "wss"
>      schemed WebSockets and "http" for "ws" schemed WebSockets.  The
>      websocket URI is still used for proxy autoconfiguration.

Just to be clear, you are saying ":scheme" must be https or http?

[Ballot comment]
Thanks for the well-written document!

I only have one comment: should we explicitly mention that the security considerations of RFC 6455
continue to apply?

[Ballot comment]
This was mostly clear and easy to understand. I wanted to pass on a few places where I struggled.

This is a nit:

  This tunneled stream will be multiplexed with other regular streams
  on the connection and enjoys the normal priority, cancellation, and
  flow control features of HTTP/2.

"streams enjoying HTTP/2 features" seems odd to me. Perhaps "has" or even "shares"? But do the right thing.

It was really easy for me to read

  o  A new pseudo-header :protocol MAY be included on request HEADERS
      indicating the desired protocol to be spoken on the tunnel created
      by CONNECT.

without realizing that ":protocol" WAS the pseudo-header - it took me two or three passes to realize that I could stop looking for the pseudo-header, because I'd already seen it. Maybe no one else will be confused? I notice that Section 5 puts scheme names in quotes, and they are more noticeable, so maybe ":protocol" (and the other pseudo-headers in the section) would be helpful to the reader. But do the right thing.

I had trouble parsing

  o  The use of a pseudo-header is something that is connection
      specific and HTTP/2 does not ever allow to be created outside of
      the protocol stack.

somewhere around "does not ever allow to be created" - the combination of passive tense and negation was probably my problem. Even then, "does not allow the creation of" - what? matching text seems to say "the use of a pseudo-header is not allowed to be created". Is that what is intended? If I'm tripping over well-understood HTTP/2 terminology, my apologies, of course.

Is there a pointer you could include with this text?

  The 2017 HTTP Workshop had a very productive discussion that helped
  determine the key problem and acceptable level of solution
  complexity.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-httpbis-h2-websockets-05. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of this document, there is a single action which we must complete.

In the HTTP/2 Settings registry on the Hypertext Transfer Protocol version 2 (HTTP/2) Parameters registry page located at:

https://www.iana.org/assignments/http2-parameters/

a single, new registration will be made as follows:

Code: 0x8
Name: SETTINGS_ENABLE_CONNECT_PROTOCOL
Initial Value: 0
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

The IANA Services Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-05-21):

From: The IESG
To: IETF-Announce
CC: httpbis-chairs@ietf.org, Mark Nottingham , mnot@mnot.net, ietf-http-wg@w3.org, alexey.melnikov@isode.com, draft-ietf-httpbis-h2-websockets@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Bootstrapping WebSockets with HTTP/2) to Proposed Standard


The IESG has received a request from the Hypertext Transfer Protocol WG
(httpbis) to consider the following document: - 'Bootstrapping WebSockets
with HTTP/2'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-05-21. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document defines a mechanism for running the WebSocket Protocol
  (RFC 6455) over a single stream of an HTTP/2 connection.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-httpbis-h2-websockets/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-httpbis-h2-websockets/ballot/


No IPR declarations have been submitted directly on this I-D.

# Shepherd Writeup for draft-ietf-httpbis-h2-websockets

## 1. Summary

Mark Nottingham is the Document Shepherd; Alexey Melnikov is the responsible Area Director.

This document defines a mechanism for running the WebSocket Protocol over a single stream of an
HTTP/2 connection.

The intended publication type is Proposed Standard.

## 2. Review and Consensus

This document enjoyed broad discussion and review in the HTTP Working Group; there seems to be
significant community interest in it, since it enables the use of WebSockets on a HTTP/2 server,
reducing operational issues for Web sites.

Deployment depends upon implementation in Web browsers; at least one has already written code for
this feature and is in process of shipping it.

There was some concern about whether it was appropriate for a version-specific extension (a HTTP/2
SETTING) to modify the semantics of a version-generic HTTP method (CONNECT), but the WG reached
consensus that CONNECT is "special" in this regard.

## 3. Intellectual Property

Patrick has confirmed that to his direct, personal knowledge, no IPR related to this document needs
to be disclosed.

## 4. Other Points

The document does not have any downrefs.

IDNits points out some minor issues which will be addressed in a subsequent draft.

The IANA Considerations are concise and correct. Note that 0x8 was chosen to avoid colliding with
draft-ietf-httpbis-cache-digest.