Re: [hybi] Versioning is a anti-pattern

["Martin J. Dürst" <[e-mail]>]

Hello Adam,

On 2010/09/04 11:06, Adam Barth wrote:
> On Thu, Sep 2, 2010 at 11:25 AM, Daniel Stenberg<[e-mail]>  wrote:
>> On Wed, 1 Sep 2010, Adam Barth wrote:
>>> Please don't add versioning to the protocol.  Versioning is a anti-pattern
>>> for the web.
>>
>> We've seen this mentioned before on this list but without a lot of
>> clarifications and I'm curious:
>>
>> What are the other transfer protocols for which versioning have failed so
>> significantly that versioning in protocols can be called an anti-pattern?
>
> Versioning has been a big pain point for TLS.  Here's a presentation
> that outlines some recent implementation experience:
>
> http://www.ietf.org/proceedings/65/slides/tls-6.pdf
>
> I encourage you to read through the presentation (it's pretty short).

This is indeed discouraging. TLS server side implementers seem to be 
rather challenged. For a security-related protocol, that's rather bad 
indeed. I very much hope WS implementers can do a better job.

>> Or isn't it so that it truly is an anti-pattern for the *web* (with the
>> emphasis added on the web word) and we're not really doing web here, we're
>> discussing a transfer protocol.
>
> It's a continual annoyance in dealing with the IETF to have to deal
> with this "browsers don't matter" attitude.

Of course browsers do matter. But servers do matter, too.

> In he case of this
> working group, we're working on a protocol expressly for use by
> browsers, which would seem to indicate that browser implementation
> experience is relevant.

Of course the browser implementation experience is highly relevant! But 
that doesn't mean that necessarily the browser implementation experience 
with HTML (or TLS) is relevant to pre-RFC WS implementations.

The way I understand it, there are three things that could potentially 
be versioned:

- Handshake
- Framing
- Extensions


Of these, the handshake is versioned almost by definition (though not 
with an explicit number), given that a change of the handshake means 
different header field names (I guess there's very wide agreement that 
it would be extremely dumb to keep the same header field names with 
different semantics).


The framing is where versioning has been proposed, but it is very 
important to note that this is only for when the framing actually 
changes. As soon as the framing is 'baked', I think there's wide 
agreement that there is no need for versioning. Frankly speaking, I'd 
also prefer to have *some* kind of indication of whether the first few 
bits of a frame are a length or a frame type or what, even if that 
doesn't have to be called a version number.


For extensions, as far as I understand, there is no proposal for 
versioning in the sense that there is no plan to bundle certain 
extensions under a certain version number. (there may be some base 
protocol features (maybe multiplexing could be one of these, we don't 
know yet) that are implemented by using the extension mechanism, but 
that's a separate matter).


There is of course the possibility for each extension (as well as for 
each subprotocol) to do versioning as they please (which hopefully will 
mean as little as possible.


So overall, it seems to be that the browser experience of "be careful, 
versioning, it may not work as well as you might think" is very much heeded.


Also, versioning has been requested for framing, and in particular for 
the first few bits/bytes of framing. Squeezing information tightly into 
bytes creates a different context with respect to versioning than a 
textual protocol with lots of redundancy such as HTML.


>> HTTP is the primary "web protocol" and AFAIK, its versioning is usually not
>> considered a failure.
>
> The version number in HTTP hasn't been change in a very long time.  I
> suspect we'd encounter tremendous difficulty if we tried to change it
> today.

Yes, indeed. The version number would only be changed if there were some 
very basic changes in the protocol. The tremendous difficulty isn't so 
much coming from a fundamental problem with versioning (if there indeed 
were some very basic protocol changes, there would probably be wide 
agreement with changing the version number) but from the fact that 
nobody currently is interested in very basic changes in the HTTP 
protocol (if you exclude this group :-).

In a similar way, it seems the big majority of contributors on this list 
agree that the version number (or the absence of a version number) 
should not change in a very, very long time *once the WS protocol, and 
in particular the framing part, is baked*.


In some ways, this reminds me of the AtomPub WG. It kept the version 
number at 0.3 while working on the spec. Everybody knew in advance that 
the final version would be version 1.0. That way, it tried to make sure 
that it had one shot at a clean spec, and reduced feature creep and 
early lock-in. I don't know how successful that were.


Regards,    Martin.


-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[e-mail]