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

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



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