W3C home > Mailing lists > Public > www-tag@w3.org > June 2012

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

From: Nathan <nathan@webr3.org>
Date: Sat, 23 Jun 2012 13:10:55 +0100
Message-ID: <4FE5B24F.7030702@webr3.org>
To: Michiel de Jong <michiel@unhosted.org>
CC: Henry Story <henry.story@bblfish.net>, Kingsley Idehen <kidehen@openlinksw.com>, www-tag@w3.org, Melvin Carvalho <melvincarvalho@gmail.com>, Read-Write-Web <public-rww@w3.org>
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 

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.


Received on Saturday, 23 June 2012 12:11:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:45 UTC