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

From: Mike Jones <[email-masked]>
Date: Mon, 23 Apr 2012 22:30:23 +0000

You wrote “we could take the approach with webfinger/swd that DNS did, and have dumb clients use a proxy server that does the full recursive lookup on dumb clients' behalf”.  I understand your argument that proxy servers could be used to reduce latency and/or make clients simpler, but at that point, you’ve effectively conceded the importance of single-GET discovery, and if so, the “real” discovery protocol becomes the client-to-proxy protocol.  But unless the client-to-proxy protocol is also part of the standard, you’re effectively suggesting a solution in which a large portion of the clients are not using the standard at all.

                                                                -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Blaine Cook
Sent: Monday, April 23, 2012 3:25 PM
To: John Bradley
Cc: [email-masked]
Subject: Re: [apps-discuss] Webfinger / SWD Issue #3: direct versus indirect discovery

On 23 April 2012 23:01, John Bradley <[email-masked]<mailto:[email-masked]>> wrote:
Blaine,

Rewrite rules could also be used if scripts are not possible.

I am mostly making the third argument.
Make a GET and retrieve the desired JRD.

I don't think we are talking about the SWD_service_redirect currently.

If the response can't be directly retuned, you would issue a 3xx redirect to the static file.

Have you tried setting up redirects on statically hosted domains? If you have .htaccess support, it might be possible, but in practice even if someone with a domain *does* have access to .htaccess, they probably don't know how to configure mod_rewrite.

I've often heard the "if only DNS servers were easier", "if only it were easier to register a domain" complaints; DNS is great, but it requires a lot of involvement from experts. As far as I'm concerned, webfinger/swd only works if EVERY domain with a webpage can serve it, and if EVERY domain owner can get it to work without too much fuss.

 We need to make clients simple.  There are far more clients than servers.

Agreed – following redirects isn't hard, but I'm not convinced that redirects are really deployable; also, it's worth noting that for the "brain-dead" redirect scenario, the server-side needs to properly rewrite the query string. :-/

DNS has different discovery paths for recursive queries versus "normal" queries. I'm not sure why we shouldn't have the same approach here.

I've mentioned a few times that we could take the approach with webfinger/swd that DNS did, and have dumb clients use a proxy server that does the full recursive lookup on dumb clients' behalf. I think that solves both problems, no?

b.

---

From: Blaine Cook <[email-masked]>
Date: Mon, 23 Apr 2012 23:39:44 +0100

On 23 April 2012 23:30, Mike Jones <[email-masked]> wrote:

>  You wrote “we could take the approach with webfinger/swd that DNS did,
> and have dumb clients use a proxy server that does the full recursive
> lookup on dumb clients' behalf”.  I understand your argument that proxy
> servers could be used to reduce latency and/or make clients simpler, but at
> that point, you’ve effectively conceded the importance of single-GET
> discovery, and if so, the “real” discovery protocol becomes the
> client-to-proxy protocol.  But unless the client-to-proxy protocol is also
> part of the standard, you’re effectively suggesting a solution in which a
> large portion of the clients are not using the standard at all.
>

No – sorry for not being clear. My proposal is this:

1. Use host-meta to discover the authoritative URI for webfinger profiles
for a given domain.
2. Make a standardised request against the authoritative URI. e.g.,

GET ${uri-from-host-meta}?address={address}[&resource={resource}]

For clients that don't implement the full protocol, all that would be
necessary would be to decide on a webfinger server URL that the client
would trust and make the same request as in #2.

Does that work?

b.