This is not aimed at anyone in particular. Replying +1 is not justification for a major breaking change. This was raised in the past and consensus was that this is not a major concern. Over the past 10 months not a single actual issue was raised about conflicts in legacy platforms. If you have an *actual* issue with a platform, please provide the full details, including why known mechanisms such as Apache rewrite rules can't solve the it.
We're must be done discussing hypotheticals and theorizing about how this protocol will get adopted by those not represented here. That was fine a year ago, but at this point, whoever is in this group gets to make the decision based on our collective deployment experience. I honestly can't be bothered to care about deployment issues in some undeclared legacy platforms no one here is struggling with. I've been doing this work continuously for over three and a half years and have learned that trying to optimize for the 'adoptions by others not present' is a complete waste of time. Suggesting that adoption will be significantly affected because of lack of parameter prefix or the inclusion of half-baked client assertion mechanism is just silly. EHL > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Skylar Woodward > Sent: Wednesday, January 26, 2011 9:33 AM > To: William Mills > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt > > +1 > > More feedback on the token specs (and v12) is in my queue for tonight, but > this has also been a concern of mine and this seems to be a more elegant > protection against conflicts than adding a "version" parameter. > > On Jan 26, 2011, at 6:14 PM, William Mills wrote: > > >>> Broken record: using a prefix for all registered parameters is much > >>> cleaner (as opposed to requiring that all no-registered parameters > >>> use a prefix). > >> > >> And once again, a strong +1 to this, even though I know it's far too > >> late to make such a breaking change to the spec. I really think this > >> was a bad decision and is going to come back and bite us in the > >> future. > >> > >> -- Justin > > > > Yep. > > _______________________________________________ > > 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
