RE: Issue: URI_URL, proposed changes

   From: Julian Reschke [mailto:julian.reschke@gmx.de]

   > From: Clemm, Geoff
   >
   > 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.

   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.

I don't disagree, but I (and RFC-2396) was making the opposite point,
namely that two different resources cannot be identified by the same
URN.  So if two resources have the same URN, you are guaranteed that
they are the same resource.

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

   I disagree. URLs are just a subset of URIs.

We don't disagree there.

   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.

There are places where the URIs are not required to identify WebDAV
resources, but which are required to be usable to access the resource.
It believe it is appropriate and desireable to use "URL" for those
places (the DAV:source URIs are examples of such a place).

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

   I think you are in disagreement with the current usage of terms,
   and with the intended purpose of the source property.

WRT to "current usage" of those terms, until it is superceded by
another RFC, I will use the definitions from RFC-2396, which in my
opinion gives those terms acceptably clear and unambiguous definitions.
WRT the intended purpose of the source property, section 13.10 of
RFC-2518 states:

 "there is typically only one destination (dst) of the link,
  which is the URI where the unprocessed source of the resource
  may be accessed."

If something can be "accessed" at that URI, that URI is a URL, as
URLs are defined in RFC-2396.  And therefore it would have been
preferable for section 13.10 to use the term "URL" here, and not "URI".
Note: It is not wrong to use "URI" here, but it is just clearer to
use "URL".

   Source properties define links to other resources, and whether
   these resources are identified by a URL or URN should be completely
   irrelevant.

Not if you are going to use that URI to "access" the resource.  A
URL is used to access a resource, while a URN only guarantees
that it names that resource.  A particular URI can of course be
both a URL and a URI, but for the purposes of the source property,
what matters is that it can be used to access the resource, and there
is no guarantee that it names the resource.

   You might want to take a look at
   <http://search.ietf.org/internet-drafts/draft-mealling-uri-ig-02.txt>.

This draft is primarily about registration of URI schemes, but there
is an early section about the "confusion" in usage of the terms URI,
URL, and URN, which the authors conclude by saying that "[RFC-2396]
has not been successful in clearing up".  I find this conclusion a bit
puzzling, since the main "confusion" identified by the authors is
how/whether URL and URN "partition" the URI space, when RFC-2396
clearly states that a URI can be a URL, a URN, *or both*, and
therefore URLs and URNs *do not* partition the URI space.  (I would
have thought that a reasonably careful reading of RFC-2396
would have therefore cleared up this "confusion").

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

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

Certainly there can be, but those are not URIs at which the
resource is "available", and therefore are not relevant to the
statement being made in 8.10.3.  In particular, I would state
that "a resource is available at a URL", although it certainly
can be "identified" by a URI that is not a URL.

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

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

I think you may be confusing the "urn:" scheme with the concept of a URN.
A URI can be both a URL and URN, so as long as
you are using http: URLs that happen to have URN behavior, that is
fine.  In particular, although every URI in the 
"urn:" scheme SHOULD (or perhaps even MUST) be a URN, not every
URN has the "urn:" scheme.

   So in general

   - only use URL instead of URI when we *know* it to be a URL (so for
   http: or https:)

Sure.  But we need to use the RFC-2396 definition of what is a URL,
and anything that can be used to access a resource is a URL.
In particular, whether or not something is a URL is not dependent
on its scheme, but is dependent on whether it provides the
ability to access the resource it identifies.

   - don't touch anything else, except for the purpose of updating from
RFC2068
   compliance to RFC2396 compliance

I disagree.  We also should use URN in all cases where we *know*
something is a URN (such as a lock token).

Cheers,
Geoff

Received on Saturday, 13 July 2002 12:19:28 UTC