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

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 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

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


Received on Saturday, 23 June 2012 13:00:21 UTC