I'm normally no fan of namespaces or other forms of needless complexity, and it's true that PoCo dropped the pdata_ prefixes to all its query parameters that we'd originally proposed, but I do think there's something helpful and and clear about oauth_ because it makes it so clear which parameters are part of OAuth--it's visually concise and readable, without the mechanical headaches of say XML namespaces. I'll agree that we can probably all learn to live without it (assuming collisions are empirically rare and there isn't code that needs to easily glob "all oauth parameters, including any future ones", e.g. the way OpenID does for signing), but I still feel a bit queasy doing so, and it's not obvious to me how much simplicity/performance/etc we buy for dropping them, so my (weak) preference would be to keep them, but I won't fight too hard if there are lots of people passionate about dropping them. :)
Thanks, js On Tue, Apr 20, 2010 at 7:55 AM, Eran Hammer-Lahav <e...@hueniverse.com>wrote: > > > > -----Original Message----- > > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > > Of John Kemp > > Sent: Tuesday, April 20, 2010 3:38 AM > > To: Peter Saint-Andre > > Cc: Marius Scurtescu; OAuth WG > > Subject: Re: [OAUTH-WG] Issue: prefixing parameters with oauth_ > > > > On Apr 20, 2010, at 12:46 AM, Peter Saint-Andre wrote: > > > > > On 4/18/10 6:46 PM, Dick Hardt wrote: > > > > > >> Given the practice that the authorization endpoint and the > > >> redirect_uri can contain URI query parameters, then differentiating > > >> between application specific query parameters and OAuth protocol > > >> parameters by prefixing the OAuth parameters with oauth_ would seem > > a > > >> useful way to minimize conflicts. > > > > > > Can't application developers avoid conflicts by giving their > > > parameters names other than those already used in OAuth? > > > > Is every application developer (those using an OAuth library, or product) > > familiar with the names that are used in the OAuth spec? > > First, the must be or how else would they interact with it or support their > developers. If they are installing a client and server products, their > vendor should make sure to provide a fully working solution. > > The OAuth flow endpoints (as opposed to protected resource endpoints) are > an *application* endpoint. This is not some add-on protocol or an extension > of existing framework, or a hack. This is a fully specified application API > which requires and deserves treatment like a separate, standalone > application. This is not the case when accessing a protected resource which > belongs to another application. > > It is odd to me that none of these arguments are made for other application > APIs such as Portable Contacts [1], Open Social [2], and others, all meant > to be implemented within the same platforms and servers as the OAuth flow > endpoints. OpenSocial for example, is implemented by a wide range of > different platforms, but yet does not have an opensocial_ prefix. Are there > reports of conflicts and deployment problems because of that? > > The argument made for a prefix is that is *seems* to be useful. However, > experience seems to point the other way that a lack of prefix does not break > the web. If "seems to be useful" is the bar this working group is setting, > we are going to end up with a much bigger, more complex specification. > > EHL > > [1] http://portablecontacts.net/draft-spec.html > [2] > http://www.opensocial.org/Technical-Resources/opensocial-spec-v081/restful-protocol.html > _______________________________________________ > 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
