RE: New Version Notification for draft-bishop-http2-extension-frames-00.txt

[Mike Bishop <[e-mail]>]

We discussed some of this at the Bellevue interim….



With regard to HbH vs. E2E:

·         End-to-end on stream zero isn’t possible, since there’s nowhere to forward them

·         On-stream frames mix hop-by-hop and end-to-end

In order to simplify the model, there was general consensus that we could simplify this considerably by reducing it to two states:

·         Stream zero is hop-by-hop, and ignored if not understood

·         On-stream is end-to-end and may be dropped or forwarded

While I’m not inherently opposed to also allowing on-stream hop-by-hop frames since the protocol has them, it does increase the handling complexity some.



With regard to your space partitioning idea, it doesn’t solve type exhaustion.  In fact, it exacerbates it since one type can be exhausted while types still remain in the other half of the space.  If we allow a mix of E2E and HbH frames on-stream, I’d prefer a flag to the MSB approach.



The idea of having a private-use range for use during development followed by registration and a shift to IANA-assigned values is an option, but given that some of our numbers tend to broadly deploy things that are still under active development, that complicates both the transition from the unassigned to assigned versions and the ability of extensions to coexist.



-----Original Message-----
From: James M Snell [mailto:[e-mail]]
Sent: Friday, November 8, 2013 12:13 PM
To: Mike Bishop
Cc: HTTP Working Group
Subject: Re: New Version Notification for draft-bishop-http2-extension-frames-00.txt



On Fri, Nov 8, 2013 at 12:06 PM, James M Snell <[e-mail]<mailto:[e-mail]>> wrote:

> It's great to see work being done on the extension model but I'm not

> convinced that the approach you suggest in this draft is the best way

> forward.

>

> The approach that I would like to see is this:

>

> For Frames:

>

> 1. Clearly define the notion that some frames are *always* end-to-end,

> while others are *always* hop-by-hop 2. Clearly differentiate these

> types using the MSB of the frame type.

> If the MSB is set, the frame is end-to-end 3. Specify that end-to-end

> frames are *always* subject to flow control 4. Change the type of the

> DATA frame to 0x80 5. Dedicate 10 frame types at the top of each range

> (0xF5-FF and

> 0x75-7F) as "private use" frame types that cannot be assigned by IANA.

> 6. Require that end-to-end frames are only sent on open streams

> (basically, whenever a DATA frame can be sent)



Missed one:



  7. Require that implementations ignore-but-forward unknown end-to-end frames; while allowing them to ignore-and-drop unknown hop-by-hop frames... with the option of signaling an error if they so choose.





>

> For Settings:

>

> Dedicate some portion of the possible range of settings as "private

> use" that cannot be assigned by IANA

>

> - James

>

> On Fri, Nov 8, 2013 at 11:21 AM, Mike Bishop

> <[e-mail]<mailto:[e-mail]>> wrote:

>> Since I was volunteered at the working group meeting to share this,

>> here’s the current version of my draft.  I will re-emphasize that

>> this is strictly a strawman, and any suggestions on how to improve

>> this are more than welcome.

>>

>> Sent from Windows Mail

>>

>> From: [e-mail]<mailto:[e-mail]>

>> Sent: ‎Friday‎, ‎November‎ ‎8‎, ‎2013 ‎11‎:‎16‎ ‎AM

>> To: Mike Bishop

>>

>>

>> A new version of I-D, draft-bishop-http2-extension-frames-00.txt

>> has been successfully submitted by Mike Bishop and posted to the IETF

>> repository.

>>

>> Filename:  draft-bishop-http2-extension-frames

>> Revision:  00

>> Title:   Extension Frames in HTTP/2.0

>> Creation date:  2013-11-08

>> Group:   Individual Submission

>> Number of pages: 10

>> URL:

>> http://www.ietf.org/internet-drafts/draft-bishop-http2-extension-fram

>> es-00.txt

>> Status:

>> http://datatracker.ietf.org/doc/draft-bishop-http2-extension-frames

>> Htmlized:

>> http://tools.ietf.org/html/draft-bishop-http2-extension-frames-00

>>

>>

>> Abstract:

>>    This document describes a proposed modification to the HTTP/2.0

>>    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

>>