I was told that my last paragraph was greatly insulting. I want to apologize if it came off that way or if anyone perceived it as directed at them. I think the quality of the discussion about version for the past year has been of low quality. People did not present requirements or shows an actual need for versions, as well as lacked detail as to what is being versioned. The only argument made is that "it seems like a useful thing".
Again, please don't take my comments to imply anything personal and I am sorry for my tone. EHL > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Eran Hammer-Lahav > Sent: Thursday, July 01, 2010 10:57 AM > To: Marius Scurtescu > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Versioning > > > > > -----Original Message----- > > From: Marius Scurtescu [mailto:mscurte...@google.com] > > Sent: Thursday, July 01, 2010 10:37 AM > > To: Eran Hammer-Lahav > > Cc: Rob Richards; OAuth WG (oauth@ietf.org) > > Subject: Re: [OAUTH-WG] Versioning > > > > On Thu, Jul 1, 2010 at 9:35 AM, Eran Hammer-Lahav > > <e...@hueniverse.com> > > wrote: > > > 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. > > > > I don't think the authz server endpoints are an issue, but the > > protected resources. The auth scheme is very generic, "Token". So > > either the scheme should be more specific, like "OAuth2", or a version > > should be added as a parameter. Maybe a token type as Dick suggested. > > HTTP Basic has no version, and I believe Digest doesn't have a version either > (though it has been revised from 2069 to 2617). The Token scheme is generic, > but also wide open. The only required parameter is 'token' (which makes > sense for a Token scheme). I can't come up with a single requirement that > would require an explicit version parameter. > > Version discussions are almost always a waste of time because at the time > they are debated, no one knows what the requirement for such a feature > will be. Versioning usually makes sense in a follow-up revision where the > protocol needs a way to differentiate itself from the previous version. > > If anyone wants to propose a versioning of any parts of this protocol, they > must present specific objectives. The vague objective of "allow future > versions" isn't valid because it has failed for 1.0 (and many other > protocols). > Instead, I suggest people pay more attention to the extensibility and ensure > that it offers enough support for future needs, without having the change > the protocol. > > We tried adding version support in OAuth 1.0 and failed. The version > parameter does not help in any real way, is incompletely, and poorly defined. > The quality of this new discussion is as low as that of the 1.0 attempt. Let's > learn from our mistakes. > > 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
