On 10/05/2010 23:38, Joseph Smarr wrote:
> Oh, one other quick benefit of JSON (kind of an extension of point 1 below):
>
> - no ambiguous treatment of whitespace or newlines (this is a problem
> I've observed multiple times while helping developers debug OAuth 1.0
> implementations--since they just split on & and =, they often don't trim
> extra whitespace or newlines that were returned by the server, leading
> to those spaces/newlines being part of the parsed attribute values,
> which then cause broken signatures and are very hard to debug, since the
> chars are invisible when printed). Not a problem with JSON.
>
> Let me try to offer some of those "logical, positive statements in
> favour of the technical merits of JSON over the original format
> choice" for those that aren't familiar or haven't gleaned them from
> the thread thus far:
>
> - unambiguous spec for encoding/decoding (including how to represent
> spaces and unicode chars, both of which are common points of
> ambiguity in url-encoding that lead to bugs, confusion, and lack of
> ability to use built-in libraries, if available). For example, the
> OAuth PHP library does the following: return str_replace('+', ' ',
> str_replace('%7E', '~', rawurlencode($input)) -- yuck!
>
> - easier to read the encoded format (because it has
> clear sentinel braces, quoted attributes, and no url-encoding of
> parameters; only some backslashing of reserved chars)
>
> - widely available libraries with good track records in the wild,
> and increasingly built in to many platforms
>
> - extensible support for more representing more complex data
> structures in the future, if needed
>
> - simple enough that it's easy to understand, but just complex
> enough that it's not too tempting to roll your own parser (which
> leads empirically to better compliance due to use of common libraries)
>
> - more likely to be recognized and understood by developers, since
> they've seen it elsewhere in API response formatsThanks for taking the trouble to respond in detail, the arguments in favour of JSON are now much clearer. > I think that about covers it. Again, it's an objective fact that > url-encoding has caused confusion and bugs in OAuth 1.0 > implementations, and it's also an objective fact that JSON has had a > very high "just works" rate in the wild, to the point that it's the > default API response format for many widely used APIs from large > providers targeting many platforms. So this is not a choice based on > "fashion", but based on trying to learn from history to increase > developer success and remove the opportunity for subtle bugs, which > was one of the major problems with OAuth 1.0a that prompted us to > work on OAuth 2.0 in the first place. I take your point. I'm slightly less convinced that this means that JSON is a single best format, as much of the above could apply to XML too. (Though I am aware of the other JSON vs XML arguments, which favour JSON). My preference is for multiple formats, but I'll leave this topic alone now. cheers, p > Thanks, js > > On Mon, May 10, 2010 at 11:33 AM, Pid <[email protected] > <mailto:[email protected]>> wrote: > > On 10/05/2010 15:56, Dick Hardt wrote: > > > > On 2010-05-10, at 1:11 AM, Pid wrote: > > > >> On 10/05/2010 07:57, Joseph Smarr wrote: > >>>> 1. Server Response Format > >>> > >>> I vote for B, though I could live with C. (A would make me > sad though) > >>> > >>> We've had a healthy and reasonable debate about the > trade-offs here, but > >>> I think the main counterargument for requiring JSON support > is that it's > >>> not quite yet a "no-brainer" to have JSON support in all > environments > >>> (e.g. iPhone libraries currently would need to statically > link in an > >>> available JSON library), whereas the counterarguments for A > are the > >>> well-documented problems properly decoding url-encoded > params from OAuth > >>> 1.0, plus the fact that it's not a common response format, > whereas JSON > >>> (and XML) are. Since I think JSON will continue to increase > in use for > >>> at least the next several years, the pain associated with > requiring JSON > >>> is likely to be higher now than it will be in the future, > and it's > >>> already low enough that we've had this debate about whether > it's already > >>> acceptable or not-quite-yet. And JSON has been proven to > "just work" in > >>> terms of avoiding encoding/decoding headaches in the wild, > which for > >>> something like OAuth is really critical. > >> > >> I don't believe this is an accurate summary. > > > > Are you saying the information is not accurate or not a > complete summary? > > > >> > >> I asked for someone in the pro-JSON camp to describe the > technical > >> merits of that format over url encoded, but to date, there's > no one who > >> has responded. > > > > per > http://www.ietf.org/mail-archive/web/oauth/current/msg01992.html > > Is that the right message? There's not much in the way of positive > arguments for JSON in that one. > > > > client libraries exist to parse JSON responses > > Meaning a dependency. > > > > client libraries do NOT exist to parse url encoded responses > > There aren't libraries to perform that type of decoding because it's > trivial, (as you acknowledged). > > > > Implementations of both OAuth 1.0 and WRAP improperly decoded > the responses. > > Also with reference to: "many developers have been caught just > splitting the parameters and forgetting to URL decode the token" > > With respect, I think this is pretty close to a straw man. It > would be > just as easy to argue that developers will make a mess of > parsing JSON. > > > > Everyone seems to have, (in some cases grudgingly), agreed that it's > easier to decode/parse urlencoded data than JSON. > > There are definitely occasions when using JSON for data > description & > transmission is advantageous, I just don't think this is one of > them. > It's a proverbial sledgehammer for a tiny OAuth nut. > > > There should be something positive to say about JSON that > establishes > why it is a better format for this purpose. > > > >> The options we've been offered seem contrived to support JSON, > > > > would you elaborate on why you think the options presented by > the editor were contrived? > > Sure. Two of them offer JSON as the default, including the putative > 'compromise' option. > > JSON and XML add complexity, as the editor states. IMHO it's odd > therefore not to select the least complex as the default, if > multiple > formats are offered. > > > > I appreciate that JSON is popular and there is a degree of devil's > advocacy to my position here, (as I've already said), but if > it's not > possible to make a list of logical, positive statements in > favour of the > technical merits of JSON over the original format choice then it > shouldn't be selected as the default. > > > p > > > > > > _______________________________________________ > OAuth mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/oauth > > >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
