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

On Tue, Jan 9, 2018 at 6:51 PM, Mark Nottingham <mnot@mnot.net> wrote:

> 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?
>

No, it's just badly written. The point here is that the citation to 7540
section 4 isn't
to the ORIGIN frame but rather to the *format* of a frame. So, this text is
confusing.
I would say

This document defines a new HTTP/2 frame type ([RFC7540], Section 4) called
ORIGING, which...


>   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.
>

OK.

>      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.
>

Well, zero length does seem special.

>   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.
>

I would say:

" A connection MUST NOT be considered authoritative for a given origin
unless the
server has authenticated to the client using a certificate that would have
been acceptable
for that origin; see ...."



> >   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/
>
>