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

From: "Jim Whitehead" <[email-masked]>
Date: Thu, 29 Mar 2001 21:02:55 -0800

Accidentally caught by the spam filter -- I've added [email-masked] to the
accept2 list, so future emails from Tim will go straight through to the
list.

- Jim

-----Original Message-----
From: Tim Berners-Lee [mailto:[email-masked]]
Sent: Thursday, March 29, 2001 11:35 AM
To: [email-masked]; [email-masked]
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

---

From: "Eric Sedlar" <[email-masked]>
Date: Thu, 29 Mar 2001 21:46:29 -0800

I don't think anyone would dispute that the "DAV:" hack should be
fixed in the next version of RFC2518.  Now that XML namespaces are
stabilized, there is no excuse for non-compliance in the way the
DAV namespace is defined.  I assume that Jim has this on his list
of to-dos.

Jim?

---

From: "Julian F. Reschke" <[email-masked]>
Date: Fri, 30 Mar 2001 14:27:31 +0200

Hi,

it's easy to agree that the namespaceUri was badly chosen -- however I
really don't see all servers and clients being converted to support two
namespace names.

Couldn't this be "fixed" easier by registering "DAV:" as an URI scheme
(looking at <ftp://ftp.isi.edu/in-notes/iana/assignments/url-schemes>, it's
listed already...).

Julian

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jim Whitehead
> Sent: Friday, March 30, 2001 7:03 AM
> To: WebDAV WG; [email-masked]
> Subject: FW: WebDAV URI Scheme - http://www.ietf.org/rfc/rfc2518.txt
>
>