'describedby' vs. 'webfinger'
Eran Hammer-Lahav
For example:
<XRD>
<Host>example.com</Host>
<Link>
<Rel>example1</Rel>
<URI>http://example.com/my-example1</URI>
</Link>
<Link>
<Rel>example2</Rel>
<URITemplate>http://example.com/my-example2/q={%uri}</URI>
</Link>
</XRD>
In which the first link is about the host and the second link is about individual resources which belong to the host. Is there is a need to express a relation between individual resources to a fixed target, the template will simply not include any variables. This is the way I am going to solve any ambiguities, not that I know what does it mean to have a link to the "host", but I will leave that to individual protocols to figure out.
---
The current proposal uses an extension relation type 'http://webfinger.info/rel/service'. Dirk proposed we use the generic 'describedby' instead which will make it easier for OpenID to use the same mechanism without having to directly reference WebFinger. In a way, this will move more from WebFinger into the generic host-meta solution and allow more protocols to share the same discovery flow for any kind of URI type, not just acct:.
---
The main implications of using a generic relation type:
* It is not possible to limit host-meta to include a single describedby relation type (it is possible for 'webfinger'). It is also not possible to limit the media type of the target to XRD (again, possible for 'webfinger' according to a proposed change to the link draft). This means clients will need to look for all the describedby links, filter out any non-XRD media types, and try them in the order they appear. What we lose is the ability to constrain links with the 'describedby' relation, something we are allowed to do with 'webfinger'.
* Since we will be using a generic relation type, we will inherit the generic host-meta template vocabulary which includes:
scheme://userinfo@host:port/path?query#fragment, as well as 'authority' and 'uri'. This means WebFinger clients will need to understand all these (which is not an issue with a generic host-meta lib). It also means that we will not have the {id} variable, but instead will need to use either {path} or {uri}. It also means the endpoint will need to accept non-'acct:' URIs, not just accounts. This makes it more generic for protocols like OpenID (allows using both an email and HTTP URI using the exact same protocol). But it means most implementations will need the URI scheme as input.
* Since not all schemes can use the full vocabulary, it means that servers might need to offer multiple templates under the same link, and leave it to the client to pick the template based on the availability of variables (based on the URI it is using as input).
The advantages of using a generic relation type are pretty obvious.
---
If we decide to use the generic 'describedby' relation type, I think I am going to drop the entire template vocabulary and just leave {uri}. I might define an extension relation type just for the extended vocabulary but using generic relation types across schemes just makes it all very complex for clients, and it does not offer anything beyond the ability to design any URI endpoint. In other words, the extended vocabulary just makes thing pretty, but does not add any more functionality.
Thoughts?
EHL
Santosh Rajan
John Panzer
--
--
John Panzer / Blogger
jpa...@google.com / abstractioneer.org / @jpanzer
John Panzer
least for webfinger, when the initial target returns a 3xx redirect.
Martin Atkins
> Also, +1 to {uri} only. But we should rigorously define behavior, at
> least for webfinger, when the initial target returns a 3xx redirect.
>
This may be a non-issue in practice, but it concerns me a little that
you'd need an additional redirect and round-trip to map, for example,
fr...@livejournal.com to http://frank.livejournal.com/data/xrd .
Being able to pull out the part before the @ is useful for avoiding this
additional round-trip. (though there are issues in LJ's case where the
account form would probably want to use _ where the hostname uses - ...
but that's LJ's problem.)
John Panzer
Blaine Cook
describedby links, they all need to be checked, adding significant
complexity to clients, and potentially adding ambiguity as to which
link and/or template is the WebFinger resource.
Let's keep this simple and unambiguous. I'd go so far as to suggest
that there MUST be EXACTLY ONE "webfinger" resource.
If XRD wants to describe a generalised discovery mechanism, good, and
if OpenID needs to traverse discovery into non-acct URIs, that's fine,
but let's not try to create the final solution here...
b.
2009/9/11 John Panzer <jpa...@google.com>:
John Panzer
My reasoning is that I want users to be able to type in any identifier, b...@foo.com, foo.com/bob. bob.foo.com, ... and have webfinger Just Work for discovering basic things like what my blog is and how to request a contact or whatever I'm trying to figure out. So first, webfinger should work for general URIs, not just acct: URIs.
Beyond that, semantically the webfinger protocol needs to be open ended anyway -- there will be new types of resources added in (photo services? document sharing services? user reputation brokers? ...) that no one here will anticipate, and they need to fit into a general framework. Obviously specific webfinger clients don't need to handle all of these, the same way that Atom clients don't handle every extension in the universe. (But well written Atom libraries do let you handle extensions, and well written webfinger libraries should let you handle extensions.)
So I don't see a huge difference in practice between rel="describedby" and rel="webfinger", except that the former is actually reusable for other protocols so there is more likelihood of getting solid library support. Perhaps that's the core of Blaine's objection: What are the practical difference between the two? And I'm willing to admit that I may be missing something here, having not participated in the XRI TC discussions until recently.
Blaine's mentioned one potential difference: Cardinality of links. Is there a reason to have more than one "describedby" link? If there is, why doesn't it apply to webfinger? Discuss.
Santosh Rajan
Blaine Cook
thoughts on this, too.
2009/9/11 John Panzer <jpa...@google.com>:
> I disagree with Blaine but want to hear his reasoning.
>
> My reasoning is that I want users to be able to type in any identifier,
> b...@foo.com, foo.com/bob. bob.foo.com, ... and have webfinger Just Work for
> discovering basic things like what my blog is and how to request a contact
> or whatever I'm trying to figure out. So first, webfinger should work for
> general URIs, not just acct: URIs.
For me, webfinger is about having a consistent representation of an
account. If we let the format become "any URI", then we remove the
(desired) pretense of a single, consistent format. My argument is and
has been that the inconsistent nature of URLs puts people off. The
fact that the URL:
http://www.google.com/search?client=safari&rls=en&q=blah&ie=UTF-8&oe=UTF-8
is presented in the same semantic space as:
means that people can't create expectations about how URLs behave
without learning the intricacies of URLs.
With WebFinger, we're reformulating those expectations, into something
that people already understand; that is, when someone asks for "your
account", it *always* takes the format "m...@domain.com". The inverse is
true --- the format "m...@domain.com" means "somewhere I can contact
you." This fits with existing usage patterns, and is [in general]
backwards compatible.
By introducing URLs as valid WebFingers, we muddle the equation, and
get back to where we started. If people sometimes see "follow us at
http://google.com/updates" and sometimes "follow us at
upd...@google.com", it makes it impossible to generalise for those
who don't understand the underlying mechanisms.
> Beyond that, semantically the webfinger protocol needs to be open ended
> anyway -- there will be new types of resources added in (photo services?
> document sharing services? user reputation brokers? ...) that no one here
> will anticipate, and they need to fit into a general framework. Obviously
> specific webfinger clients don't need to handle all of these, the same way
> that Atom clients don't handle every extension in the universe. (But well
> written Atom libraries do let you handle extensions, and well written
> webfinger libraries should let you handle extensions.)
>
> So I don't see a huge difference in practice between rel="describedby" and
> rel="webfinger", except that the former is actually reusable for other
> protocols so there is more likelihood of getting solid library support.
> Perhaps that's the core of Blaine's objection: What are the practical
> difference between the two? And I'm willing to admit that I may be missing
> something here, having not participated in the XRI TC discussions until
> recently.
>
> Blaine's mentioned one potential difference: Cardinality of links. Is
> there a reason to have more than one "describedby" link? If there is, why
> doesn't it apply to webfinger? Discuss.
Right; so what I would emphatically get behind is that the resources
*pointed at* by a webfinger address must be addressable in general.
That is to say, *any* URI and URI scheme must be acceptable in the XRD
that you get at the end of basic WebFinger discovery. So really it is
a question of cardinality, and trying to make the easy things easy and
the hard things possible...
I hope that helps clarify where I'm coming from. :-)
b.
Christian Scholz
I actually think that it will confuse people even more as it is not
really an email address but looks like one.
What really is needed is a brand X. If a site asks for X then people
need to know what to put in there. And once they
know it doesn't matter if it's a acct: URI or an HTTP URL.
As long as there is no brand people will still have the problem that
they think it's an email address, put in theirs and most likely get an
error because most of the email provider won't support it (like
national telcos). Moreover it will move the burden to implement a
social networking feature to the email provider which seems strange.
And on the other hand social networks which want to host your list of
services then need to implement an email like identifier? And if they
do these identifiers might be again mistaken for email addresses.
I also think that the whole NASCAR thing hurt OpenID quite a bit
because it's watering down the meaning of OpenID.
If there just would have been that OpenID button then of course nobody
would know right now what it is but eventually people would have found
out. Now though it's just a button under many and people might think
it's simply another site like all the other buttons.
These things take time and I think if we build some useful technology
first (which also would make OpenID more useful to people) then a name
will be found later which becomes that brand. And then it really
doesn't matter if it's domain.com/user or us...@domain.com.
Hence I would like to keep this open to any URI. IMHO it's a problem
where all those providers need to come together, invent a name and
stick with it while removing any amiguity from it.
-- Christian
--
Christian Scholz Homepage: http://comlounge.net
COM.lounge GmbH blog: http://mrtopf.de/blog
Hanbrucher Str. 33 Skype: HerrTopf
52064 Aachen Video Blog: http://comlounge.tv
Tel: +49 241 400 730 0 E-Mail c...@comlounge.net
Fax: +49 241 979 00 850 IRC: MrTopf, Tao_T
neuer Podcast: Der OpenWeb-Podcast (http://openwebpodcast.de)
new podcast: Data Without Borders (http://datawithoutborders.net)
Martin Atkins
>
> I actually think that it will confuse people even more as it is not
> really an email address but looks like one.
> What really is needed is a brand X. If a site asks for X then people
> need to know what to put in there. And once they
> know it doesn't matter if it's a acct: URI or an HTTP URL.
> As long as there is no brand people will still have the problem that
> they think it's an email address, put in theirs and most likely get an
> error because most of the email provider won't support it (like
> national telcos). Moreover it will move the burden to implement a
> social networking feature to the email provider which seems strange.
>
One benefit of email-like identifiers over HTTP URLs -- at least for the
OpenID-like use-case -- is that there is a sensible fallback behavior if
the issuing party doesn't yet support discovery: send it an email.
That's currently the standard operating procedure for signing up for
accounts, so users ought not to be surprised by it. But we can use the
principle of progressive enhancement to provide them with an OpenID
signin flow instead when it's available.
Eran Hammer-Lahav
This can include a cardinality restriction on webfinger. But this too
implies moving to a single template variable.
And be carefull calling things "the final solution'"... :-)
EHL
Christian Scholz
Am 12.09.2009 um 02:28 schrieb Martin Atkins:
>
> Christian Scholz wrote:
>> I actually think that it will confuse people even more as it is
>> not really an email address but looks like one.
>> What really is needed is a brand X. If a site asks for X then
>> people need to know what to put in there. And once they
>> know it doesn't matter if it's a acct: URI or an HTTP URL.
>> As long as there is no brand people will still have the problem
>> that they think it's an email address, put in theirs and most
>> likely get an error because most of the email provider won't
>> support it (like national telcos). Moreover it will move the
>> burden to implement a social networking feature to the email
>> provider which seems strange.
>
> One benefit of email-like identifiers over HTTP URLs -- at least for
> the OpenID-like use-case -- is that there is a sensible fallback
> behavior if the issuing party doesn't yet support discovery: send it
> an email.
Right. But what would be the contents of that email? "Please tell your
email provider to implement webfinger" ?
And another note: If webfinger is for retrieving basic information
about a user like finger back then was (which only a small minority of
the internet population knows about anyway) IMHO it makes more sense
to use a profile URL for that. People already know that http://myspace.com/
<user> is their profile so IMHO it's easier to understand to enter
that URL than an email like identifier as <user>@myspace.com.
But maybe we should write use cases so that it's clearer what we are
trying to solve. For me personally the most interesting aspect of all
of this is at least not the email like identifier but that some people
start discussing service catalogues eventually. This might also later
include on how to update them, how to do authorization and so on.
-- Christian
Eran Hammer-Lahav
* Each link can include multiple URIs or URITemplates. This is
semantically equivalent to seperate links. Either way, while clients
should pick the best one for them (for example, when both http and
https versions are offered), the protocol must still work if the
client is dumb and always grabs the first one. So having multiples
should not be an issue.
* We still need to agree on the template vocabulary. There seems to be
consensus on a single variable. But the open question is whether that
should be an absolute URI (with scheme) or just the identifier. If it
is the full URI then again this is a non-issue as it becomes a
deployment decision and not something the client has to deal with.
I think we can go with a general rel value and simply expect servers
to be able to handle providing an XRD for acct: URIs. What they do
with other URI schemes is not important for WebFinger.
EHL
Martin Atkins
>>
>> One benefit of email-like identifiers over HTTP URLs -- at least for
>> the OpenID-like use-case -- is that there is a sensible fallback
>> behavior if the issuing party doesn't yet support discovery: send it
>> an email.
>
> Right. But what would be the contents of that email? "Please tell your
> email provider to implement webfinger" ?
>
No, it's:
"Please click on this link in order to confirm your email address."
WebFinger doesn't need to be mentioned at all.
Of course, as I originally stated, this particular fallback only really
makes sense for the OpenID-like use-case where we're trying to get the
user to log in to something.
Dirk Balfanz
I actually don't like the generality; if there are more than one
describedby links, they all need to be checked, adding significant
complexity to clients, and potentially adding ambiguity as to which
link and/or template is the WebFinger resource.
Let's keep this simple and unambiguous. I'd go so far as to suggest
that there MUST be EXACTLY ONE "webfinger" resource.
Eran Hammer-Lahav
How does that sound?
EHL
Santosh Rajan
Santosh Rajan
Blaine Cook
want to know how this host XRD is supposed to be interpreted by a
WebFinger client:
<?xml version=’1.0′ encoding=’UTF-8′?>
<XRD xmlns=’http://docs.oasis-open.org/ns/xri/xrd-1.0′>
<Host xmlns=’http://host-meta.net/xrd/1.0′>example.com</Host>
<Link>
<Title>Resource Descriptor</Title>
<Rel>describedby</Rel>
<URITemplate>http://example.com/users?uri={%uri}</URITemplate>
</Link>
<Link>
<Title>Resource Descriptor</Title>
<Rel>describedby</Rel>
<URITemplate>http://example.com/api?uri={%uri}</URITemplate>
</Link>
</XRD>
Which one is the webfinger? How can the client figure that out? Why
are we making this harder on webfinger clients?
b.
2009/9/16 Santosh Rajan <sant...@gmail.com>:
Dirk Balfanz
Ok. So with the changes that Eran has proposed and made to his blog, I
want to know how this host XRD is supposed to be interpreted by a
WebFinger client:
<?xml version=’1.0′ encoding=’UTF-8′?>
<XRD xmlns=’http://docs.oasis-open.org/ns/xri/xrd-1.0′>
<Host xmlns=’http://host-meta.net/xrd/1.0′>example.com</Host>
<Link>
<Title>Resource Descriptor</Title>
<Rel>describedby</Rel>
<URITemplate>http://example.com/users?uri={%uri}</URITemplate>
</Link>
<Link>
<Title>Resource Descriptor</Title>
<Rel>describedby</Rel>
<URITemplate>http://example.com/api?uri={%uri}</URITemplate>
</Link>
</XRD>
Which one is the webfinger?
Eran Hammer-Lahav
But if you really want the ability to declare explicit support for acct URIs, we can add an extension rel type in addition to describedby that will state that. So lazy clients can look only for servers who explicitly shout to the world they provide descriptors for acct URIs.
Would that work?
Blaine Cook
>
>> Which one is the webfinger?
>
> I don't think the question is well-formed. There is no such thing as "the
> webfinger [data]". There is just meta-data for URIs. The above XRD says that
> there's meta-data to be had for a given URI both
> at http://example.com/users?uri={%uri} and http://example.com/api?uri={%uri}.
> A webfinger client might follow both links, or might ignore one of them,
> depending on how thorough it wants to be in its hunt for a acct:-URI's
> meta-data.
> (just my 2c, of course)
My argument is that in the quest for purity, having acct URIs resolve
at "any one, or possibly more than one of the available meta-data
providing URIs" means that the client complexity has increased
dramatically, and the efficiency has dropped by a non-trivial amount.
b.
Blaine Cook
> If the server supports it on one, if should support it on both.
>
> But if you really want the ability to declare explicit support for acct URIs, we can add an extension rel type in addition to describedby that will state that. So lazy clients can look only for servers who explicitly shout to the world they provide descriptors for acct URIs.
>
> Would that work?
Yes*.
b.
* I wonder why anyone would write a non-lazy client, or why anyone
would be so lazy as to provide multiple servers that respond to
describedby but not point out which one serves webfinger...
b.
Eran Hammer-Lahav
But I think people will write generic engines that take any URI they find for a given host and just try to get descriptions for it. I wouldn't want them to fail when the server is happy to talk about account, but they are not aware of webfinger. They are aware of XRD and general discovery.
So two rels, and everyone wins.
I would propose 'http://webfinger.net/rel/acct-desc' as the rel type in addition to 'describedby' we are explicit about what this endpoint is promising to support. If in the future it also supports some XRD api for updating records, it can have another rel in host-meta or in the XRD for the endpoint itself.
EHL
> -----Original Message-----
> From: webf...@googlegroups.com [mailto:webf...@googlegroups.com] On
> Behalf Of Blaine Cook
> Sent: Thursday, September 17, 2009 6:34 PM
> To: webf...@googlegroups.com
> Subject: Re: 'describedby' vs. 'webfinger'
>
>
John Panzer
More generally, I don't know what a "webfinger" resource is. What if my photo collection is on servera and my contacts on serverb, maintained by two different companies? How should that be handled, and how would mandating a single describedby/webfinger link help?
John Panzer / Google
Eran Hammer-Lahav
Blaine would like to enable a client to know *for sure* that a server supports providing XRD descriptors for acct: URIs. After all, that is really all WebFinger is from a discovery standpoint. So there is nothing wrong with trying different endpoints and offering multiple endpoints, but Blaine is making the case that we should make it trivial for clients by telling servers to spell out if they understand acct: URIs.
My compromise is to still use ‘describedby’ but also provide a rel value that does just that, explicitly say that acct: URIs are welcome here. A lazy client will only look for that relation type and stop. A more verbose client may try different URI schemes at different endpoint as it sees fit.
EHL
From:
webf...@googlegroups.com [mailto:webf...@googlegroups.com] On Behalf Of John
Panzer
Sent: Thursday, September 17, 2009 6:50 PM
To: webf...@googlegroups.com
Subject: Re: 'describedby' vs. 'webfinger'
So, I don't quite understand the complexity problem between 1 link and n links. For loops are easy to write in the simple case.
Blaine Cook
be only one <Link> containing the <URITemplate>
for WebFinger resources.
2009/9/18 John Panzer <jpa...@google.com>:
> So, I don't quite understand the complexity problem between 1 link and n
> links. For loops are easy to write in the simple case.
I agree, but the complexity comes when a server provides multiple
"describedby" Links, one of which supplies WebFinger resources, and
the others which may or may not. In the case where there are n links,
caching adds extra complexity, because the naive approach will always
result in n requests to the servers pointed at by the host-meta file.
But caching isn't generally possible, because say I have four describedby links:
http://example.com/api?uri={%uri}
http://example.com/users?uri={%uri}
http://example.com/shorten?uri={%uri}
http://example.com/directory?uri={%uri}
(full XRD here: http://gist.github.com/188969 )
Assume that "users" and "directory" return WebFinger results; any
requests to "api" or "shorten" are wasted if an "acct" URI is used.
Next, what happens when "directory" and "users" return *different*
results for the same acct URI? In the case where one returns a 404 and
the other returns a valid document, it's still relatively simple, but
if they return different valid XRD content, conflict resolution
becomes a pain (possibly intractable).
What happens when we chain together XRDs? Instead of finding a
URITemplate, we find n describedby links to other XRD documents, each
with m describedby links, some of which might be URITemplates, but
some of which might be links to other XRDs. Now instead of a simple
for loop, we have nested recursion which may return conflicting data.
> More generally, I don't know what a "webfinger" resource is. What if my
> photo collection is on servera and my contacts on serverb, maintained by two
> different companies? How should that be handled, and how would mandating a
> single describedby/webfinger link help?
That's a different question - once we have a webfinger resource, i.e.,
an XRD for a single acct, then compiling relevant links to external
services is straightforward. There may even be describedby links in
the acct's XRD that should be traversed, but by that time we know what
object we're performing discovery on when we ask for those XRDs, and
URITemplates aren't valid (at least, I don't think they are, and I
can't see why you'd want to enable that).
For example: http://gist.github.com/188967 - note the multiple
"describedby" links, which are unambiguous in this context.
Does that make sense?
b.
Blaine Cook
> Blaine would like to enable a client to know *for sure* that a server
> supports providing XRD descriptors for acct: URIs. After all, that is really
> all WebFinger is from a discovery standpoint. So there is nothing wrong with
> trying different endpoints and offering multiple endpoints, but Blaine is
> making the case that we should make it trivial for clients by telling
> servers to spell out if they understand acct: URIs.
>
> My compromise is to still use ‘describedby’ but also provide a rel value
> that does just that, explicitly say that acct: URIs are welcome here. A lazy
> client will only look for that relation type and stop. A more verbose client
> may try different URI schemes at different endpoint as it sees fit.
What about something like describedby/webfinger or
describedby.webfinger? I don't know either of those are "valid", but
there's certainly examples of use in the wild of both patterns. The
problem for me with this compromise is that the naive client (i.e.,
the one everyone will use in practice) is going to miss some data, so
only the more complex client can *actually* give you webfinger data.
That doesn't work.
b.
Eran Hammer-Lahav
We can make it a 'MUST' for servers supporting WebFinger to declare that and a MAY for clients to look for it. This way you can write a simple client that will always give you something useful but will not prevent the more robust clients from building a bigger picture.
The rel type must be a URI. Short names (with or without a period) must be registered and registration is only allowed for generic relation types, that can be shared across protocols (i.e. you just agree on the semantic meaning, not the resolution protocol). So it needs to be a URI. I think 'acct-desc' is very precise to what it is the server is declaring support for.
EHL
> -----Original Message-----
> From: webf...@googlegroups.com [mailto:webf...@googlegroups.com] On
> Behalf Of Blaine Cook
> Sent: Friday, September 18, 2009 2:34 AM
> To: webf...@googlegroups.com
> Subject: Re: 'describedby' vs. 'webfinger'
>
>
Blaine Cook
> How come?
>
> We can make it a 'MUST' for servers supporting WebFinger to declare that and a MAY for clients to look for it. This way you can write a simple client that will always give you something useful but will not prevent the more robust clients from building a bigger picture.
As long as listing <Rel>... acct-desc</Rel> is a MUST for servers
supporting WebFinger, then I'm happy. :-)
b.
Eran Hammer-Lahav
The best answer I can give you is that servers should not design poor descriptors and descriptors services. I agree that we should keep the rules for webfinger simple and consistent and I think with the extension rel value we guarantee that it is.
EHL
> -----Original Message-----
> From: webf...@googlegroups.com [mailto:webf...@googlegroups.com] On
> Behalf Of Blaine Cook
> Sent: Friday, September 18, 2009 2:28 AM
> To: webf...@googlegroups.com
> Subject: Re: 'describedby' vs. 'webfinger'
>
>
Eran Hammer-Lahav
EHL
> -----Original Message-----
> From: webf...@googlegroups.com [mailto:webf...@googlegroups.com] On
> Behalf Of Blaine Cook
> Sent: Friday, September 18, 2009 8:22 AM
> To: webf...@googlegroups.com
> Subject: Re: 'describedby' vs. 'webfinger'
>
>
John Panzer
(My hope is of course that acct: becomes as accepted as any other URI for URIs likely to be participating in discovery.)
On a technical note, I think this is parallel to type="image/jpeg" and note that those are merely hints / not considered authoritative -- the destination can change its type at any moment, and I think that's the case here too. So there's no way to know really for sure without querying the actual resources/services.
John Panzer
Just to clarify: I only mean to say that for host-meta, there should
be only one <Link> containing the <URITemplate>
for WebFinger resources.
2009/9/18 John Panzer <jpa...@google.com>:
> So, I don't quite understand the complexity problem between 1 link and nI agree, but the complexity comes when a server provides multiple
> links. For loops are easy to write in the simple case.
"describedby" Links, one of which supplies WebFinger resources, and
the others which may or may not. In the case where there are n links,
caching adds extra complexity, because the naive approach will always
result in n requests to the servers pointed at by the host-meta file.
But caching isn't generally possible, because say I have four describedby links:
http://example.com/shorten?uri={%uri}
http://example.com/directory?uri={%uri}
(full XRD here: http://gist.github.com/188969 )
Assume that "users" and "directory" return WebFinger results; any
requests to "api" or "shorten" are wasted if an "acct" URI is used.
(I should read my email in order.) OK, in this case the /shorten service is for URIs of the form http://example.com/blah which for whatever reason the service doesn't want to or can't use the Link: header instead of a URI template. And it's defined only for HTTP URIs.
Next, what happens when "directory" and "users" return *different*
results for the same acct URI? In the case where one returns a 404 and
the other returns a valid document, it's still relatively simple, but
if they return different valid XRD content, conflict resolution
becomes a pain (possibly intractable).
This is a place where actual code and examples are helpful (thanks for the examples). My impression so far is that XRDs can be parsed into lists of edges-with-metadata. This gets into Eran's other chaining thread for today but I think it'd be worth seeing how difficult it is. If nothing else, people who handle import and export of XRDs, and automatic updates of XRDs, may need to need to deal with this.
What happens when we chain together XRDs? Instead of finding a
URITemplate, we find n describedby links to other XRD documents, each
with m describedby links, some of which might be URITemplates, but
some of which might be links to other XRDs. Now instead of a simple
for loop, we have nested recursion which may return conflicting data.
What stops an individual XRD document from having conflicting data?
The possiblity of infinite loops is of course there. (It's also there with 301 redirects of course, at another level.)
That's a different question - once we have a webfinger resource, i.e.,
> More generally, I don't know what a "webfinger" resource is. What if my
> photo collection is on servera and my contacts on serverb, maintained by two
> different companies? How should that be handled, and how would mandating a
> single describedby/webfinger link help?
an XRD for a single acct, then compiling relevant links to external
services is straightforward. There may even be describedby links in
the acct's XRD that should be traversed, but by that time we know what
object we're performing discovery on when we ask for those XRDs, and
URITemplates aren't valid (at least, I don't think they are, and I
can't see why you'd want to enable that).
Yep, that makes sense. I was confused by the "webfinger resource" naming. However, the chaining question still looms:
For example: http://gist.github.com/188967 - note the multiple
"describedby" links, which are unambiguous in this context.
Does that make sense?
Yep. The one issue with this specific example is that some of these things are really describing the destination (hcard) rather than the relationship (describedby). Not that it's bad to have hints.
b.
Santosh Rajan
John Panzer
I believe that the primary problem that needs to be solved is not "do I understand all possible personal identifiers" but "can I figure out what my own personal identifier is" so I can sign in to a web site or provide it to someone else. Webfinger solves this neatly by letting people just user their email address, which is a proven solution for account identifiers.
However, dictating that _all_ personal identifiers must follow this format is both unnecessary and harmful. It's unnecessary because people already deal with URLs every day in a non-login context. It's not at all confusing to tell someone "you can go to twitter.com/jpanzer to find me", even if you scrawl this on a bar napkin, because the end user can put this into a web browser and it Just Works. Similarly you will be able to tell someone "just add me to your allow list, I'm foo.blogspot.com" and it will Just Work.
It would be harmful to restrict this to acct: IDs because it'd lock out millions of existing identifiers and create yet another namespace that people have to be in -- note that if you _don't_ want to expose your email address, you can't just use your Twitter homepage, you have to go and create a new email address that isn't really an email address for purposes of handing out to people. That's confusing.
-John