- From: Nathan <nathan@webr3.org>
- Date: Sat, 23 Jun 2012 14:42:07 +0100
- To: Michiel de Jong <michiel@unhosted.org>, "Henry S. Thompson" <ht@inf.ed.ac.uk>
- 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>
Michiel de Jong wrote: > 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? Perhaps the problem is that you don't have URIs to use as identifiers, and that you're trying to make custom strings in to URIs by creating a new scheme and prefixing the user@host with that scheme, rather than levering the advantages of existing URI schemes, or giving user accounts unique, stable over time, non 1:1 with email address URIs. RFC6415 makes specific provision for this use case under section 3.1.1.1: ''' Protocols MAY define additional relation-specific variables and syntax rules, but SHOULD only do so for protocol-specific relation types ''' So rather than creating an unstable pretty much useless URI for use internally within a specific protocol, why not take advantage of this provision and define the variable {acct} instead, such that you can do: https://gmail.com/.well-known/host-meta?acct=joe@gmail.com That way you tie in with web architecture, don't need a new URI-scheme, and still get to do what's required. Best, Nathan
Received on Saturday, 23 June 2012 13:43:05 UTC