Re: [apps-discuss] Is host-meta.json viable? Re: Webfinger / SWD Issue #3: direct versus indirect discovery

[Eran Hammer <[e-mail]>]

Serving anything other than JRD on host-meta.json, while legal HTTP, is odd. I would reject the request if the Accept header is specifying anything other than JRD. The benefit of this approach is that it allows protocol to explicitly specify host-meta.json as the discovery endpoint, which has the same effect of making JSON the required and only format. One issue is that this doesn’t extend to LRDD which means, if the server doesn’t support the query parameters, the client might end up with XML in LRDD links.

We should first decide on how to approach the format issue, then just go and update/replace 6415 accordingly. I don’t think the scale of existing deployment is significant enough to play a major role. It’s ok to break some stuff for a cleaner, clearer future.

EH


From: [e-mail] [mailto:[e-mail]] On Behalf Of Paul E. Jones
Sent: Wednesday, April 25, 2012 11:23 AM
To: 'William Mills'; 'Mike Jones'; 'Blaine Cook'; [e-mail]
Subject: Re: [apps-discuss] Is host-meta.json viable? Re: Webfinger / SWD Issue #3: direct versus indirect discovery

Bill,

Host-meta.json was introduced in RFC 6415 as a means of selecting JSON, particularly when the client does not have the ability to indicate via the “Accept” header that it wants “application/json”.  On my server, I return XML by default.  I also honor the “Accept” header and return the type requested.  And, I support host-meta.json, which will return JSON by default (i.e., “Accept” is “*/*”), but I still honor the “Accept” header.  I always given preference to the Accept header, which I think is appropriate, though not explicitly documented anywhere.  This is where the “hack” part comes in.  One should honor what HTTP says, but then how to we treat a request based on the URI path?  Not sure, but I’m inclined to leave it that way until somebody tells me why it’s a bad idea.

In any case, this was not invented as a part of the current draft; it was already defined.

Paul

From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]]<mailto:[mailto:[e-mail]]> On Behalf Of William Mills
Sent: Monday, April 23, 2012 11:29 AM
To: Mike Jones; Blaine Cook; [e-mail]<mailto:[e-mail]>
Subject: [apps-discuss] Is host-meta.json viable? Re: Webfinger / SWD Issue #3: direct versus indirect discovery

I note that some examples are now using the construct (Eran called it a hack, which it probably is, but I like it) host-meta.json to select the data format.  This seems to me to be a workable way to:

-    extend the current WF stuff keeping compatibility
-    support for JSON without funky logic
-    allow the clients to implement a single simple code path

-bill

________________________________
From: Mike Jones <[e-mail]<mailto:[e-mail]>>
To: Blaine Cook <[e-mail]<mailto:[e-mail]>>; "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Sent: Sunday, April 22, 2012 9:11 PM
Subject: Re: [apps-discuss] Webfinger / SWD Issue #3: direct versus indirect discovery

I agree with your goal of simplicity for clients.  Paul’s example seems about as simple as it can get for clients:
               curl -v https://packetizer.com/.well-known/host-meta.json?resource=acct:[e-mail]
It shares the property with your earlier example (below) that clients have a no-branches code path to do discovery:
               curl -s http://example.com/.well-known/host-meta|<http://example.com/.well-known/host-meta%7C>
               awk "/lrdd/,/template/"|tr -d '\n'|sed -e "s/^.*template='\([^']*\)'.*$/\1/"|
               sed -e "s/{uri}/[e-mail]/<mailto:s/%7buri%7d/[e-mail]/>"|xargs curl –s

However, I challenge the assumption in your note below that servers using only static pages must be supported.  I just don’t see the requirement to implement a query parameter as being an impediment in practice, even for hosted domains.  I know of no hosting company that doesn’t provide a means of putting executable code behind web pages, be it PHP, Perl, Ruby, ASP, JSP, etc.  I know you’re trying to make the case for static pages, but in practice, I believe that dynamic pages are always easily available.

Assuming that we’re in an either-or situation with regard to either having single-GET discovery or supporting discovery using only static server pages (and I’d love to have someone demonstrate to us that we’re not), I’d take single-GET discovery for sure, as in some cases, it makes an appreciable difference in user interface latency, and per the paragraph above, I believe that dynamic queries can be implemented on all hosting platforms.

Assuming the WebFinger authors agree, I’d suggest that a logical next step would be for a -04 version of draft-jones-appsawg-webfinger to be published that changes support for the resource parameter from RECOMMENDED to REQUIRED, as that could provide a starting point for a common discovery spec.

                                                            -- Mike

P.S.  As long as draft-jones-appsawg-webfinger is being revised, I’d also suggest adding text making explicit what has been an implicit assumption in both WebFinger and SWD - that depending upon whether and how the client is authenticated, the set of resources returned may vary (as Blaine had pointed out earlier).  That could help deal with some of the privacy perceptions.

From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]]<mailto:[mailto:[e-mail]]> On Behalf Of Blaine Cook
Sent: Sunday, April 22, 2012 2:15 PM
To: [e-mail]<mailto:[e-mail]>
Subject: [apps-discuss] Webfinger / SWD Issue #3: direct versus indirect discovery

This is the last issue that I've flagged as blocking a new Webfinger / SWD draft.

Mike suggested that being able to request a user's profile with a single request (i.e., that the /.well-known/ profile resource should be able to respond with full profile data immediately, rather than pointing at a second URL that will fulfil the request) is a requirement for this standard.

I'd like to challenge that requirement. The arguments for a direct discovery endpoint are:

1. Fewer requests against the server, since we save (in the worst-case) 50% of requests by bypassing the indirect lookup phase.
2. Lower latency for clients (e.g., mobile clients) owing to the reduced number of lookups.

The arguments for an indirect discovery endpoint are:

1. Trivial and web-standards friendly deployment for domains that won't host their own webfinger/swd profile servers, but want to enable accounts on their domains (e.g., statically hosted sites).
2. A loosening of the requirement that URLs at the bare domain must run dynamic scripts that respond to requests to the /.well-known/ path.

My opinion is that the approach that SWD has proposed for the redirect is problematic. First, the format is very similar in form to the HTML "meta refresh" tag that provided HTTP redirect support from within HTML. That format has been widely deprecated, and in these more enlightened times, we just use the 3xx response codes with Location headers, instead.

Secondly, the SWD request format means that for smaller sites, often those with the least resources, will end up serving static content in a way that's difficult to cache; certainly, more difficult to cache than just serving static content. This is due to the request parameters present in all SWD requests; those request parameters will bust caches.

As for the first argument *for* SWD's approach, I'd suggest we look to DNS, which uses the same indirection approach for NS records, relying on a (relatively) very small set of root servers to handle the traffic for the whole internet. Clearly, this approach works, and webfinger/swd servers are in a much better position to handle this additional traffic. Most of this traffic will be heavily cached, especially for the largest providers.

In fact, in terms of real deployments, hosting a script at, e.g., google.com/.well-known/simple-web-discovery<http://google.com/.well-known/simple-web-discovery> is much harder than hosting a script at profiles.google.com/profile.json<http://profiles.google.com/profile.json> for all sorts of reasons, so it's my belief that the first argument is a red herring.

The second argument is legitimate, but only if mobile clients will actually be making requests to diverse webfinger/swd hosts. Instead, I strongly believe that we'll see the emergence of DNS-like servers that provide both profile hosting as well as proxy services. For a mobile client, the optimal approach will be to use SPDY to connect to a single host that performs webfinger/swd lookups on the mobile client's behalf, eliminating the latency concerns.

I offer that the two-step lookup can be implemented without conditionals on the client, whereas the direct-unless-not approach cannot be implemented that way (see my earlier curl example for proof). It's simpler, and easier to explain to the (hopefully many) small site owners who we'd like to implement this technology.

Thoughts? Am I missing something?

b.

_______________________________________________
apps-discuss mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/apps-discuss