To me this smells a lot like XML a few years ago... how XML is baked into XMPP and people thought that HTML should be converted to XML... seemed like a good idea at the time :D
So yeah, I'm against supporting ONLY JSON. I'd be fine if the spec allowed for form-encoded, XML or whatever else might become the hot new thing. I'm really for leaving it up to the provider. I don't think it's up to OAuth to force people to use what we think is the coolest encoding format. Leah On Mon, May 24, 2010 at 5:52 PM, Dick Hardt <[email protected]> wrote: > > On 2010-05-24, at 4:55 PM, Marius Scurtescu wrote: > > > And to add to this, this example shows that encoding is hard, JSON > > only solves decoding (in most cases, but not all). > > JSON solves encoding and decoding with the same library. > > > > > For all direct requests clients still need to encode and without a > > library still need to figure what chars must be encoded. > > You argued this point numerous times at the in-person meeting. Clients are > used to encoding and creating requests to servers. That is what they do. > There are many simple ways of doing this. > > Clients in general do NOT decode forms data, that is done by servers, and > is built into server frameworks. > > > Introducing JSON because dealing with form-encoded is hard does not > > make much sense. As discussions last week showed (and earlier on this > > list), with JSON there is also the perception that it is easy to do by > > hand and that no escaping is needed. IMO that will lead to way more > > problems. > > Libraries exit for encoding and decoding JSON. They are really easy to use. > There is asymmetry in the forms data. Servers typically decode, and clients > typically encode. > > -- Dick > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
