Why is a version better than a new scheme name? Version is only helpful when 
the protocol is practically the same with some minor changes, and if that is 
the case, extensibility alone should be enough.

EHL 

> -----Original Message-----
> From: William Mills [mailto:wmi...@yahoo-inc.com]
> Sent: Thursday, July 01, 2010 10:49 AM
> To: Eran Hammer-Lahav; Rob Richards; oauth@ietf.org
> Subject: RE: [OAUTH-WG] Versioning
> 
> My feeling on this is that versioning explicitly in the protocol adds clarity 
> and
> some small level of compatibility.  Different auth and token endpoints are
> easy, what's harder is supporting multiple protocols on the same protected
> resource.  It's on the protected resource I'd like to see some clearer 
> protocol
> version spec so I'm not having to figure out from the variable names which
> protocol it is.
> 
> > -----Original Message-----
> > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> > Of Eran Hammer-Lahav
> > Sent: Thursday, July 01, 2010 9:36 AM
> > To: Rob Richards; OAuth WG (oauth@ietf.org)
> > Subject: Re: [OAUTH-WG] Versioning
> >
> > Hi Rob,
> >
> > > -----Original Message-----
> > > From: Rob Richards [mailto:rricha...@cdatazone.org]
> > > Sent: Thursday, July 01, 2010 3:26 AM
> > > To: OAuth WG (oauth@ietf.org); Eran Hammer-Lahav
> > > Subject: Versioning
> > >
> > > Versioning is still something that needs to be addressed
> > before being
> > > being able to consider the draft core complete.
> >
> > Versioning rarely works because when you define it, you have no idea
> > what the requirements will be for the next version. A good example is
> > the OAuth 1.0 version parameter. When we worked to revised 1.0 into
> > 1.0a, we had a long debate on changing the protocol version number. We
> > had a hard time agreeing on what the version meant and what was it a
> > version
> > *of*: the signature method or the token flow.
> >
> > If this protocol will require significant changes in the future that
> > go beyond its extensibility support, such a new version will need to
> > use different endpoints (token or end-user authorization) and/or
> > different HTTP authentication scheme.
> >
> > If you want to discuss versioning, you must provide your requirements
> > for such a feature, and clearly show how they are not served by the
> > current extensibility proposal.
> >
> > > On this I'm still of the opinion that at the very minimum you will
> > > need to require an oauth_version parameter for the resource
> > endpoints,
> > > if not also for the others as well.
> >
> > I think the difficulty of differentiating a 1.0 from a 2.0 protected
> > resource request is exaggerated. As said before, you can tell the
> > difference based on the presence of other parameter
> > (oauth_signature_method), or by examining the provided token (assuming
> > you issue different tokens for each version). The argument that a 2.0
> > request can also be a malformed 1.0 request is silly. I have yet to
> > hear about that level of incompetence for a 1.0 developer (and I've
> > heard about a lot) - omitting every other required parameter.
> >
> > At most, I'm open to renaming the oauth_token parameter to something
> > else (oauth_access_token, oauth.token, oauth-token,
> > etc.) but I think even that is not needed.
> >
> > EHL
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to