Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)

["Paul E. Jones" <[e-mail]>]

Melvin,

The acct: URI scheme is not a new protocol, but just a scheme that refers to user accounts. It is documented in the WebFinger draft.

Paul


-------- Original Message --------
From: Melvin Carvalho <[e-mail]>
Sent: Sat Apr 21 23:09:54 EDT 2012
To: Mike Jones <[e-mail]>
Cc: "Paul E. Jones" <[e-mail]>, Michael Thomas <[e-mail]>, Derek Atkins <[e-mail]>, Apps Discuss <[e-mail]>
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)

On 21 April 2012 18:37, Mike Jones <[e-mail]> wrote:

> 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:[e-mail]
> 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.
>

if acct: is to become a new protocol for the internet , I request that it
should be fully documented, and available for review


>                                Best wishes,
>                                -- Mike
>
> (moved OAuth to bcc)
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> On Behalf Of Paul E. Jones
> Sent: Friday, April 20, 2012 9:11 PM
> To: 'Michael Thomas'; 'Derek Atkins'
> Cc: [e-mail]; '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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>
> _______________________________________________
> apps-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>