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

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?


>
> -----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:52:31 UTC