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

On 23 June 2012 15:42, Nathan <nathan@webr3.org> wrote:

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

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.

http://tools.ietf.org/html/draft-jones-simple-web-discovery-02

As I understand it, both simple web discovery and webfinger are merging
into one effort.


>
> Best,
>
> Nathan
>