Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON

[Richard Barnes <[e-mail]>]

On the other hand, if you've already got a JSON or XML library on hand  
(as many apps these days do), then JSON/XML is a lot easier to handle  
than form-encoded.  Plus, if you're not re-using form-encoding, then  
there's no risk of being confused with actual "forms" / request  
parameters.  Not trying to argue one side or the other, just noting  
that there are trade-offs.

To refine Eran's point a little, how about this proposal?
1. Define N encodings of the OAuth parameters
2. Require servers to support *all* encodings
3. Require clients to support *one* encoding (and to send only one at  
a time!)
4. Require servers to respond in the encoding they receive

Seems like that would minimize the burden on clients, without placing  
a huge burden on servers.

--Richard



On Apr 19, 2010, at 3:37 PM, Mike Moore wrote:

> On Mon, Apr 19, 2010 at 1:03 PM, Torsten Lodderstedt <[e-mail] 
> > wrote:
>
> So what should be the singlemost encoding to be standardized? I  
> would be unable to choose one.
>
> I think form encoding is just fine. Its lightweight, minimalistic,  
> and easy to implement. I don't see a reason to switch from the 1.0  
> spec.
>
> If the issue is poor implementations or devs not reading the spec,  
> then perhaps we should discuss a series of executable specs or a  
> reference implementation. (I know I sure could have used that when I  
> implemented OAuth.) Just my two cents.
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth