Version Handling [ was OpenID status update ]

[Paul Crowley]

Evan Martin wrote:
> There's no point in slapping a version=1 if you don't define what
> version=2 means.
> If you do need to define a version=2, then you can just define
> version=1 as "sending no version= field".  They're basically the same
> thing, and I don't care very much about it either way.

I think there would be some advantage to adding a field openid.version 
to all client requests, with this definition:

"Servers that see this field in a client request with any value other 
than 1 should return an unsupported_version error."

But at the moment we don't really have a way of returning errors.  In 
fact the protocol states that in many circumstances we won't tell the 
client what's wrong, we'll just refuse the request.  I'm not sure that's 
the right response to *all* errors.

In the end, if we want to introduce totally incompatible protocol 
changes, we can always tack a version number on to the openid.mode 
parameter.  Any client or server that gets a request or response with an 
unrecognised openid.mode is going to reject it appropriately.
-- 
   __
\/ o\ Paul Crowley, paul at ciphergoth.org
/\__/ http://www.ciphergoth.org/