On 04/23/2012 09:55 AM, Derek Atkins wrote:
Michael Thomas<m...@mtcc.com> writes:
Derek Atkins wrote:
Michael Thomas<m...@mtcc.com> writes:
Why not MUST ASN.1 while you're at it? JSON has won in case
you'all haven't noticed it.
Well, now that you mention it... ;-)
But seriously, we're basing this work on an RFC that was just release
six months ago and it requires XML. Why be so quick to drop something
we just published half a year ago? So maybe in 6 months we drop JSON
and add the next big thing? Come on, Mike.
I agree, we should definitely support JSON. But I also think we should
support XML. The client can do what it wants, which is where want the
light weight implementation.
I think you're probably misunderstanding me. I'm (I believe) with Tim
in saying "pick one". Just one. For clients and servers. And I'm only
No, I'm not misunderstanding you, I know exactly what you are arguing
for. And I'm agreeing with you that we must support JSON. However, I
disagree that we should drop XML, especially considering 6415 requires
XML and it was just released 6 months ago.
I'm also saying that this is only a server-side requirement to support
both. The client can choose to support only one based on its own
requirements. If you already have an XML-based client, why force them
to add JSON support? Similarly, if you already have a JSON-based
client, why force them to add XML support?
If you're writing a client, you can ignore XML and only play with JSON.
Derek -- I think that the modern reality is that most things can
support both without much problem from a code footprint and
library availability standpoint, both client and server. But that
misses a larger point of whether we _should_ just because we
_can_. There is a cost to maintaining two different encoding/
decoding both on the implementation side, as well as the
specification (and the debugging thereof) side. So my feeling
is that "chose one" should *always* be a SHOULD in the way
that Stephen outlined as well. If that means choosing XML
mainly for historical reasons, that's still better than trying to
placate both sides or "facilitating the transition" or any other
reason on offer.
Mike
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
