Subject: Re: [apps-discuss] Proposed changes to WebFinger regarding XML vs JSON

From: Mikael Nordfeldth <[email-masked]>
Date: Sat, 01 Sep 2012 11:43:09 +0200

01.09.2012 04:57 skrev William Mills:
> I'm in favor of mentioning legacy applications using XML and
> referring to the original spec there, just to make it clear that 
> there
> is an installed base.

StatusNet and Diaspora are heavy users of Webfinger and seem to only 
support the XML version to date and the leading federated social web 
standards draft OStatus currently suggests all remote servers to support 
an application/xrd+xml
SN: 
http://gitorious.org/statusnet/mainline/blobs/master/actions/hostmeta.php
OS: 
http://ostatus.org/sites/default/files/ostatus-1.0-draft-2-specification.html
D*: 
https://github.com/diaspora/diaspora/wiki/Diaspora%27s-federation-protocol

Also, it is my belief XML is simply more extensible with its splendid 
namespacing in the case where an application may wish to deliver 
alternative, marked data from host-meta to avoid several requests.

As mentioned previously in this thread, there's less adoption-trouble 
if the requirement to support both XRD and JRD is put on the server. Any 
reliably accessible server out there should reasonably be able to 
support both just because in its simplest form, host-meta is dead simple 
to convert.

As a sidenote I do appreciate having a separate extension for the 
content-type. I.e. host-meta.json for json data, as it allows for static 
file structure and does not require dynamic interpretation of headers. 
Which definitely simplifes adoption.

-- 
Mikael Nordfeldth
http://blog.mmn-o.se/
[email-masked]

---

From: Mikael Nordfeldth <[email-masked]>
Date: Sat, 01 Sep 2012 11:59:45 +0200

01.09.2012 03:18 skrev Paul E. Jones:
> I believe the group is leaning toward not having the appendix and 
> merely
> indicating that JSON is the only format that is mandatory to 
> implement.
> I’ll try to re-word it in that way.  In all examples, I will use
> host-meta.json.  I do think it would be useful to discuss content
> negotiation.  I’ll mention that and provide an example.  Host-meta 
> should
> support content negotiation, in my opinion.  However, since XML might 
> not be
> implemented, a client may get nothing.

It is important to remember that content-negotiation requires a more 
dynamic handling of server request. The Webfinger requests, in my view, 
MUST be fully compliant with a webserver that has _only_ static file 
fetching.

My personal dream scenario is where 'host-meta' supports 
content-negotiation but 'host-meta.json' and 'host-meta.xml' could be 
used as fallbacks.

> Making JSON the only MTI format does still give me a feeling of 
> uneasiness
> since, as you note, every implementation right now is XML.  This will
> definitely break that.  However, the push has been pretty strong to 
> go in
> this direction.  My own personal preference still remains that 
> servers
> implement both, since it’s so darn simple to do.

Despite all the "+1" messages "sent from my iPhone", I think support 
for the XML content-type is stronger than this mailing list currently 
portrays. The arguments for simple adoption are perfectly valid, though 
I only see them being an issue for client-side adoption. Server-side 
applications should have no problem supporting both XML and JSON, thus 
not at all impeding on adoptionability.

> That said, we would still have a problem with existing servers if 
> they do
> not support JSON and a client expected all servers support JSON.  
> Would
> people feel ok with saying that servers should support both XRD and 
> JRD?  Or
> is the preference really JRD is MUST and XRD is MAY?

I am totally in favor of this because, as you mentioned it is "darn 
simple to do".

Using XRD also _greatly_ improves the integration of well-established 
implementations of user-centric communications networks like XMPP. If 
one had to implement a JSON parser in every XMPP server out there, it 
would be a heck of a lot more impeding on adoption than simply having a 
MUST support for both JRD and XRD server-side.
I'm not saying XMPP currently implements Webfinger on any widely used 
deployment, only that it is a very likely future adoption. And would be 
much tougher if there was a risk you got zero data from a lookup.

-- 
Mikael Nordfeldth
http://blog.mmn-o.se/
[email-masked]