RE: draft-bishop-httpbis-extended-settings-00 comments

[Mike Bishop <[e-mail]>]

I mostly agree.  Certainly each extension could just define a XXX_SETTINGS frame that carries its own extension-local semantics.  There's no drawback to the extension itself to doing so -- describing a frame payload versus describing a setting payload is pretty equivalent spec work.  The question is whether it simplifies implementations to have a single instance of how to handle this frame, versus having to code handling for each XXX_SETTINGS frame as it gets defined, each with its local quirks.  However, that inclines me to the other direction -- this isn't substantially more difficult than adding a CERT_SETTINGS frame to the certs draft, and it might simplify something in the future, so why not?  I just worry that instances where this could have been used will crop up with just low enough frequency that there are never more than 1-2 outstanding at a time, but they'll exist.

You're correct that the setting to enable this could be replaced with a requirement to MUST send one of these, even if it's empty.  You need something to gate enabling the ACK timer on, but which of those two it is doesn't really matter.

As to the HTTP/1.1 header on upgrade, that's a good point and should probably be defined. The flip side of this versus legacy SETTINGS is that I could envision this growing pretty large in some instances -- it might make more sense to encode each setting as a header.  Details we can sort out if we go down this road.

-----Original Message-----
From: Martin Thomson [mailto:[e-mail]] 
Sent: Tuesday, July 12, 2016 9:53 PM
To: HTTP Working Group <[e-mail]>
Subject: draft-bishop-httpbis-extended-settings-00 comments

I am conflicted about this draft.  On the one hand, it's the design we should have had for HTTP/2.  I like that it's more general, saves space in most cases, and includes a flag to request acknowledgment.
All these are real improvements.

On the other hand, I don't think we need it now, and I'm not convinced that will ever need it.  At some level, we can achieve the same effect with careful use of SETTINGS and new frames.  For that reason, I'm inclined to keep this on hold until we identify a few things that depend on this.

-- on the details:

Section 2.  I think that SETTINGS_EXTENDED_SETTINGS is redundant.  You can simply send the EXTENDED_SETTINGS frame to indicate that you support it and have a reason to do so.  In most cases, the need to support the frame will come with a need to send the frame, so it's a pretty simple optimization.

What do you want to do about Http2-Settings?  Have we given up on the pretense that there is a cleartext variant of HTTP/2?