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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
