W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2002

Issue: URI_URL, proposed changes

From: Lisa Dusseault <ldusseault@xythos.com>
Date: Wed, 26 Jun 2002 11:37:48 -0700
To: "Webdav WG \(E-mail\)" <w3c-dist-auth@w3c.org>
Message-ID: <002401c21d40$935f1630$7801a8c0@moose>

This issue is described in more detail in
"http://www.webdav.org/wg/rfcdev/issues.htm".  Basically, Larry Masinter
suggested that the use of URI vs. URL is not ideal in RFC2518.  If I
understand the problem, it seems the term URL is used appropriately wherever
it is used.  However, the term URI is used too often, at times when the term
URL would be more appropriate.

Here is what I propose to do to fix that, on a case-by-case basis.  The
first two cases are the only changes, the rest are cases where I propose to
continue the current usage.  I wanted to list all the cases, both for
changing and for continuing, so you can point out if I've missed any cases.

 - Change to refer to URL whenever we refer to the address of a collection
or resource.  This replaces the definition of "Member URI" with "Member URL"
in the Terminology section, and replaces URI with URL in the definition of
that.  Same with "Internal Member URI" to "Internal Member URL".  Many other
instances of URI will be replaced with URL according to this new terminology
approach.  E.g. throughout sections 5.2, 5.4, 7.5, 8.1, and 8.10.3 .

 - Change the language to refer to what the Destination header contains as a
URL, not a URI.

 - Continue to refer to URI when discussing lock tokens. E.g. section 6.3,

 - Continue to refer to the "Request-URI" as that is the way the address in
the first line of a request is named.

 - Continue to refer to tokens in the IF header as URIs.

 - Continue to use URI in section 9.7, where the Status-URI response header
is defined to contain a URI.

 - Continue to define the <href> element in section 12.3 as containing a
URI, because to do otherwise would change the specificaiton, not clarify it.
Likewise for <src>, <dst> and <owner> elements.

 - Continue to define the property name as a URI in section 16.

 - Continue to use the term URI in IANA considerations, where the property
name and lock token URIs are discussed.

 - Continue to use the term URL as in "HTTP URL Namespace" (e.g. section
5.1).  Continue using the term URL wherever it is used.

I will not be able to get this done by the draft deadline (Monday) since I'm
taking a long weekend to celebrate Canada Day ;)  But I'll gather the
feedback after that and incorporate it later.

Received on Wednesday, 26 June 2002 14:37:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:26 UTC