Re: http/2 and "extensions"

On 16 July 2014 07:48, Martin Thomson <martin.thomson@gmail.com> wrote:

> On 15 July 2014 14:46, Matthew Kerwin <matthew@kerwin.net.au> wrote:
> > My feeling, coming from my encoded data thing, is that the more "real"
> the
> > extension (i.e. not just communicating nice-to-know metadata, but
> actually
> > doing something semantic), the more design and text is going to be
> dedicated
> > to dealing with unsupportive or broken peers.
>
> Which leads back to a preference for a new protocol label at that point.
>

Indeed, but that's a big wager for something potentially marginal. For a
single extension the technical difference is really only: in the one case,
just send the introductory frame/settings/etc. and see if it comes back; in
the other, negotiate on the token. Either way you learn whether or not it's
safe to use, and thereafter the logic in the code isn't that different.
However there's a bit of non-technical difference, in that supporting this
whole new "h2-zip" protocol just for a single flag in a DATA frame may seem
disproportionate and scary.

The real issue is multiple extensions, which we've said all along. If I
write encoded data, and someone else writes an awesome new header
extension, say, then which (if any) gets to have a protocol token? Do we
make three tokens for the two extensions? Dragons, etc. So I think we have
to write the extensions, do all the extra work to deal with the jagged
edges, and maybe one day they get to be coded into a new protocol.

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