- From: Michiel de Jong <michiel@unhosted.org>
- Date: Sat, 23 Jun 2012 14:59:51 +0200
- To: nathan@webr3.org
- Cc: Henry Story <henry.story@bblfish.net>, Kingsley Idehen <kidehen@openlinksw.com>, www-tag@w3.org, Melvin Carvalho <melvincarvalho@gmail.com>, Read-Write-Web <public-rww@w3.org>
On Sat, Jun 23, 2012 at 2:32 PM, Nathan <nathan@webr3.org> wrote:
> Michiel de Jong wrote:
>> It's a premise of webfinger that we resolve a human-memorable string
>> of the form 'user@host' to accounts.
>
> I understand that, but don't see any need for a acct: URI scheme to
> accomplish that.
>
> This is a URI that will accomplish the task:
>
> https://gmail.com/.well-known/host-meta?resource=joe@gmail.com
>
> So where's the need for acct: ?
>
> This is not two URIs, it's one URI, and no better than the above in any way:
>
> https://gmail.com/.well-known/host-meta?resource=acct:joe@gmail.com
>
> Thus, I conclude that the only reason to have acct: and to strap it to
> joe@gmail.com is to use it as an identifier for an account, when that
> account already has a perfectly good, stable over time, but not exposed and
> non dereferencable identifier of it's own. Hence my previous mail.
>
> Best,
>
> Nathan
That would in itself work, but it would violate
http://tools.ietf.org/html/rfc6415 on which webfinger is based.
RFC6415 unambiguously states that the specific resources about which
information is retrieved should be identified by their URIs, not by
any custom strings. It says additional protocol-specific parameters
may be used, but identifying the resource should be done with a URI.
Especially in the two-step setup (when resolving an LRDD template),
putting "joe@gmail.com" at the place of "{uri}" would be incorrect.
That's why the choice was made to put "acct:joe@gmail.com" there
instead. There is a reason that resources are identified by URIs and
not by per-protocol strings. Namely that if every protocol uses the
URI format to refer to resources, then everything becomes more
combinable.
As i understand it, if the authors of webfinger have tried to change
RFC6415 to allow referring to resources with protocol-specific strings
that are not URIs, that would be going against the architecture of the
web?
Cheers,
Michiel
Received on Saturday, 23 June 2012 13:00:21 UTC