- From: Martin Duerst <duerst@w3.org>
- Date: Mon, 17 Feb 2003 18:00:42 -0500
- To: Tim Bray <tbray@textuality.com>, WWW-Tag <www-tag@w3.org>
Hello Tim,
Some comments on this document.
- The 'Status of this document' says 'This is the second draft'.
Guess this should be 'third'.
- The first sentence of the Introduction can be read two ways:
"Software is commonly required to compare two URIs."
Does this mean:
"Comparing URIs is rarely done by hand, software is commonly used to
do the job."
or:
"Software often has a need to compare two URIs."
- Please include some examples for 'Simple String Comparison'
- I have to disagree that http://dir/a and http://dir/%61 can be
considered to be different. This is I think based on a misunderstanding
of RFC 2396. What is true is that both 'a' and '%61' do not necessarily
have to stand for the character 'a' on the server side, but could
stand for a '/' character on an EBCDIC server (if that character
is part of a path component (read file or directory name)
rather than a path separator). Whether we have an 'a' on an
ASCII-based server or a '/' on an EBCDIC-based server, we have
to send the octet <61> to the server to retrieve a representation
of that resource. To have a browser (or something similar) send
an octet <61> (or whatever the server will interpret as such)
to the server, both 'a' and '%61' can be used, interchangeably.
I therefore suggest that the section on %-escaping be the first
section of RFC2396-Sensitive Comparison, and that it nails down
that %-equivalence (e.g. ~ == %7E == %7e) is (as currently observed)
and be (to be specified by specifications) the minimal (baseline)
equivalence to be respected by resolution-related operations
(as opposed to namespace-like equivalences). (with the exception
of reserved characters)
I'd be glad to help with some actual text.
- The document should itself use upper case for %-escapes as it
recommends (except for examples that are explicitly about casing).
Regards, Martin.
At 18:23 03/02/01 -0800, Tim Bray wrote:
>I just uploaded http://www.textuality.com/tag/uri-comp-3.html with changes
>based on feedback here and in our telecon. Below are some of the details
>of the update.
>
>Roy has suggested that some or all of this text may find its home in the
>RFC2396bis, which is his current work-in-progress, which sounds sensible.
>
>Stuart argues in
>http://lists.w3.org/Archives/Public/www-tag/2003Jan/0019.html that we rush
>too quickly into "equivalence" without making it clear that equivalence is
>in respect of some purpose. He's right and I've rewritten the
>introduction to say this; however I have not included Stuart's examples,
>as I think the specifics are well-populated with examples below.
>
>He also agonizes at length about the %-escaping issue (as do other posters
>to www-tag), but I'm just not gonna rewrite this any more. I think
>RFC2396 is first of all vague in that various reasonable people on www-tag
>disagree on what it says, and secondly wrong in the degree of latitude it
>offers in the char->octet mapping. I think the current uri-comp draft is
>as reasonable an interpretation of what it says and what you might do
>about it as you're going to find anywhere.
>
>Dan comments at length in
>http://lists.w3.org/Archives/Public/www-tag/2003Jan/0132.html, and the TAG
>waded through some of them (in his absence, snicker) in
>http://www.w3.org/2003/01/20-tag-summary. I'll skip his editorial comments.
>
>His first comment is basically the same as Stuart's first.
>
>He also challenges the assertion that it is never possible to be sure that
>two URIs identify "different" resources, with reference to a previous
>posting that I can't find, sorry, so I left that as is.
>
>The TAG didn't agree with the commentary on the usage of the term "URI
>reference".
>
>After some discussion, the TAG also decided that the /./ and /../
>semantics really need to apply to absolute as well as relative URIs.
>
>Finally, Paul Cotton in
>http://lists.w3.org/Archives/Public/www-tag/2003Jan/0129.html argued that
>the recommended best practice in %-escaping would be to use uppercase A
>through F, and this has been adopted and explained. -Tim
Received on Monday, 17 February 2003 19:54:31 UTC