Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13)

[Pid <[e-mail]>]

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