Subject: Re: [hybi] Versioning is a anti-pattern

From: Benjamin Black <[email-masked]>
Date: Fri, 3 Sep 2010 19:50:14 -0700

On Wed, 3 Sep 2010, Adam Barth wrote:
> 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).
>

Having dealt extensively with exactly this problem, I don't see an
"anti-pattern" in versioning.  To the contrary, properly specified and
implemented versioning is very effective in making protocols that are
interoperable and extensible (one or the other alone is much easier
and does not require versioning).  The anti-pattern, as evidenced in
TLS and documented in the presentation you reference, is in
_under-specifying_ the protocol and not producing a way to _validate
compliance_ such that you can produce implementations that are
compliant and incompatible.  See slide 7 of the presentation for a
specific example.

Consider BGP4: it is ostensibly versioned, but almost all change
effort goes into extensions.  In turn, incompatible implementations
blow up in exciting, globally destructive ways every few years.  Look
at the introduction of the capabilities negotiation mechanism (which,
admittedly, did not cause _unexpected_ problems) 10 years ago, or the
recent IOS bug tickled by researchers (at Duke?) for specific
examples.

>> 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.

Without delving into the realm of attempting to prove a negative, I
suggest this argument is invalid.  The fact is the change from 1.0 to
1.1 with HTTP did not result in nearly the raft of incompatible but
compliant implementation problems that were seen with SSL and TLS.
Protocol versioning can absolutely be done properly.  The existence of
improper specifications and implementations does not damn versioning
in general.

Back to lurking,
b

ps - This sort of voluntary rejection of rigorous specification and
compliance is exactly what I dislike about the current Websockets
protocol upgrade handshake.  It's kind of HTTP, but not quite.
Hilarity ensues.

---

From: David Orchard <[email-masked]>
Date: Fri, 3 Sep 2010 21:09:26 -0700

> compliant and incompatible.  See slide 7 of the presentation for a

There are many "rules" that can help define a robust versioning
strategy.  I've worked on versioning protocols and document formats
for many years.  The one thing that I've learned, which isn't a
surprise, is that it's hard.  If you'd like to spend an hour or so
reading, I worked a lot on the W3C TAG on versioning and some of the
conclusions as best I could write are at
http://www.w3.org/2001/tag/doc/versioning.  An example nugget: "All
systems that include inputs and outputs must consider both when making
changes and determining compatibility. For full compatibility, a
revised consumer or producer must ensure any input message changes are
backwards compatible and any output message changes are forwards
compatible."

A really big part of the problem is that documents or data that are
exchanged as part of the protocol contain version identifiers and it's
often unclear whether they are identifying the containing document or
data version information or the version identiifier is
protocol/client/server versioning that is "smuggled" into the
document.  I think in the hybi scenario, there is little likelihood of
somebody picking up a bunch of hybi packets on a disk somewhere and
constructing a document - which is very much the web situation - so I
think probably any version identifiers in hybi exchanges will be for
hybi components, not the underlying languages/documents/formats.

Having dispensed with that, I think some further reading at
http://www.w3.org/2001/tag/doc/versioning-compatibility-strategies
could help.  Section 5.3 describes a few good practices.

"When producers use the highest possible version identifier, languages
SHOULD provide a default model for unknown version identifiers for
forwards-compatible evolution.

The handling model could be an algorithmic approach. For version
numbers, one could say that version numbers will only have a "major"
change if there is an incompatible change. For example, version 1.1 of
a language is by definition compatible with version 1.0 and version
2.0 is incompatible. Then, when the producer puts 1.0, 1.1, or 2.0, a
consumer at any level will know whether it can process the content.
This also means that there is a choice about which version number to
put in, the lowest or the highest. A document that contains "1.1"
means that any 1.X processor can process it. A "2.0" document means
that a 1.X processor cannot process it, but any "2.X" processor can.

Then the language should have wording about processing unknown version
numbers. Sample wording for a handling model for version identifiers
is, "A processor of this version MUST not fault if it receives a
document that contains the same major version number." This rule would
be in conjunction with forwards-compatible design for the texts, such
as "Must Accept Unknowns"
"

"When producers use the lowest possible version identifiers,
languagues should only change the version identifer for incompatible
changes."

There's much more, but I hope those snippets help.  If version
identifiers are in hybi, and I think they should be because the
messages will not be constructed by millions of people cut 'n pasting,
then please provide rigorous rules for what processors do with various
version identifiers they don't know about, and about messages that
contain content they don't know about, where know about typically
means that the implementor didn't know and programmed accordingly.

Cheers,
Dave