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. On Mon, May 10, 2010 at 3:35 PM, Joseph Smarr <[email protected]> wrote: > 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 formats > > 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. > > Thanks, js > > On Mon, May 10, 2010 at 11:33 AM, Pid <[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] >> https://www.ietf.org/mailman/listinfo/oauth >> >> >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
