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

On Fri, Jun 22, 2012 at 11:01 PM, Henry Story <> wrote:
> Yes, though one wonders why they don't just put a URL in there: it could be
> 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 '' but you probably meant
'', because there is no way the client can know is
owned by google. And we use https. So the choice was between:


as the URL to retrieve information about, 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 "" or
"", is in itself a URI.

Even though "" is understood as "a Uniform Identifier for
a Resource", it's not a URI. All existing URIs start with a scheme,
and saying "" (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.


Received on Saturday, 23 June 2012 11:37:21 UTC