Adding "versioning" to a spec when you only have one version is risky.
Instead, I think it's better to wait until you know precisely how you
want to evolve the spec before you decide what the version mechanism
will be.
If it does end up being an HTTP header with an integer in it, it's easy
enough to write in the new version that in the absense of the header the
version is 1.
However, often protocols strive to evolve in a backward-compatible way
and an explicit version number is not necessary. For example, OAuth 1.0a
still uses a wire version of 1.0 because despite the new spec version
the protocol is wire-compatible with older clients. On the other hand,
OpenID 2.0 was incompatible with 1.1, so a new version parameter was
added for 2.0 and implementations take the lack of a version number as
an implicit 1.1.
Therefore I would caution against adding some arbitrary versioning
scheme right now and re-visiting this once there is actually a need for it.
Jay Rossiter wrote:
Something that's not addressed anywhere in the spec currently is
protocol versioning.
I think it becomes fairly evident that as the protocol changes (in
some suggestions, quite drastically, such as using atom:id instead of
atom:link[rel=self] for feed identifiers), things could become very out
of sync between what subscribers and hubs support.
In my opinion, there's a real need/benefit to adding an
"X-PuSH-Version:" (revise naming as you will) header for all outgoing
connections. The receiving host should respond appropriately (415
Unsupported Media Type ?) if a version is unsupported.
This would alleviate confusion once the protocol starts to diverge
from its current state, and different specs become incompatible with
each other.
--
Jay Rossiter | Software Engineer/System Administrator
Pioneering RSS Advertising Solutions
[email protected] <mailto:[email protected]> | Phone: 503.896.6187
| Fax: 503.235.2216
Website: www.pheedo.com <http://www.pheedo.com/> | RSS:
www.pheedo.info/index.xml <http://www.pheedo.info/index.xml>
