On Tue, May 11, 2010 at 3:33 AM, Vivek Khurana <hiddenharm...@gmail.com> wrote: > On Mon, May 10, 2010 at 2:36 AM, Eran Hammer-Lahav <e...@hueniverse.com> > wrote: >> DEADLINE: 5/13 >> >> I would like to publish one more draft before our interim meeting in two >> weeks (5/20). Below are two open issues we have on the list. Please reply >> with your preference (or additional solutions) to each item. Issues with >> consensus will be incorporated into the next draft. Those without will be >> discussed at the meeting. >> >> EHL >> >> --- >> >> 1. Server Response Format >> >> After extensive debate, we have a large group in favor of using JSON as the >> only response format (current draft). We also have a smaller group but with >> stronger feelings on the subject that JSON adds complexity with no obvious >> value. >> >> A. Form-encoded only (original draft) >> B. JSON only (current draft) >> C. JSON as default with form-encoded and XML available with an optional >> request parameter > > Being someone who has been involved in development of general purpose > libraries, I will either A or B, which means either full JSON RFC 4267 > compliance or Form-encoded only. Support of multiple format not only > increases development and maintenance effort, it increases the size of > library too. Since on the web, client might have to download the > library, keeping library size small is very important. If the standard > supports multiple formats, we might end up with libraries which will > support either JSON or XML or Form-encoded, thus leading to confusion > among developers.
For C, I don't think clients would be required to support both, only servers must support both. That being said, clients have to support A regardless (refresh token request still require clients to use form-encoded for the request; browser based requests require adding parameters to query string; browser based responses require parsing the query string; the User-Agent flow requires parsing query string from fragment). To me B and C are the same when it comes to dependencies and complexity. Marius _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
