- From: Clemm, Geoff <gclemm@rational.com>
- Date: Sat, 13 Jul 2002 12:18:55 -0400
- To: "'Webdav WG (E-mail)'" <w3c-dist-auth@w3c.org>
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