Subject: RE: Issue: URI_URL, proposed changes

From: "Clemm, Geoff" <[email-masked]>
Date: Sat, 13 Jul 2002 12:18:55 -0400

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

   > 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

---

From: "Julian Reschke" <[email-masked]>
Date: Sat, 13 Jul 2002 19:30:40 +0200

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

I  mis-read what you wrote, but I still disagree (now in a different way). A
URI (no matter whether URN or URL) identifies a resource. So two different
resources can't have the same URL either. That's by definition.

>    > returned in DAV:response should be URLs (or more accurately,

Actually, they MUST be URLs in the same scheme as the request URI...

>    I disagree. URLs are just a subset of URIs.

RFC2518 has defined that lock tokens are identified by URIs with no
restriction. An attempt to restrict lock tokens to specific URI types (are
you trying to do that?) can break existing code with no benefit -- the only
thing a client should do with a lock token is to remember it, and to
resubmit when needed -- from it's point of view it just a string, and
clients MUST not make any assumptions about the type of the URI scheme in
use.

> places (the DAV:source URIs are examples of such a place).

I disagree that the source link MUST use "locatable" resources. We may want
to clarify with Roy.

Example: I might want to have a source link from

	http://greenbytes.de/tech/webdav/rfc3253.html

to

	urn:ietf:rfc:3253

Do you say this is wrong?

>   which is the URI where the unprocessed source of the resource

This is just s statement about a typical use case. It doesn't say anything
about other use cases.

> preferable for section 13.10 to use the term "URL" here, and not "URI".

So who defines whether a URI is a URN? Is

	urn:isbn:(some-isbn)

a URN? Is it a URL? If it *is* a URN (it clearly says so :-), does it become
a URL as well if I install a custom URI resolver in my system which knows
about the urn:isbn: scheme? I think the concept of *partitioning* URIs into
"locatable" und "naming" is bogus -- both types can be used both ways. The
joint IETF/W3C URI interest group is currently trying to clarify this, and
we should not to rely on outdated definitions.

> Not if you are going to use that URI to "access" the resource.  A

Who says that the URI must be usable to "access" the resource? It's
certainly not in the current definition.

> that it names that resource.  A particular URI can of course be

URLs name resources as well. So are they a superset of URNs? Just wondering.

> is no guarantee that it names the resource.

URLs are URIs. URIs *identify* resources, so they provide *identifiers* for
resources. Are you saying that an "identifier" is not a "name"?

> can be "identified" by a URI that is not a URL.

Resources never are *available* at a URI. *Representations* of resources may
be available. I think you are saying that any URI that can be used to locate
a representation of a resource is a URL. That may be technically correct (so
*I* can basically turn every URN into a URL by implementing a resolver for
the scheme). However, most people clearly have a different understanding of
URLs. We should try to *avoid* additional confusion, instead of adding to
it.

> and anything that can be used to access a resource is a URL.

I don't think that RFC2396 says that. For instance, "urn:isbn:" clearly is a
URN scheme, but I still can use that URN to access a representation of the
resource (the resource for instance being a book).

> ability to access the resource it identifies.

How would a *URI* provide that ability? The URI itself is just a name. For
specific URI schemes, my computer may have software installed to resolve it,
but that's it. RFC2396 characterizes a URL as a URI "that identify resources
via a representation of their primary access mechanism (e.g., their network
"location")", but that doesn't mean that a non-URL URI can't be used to
locate the resource as well.

> something is a URN (such as a lock token).

Well.

If you agree that a HTTP URL can be used to identify a lock token, thus it
*is* both a URN and a URL, could you please give an example of a HTTP URL
that doesn't share these properties (thus *isn't* a URN)?