Re: New Version Notification for draft-bishop-http2-extension-frames-01.txt

My intermediate version said all extensions were hop-by-hop and negotiated; end-to-end was added in response to James' feedback.  The requirement that extensions define how, if at all, they get translated to back-end links that do/do not support the extension was the only end-to-end version I had prior to that change.  I'm still ambivalent about that, but if there's a use-case, I'm not opposed.

If we do allow end-to-end, though, I think they *have* to be silently discardable -- because, as Matthew observes, there's no chance to negotiate.  If I can't know what you'll recognize, I can't avoid sending you something you won't.  Sure, there are headers and history, but you can't know what rules the intermediary is using to route -- the selection of the back-end server may depend on the twenty-seventh character of the path and the tide level in Pamlico Sound, for all you know.

The only end-to-end extension I've currently thought of is the one that was a sample in the previous version, Server Hint.  (Forget if that's what we actually called it.)  Basically, rather than actively pushing, it's a server-driven "You'll want to check that these resources are in your cache and current." that works for when you suspect a client may already have a resource, or the resource is hosted on another server.  There's no harm if an intermediary observes it going by and also freshens its cache, but the intended recipient is the user agent.  But like Push, if the UA just drops it, it will discover that it wants the resource a little later.

As for hardening, Gabriel and I discussed that some.  Let's say we're just talking about hop-by-hop:

  *
If we say you can't send any extension frames until you've seen the other party's EXTENSIONS, then you can't use any in your first request.  That may be acceptable, but seems sub-optimal.
  *
If we say you MUST NOT send even informative extensions once you've seen the other party's EXTENSIONS and you know they haven't requested it, how do you know when to enforce the MUST NOT?  Now we need an ACK for this too, or every connection begins with SETTINGS-EXTENSIONS-PING to simulate one.  Plus, that means the server has to maintain two different states -- one in which it permits unknown frames, and one in which it doesn't.

Sent from Windows Mail

From: James M Snell<mailto:jasnell@gmail.com>
Sent: ?Thursday?, ?May? ?22?, ?2014 ?8?:?18? ?PM
To: Matthew Kerwin<mailto:matthew@kerwin.net.au>
Cc: Mike Bishop<mailto:Michael.Bishop@microsoft.com>, HTTP Working Group<mailto:ietf-http-wg@w3.org>, Roberto Peon<mailto:grmocg@gmail.com>


I will say, however, that I'd prefer that unknown end to end extensions at the endpoints result in hard exceptions rather than must ignore.

On May 22, 2014 7:08 PM, "Matthew Kerwin" <matthew@kerwin.net.au<mailto:matthew@kerwin.net.au>> wrote:
On 23 May 2014 10:24, Roberto Peon <grmocg@gmail.com<mailto:grmocg@gmail.com>> wrote:
Extensions cannot safely modify the semantics of defined frames. This is implied from:

Such frames are, by definition, informational and can be
   safely ignored without affecting the shared state with the sender.

Anything that does modify defined-frame semantics isn't guaranteed to interoperate, and is more than simply an extension.


Sorry, I should have looked at the appendices a bit better.

So, an extension can't extend DATA frames, nor replace them without going hop-by-hop. The only end-to-end extensions we can introduce must be informational.

Presumably this stems from the fact that we can't negotiate end-to-end extensions. I guess a justification here is that you can use application-level extensions instead? (I.e. new HTTP headers, etc., which *are* end-to-end, and can be used for negotiation.)

I'd probably prefer the proposal if it just eliminated end-to-end extensions altogether. That would harden up a lot of the wishy-washy "ignore without error" cases, and I can't think of an end-to-end extension (especially an informational one) that can't equally be served by a new HTTP header*.  As a result extensions are less rich than I could have hoped, but they're simple enough to actually potentially get implemented.


* Particularly since "An end-to-end frame on stream zero is meaningless, and MUST be discarded upon receipt." If it's on a stream, it might as well be in a header. The only difference is that extension frames are flow controlled and headers (currently) aren't.


Incidentally, the compressed data frames in Appendix 3 are pretty wild; it might be less controversial to reign them in a bit, to more closely match what's currently in the draft (and align with the discussion that lead thereto).


--
  Matthew Kerwin
  http://matthew.kerwin.net.au/