Version Handling [ was OpenID status update ]
bhyde at pobox.com
Mon Jun 6 09:57:08 PDT 2005
The following is a brutal peice of cherry picking from various
responses. Hopefully I haven't
done any damage to the points anybody was making. My goal is to drive
to closure so I maybe
glossing over points that people made.
I see two plans for getting to closure on this:
Plan A: ignore the issue in this time frame; deal later.
Plan B: assure that we have a way to deal, possibly with a version
scheme in this time frame.
I mostly want the spec to give clear instructions to implementors about
how to code in a manner
that assures they are prepared to deal with version skew. I'd much
prefer a scheme that can test
those servers in the current time frame.
Plan A: deal later; has a ground swell of support and it certainly
looks like it gets us out the
On Jun 5, 2005, at 5:56 AM, Martin Atkins wrote:
> ... For what it's worth, I think it's pointless. Everyone will ignore
On Jun 5, 2005, at 2:11 PM, Paul Crowley wrote:
> I still can't see what you're gaining by it. I can't think of a way
> the protocol could change that would be made easier/possible by adding
> a major version now.
Plan B: deal minimally now - that's what I want.
On Jun 5, 2005, at 3:25 PM, Evan Martin wrote:
> However, one useful thing is to define behavior for when the version
> does change.
On Jun 5, 2005, at 12:21 PM, Ken Horn wrote:
> Versioning is always a mare, but i think the main benefit is declaring
> what your message (either from consumer to id server or the return, or
> any other interaction) contains, ie is explicit. Without going for a
> full negotiation, I think there's still value in the declaration.
On Jun 5, 2005, at 6:07 PM, Martin Atkins wrote:
> I think the idea is that the software will downgrade to suit what it's
> talking to, rather than failing.
+1 to all three of those.
A possible outcome of the plan B kind was floated.
Brad Fitzpatrick wrote:
> I'm fine with adding an integer. (effectively the major) Minor
> revs will be implied by the presence of new parameters.
If we do that then the spec needs to be clear and testing should verify
that servers implement either
1) sadly fail if you get openid.* parameters you don't comprehend. [
2) happily ignore openid.* parameters you don't comprehend.
I'd like to see an integer added. The clients then declare the version
they are speaking by providing
the integer either explicitly (or implicitly it's 1). We can then spec
and test to verify that servers fail when
they are asked to deal with requests from versions they don't
Don't do anything in this time frame, and say so in the spec, about
I forecast sunny weather!
More information about the yadis