I want to completely agree with what Paul wrote: "What is a pain on the client
side is conditional code that has to be followed in order to consume whatever
the server wants to send. The client should have a single code path knowing it
will get what it wants".
BTW, this is also part of the argument for making the resource parameter
required. Paul's example of:
curl -v
https://packetizer.com/.well-known/host-meta.json?resource=acct:pau...@packetizer.com
should work on all deployments - not just packetizer.com, so clients can rely
on it working (and not have to have conditional code to try again in a
different way when it doesn't).
As a design principle, to the extent there's any complexity, it should be
pushed to the servers, rather than the clients, as clients will vastly
outnumber servers. The solution should be as simple for clients to use as
possible, to facilitate adoption.
Best wishes,
-- Mike
(moved OAuth to bcc)
-----Original Message-----
From: apps-discuss-boun...@ietf.org [mailto:apps-discuss-boun...@ietf.org] On
Behalf Of Paul E. Jones
Sent: Friday, April 20, 2012 9:11 PM
To: 'Michael Thomas'; 'Derek Atkins'
Cc: oauth@ietf.org; 'Apps Discuss'
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)
Mike,
> On 04/20/2012 07:17 AM, Derek Atkins wrote:
> > <OAUTH Chair Hat> Note that this is a replay of the historical "MUST
> > Implement" versus "MUST Use" arguments. Just because the server MUST
> > IMPLEMENT JSON and XML does not mean that a Client must use both (or
> > even that a client must implement both). It is perfectly reasonable
> > and generally acceptable to have a server that provides data in
> > multiple formats whereas the client only supports a subset and
> > specifies which format(s) are acceptable. </OAUTH Char Hat> -derek
>
> To Paul's point about how easy it is for a server to support both, I'd
> retort that it's equally easy for a client to gin up JSON instead of XML.
I don't follow.
I agree I could write a client that could do JSON easily.
I agree I could write a client that could do XML easily.
What is a pain on the client side is conditional code that has to be followed
in order to consume whatever the server wants to send. The client should have
a single code path knowing it will get what it wants, ether XML or JSON.
Granted, the server has to have a conditional statement and generate XML or
JSON as requested. However, generating either is trivial. Really, I did it in
minutes. We're not talking about huge complex data structures here with
WebFinger.
> Pity the poor programmer who can't get their head around that gigantic
> change. On the other hand, having to support XML and JSON is an
> ongoing maintenance headache server-side. Why do it?
Would we expect to see a lot of changes to the data structures used by
WebFinger? That's really the only ongoing maintenance issue. Don't touch the
code that produces the XML or JSON and there is no ongoing maintenance.
> There isn't even the dubious
> religious war like back in the day saying that binary encoded ASN.1
> was "better/faster/stacks and cleans dishes" than "human readable"
> XML. XML is just a clunky and past its prime text encoding at this
> point. Requiring it smacks of nostalgia to me.
I disagree with you on that one. First, ASN.1 is better for defining
protocols, so long as you stay away from the complex stuff. Basic ASN.1 looks a
lot like C and produces C data structures that can be readily read, decoded,
and consumed in C code. Rarely, rarely do I see decoding issues when using
ASN.1, whereas issues pop up quite often with text protocols, especially things
like SIP where a semi-colon in the wrong place breaks things. But, let's not
start that debate again ;-)
XML *can* be big and clunky. As you've well noticed, I can also write lengthy
emails that seem to have more typos as the evening progresses. :-)
However, XML can be a very compact encoding and it's extremely readable.
I just did a query on my server to see the XML vs. JSON output. The XRD
document provided was 1032 octets. The JRD document was 1077 octets.
Removing every possible space and making both formats hard as heck to read,
JSON was 837 and XML was 940. I'm hard pressed to say that's makes much
difference. Further, I can't read either of them now without some effort.
Considering that a lot of WebFinger use (I suspect) is going to be
server-to-server interaction, XML seems like a reasonable format to retain.
That, and the fact it is already mandatory in RFC 6415 and deployed out there.
It's not nostalgia for me. XML is a very well-structured, readable format.
No objection to JSON, but I really don't understand the clamoring for JSON.
I guess more precisely, I don't understand the disdain for XML. Is it because
people created hideously complex XML data structures and feel pain for having
done that? XRD is not that kind of document.
Paul
_______________________________________________
apps-discuss mailing list
apps-disc...@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
