Richard Barnes' Discuss on draft-ietf-httpbis-http2-16: (with DISCUSS and COMMENT)

Richard Barnes has entered the following ballot position for
draft-ietf-httpbis-http2-16: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-httpbis-http2/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

(1) Section 3.2: "A server MUST ignore a "h2" token in an Upgrade header
field."
What is the reasoning behind this exclusion?  This seems to unnecessarily
rule out the use of TLS, especially given that the server can opt out by
choosing "h2c".

(2) Figure 1 seems really confusing.  If the reader notices the phrase "9
octets of the frame header", he'll probably come to the right conclusion,
but it also seems likely that some readers will infer from the layout
that the header is 12 octets long, with the fields aligned to word
boundaries.  Just eliminating the header with the bit positions would
help a lot.  Likewise for the figures in Section 6.

(3) Section 9.1.1: "For "http" resources..."
This seems to imply that requests for "http" resources can only be
carried over bare TCP, which seems wrong given the presence of the
":scheme" pseudo-header.  Proposed text: 

OLD: "For "http" resources, this depends on the host having resolved to
the same IP address."
NEW: "For TCP connections without TLS, this depends on the host having
resolved to the same IP address."

(4) Section 9.1.1: "For "https" resources..."
The salient requirement here is that the certificate provided by the
server MUST pass any checks that the client would have done if it were
initiating the connection afresh.  In addition to the name check here,
that would include things like HPKP.  Suggested text:

OLD: "For "https" resources, connection reuse additionally depends on
having a certificate that is valid for the host in the URI."
NEW: "For "https" resources, connection reuse additionally depends on
having a certificate that is valid for the host in the URI.  The
certificate presented by the server MUST satisfy any checks that the
client would perform when forming a new TLS connection for the host in
the URI (e.g. HPKP checks [HPKP])." 

(5) Section 10.4: "Pushed responses for which an origin server is not
authoritative (see Section 10.1) are never cached or used."
This seems like a rather important point, for which I can't find any
normative text.  It seems like in Section 8.2.1, the client should be
REQUIRED to verify that the ":authority" field in the PUSH_PROMISE
contains a value for which the client would have been willing to re-use
the connection (as specified in Section 9.1).


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 2.1:
The definitions of "client" and "server" here are a bit lean.  For
example, one might read them and conclude that the client and server
roles are independent of who sends requests and responses.  It would be
good to clarify these roles, updating the definition in RFC 7230: "An
HTTP "client" is a program that establishes a connection to a server for
the purpose of sending one or more HTTP requests.  An HTTP "server" is a
program that accepts connections in order to service HTTP requests by
sending HTTP responses."

Section 2.1: "across a virtual channel"
What is a virtual channel?  Can this phrase just be deleted?

Section 3.1: "CREF1: RFC Editor's Note:"
It seems like it could be useful to leave in a variant of this note,
describing the variant identifiers used by pre-RFC versions of the
protocol.  (And thus removing the RFC 2119 language.)

Section 3.4: "the sever MUST send"

Section 4.1: "R: A reserved 1-bit field."
I was mystified by the purpose of this field until I realized that it's
only there because stream IDs are 31 bits (to make room for the Exclusive
flag, I guess).  Might help this read more smoothly to note something to
that effect here.

Section 5.1: 
When I initially read Figure 2, I thought that "H/", "ES/", etc.
designated types of frames (or frames + flags).  If, as they appear, they
indicate alternatives, it would be clearer to add a space before the
"/".

Section 8.1.2.3: "_:authority_"
Remove the underscores?
 
Section 10.3: "if they are translater verbatim"

Received on Thursday, 22 January 2015 06:14:53 UTC