FW: WebDAV URI Scheme - http://www.ietf.org/rfc/rfc2518.txt

Accidentally caught by the spam filter -- I've added timbl@w3.org to the
accept2 list, so future emails from Tim will go straight through to the
list.

- Jim

-----Original Message-----
From: Tim Berners-Lee [mailto:timbl@w3.org]
Sent: Thursday, March 29, 2001 11:35 AM
To: w3c-dist-auth@w3.org; w3c-policy@apps.ietf.org
Cc: w3t-arch group
Subject: [Moderator Action] WebDAV URI Scheme -
http://www.ietf.org/rfc/rfc2518.txt


I have never formally made a comment about RFC2518's
http://www.ietf.org/rfc/rfc2518.txt
 DAV: URI space but I do now.

I only recently noticed that it invents two completely new URIabuse one of
the weakest points of the web, the flat
highest level space of URI schemes.   The URI scheme name
if the root of the URI system, and DNS's TLDs being some
way below it.  Imagine the fuss there would have been
if WebDAV had introduced a TLD!  This is a little like
introducing an amendment to the constitution to allow
change the admission to town museums. It is being done
at entirely the wrong level.

I am quite appalled at this abuse of URIspace, and
schemes.  It is quite inappropriate for a specification to

am inclined to suggest that the specification be updated to
use a URI which the working group has in its power to allocate
(such as http://www.w3.org/2001/dav  or http://www.ietf.org/2001/dav)
This would entail all code being rewritten over time to accept first
both and then only this space. The tedious process of cleaning up
this debris in the web's front hall should begin now.

Looking at ftp://ftp.isi.edu/in-notes/iana/assignments/url-schemes
we find that there is *another* space reserved:

    opaquelocktoken

At least this is a real space of identifiers. It would be preferable
as a question of overall architecture to make this a separate
specification, as it is quite general uuid: with knobs on.
In fact, as there is no spec linking ISO-11578 UUIDs to the uuid:
scheme registered with IANA.  There should, in my opinion,
be such a specification.

There is a fundamental mistake that the URI scheme which is very general
is being specified as only applying to a particular class of object.
opaquelocktoken: would be quire reusable as a piece of technology
if it didn't have such an unnecessary restriction.

_______________________________________

I would like to suggest in the future that any new URI scheme
be resisted by W3C TAG and IESG  unless there really
is a new space with new well defined properties being defined.
It should then be put through a review by IETF and W3C at least,
at the start of the design process.

Tim

Received on Friday, 30 March 2001 00:04:14 UTC