Re: Issue: URI_URL, proposed changes

As an addendum to this: there is work in progress on a new
version of RFC 2396, which should also include clarifications
about the usage of terms URI, URL and URN - among other things.

I think Larry Masinter has taken the lead on this activity and
I would consider it prudent to align the wording of a future
2518 with his findings. Maybe Larry can give us a hint at his
schedule?

//Stefan

Am Donnerstag den, 27. Juni 2002, um 00:42, schrieb Julian Reschke:

>
> 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 Thursday, 27 June 2002 08:32:16 UTC