Re: Webfinger & FedSocWeb notes from IIW

On 12-10-30 09:21 PM, Paul E. Jones wrote:
>
> Markus, thanks for sharing.  I copied Evan since there were some 
> points on the page that I thought were worth discussing.
>
> "Webfinger has JSON now, but didn't have it when SWD was invented."
>
> That's not quite right.  JSON has been a part of WebFinger since RFC 
> 6415.  The only issue was that JSON was not mandatory on servers. 
>  That said, anyone wishing to allow use of OpenID Connect on their 
> domain could have implemented JSON support if the spec demanded it.  
> It's not an issue now, anyway, since JSON is now mandatory with WebFinger.
>
I think the question was "Why was SWD created?" and Mike Jones gave this 
as one of the reasons.

I'm not sure if there's much value in fighting it out.
>
> "It's possible to retrieve either host-meta.json or host-meta with 
> "json" Accept header. --> confusing?"
>
> This should not be confusing and if it is, we need to clarify it in 
> the spec.  XRD is /optional/ and JRD is mandatory. If a server 
> implements both (as mine does), the default format returned by 
> host-meta will be XRD and host-meta.json is JRD.  If a server only 
> supports JSON, it will likely return JRD in response regardless.  
> Usually, that's how web services behave with the Accept header.
>
I think the idea that came up was that we should just concentrate on the 
/.well-known/host-meta.json endpoint for the Webfinger protocol (by 
which I mean: additional resource and rel parameters).

It would simplify server implementations if I can just ignore resource 
and rel for /.well-known/host-meta. It would also simplify client 
implementations if they know /always/ to use /.well-known/host-meta.json.
>
> "Questions about the case when multiple links/locations are discovered"
>
> We might have to defer to others on this one, but my understanding is 
> that the order of links is the approach. RFC 6415 is clear about 
> ensuring that order is always maintained.  Thus, in my implementation, 
> I have an integer value in the database and all data is sorted per 
> that integer value.   Essentially, it is my "priority" value, but it 
> does not appear in the protocol.
>
>
There's not an explicit interpretation of having multiple links with the 
same rel, like:

{
     links: [
         {
             rel: "http://api.example/some-api",
             href: "http://server1.example/endpoint"
         },
         {
             rel: "http://api.example/some-api",
             href: "http://server2.example/endpoint"
         }
     ]
}

I think the typical (?) interpretation is that both links are equally 
valid and that the client can pick whichever they want. Most code I've 
seen will either pick the first or last.

There are some systems where you can define priority for different 
members of the list, like MX records in DNS. "Try the first endpoint, 
and if it doesn't work try the next one, and then one of the next three 
at your discretion."

It's probably an issue that should be worried about in the distant future.

-Evan

-- 
Evan Prodromou, CEO and Founder, StatusNet Inc.
1124 rue Marie-Anne Est #32, Montreal, Quebec, Canada H2J 2B7
E: evan@status.net P: +1-514-554-3826