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

On 6/23/12 8:10 AM, Nathan wrote:
> Michiel de Jong wrote:
>> On Fri, Jun 22, 2012 at 11:01 PM, Henry Story 
>> <henry.story@bblfish.net> wrote:
>>> Yes, though one wonders why they don't just put a URL in there: it 
>>> could be
>>>
>>>   http://google.com/.wellknown?id=joe@gmail.com
>>>
>>> or whatever.
>>
>> That's a good point, and that's also what was the other option: not
>> registering a URI scheme (effectively using the actual webfinger
>> lookup URL as a URI), and then just using "bare user addresses" in the
>> ?id= parameter. in fact, the proposal is not "/.wellknown?id=" but
>> "/.well-known/host-meta[.json]?resource=", but the idea is the same,
>> of course. also note you used 'google.com' but you probably meant
>> 'gmail.com', because there is no way the client can know gmail.com is
>> owned by google. And we use https. So the choice was between:
>>
>> https://gmail.com/.well-known/host-meta?resource=joe@gmail.com
>>
>> or:
>>
>> https://gmail.com/.well-known/host-meta?resource=acct:joe@gmail.com
>>
>> as the URL to retrieve information about joe@gmail.com, and by that
>> merit, also as a URI to refer to this information itself. At the same
>> time, host-meta says it will respond with information about "any URI'
>> you put into its resource parameter. Why did we choose the second one?
>> Because at the same time of defining these URLs, we are saying that
>> the "?resource=" parameter, so either "joe@gmail.com" or
>> "acct:joe@gmail.com", is in itself a URI.
>>
>> Even though "joe@gmail.com" is understood as "a Uniform Identifier for
>> a Resource", it's not a URI. All existing URIs start with a scheme,
>> and saying "joe@gmail.com" (however much we would like to) is a URI
>> would be breaking a pattern. Randomly adding "xmpp:" in front would be
>> really random and imprecise (same for "sip:" and "mailto:"). That's
>> why adding the 'acct:' at the front made sense.
>>
>> All these options were discussed, and a decision was made. We now have
>> had this working in production for a while already, which is what i
>> meant when i said that changing it would result in extra work, and
>> loss of momentum for us.
>>
>> So yeah, using bare 'user@host' user addresses instead of
>> 'acct:user@host' URIs was an option, but the second option was chosen
>> precisely to stay within the established way the web refers to
>> resources: with URIs instead of with custom strings.
>
> I'm going to go out on a limb here and suggest that the URIs (or 
> URI-References) being discussed here don't identify accounts, and that 
> this is being modelled incorrectly.
>
> Historically I understand there was often a 1:1 association between 
> peoples email addresses (often input minus the mailto: scheme) and 
> their logins for certain user accounts. However it's common practice 
> now to have multiple email addresses associated with each account. If 
> we were modelling this in an ontology, user@host would not identify a 
> user account, or be the identifier for the user account, and further 
> it wouldn't even be an Inverse Functional Property since one user@host 
> may be associated with multiple user accounts, and each user account 
> associated with multiple users@various-hosts. I know this is true in 
> most areas of google, and other services, as I use multiple addresses 
> myself with multiple accounts.
>
> I'd suggest that there are two things going on here:
>
> 1) The true identifier for "user accounts" isn't being used, exposed 
> or made dereferencable, and
>
> 2) "Email addresses" associated with (not identifying) a user account 
> are being used to find out more information about an associated user 
> account.
>
> Whichever way I look at this, binding a thing that's used as an email 
> address in a 1:1 relation to a user account and calling it the user 
> accounts identify, by way of strapping on acct: or anything else, 
> seems like a poor modelling choice that could cause multiple problems; 
> including requiring the identifier for said user account to change 
> everytime an associated login/email-address is removed or changed.
>
> Each service I can think of, has a stable (non-URI) identifier for 
> user accounts, from google through twitter, IMO those should be used, 
> not these fragile email addresses with a new scheme bolted on the 
> front to try and make it identify something it doesn't.
>
> Best,
>
> Nathan
>
>
>
Nathan,

You are correct, if one discards the notion of URI opacity [1] re. AWWW. 
This is all about signs for denotation (naming). URIs can serve as 
names, de-reference enables exploitation of indirection such that a name 
resolves to its descriptor resource, as espoused by the Linked Data meme.

As you know, http: scheme URIs are endowed with in-built resolution 
that's in broad use, courtesy of the World Wide Web's ubiquity. Thus, 
its as cost-effective a mechanism you are going to find for the Web 
medium with regards to Linked Data deployment.

In light of what's outlined above, being cost-effective doesn't make 
http: scheme URIs the only option for Linked Data, any URI can be used 
the same way, albeit at the cost of resolver protocol construction and 
adoption by publishers and consumers.

An acct: scheme URI is just a URI. Webfinger is resolver mechanism for 
said URI scheme. The user@host component is just an intuition cue for 
humans :-)

Links:

1. http://www.w3.org/TR/webarch/#pr-uri-opacity -- URI opacity .

-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen