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 client libraries exist to parse JSON responses client libraries do NOT exist to parse url encoded responses Implementations of both OAuth 1.0 and WRAP improperly decoded the responses. > > 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? _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
