Eric Rescorla's No Objection on draft-ietf-httpbis-origin-frame-04: (with COMMENT)

Eric Rescorla has entered the following ballot position for
draft-ietf-httpbis-origin-frame-04: No Objection

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 https://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:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-origin-frame/



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


   The ORIGIN HTTP/2 frame ([RFC7540], Section 4) allows a server to
   indicate what origin(s) [RFC6454] the server would like the client to
The citation here is to the frame format. I think you could make this clearer
and also point the user to that section for the conventions,

   The ORIGIN frame type is 0xc (decimal 12), and contains zero to many
   Origin-Entry.
Nit: "zero or more" is conventional

      serialization of an origin ([RFC6454], Section 6.2) that the
      sender believes this connection is or could be authoritative for.
What are the semantics of a zero-length origin entry? It seems like an odd
thing to allow.

   Note that for a connection to be considered authoritative for a given
   origin, the client is still required to obtain a certificate that
   passes suitable checks; see [RFC7540] Section 9.1.1 for more
"Obtain" seems confusing here. Perhaps "the server is still required to
authenticate using"

   viable connection to an origin open at any time.  When this occurs,
   clients SHOULD not emit new requests on any connection whose Origin
   Set is a proper subset of another connection's Origin Set, and SHOULD
Nit: SHOULD NOT

Received on Sunday, 7 January 2018 02:12:05 UTC