Re: New Version Notification for draft-kazuho-early-hints-status-code-00.txt

On Thu, 2016-11-03 at 09:08 +0000, Cory Benfield wrote:
> > 
> > On 2 Nov 2016, at 22:50, Roy T. Fielding <fielding@gbiv.com> wrote:
> > 
> Sure. But my comment was about having *well-oiled* extension
> mechanisms. Put another way, if you have exactly one place to put an
> extension, then that is where all extensions will be put. This will 

Just jumping in with my tiny bit of experience on this narrow subject
of handwaving standardized extensions.

>From the point of view of ws, extensions were an almost complete
failure and came into being to stop the endless dithering (let us
recall, there were like 80 versions of that standard...) at least in
part caused by Google trying to mutate it into spdy.  It only got out
the door by the sleight of hand of pushing compression and mux into
"extensions" to be discussed later.  Ws mux was stillborn, because
Google passed on the honour and it instead became http/2.

So one of the two major targets for "ws extensions" said "nope", and
the only ws extension in any kind of actual use AFAIK is RFC7692
permessage-deflate.  Doing even that properly (ie, streaming the
deflate in chunks, rather than allocating for inflate of the whole
message) has radical impacts on the whole architecture, and supporting
generic extensions even more so --->

> greatly increase the speed which with the bug-finding use-case will

...therefore many ws implementations support neither extensions in
general nor permessage-deflate specifically.  (You might say, "that's
OK because they are extensions", but they architecturally decided they
repudiated the whole idea of extensions).  So no, it didn't increase
any bug finding.

>From this experience, I think maybe the standards should avoid looking
towards Founding An Empire That Lasts A Thousands Years and just have
it do what it should do.  If you look at http, his "extensions" were
very natural compared to ws reserved bits that will never come into
use, unused extensions bar one, you could just get additional random
headers with a well-defined way to skip what you didn't understand at
the per-header level.  The paleo-headers were "extensible", they were
not "extensions".  Or .well-known, as another example of a positive
pattern,  that didn't extend http at all but is open-ended for what it
does.

I want to suggest "extensions" are a sign the definition of the
protocol has failed...

-Andy

Received on Thursday, 3 November 2016 10:32:37 UTC