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

[Matthew Kerwin <[e-mail]>]

I like this. Is an unwritten implication of the proposal that an extension
can redefine existing frame types?

I'm thinking of DATA compression as an extension, adding settings
parameters/flags/frame headers/etc. The current compression mechanism is
hop-by-hop, and it would be negotiated as a hop-by-hop extension, so it
works there; but I'll have to think more about the implications for
introducing end-to-end compression. My initial reaction is that we'd have
to introduce an extension frame type that duplicates DATA, like
COMPRESSED_DATA. This could have far reaching consequences, especially for
things like caching or transforming proxies.

Also: there's a lot of "it's safe it ignore these" things in there. I'd
feel much more comfortable if there were some more hard, loud failures.

3.3.4.1.  Handling by Intermediaries

   Intermediaries MUST forward all end-to-end frames regardless of
   whether they recognize the frame type.  Endpoints (user agents and
   origin servers) MUST discard any frame types which they do not
   recognize.  Such frames are, by definition, informational and can be
   safely ignored without affecting the shared state with the sender.

   All hop-by-hop extension-defined frames MUST be dropped by
   intermediaries which do not support the extension.  However, each
   extension SHOULD specify how an intermediary translates the frames
   defined by the extension toward other peers which might or might not
   support the same extension.  When an intermediary advertises support
   for an extension, it MUST abide by the extension-defined intermediary
   behavior.

3.4:

   [...] Implementations MUST ignore unknown settings and
   MUST NOT emit settings defined by an extension which has not been
   announced in an EXTENSIONS (Section 3.3.2) frame.

If extensions are negotiated, there should never be a case where you
receive an extension-defined frame type or setting that you don't
recognise, so it should be a hard error. At the least you'd be flagging a
broken implementation.



On 23 May 2014 03:34, Mike Bishop <[e-mail]> wrote:

>   When we decided in Zurich to foreclose the option to extend HTTP/2, we
> thought that we were close to done with the basic protocol.  And it’s true
> -- the fundamentals of HTTP/2 haven’t changed all that much since
> then.  But various cases keep coming up where certain parties need to add
> one more feature.  While these aren’t core to the HTTP/2 protocol, they’re
> also not worth versioning the protocol for later, and so we’ve added them
> to the spec for experimentation as optional components.
>
> This draft proposes that many of these would be perfectly valid use-cases
> for extensions, and that we might make progress more quickly if we add a
> simple extension model.  I believe that the time we take in getting the
> extension model right will be more than offset by the ability to unblock
> the protocol and still handle new situations as they arise, even though
> we’re late in the process.
>
> I want to emphasize that the goal of the extension model is simplicity in
> the core protocol, and I’d welcome feedback on how to simplify it further.
>   Sent from Windows Mail
>
>   *From:* [e-mail]
> *Sent:* ‎Thursday‎, ‎May‎ ‎22‎, ‎2014 ‎10‎:‎24‎ ‎AM
> *To:* Mike Bishop <[e-mail]>, Mike Bishop<[e-mail]>
>
>
> A new version of I-D, draft-bishop-http2-extension-frames-01.txt
> has been successfully submitted by Mike Bishop and posted to the
> IETF repository.
>
> Name:  draft-bishop-http2-extension-frames
> Revision: 01
> Title:  Extension Frames in HTTP/2
> Document date: 2014-05-22
> Group:  Individual Submission
> Pages:  18
> URL:
> http://www.ietf.org/internet-drafts/draft-bishop-http2-extension-frames-01.txt
> Status:
> https://datatracker.ietf.org/doc/draft-bishop-http2-extension-frames/
> Htmlized:
> http://tools.ietf.org/html/draft-bishop-http2-extension-frames-01
> Diff:
> http://www.ietf.org/rfcdiff?url2=draft-bishop-http2-extension-frames-01
>
> Abstract:
>    This document describes a proposed modification to the HTTP/2
>    specification to better support the creation of extensions without
>    the need to version the core protocol or invoke additional protocol
>    identifiers.
>
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>


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