Is it worth referencing the URI Template draft spec?

http://tools.ietf.org/html/draft-gregorio-uritemplate-03

It seems to have some traction.

How is this different than EAUT? http://eaut.org/

I'd like to suggest the Link-Patterns include a provision for one-way address obfuscation, as some hosts may not be comfortable exposing "raw" email addresses. E.g. I might want to set up a domain to point to example.org, but don't want example.org to learn of valid addresses unless it's previously been informed.

My preference would be FOAF-style hashes of a mailto URI.

So the primary goal is an XRD recovery service?

What would the benefits of XRD be over vcards? A public vcard service would be more directly analogous to classic finger, so what are the design goals that XRD would deliver?

Great idea.

As most of you guys are very familiar with openid, I'm sure you've already thought of this. But I'll bring it up anyways :

How about using YADIS for discovery on the root url for example.com? Big sites will understand the Accept header and small sites can just add the meta element.

I like this idea, but why not use JSON instead of XML for the XRD file?

I feel that it would be a Right Thing if the Link-Pattern allowed substitution of the email's local part and domain part as separate elements. That would allow most common transformations to be done without the need to run any application on the server. For example:

Email: jsmith@example.com

Link-Pattern: http://{%local}.example.com/profile.xrd Result: http://jsmith.example.com/profile.xrd

Link-Pattern: http://profiles.example.com/{%local} Result: http://profiles.example.com/jsmith

Link-Pattern: http://www.{%domain}/~{%local}/ Result: http://www.example.com/~jsmith/

Also: encoding rules for the local part of the address need to be defined, as the local part is allowed to contain characters that are treated as special in the URLs.

Eugene

fred@example.com being webfingerable to http://example.com/@fred would have been much easier for machines and humans.

The 'pattern matching' could have been implemented with HTTP-301 (Moved Permanently)

So you're basically trying to complicate things by doing id (email address) -> dns -> xrd -> contact data instead of doing .tel domain dns -> contact data ?

Also the id will change when the user's email changes, so the user will have to find an email provider that also provides the whole webfinger protocol.

Following up on my earlier comment, whatever TLD you choose, just use NAPTRs! In a .tel domain, you could write something like: "E2U+x-xrd:http+x-lbl:my-personal-zrd" "!^.$!http://somedomain.com/myxrdfile.xml!"

WRT Getting host-meta, couldn't it be linked from the root resource?

HEAD / HTTP/1.1
Host: example.org

200 OK
Link: <lesser-known/host-meta>; rel=host-meta

Vcard.

vCard + necessary extensions and /@local-name uri:

http://whereismybon.net/@reed

There is a lot of stuff in enterprise around web service descovery, UDDI etc..

was just thinking there may be some methods ofd doing stuff that could be usefull in there

I feel that the "well known location" of the XRD file should be just hard-wired to <http://example.com/~joe>. This is the default location of a user directory, which would allow most users to join the WebFinger? without the special configuration from web-services providers.

If we should use some sort of </.well-known/host-meta> or even <http://example.com/@joe>, we would have to wait for all the website administrators to reconfigure their servers.

Of course, lazy users will not publish proper finger data on their websites. The administrator could then perform XSLT transformation on the root index file of an user, adding neccessary <link rel='webfinger-query'/> tag.

Making sweeping statements about "the default location of a user directory" in this day and age seems unwise. Just a thought.

Have you looked at Fingerpoint?

http://buzzword.org.uk/2009/fingerpoint/spec

It seems like this is much more in-line with current web architecture than the web finger protocol proposed here.

More commentary here:

http://blogs.sun.com/bblfish/entry/web_finger_proposals_overview