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 <[email protected]
> 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
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
