- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Sat, 23 Jun 2012 16:31:36 +0200
- To: nathan@webr3.org
- Cc: Michiel de Jong <michiel@unhosted.org>, "Henry S. Thompson" <ht@inf.ed.ac.uk>, Henry Story <henry.story@bblfish.net>, Kingsley Idehen <kidehen@openlinksw.com>, www-tag@w3.org, Read-Write-Web <public-rww@w3.org>
- Message-ID: <CAKaEYhLR+xXV3Qj24i8y9NFPmK4bnkqn6jO9rt0ueKsTaRmOdA@mail.gmail.com>
On 23 June 2012 15:42, Nathan <nathan@webr3.org> wrote: > 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<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<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 <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<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. > Also, in case anyone was not aware, Mike Jones produced an elegant solution to this problem called "Simple Web Discovery", which solves the web finger use case, without requiring a new URI scheme. http://tools.ietf.org/html/draft-jones-simple-web-discovery-02 As I understand it, both simple web discovery and webfinger are merging into one effort. > > Best, > > Nathan >
Received on Saturday, 23 June 2012 14:32:08 UTC