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

On 6/20/2012 1:42 PM, Kingsley Idehen wrote:

> If the architecture of the world wide web can't accommodate new URI schemes
> then its broken. The great news is that it isn't broken.

The way this is phrased, you leave out a crucial subtlety. The Architecure 
of the World Wide Web is quite clear on the fact that definition of new 
schemes is allowed, but costly [1]:

While Web architecture allows the definition of new schemes, introducing a 
new scheme is costly. Many aspects of URI processing are scheme-dependent, 
and a large amount of deployed software already processes URIs of 
well-known schemes. Introducing a new URI scheme requires the development 
and deployment not only of client software to handle the scheme, but also 
of ancillary agents such as gateways, proxies, and caches. See [RFC2718] 
for other considerations and costs related to URI scheme design.

Because of these costs, if a URI scheme exists that meets the needs of an 
application, designers should use it rather than invent one.

Good practice: Reuse URI schemes

A specification SHOULD reuse an existing URI scheme (rather than create a 
new one) when it provides the desired properties of identifiers and their 
relation to resources.

Many TAG members seem to be concerned that the advice above is too often 
being ignored. In addition to the points made above, each token in the 
scheme space is valuable, precisely because it is, by tradition, one in 
which the names are short, central registration is required, and no two 
facilities can use the same scheme name for different purposes. Even if no 
acct URI's "leak" out from the intended private use within Web finger, that 
relatively suggestive short name is now not available for any other purpose 
as a scheme.

For all these reasons, the bar should be set very high on the registration 
of new schemes. That does not mean, as you suggest, that there is a 
question of not "accommodating" new schemes. In the rare cases where a new 
scheme is appropriate, the architecture can accommodate it.



Received on Wednesday, 20 June 2012 21:30:55 UTC