+1 on not requiring JSON exclusively. There are enough number of small embedded software stack where JSON is not an option.
On Apr 20, 2010, at 12:45 PM, David Recordon wrote: > Having written an implementation last night against the web server > flow, I'm worried about adding JSON as a requirement for the response. > While it might be easier for environments with JSON libraries, it's > drastically more complex for environments (like embedded hardware) > which doesn't support JSON. And writing basic form encoded parsing > code really isn't that hard – especially if I can do it! > > > On Tue, Apr 20, 2010 at 9:24 AM, Joseph Smarr <jsm...@gmail.com> wrote: >> +1 to including JSON format, and perhaps making it the required format. In >> my experience helping numerous developers debug their OAuth implementations, >> url-encoding/decoding was often a source of bugs, since a) the libraries are >> usually hand-built, b) url-encoding is known to be funky/inconsistent wrt + >> vs. %20 and other such things, and c) it's very sensitive to things like a >> trailing newline at the end of the response, which can easily be tokenized >> as part of the the last value (since the normal implementations just split >> on & and =). In contrast, I've never heard of any problems parsing JSON, nor >> any encoding/decoding bugs related to working with JSON in other APIs >> (something I *cannot* say about XML, which is way more finicky about >> requiring its values to be properly encoded or escaped in CDATA etc.; I've >> also seen way more inconsistency in support of XML parsers and their output >> formats, whereas JSON always works exactly the same way and always "just >> works"). >> So in conclusion, url-encoding has caused a lot of pain in OAuth 1.0, and >> JSON is already widely supported (presumably including by most APIs that >> you're building OAuth support to be able to access!), so I think it would >> simplify the spec and increase ease/success of development to use JSON as a >> request format. In fact, I think I'd like to push for it to be the >> default/required format, given the positive attributes above. Does anyone >> object, and if so, why? >> Thanks, js >> >> On Tue, Apr 20, 2010 at 8:10 AM, Eran Hammer-Lahav <e...@hueniverse.com> >> wrote: >>> >>> There seems to be support for this idea with some concerns about >>> complexity. Someone needs to propose text for this including defining the >>> request parameter and schema of the various reply formats. >>> >>> EHL >>> >>>> -----Original Message----- >>>> From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] >>>> Sent: Monday, April 19, 2010 4:48 AM >>>> To: Eran Hammer-Lahav >>>> Cc: Dick Hardt; OAuth WG >>>> Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON >>>> >>>> >>>>> We can also offer both and define a client request parameter (as long >>>>> as the server is required to make at least one format available). >>>> >>>> +1 on this >>>> >>>> regards, >>>> Torsten. >>>> >>>>> >>>>> EHL >>>>> >>>>>> -----Original Message----- >>>>>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On >>>>>> Behalf Of Dick Hardt >>>>>> Sent: Sunday, April 18, 2010 9:30 PM >>>>>> To: OAuth WG >>>>>> Subject: [OAUTH-WG] application/x-www-form-urlencoded vs JSON >>>>>> >>>>>> The AS token endpoint response is encoded as application/x-www-form- >>>>>> urlencoded >>>>>> >>>>>> While this reuses a well known and understood encoding standard, it >>>>>> is uncommon for a client to receive a message encoded like this. Most >>>>>> server responses are encoded as XML or JSON. Libraries are NOT >>>>>> reedily available to parse application/x-www-form-urlencoded results >>>>>> as this is something that is typically done in the web servers >>>>>> framework. While parsing the name value pairs and URL un-encoding >>>>>> them is not hard, many developers have been caught just splitting the >>>> parameters and forgetting to URL decode the token. >>>>>> Since the token is opaque and may contain characters that are >>>>>> escaped, it is a difficult bug to detect. >>>>>> >>>>>> Potential options: >>>>>> >>>>>> 1) Do nothing, developers should read the specs and do the right >>>>>> thing. >>>>>> >>>>>> 2) Require that all parameters are URL safe so that there is no >>>>>> encoding issue. >>>>>> >>>>>> 3) Return results as JSON, and recommend that parameters be URL safe. >>>>>> >>>>>> -- Dick >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>> >>>> >>>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
