W3C home > Mailing lists > Public > uri@w3.org > August 2009

Re: Guidelines on usage of // in new URI schemes

From: Graham Klyne <GK-lists@ninebynine.org>
Date: Thu, 20 Aug 2009 09:50:01 +0100
Message-ID: <4A8D0E39.3030404@ninebynine.org>
To: URI <uri@w3.org>
[Sent originally in response to IETF-apps, but I realize it's probably more
usefully sent here.]

> On Wed, 2009-08-19, Eran Hammer-Lahav wrote:
>> I am in the process of proposing a new URI scheme to identify user
>> accounts [1]. This is part of the WebFinger protocol [2] effort.

[...]

>> acct:username@host
>> acct://username@host

[...]

>> Any suggestions?

The '//' is used to introduce an "authority" component in a URI.  A URI without
an authority resolved against a base with one would acquire the base authority
(from
RFC 3986, pp31-32, also section 5.4.1 example "/g"); e.g.

base URI:
   foo://auth/path

URI reference:
   /otherpath

would resolve to:
   foo://auth/otherpath

If your URI scheme consists of *only* an authority (which I think is your stated
intent) then the distinction is probably moot.

BUT, the thought that occurs to me is that there are multiple notions of
authority here (e.g. the authority of the user-account issuer vs the authority
of a user to post messages).

Where this leads me is to a *third* design along the lines of:

   foo://user-issuing-authority/username

The main advantage of this that I see is that there is shed-loads of code out
there that will parse this form of URI and present you with the pieces (i.e.
pretty much every URI handling library in every language, not to mention the
regex in RFC 3986, appendix B).

A second advantage is that there is further scope for future extension to, say,
hierarchical user structures - which I recognize is not part of the current scope.

A third possible advantage (with a nod to a comment made by Larry Masinter) is
that by putting the user component in the path rather than the "domain"
authority, some username I18N issues may be easier.  (I'm no expert here, so I
could easily be way wrong, but I seem to recall reading somewhere that
mechanisms for I18N within the authority are likely to diverge from the
widely-used UTF-8 + %-encoding that apply in the path of the URI.)

#g
Received on Thursday, 20 August 2009 08:50:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 13 January 2011 12:15:42 GMT