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: Thursday, July 11, 2002 2:52 PM
> To: 'Webdav WG (E-mail)'
> Subject: RE: Issue: URI_URL, proposed changes
>
>
>
>    From: Larry Masinter [mailto:LMM@acm.org]
>
>    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.

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 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. 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 while I'm responding to this thread anyway, a few comments
> on one of Julian's messages:
>
>    From: Julian Reschke [mailto:julian.reschke@gmx.de]
>
>    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.

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

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

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


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

Received on Thursday, 11 July 2002 09:31:32 UTC