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

On 26 June 2012 09:39, Melvin Carvalho <> wrote:

> On 26 June 2012 01:30, Bjoern Hoehrmann <> wrote:
>> * Graham Klyne wrote:
>> >Thus, while URIs from different schemes may be dereferenced to obtain
>> web pages,
>> >mailboxes, etc., the acct: scheme is specifically intended to return user
>> >account description(s) when dereferenced, and to obtain said
>> description(s)
>> >using the WebFinger protocol.  No other URI scheme does that.
>> >
>> >While I might agree that it's not the most compelling candidate for a
>> new URI
>> >scheme, I think it does meet the expectations for such a scheme, and
>> there does
>> >appear to be a significant community who want the capability it provides.
>> My impression is largely similiar. I also think people who think this
>> scheme should not be registered should post to <>.
> Thanks for the point, I'll follow that discussion.
> I think the concerns I have can be summarized as follows:
> *disclaimer: these are my personal queries and in no way represent the TAG
> or W3C *
> - Seems unclear to me whether the whole webfinger community is
> unilaterally behind the acct: naming scheme
> - Increased implementation complexity
> - "Simple Web Discovery" has shown that this problem can be solved without
> requiring a new URI scheme
> - The same problem can be solved using mailto: without requiring a new
> URI scheme
> - There seems to be strong calls in the community for user@host to be a
> parameter, how will this be handled
> - The same problem can be solved using HTTP, without requiring a new URI
> scheme
> - The same problem can be solved using SPARQL, without requiring a new URI
> scheme
> - The scheme could equally be a URN
> - It will take several years to gain adoption of acct: and initially other
> schemes have a bigger network effect
> - Developers will get confused between acct:user@host mailto:user@hostand user@host
> - Linked data systems will have to have another branch in order to do joins
> - If the account whose object is a mail address requires a URI scheme, why
> not the user: thing: agent: person: etc.
> - Does this open the door for more and more schemes to be registered by
> the bigcos, diluting the space
> - I'm unsure that the mapping from identifer user@host -> acct:user@hosthas been documented, for example, one of the motivating use cases brought
> up was for twitter, yet the RFC seems unclear how this would work
> - The relationship between mailto: address and acct: address appears not
> to be returned in the descriptor document
> Having said that, I think that the acct: scheme registration could have
> some positive side effects.  Namely that it will get people to think about
> URIs and identity, and multiple identity linking.  Perhaps the linked data
> (using http URIs to name things and w3c recs) will benefit from some
> friendly competition in terms of naming, a kind of democracy of ideas.
> Perhaps my biggest concern is that once this precedent is set they may be a
> future land rush to create apps, or solve technical problems, using a new
> uri scheme, thereby diluting that name space.
> So, although I find acct: confusing and perhaps reinventing, in the spirit
> of tolerance, I'm not fearful of competition.  HTTP URIs will continue to
> benefit from the network effect, and any other scheme will have a chance to
> state its case.  Any outcome can have positive implications.  It's up to
> the IETF to curate and maintain quality in the namespace as it sees fit.  I
> look forward to following discussions there.

One final observation from this morning:

If you type something like into
- Gmail
- GTalk
- IRC (at least my client)

It underlines it and puts a hyperlink with the assumption of mailto:

I'm sure there are 100s if not 1000s of other software applications that
have allowed the freeform user@host identifer to date and translated it to
mailto.  Behavior may need to change assuming the acct: gains wide
adoption.  I suppose it will be up to each individual piece of software to

>> --
>> Björn Höhrmann · ·
>> Am Badedeich 7 · Telefon: +49(0)160/4415681 ·
>> 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 ·

Received on Tuesday, 26 June 2012 12:52:18 UTC