Version Handling [ was OpenID status update ]

[Ben Hyde]

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

On Jun 5, 2005, at 5:56 AM, Martin Atkins wrote:
> ... For what it's worth, I think it's pointless. Everyone will ignore 
> it

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 
> protocol
> 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.  [ 
my prefence]
   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 
comprehend.

Don't do anything in this time frame, and say so in the spec, about 
version negotiation.

- ben

----
http://enthusiasm.cozy.org   http://gibbon.cozy.org   
tel:+1-781-240-2221
  I forecast sunny weather!