RE: Issue: URI_URL, proposed changes

I think it is a good idea to delay this change. The whole terminology needs
to be checked carefully if we update the draft to refer to RFC2396 rather
than RFC2068 (because the *meaning* of the term "URI" changed between the
two RFCs!).

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.

8.1:

"Each response XML element MUST contain an href XML element that gives the
URI of the resource on which the properties in the prop XML element are
defined"

needs to be fixed in that the DAV:href element must be defined to be a "URI
reference to be resolved relative to the request URI" (1). If we require a
URI (or URL), we wouldn't be allowed to return absolute URI references such
as "/collection/resource" (this isn't syntactically a URL or URI).

8.10.3: don't agree - resources may have alternate URIs which do not happen
to be URLs.

>  - Change the language to refer to what the Destination header
> contains as a
> URL, not a URI.
>
>  - Continue to refer to URI when discussing lock tokens. E.g. section 6.3,
> 6.4
>
>  - Continue to refer to the "Request-URI" as that is the way the
> address in
> the first line of a request is named.
>
>  - Continue to refer to tokens in the IF header as URIs.
>
>  - Continue to use URI in section 9.7, where the Status-URI
> response header
> is defined to contain a URI.

I think that's a section that we may have to remove anyway (issue:
INTEROPERABILITY_OF_102PROCESSING_STATUS_DEMONSTRATED).

>  - Continue to define the <href> element in section 12.3 as containing a
> URI, because to do otherwise would change the specificaiton, not
> clarify it.

Actually, this needs to be fixed. The definition should refer to RFC2396,
and use the term "URI reference".

> Likewise for <src>, <dst> and <owner> elements.
>
>  - Continue to define the property name as a URI in section 16.

As mentioned before, properties do not have URIs (at least there's no
one-to-one mapping unless we define it ourselves). The entire paragraph in
section 16 needs to be removed or rewritten.

>  - Continue to use the term URI in IANA considerations, where the property
> name and lock token URIs are discussed.

Again -- needs to be fixed.

>  - Continue to use the term URL as in "HTTP URL Namespace" (e.g. section
> 5.1).  Continue using the term URL wherever it is used.
>
> I will not be able to get this done by the draft deadline
> (Monday) since I'm
> taking a long weekend to celebrate Canada Day ;)  But I'll gather the
> feedback after that and incorporate it later.

Received on Wednesday, 26 June 2002 18:43:24 UTC