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

On 23 June 2012 15:42, Nathan <> wrote:

> Michiel de Jong wrote:
>> On Sat, Jun 23, 2012 at 2:32 PM, Nathan <> 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:
>>> 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:
>>> Thus, I conclude that the only reason to have acct: and to strap it to
>>> 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
>>**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 "" at the place of "{uri}" would be incorrect.
>> That's why the choice was made to put "" 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.

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.

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:05 UTC