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

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.

-=R


On Thu, May 22, 2014 at 4:48 PM, Matthew Kerwin <matthew@kerwin.net.au>wrote:

> 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 <Michael.Bishop@microsoft.com> 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:* internet-drafts@ietf.org
>> *Sent:* ‎Thursday‎, ‎May‎ ‎22‎, ‎2014 ‎10‎:‎24‎ ‎AM
>> *To:* Mike Bishop <Michael.Bishop@microsoft.com>, Mike Bishop<Michael.Bishop@microsoft.com>
>>
>>
>> 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/
>