W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2002

Re: Issue: URI_URL, proposed changes

From: Stefan Eissing <stefan.eissing@greenbytes.de>
Date: Thu, 27 Jun 2002 14:31:35 +0200
Cc: "Lisa Dusseault" <ldusseault@xythos.com>, "Webdav WG \(E-mail\)" <w3c-dist-auth@w3c.org>, LMM@acm.org
To: "Julian Reschke" <julian.reschke@gmx.de>
Message-Id: <D1CDEA58-89C9-11D6-8490-00039384827E@greenbytes.de>

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


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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:26 UTC