Subject: [apps-discuss] Webfinger / SWD Issue #3: direct versus indirect discovery

From: Blaine Cook <[email-masked]>
Date: Sun, 22 Apr 2012 22:15:19 +0100

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 is much harder than hosting a
script at 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.