Subject: Issue: URI_URL, proposed changes

From: "Lisa Dusseault" <[email-masked]>
Date: Wed, 26 Jun 2002 11:37:48 -0700

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,
6.4

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

Lisa

---

From: "Julian Reschke" <[email-masked]>
Date: Wed, 26 Jun 2002 21:42:21 +0200

I'm not convinced that this change is important. A URL is a URI. We just
need to be clear about when a URI actually happens to be a *WebDAV* URI.

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

That section needs to be fixed anyway -- property names do not have URLs or
URIs. Period. This should be put onto the issues list (Jim?).

> ...

There maybe a deadline for draft submissions before the IETF meeting, but
does that mean that a new RFC2518bis draft needs to be submitted at all? I
would have hoped that before a new draft is submitted, the issues
*introduced* by the submission of the previous draft are actually resolved
(or at least discussed). See

<http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0185.html> and
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0186.html>

---

From: "Julian Reschke" <[email-masked]>
Date: Thu, 27 Jun 2002 00:42:53 +0200

I think it is a good idea to delay this change. The whole terminology needs
to be checked carefully if we update the draft to refer to RFC2396 rather
than RFC2068 (because the *meaning* of the term "URI" changed between the
two RFCs!).

Some more comments inline.

> approach.  E.g. throughout sections 5.2, 5.4, 7.5, 8.1, and 8.10.3 .

When 5.4 refers to source URIs, it needs to continue to do so. Source
resources may not be HTTP resources at all.

8.1:

"Each response XML element MUST contain an href XML element that gives the
URI of the resource on which the properties in the prop XML element are
defined"

needs to be fixed in that the DAV:href element must be defined to be a "URI
reference to be resolved relative to the request URI" (1). If we require a
URI (or URL), we wouldn't be allowed to return absolute URI references such
as "/collection/resource" (this isn't syntactically a URL or URI).

8.10.3: don't agree - resources may have alternate URIs which do not happen
to be URLs.

> is defined to contain a URI.

I think that's a section that we may have to remove anyway (issue:
INTEROPERABILITY_OF_102PROCESSING_STATUS_DEMONSTRATED).

> URI, because to do otherwise would change the specificaiton, not

Actually, this needs to be fixed. The definition should refer to RFC2396,
and use the term "URI reference".

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

As mentioned before, properties do not have URIs (at least there's no
one-to-one mapping unless we define it ourselves). The entire paragraph in
section 16 needs to be removed or rewritten.

> name and lock token URIs are discussed.

Again -- needs to be fixed.

---

From: Stefan Eissing <[email-masked]>
Date: Thu, 27 Jun 2002 14:31:35 +0200

As an addendum to this: there is work in progress on a new
version of RFC 2396, which should also include clarifications
about the usage of terms URI, URL and URN - among other things.

I think Larry Masinter has taken the lead on this activity and
I would consider it prudent to align the wording of a future
2518 with his findings. Maybe Larry can give us a hint at his
schedule?

//Stefan