- From: Mark Nottingham <mnot@mnot.net>
- Date: Wed, 10 Jan 2018 13:51:37 +1100
- To: Eric Rescorla <ekr@rtfm.com>
- Cc: The IESG <iesg@ietf.org>, draft-ietf-httpbis-origin-frame@ietf.org, Patrick McManus <mcmanus@ducksong.com>, HTTP Working Group <ietf-http-wg@w3.org>
Hi EKR, On 7 Jan 2018, at 1:11 pm, Eric Rescorla <ekr@rtfm.com> wrote: > 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, Did this comment get truncated? > The ORIGIN frame type is 0xc (decimal 12), and contains zero to many > Origin-Entry. > Nit: "zero or more" is conventional Will be in -05. > 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. I suppose, but so is an origin-entry with a length of 1 (since it needs to be a FQDN, effectively). Where do we draw the line? The semantics are defined above the syntax. > 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" Could you please provide complete text? This section has been agonised over a fair amount. > 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 Will be in -05. Thanks! -- Mark Nottingham https://www.mnot.net/
Received on Wednesday, 10 January 2018 02:52:07 UTC