Subject: RE: Issue: URI_URL, proposed changes

From: "Clemm, Geoff" <[email-masked]>
Date: Thu, 11 Jul 2002 08:51:33 -0400

From: Larry Masinter [mailto:[email-masked]]

   What about the usage of the terms URI, URL and URN do you actually
   need?  In what way does the definition of these terms affect the
   WebDAV specification? Most of the terminology is really just
   advisory.

I also don't see what changes we need/expect from RFC-2396.
The language there is quite clear.  The superclass is "URI".
The subclass of "locatable" URIs (i.e. ones that you can
type in to a client and expect it to "locate" the specified
resource is "URL".  The subclass of "naming" URIs
(ones that will never be shared by two "different" resources)
is URN.

In WebDAV, we have some URIs that we SHOULD/MUST be usable
to locate the resource.  We should call those "URLs" to emphasize
that point.  For example, the contents of the DAV:href elements
returned in DAV:response should be URLs (or more accurately,
URL-references).  We also have some URIs which name a resource
(in particular, lock tokens).  These should be called URNs.

And while I'm responding to this thread anyway, a few comments
on one of Julian's messages:

   From: Julian Reschke [mailto:[email-masked]]

   Some more comments inline.

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

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

Whether or not it is an HTTP URI/URL is not the issue here.  I believe
that the purpose of the source property is to locate the resource,
and therefore I believe it is appropriately called a URL.

   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"

I agree.

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

I disagree.  This is about URIs at which the resource is "available".
To me, being available means it is a URL, i.e. can be used to
locate the resource.

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

I disagree with this comment (note that this was something in the
original message, not something from Julian's post).  We should use
the term URN when discussing lock tokens.

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

I agree.

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

   Again -- needs to be fixed.

In particular, property names are not URIs at all (but rather a pair
consisting of a URI and a property name) and lock tokens should be called
URNs, not URIs.

Cheers,
Geoff

---

From: "Julian Reschke" <[email-masked]>
Date: Thu, 11 Jul 2002 15:31:00 +0200

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Clemm, Geoff
> Sent: Thursday, July 11, 2002 2:52 PM
> To: 'Webdav WG (E-mail)'
> Subject: RE: Issue: URI_URL, proposed changes
>
>
>

I don't think this is supported by RFC2396. Two URNs may identify the same
resource. If you disagree, you'll have to prove that.

> (in particular, lock tokens).  These should be called URNs.

I disagree. URLs are just a subset of URIs. When we talk about URIs that
identify WebDAV resources, we can talk about URLs (because we know that they
use the http: or https: scheme). Otherwise, we shouldn't make any
assumptions.

> and therefore I believe it is appropriately called a URL.

I think you are in disagreement with the current usage of terms, and with
the intended purpose of the source property. Source properties define links
to other resources, and whether these resources are identified by a URL or
URN should be completely irrelevant. You might want to take a look at
<http://search.ietf.org/internet-drafts/draft-mealling-uri-ig-02.txt>.

> To me, being available means it is a URL, i.e. can be used to

Yes, but it doesn't mean that there can't be a non-URL URI that identifies
the same resource.

> the term URN when discussing lock tokens.

That will break existing code for no good reason. One of my repository
managers uses the http: scheme to identify lock tokens.

So in general

- only use URL instead of URI when we *know* it to be a URL (so for http: or
https:)
- don't touch anything else, except for the purpose of updating from RFC2068
compliance to RFC2396 compliance