Re: notes on http2 draft

[Martin Thomson <[e-mail]>]

On 21 May 2013 08:01, Patrick McManus <[e-mail]> wrote:
> Section 1. [...] [editorial]

Thanks.  Fixed.

> message: [...]
> I suggest we scrub the term message from the document (and this section)
> except when it refers to HTTP messages.

Scrubbing done.  Turns out that "message" was misused almost
everywhere it appeared :)

> 3.2 Connection Magic [...] a multiple of 4 bytes

I don't know how to do that, except by trimming "BAR" down to "BA" (or
"GO" or some other shed-tone).  That might need to be tested.

> Implementations MUST ignore unsupported and unrecognized frame types.
> [...] this is exactly the kind of thing that leads to interop doom.

I think that we plan to discuss this at the interim.  I don't plan to
take a position on this, except that whatever we choose needs to be
consistently applied and motivated, so maybe I can do a (poor) Patrick
impersonation for you.

> 3.3.2 [...]
> we can just drop this section and require everyone to deal with 64KB.

I would be perfectly happy with this position, if only because a) it
resolves the issue, and b) ends up with less text in the draft.

> 3.4
>
> A "stream" is an independent, bi-directional sequence of frames
>
> Due to the (expected) compression requirements the frames aren't really
> independent of other streams. I know this mistake comes up pretty commonly
> on spdy-dev from new implementers of that protocol, so it probably helps to
> avoid saying independent here. (section 5.3 does it too).

This is an interesting one.  The view that I think that James has
taken is that the compression context is evaluated at a lower layer of
the logical stack than streaming.  That would allow this to remain
true, at least superficially.

I get the point though.  Do you think that qualifying the statement to
say that streams are subject to independent flow control and
life-cycles would be enough?

> 3.4.1
>
> Rather, new streams are established by sending a frame whose stream
> identifier field references a previously unused stream identifier.
>
> That's a little too loose. Streams are created by the client through
> HEADERS+PRIORITY (4.2.2) and by the server through PUSH_PROMISE. The text
> as-is makes it sound more free flowing than that.

I think that the intent is to avoid precluding any chance of
multiplexing websockets in here.  HEADERS+PRIORITY might be used
there, but it might not be necessary.

> The identifier of a newly established stream MUST be numerically greater
> than all previously established streams from that endpoint within the
> HTTP/2.0 connection, unless the identifier has been reserved using a
> PUSH_PROMISE (Section 3.8.5) frame.
>
> Likewise, PUSH_PROMISE really creates the stream (4.3.1) from the server.. I
> don't see a reason for the caveat here.

PUSH_PROMISE doesn't create a stream.  It promises to.  This is
important because it allows a pushing server to promise more streams
that the maximum stream concurrency limit set by the client.  Hence
the caveat.

> 3.4.2
>
> I thought one of the takeaways at Tokyo was to define a change-priority
> frame.. Can we do that now? is the intention to use a H+P without any
> headers at any point in the stream? If so, I think that should be called out
> so that server implementation's don't freak out at seeing H+P at strange
> points in the stream.. and I think there is some language in 4.2.2 that
> could be interpreted as meaning certain colon headers are required to be in
> every H+P

We haven't had a proposal for a change-priority frame yet.  I'm not
sure that H+P is going to be optimal for this case.

> 3.8.5
>
> The PUSH_PROMISE frame (type=0x5) is used to notify the peer endpoint in
> advance of streams the sender intends to initiate.
>
> I think I must have missed something on list about this. Why is the language
> here general (peer, sender).. why define this so that clients can generate
> PUSH_PROMISE ?

No particular reason.  Other than it being easier.  Switching to

> 3.8.9.4
>
> After a receiver reads in a frame that marks the end of a stream (for
> example, a data stream with a FINAL flag set), it ceases transmission of
> WINDOW_UPDATE frames. A sender is not required to maintain the available
> flow control window for streams that it is no longer sending on.
>
> First - since this is a spec, that should be "it MAY/SHOULD/MUST cease
> transmission of WINDOW_UPDATE frames". I suggest MUST.

Righto.  MUST.

> Second - The language isn't clear if this applies to session windows or just
> the stream window. I think it is just the stream window and the receiver
> still needs to ack^H^H^HWINDOW_UPDATE the session window after the FINAL
> flag, but we should say explicitly.

Yes.  Express > implied.

> 4.2.2
>
> User-agents MUST support gzip compression. Regardless of the Accept-Encoding
> sent by the user-agent, the server may always send content encoded with gzip
> or deflate encoding. [rfc.comment.11: Still valid?]
>
> I support that still being valid. This is an important performance property
> to rely on.

I think that this was marked as so when the COMPRESSED bit was
removed.  I don't think that this proscription on the upper layer is
unreasonable, even if it is a bit of a layering violation that this
specification doesn't strictly need to address.

I've moved this to the response processing side and clarified the
statement.  If there are objections to this, the paragraph is easy
enough to remove.

> also 4.2.2
>
> The client initiates a request by sending a HEADERS+PRIORITY frame [...] if
> the server receives a data frame prior to a HEADERS or HEADERS+PRIORITY
> frame
>
> I think that means just "prior to a HEADERS+PRIORITY frame" which is what is
> required to open the stream...

Gotcha, and 4.2.3 fixed (to the converse) too.  Servers have no real
business setting priority (for HTTP).