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

[Pid <[e-mail]>]

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 formats

Thanks 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 <[e-mail]
>     <mailto:[e-mail]>> 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
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/oauth
> 
> 
>