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

On 6/21/12 11:01 AM, Jonathan A Rees wrote:
> On Thu, Jun 21, 2012 at 3:39 AM, Larry Masinter <> wrote:
>> looks like the registration form is missing pointers to the actual semantics
>> of the scheme as well as to the only actual use case.
> In defense of the webfinger draft, the form of the registration is no
> different from the http: scheme registration in this respect.  In both
> cases, the syntax of the URIs is specified, but the registration
> section of the RFC says almost nothing about semantics. Yes, there is
> strong guilt by association because the scheme description happens to
> occur inside the documentation of a protocol, but the HTTP protocol
> (like webfinger) can be used with any kind of URI, and there is no
> explicit statement in the RFC linking the scheme to the protocol.


> There is the one semantic-sounding statement 'The "http" scheme is
> used to locate network resources via the HTTP protocol' but this is
> completely uninformative since other schemes, such as ftp:, can *also*
> be used to locate network resources via the HTTP protocol.


Hopefully,  you can see how this becomes a major HttpRange-14 imbroglio 
vector. Some folks go to this particular spec and conclude that a URI 
can only be a resource locator. The "I" in "URI" becomes the Identifier 
for the Resource at a Location (which is also a safe denotation 
mechanism in the Web medium for Web resources). Then we have RDF that's 
primarily about denotative use of URIs, solely; and then we the Linked 
Data meme that espouses denotation and resource identification packed 
into a single URI via implicit or explicit indirection, subject to 
choice of hash or hashless http: URIs.
> I don't think HTTPbis is substantially different from 2616 in this
> respect, either.
> So, if the criticism applies to acct:, it also applies to http:.


> Jonathan
>> -----Original message-----
>> From: Kingsley Idehen <>
>> To: "" <>
>> Sent: Wed, Jun 20, 2012 21:57:13 GMT+00:00
>> Subject: Re: Registration of acct: as a URI scheme has been requested
>> On 6/20/12 5:30 PM, Noah Mendelsohn wrote:
>>> 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]:
>> True!
>>> ===========
>>> 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
>> Yes.
>>> 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.
>> As you know, there's no bar higher that knocking HttpRange-14
>> distractions at every turn. WebID solve a major problem. Its reliance of
>> Linked Data ultimately brings the denotation (name) and web resource
>> identification duality issues into scope. Thus, we have an example of a
>> situation where a new URI scheme is warranted albeit solely as an
>> additional option for entity (web or real-world) names that use
>> indirection to resolve to web based descriptor documents/resources.
>> Kingsley
>>> Noah
>>> [1]
>> --
>> Regards,
>> Kingsley Idehen
>> Founder & CEO
>> OpenLink Software
>> Company Web:
>> Personal Weblog:
>> Twitter/ handle: @kidehen
>> Google+ Profile:
>> LinkedIn Profile:



Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web:
Personal Weblog:
Twitter/ handle: @kidehen
Google+ Profile:
LinkedIn Profile:

Received on Thursday, 21 June 2012 16:56:32 UTC