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

A few additional specific comments:

1. re: BASE_SPECIFICATION_ONLY ... this is currently underspecified in
the draft. Let's suppose my client establishes a stream that "travels"
through two intermediate hops on it's way to the server. The path
determined dynamically by the intermediaries. The first intermediary
allows end-to-end extension frames to pass through, but the second
intermediary does not and sends BASE_SPECIFICATION_ONLY. What should
the first intermediary do if it receives extension frames from the
client? Obviously, it cannot send those but there is nothing in the
draft that describes exactly how the intermediary ought to handle it.

 a. Should it just silently drop any extension frames it receives from
the client without notification. The problem being, of course, that
the client would have no idea that it's complete message is not
getting through
 b. Should it update it's settings with the client and say
BASE_SPECIFICATION_ONLY, while silently dropping any extension frames
it may have already received? The problem with this, of course, is
that it terminates that clients ability to send extension frames
through that first intermediary to any other endpoint that might not
have the BASE_SPECIFICATION_ONLY requirement.
 c. Should it RST_STREAM the stream with the client letting it know
that the extension frames could be passed on?

 (IMHO, (c) is obviously the best choice)

2. re: Flow control ... are end-to-end extension frames subject to
flow control, and if not, why not?

3. Strongly feel that the use of Private enterprise numbers as a
namespacing mechanism for extensions is going to encourage abuse and
non-standardization of protocol extensions. Specifically, it allows
specific vendors the ability to define, deploy and maintain their own
proprietary protocol extensions without any pressure whatsoever to
take things through standardization. IMHO, that's fairly dangerous.
Having a limited extension space with very clear processing
requirements is a significantly better option.

4. A compromise approach here would be to utilize both of the
approaches suggested by myself and Mike's draft. Specifically:

  a. Segment the existing frame type space into end-to-end and
hop-by-hop as I have suggested,
  b. Define that hop-by-hop frames MUST either be passed through
untouched or RST_STREAM returned,
  c. Define that *all* hop-by-hop frames are subject to flow-control,
  d. Define that extension end-to-end frames MUST NOT change session
state and can be silently dropped.
  e. Define a new INFO frame type that can always be silently dropped.
The structure of the INFO frame would essentially be the same as Mike
suggests in his draft. The INFO frame would be hop-by-hop, with the
intermediary having the ability to decide whether or not to forward
those on (like we currently do with PUSH_PROMISE).

This would be a much more robust and reliable approach.

- James

On Fri, Nov 8, 2013 at 11:21 AM, Mike Bishop
<Michael.Bishop@microsoft.com> 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: internet-drafts@ietf.org
> 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-frames-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
>

Received on Sunday, 10 November 2013 19:20:36 UTC