Re: [apps-discuss] Looking at Webfinger

You've essentially described Simple Web Discovery!  It avoids the complications introduced by host-meta exactly by using its own .well-known value.  The basic example is:

   GET /.well-known/simple-web-discovery?principal=mailto:joe@example.com&service=urn:example.org:service:calendar HTTP/1.1
   Host: example.com

   HTTP/1.1 200 OK
   Content-Type: application/json

   {
    "locations": ["http://calendars.example.net/calendars/joseph"]
   }

See http://tools.ietf.org/html/draft-jones-simple-web-discovery-02 for more details.  By design, there aren't many...

				-- Mike

-----Original Message-----
From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Mark Nottingham
Sent: Monday, July 02, 2012 10:47 PM
To: IETF Apps Discuss
Subject: [apps-discuss] Looking at Webfinger

I've pretty much ignored the whole webfinger / acct: / SWD discussion (too much!). However, since it's apparent it may soon become Real, I had a look.

In a nutshell, my initial reaction is "It's Not Nearly As Bad As I Thought It Would Be." :)

With that in mind, a few questions / comments (I'll resist going into editorial matters, for the time being):

* First and foremost, why use host-meta? What value does adding this extra step to the dance bring, beyond "We've defined it, therefore we must use it?"

As I think I've said many times before, the whole point of a .well-known URI is to group like uses together, to avoid having a "dictionary" resource that gets bloated with many application's unrelated data, thereby overburdening clients with too much information (especially when they're constrained, e.g., mobile).

As such, host-meta is a spectacularly bad example of a well-known URI. Defining a end-all-be-all well-known-URI kind of removes the point of having a registry, after all...

Instead, why not just define a NEW well-known URI for user data? That has a more constrained scope, and saves one round trip (or more). E.g.,

GET /.well-known/webfinger?user=bob%40example.com HTTP/1.0
Host: example.com

I.e., let webfinger define the URI template to use. Yes, some implementations might want to come up with crazy URIs, but is that really a problem we want to solve?

Astute observers will notice that this approach removes the need for an ACCT URI scheme (at least here).

* What's the fascination with XRD and JRD? These specifications seem to be creeping into IETF architecture; first it was in a pure security context, but now folks are talking about using them in a much more generic way, as a cornerstone of what we do. As such, I think they deserve a MUCH closer look, especially since we're defining things with "Web" in their name when the W3C has already defined solutions in this space.

Thanks,

--
Mark Nottingham   http://www.mnot.net/

_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss