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

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

Best,

Nathan

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