RE: Issue: URI_URL, proposed changes

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]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
>
>
>
>    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.

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.

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

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

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

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.

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

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?

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

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

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

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.

> 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

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

> URL is used to access a resource, while a URN only guarantees
> 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.

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

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

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

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.

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

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

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

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.

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

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)?

Received on Saturday, 13 July 2002 13:31:15 UTC