Subject: Re: [apps-discuss] XML in Webfinger

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 9 Oct 2012 12:16:48 -0400

Evan,

Perhaps this is not stated and should be, but my assumption would be that if
one requested the XRD version of host-meta, then the LRDD link would refer
to the XML version.  Likewise, if one requested the JRD version, then it
would point to the JRD version.

Note that I do precisely that with my own implementation:
curl http://packetizer.com/.well-known/host-meta
curl http://packetizer.com/.well-known/host-meta

I explicitly include the "type" attribute so that it is made explicit as to
the format that will be returned.  For example:

  <Link rel="lrdd"
        type="application/xrd+xml"
        template="https://packetizer.com/lrdd/?resource={uri}"/>

and

    {
      "rel" : "lrdd",
      "type" : "application/json",
      "template" : "https://packetizer.com/lrdd/?format=json&resource={uri}"
    }

Are you suggesting that if the "type" attribute is missing, it defaults to
XRD?  Even if the requestor requested host-meta.json or included the
"Accept" header with "application/json"?

Paul

> -----Original Message-----
> From: [email-masked] [mailto:apps-discuss-
> [email-masked]] On Behalf Of Evan Prodromou
> Sent: Wednesday, September 26, 2012 1:12 PM
> To: [email-masked]
> Subject: Re: [apps-discuss] XML in Webfinger
> 
> Paul,
> 
> I'm happy with making XRD "SHOULD" and JRD "MUST".
> 
> I suggest that the default content type, if unspecified, stay XRD. So,
> if a client sees:
> 
>       <Link rel="lrdd"
>                 template="http://webfinger.example/lrdd?uri={uri}" />
> 
> ...they can be somewhat confident that the results will be XRD,
> regardless of the specification the remote host supports.
> 
> -Evan
> 
> --
> Evan Prodromou, CEO and Founder, StatusNet Inc.
> 1124 rue Marie-Anne Est #32, Montreal, Quebec, Canada H2J 2B7
> E: [email-masked] P: +1-514-554-3826
> 
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 9 Oct 2012 12:28:37 -0400

Evan,

> One thing I'm grappling with with the Webfinger draft is that it depends
> on RFC 6415, then requires some incompatible changes to that spec, or
> drops requirements from it.

Making XML optional will break backward compatibility.  I hate doing that,
but "it's the will of the people" :-)  However, I think if we make it clear
that the types used will follow what the user requests, that should be
sufficient.  Requesting /.well-known/host-meta without explicitly stating a
type should default to XRD.  However, one might get JRD if XML is not
supported, and XML will be optional in the next draft.  (I would personally
implement both on the server since it's trivial, but people do not want to
be required to do so.)

> This means that implementers that support the (still active!) RFC 6415
> but don't yet know about or support the Webfinger draft will get
> unexpected results.

This is entirely true.  And there are implementations out there.  That said,
if shifting the requirement to JRD as the only MTI format helps make
WebFinger much more widely implemented, I think that would be "a good
thing".  For virtually every application we've looked at for WebFinger, JSON
is the preference for developers.  I've been clinging to XML only because I
hate (and I mean ... really hate ...) breaking backward compatibility.  But,
I'd say the vast majority want JRD only.

Just do both if you want, though.  I plan to do that on my server.  It is
trivial.

> Is there a reason that we don't simply replace RFC 6415 with a new RFC?
> That would make it clear that there's a preferred new way to do things.

We could say that this new RFC "updates" RFC 6415, but there's a lot of good
content in RFC 6415 that I do not think we need to replace.  The procedures
are the same.  The guidance in there is the same.  We're adding a few
additional things and changing the MTI format.  I do not think that warrants
replacing RFC 6415.
 
> Otherwise, we should make it a priority that a compliant Webfinger
> implementation is also compliant with the closely-related RFC 6415.

I would personally make that a priority.  There might be some applications
like OpenID that specify only JRD.  The new RFC will align with that desire.
However, there might be other applications that mandate XRD.  I think that
would be reasonable.  HTTP was designed with content negotiation
capabilities.  So, one could use that functionality.  Perhaps in two hears,
some new format prevails.  I doubt it, but I think that if you want to
guarantee universal acceptance, the format must be JSON.  If you have
servers you control or will use it with only specific applications, you
could use (and mandate) XML.

Paul

---

From: Evan Prodromou <[email-masked]>
Date: Tue, 09 Oct 2012 15:55:53 -0400

Paul,

Per RFC 6415 sec 6.3 <http://tools.ietf.org/html/rfc6415#section-6.3>:

    LRDD resources MUST have an "application/xrd+xml" representation, and MAY have others.

I think that the de facto default when a type is not defined is XRD, but 
it's not actually specified in the RFC.

-Evan

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 09 Oct 2012 16:23:32 -0400

The default for host-meta would be XRD, but it would be JRD if JSON was requested. That needs to be clarified.

Paul

-------- Original Message --------
From: Evan Prodromou <[email-masked]>
Sent: Tue Oct 09 15:55:53 EDT 2012
To: "Paul E. Jones" <[email-masked]>
Cc: [email-masked]
Subject: Re: [apps-discuss] XML in Webfinger

Paul,

-Evan

---

From: Evan Prodromou <[email-masked]>
Date: Tue, 09 Oct 2012 16:24:37 -0400

> implement both on the server since it's trivial, but people do not want to
So, what about using "/.well-known/host-meta.json" instead?

This endpoint has always meant "I want JRD", so there's nothing to worry 
about with content negotiation or XRD defaults. XRD could be dropped 
entirely from the Webfinger draft entirely. It'd make things a lot simpler.

Since host-meta.json wasn't even around before RFC 6415, I don't think 
older implementations will even try to hit that endpoint.
> additional things and changing the MTI format.  I do not think that warrants
I agree with that idea. What I want is to be able to implement RFC 6415 
/and/ the new Webfinger protocol.

I don't think it's that hard as long as we don't mess with older 
processors' expectations.

-Evan