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 <masinter@adobe.com> 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.

+1

>
> 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.

+1

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:.

Amen!

Kingsley
>
> Jonathan
>
>> -----Original message-----
>>
>> From: Kingsley Idehen <kidehen@openlinksw.com>
>> To: "www-tag@w3.org" <www-tag@w3.org>
>> 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] http://www.w3.org/TR/webarch/#URI-scheme
>>>
>>>
>>>
>>
>> --
>>
>> Regards,
>>
>> Kingsley Idehen
>> Founder & CEO
>> OpenLink Software
>> Company Web: http://www.openlinksw.com
>> Personal Weblog: http://www.openlinksw.com/blog/~kidehen
>> Twitter/Identi.ca handle: @kidehen
>> Google+ Profile: https://plus.google.com/112399767740508618350/about
>> LinkedIn Profile: http://www.linkedin.com/in/kidehen
>>
>>
>>
>>
>>
>
>


-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen