W3C home > Mailing lists > Public > www-tag@w3.org > June 2012

Re: Registration of acct: as a URI scheme has been requested

From: Nathan <nathan@webr3.org>
Date: Sat, 23 Jun 2012 14:42:07 +0100
Message-ID: <4FE5C7AF.7030607@webr3.org>
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
    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:


That way you tie in with web architecture, don't need a new URI-scheme, 
and still get to do what's required.


Received on Saturday, 23 June 2012 13:43:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:45 UTC