http/2 and "extensions"

I really haven't had the opportunity to go through an read all of the
messages to understand the full context or what's actually being
written into the spec so I want to make sure... I'm seeing quite a few
comments passing by about pushing things into http/2 "extensions".
While having a clear, well-defined extensibility model in HTTP/2 is a
good thing. extensions themselves are a certainly a double-edged sword
if not handled appropriately. There are generally two points of view:

1. Extensions are good because they allow the protocol to evolve and
grow to meet new demands over time.

and

2. Extensions are bad because they give vendors excuses to not
implement functionality they disagree with. I.e. "We don't actually
want to do it that way, so we're going to pretend to be 'open' and
'encouraging' by saying that can be an "extension" when what we're
really going to do is kill it off by not implementing it".

So the question is: in HTTP/2, are there going to be clear notions of
mandatory-to-implement-but-not-mandatory-to-use extensions or are all
extensions going to be optional-to-implement. The difference is
critical. For example: I typically do not spend my time building
HTTP/2 infrastructure; I do, however, build applications on top of
HTTP/2 infrastructure. And if one of my applications depends on the
ability to use a particular HTTP/2 extension, I want to be clear on
whether or not I can rely on that extension being implemented or not.

- James

Received on Tuesday, 15 July 2014 17:42:44 UTC