Re: Ooops: generic syntax I-D bounced: ftp://ftp.parc.xerox.com/pub/masinter/draft-fielding-url-syntax-06.txt instead

On Mon, 4 Aug 1997, Larry Masinter wrote:

> I misaddressed my submission to "[email protected]" instead of
> "[email protected]", and missed the submission deadline.
> 
> So, in the meanwhile, check out the above URL.
> 
> 
> ftp://ftp.parc.xerox.com/pub/masinter/draft-fielding-url-syntax-06.txt


Many thanks for the update, Larry!

I have submitted three drafts to [email protected] before the
deadline, but they haven't yet turned up in the anouncements, and so
you maybe in the same situation if you had choosen the other address.


I have made a quick diff, which showed the following:


<<<<<<<<<<<<<<<<<<<<<<<<< Start of Diff
1d0
<
4,5c3,4
< draft-fielding-url-syntax-05              L. Masinter, Xerox Corporation
< Expires six months after publication date                    May 2, 1997
---
> draft-fielding-url-syntax-06              L. Masinter, Xerox Corporation
> Expires six months after publication date                  July 30, 1997
894c893,901
<       h) If the buffer string contains a question-mark "?" character,
---
>       h) If the resulting buffer string still begins with one or more
>          complete path segments of "..", then the reference is
>          considered to be in error.  Implementations may handle this
>          error by retaining these components in the resolved path
>          (i.e., treating them as part of the final URL), by removing
>          them from the resolved path (i.e., discarding relative levels
>          above the root), or by avoiding traversal of the reference.
>
>       i) If the buffer string contains a question-mark "?" character,
899c906
<       i) The reference URL's new path component is the buffer string up
---
>       j) The reference URL's new path component is the buffer string up
1269a1277,1293
>    Note that within a relative URL, "?", ";", and "#" that are not
>    leading characters are not interpreted with their reserved meaning;
>    in some cases, this results in illegal URLs.
>
>    While the rules for resolving partial/relative URLs since the have
>    been such that if relative symbolic elements end up at the
>    beginning of paths they should be retained,
>
>       /../s/x      =  http://a/../s/x
>
>    in practice, most parsers will strip lead relative symbolic
>    elements in the destination URL, such that
>
>      /../s/x       = http://a/s/x
>
>    Because of the ambiguity, such relative forms should be avoided.
>
1353d1376
<
1491d1513
<
<<<<<<<<<<<<<<<<<<<<<<<<< End of Diff


One thing I noted is some text that seems to be missing in the following
sentence:

>    While the rules for resolving partial/relative URLs since the have
                                                                  ^?
>    been such that if relative symbolic elements end up at the
>    beginning of paths they should be retained,


Another thing I wondered about is:

>    Note that within a relative URL, "?", ";", and "#" that are not
>    leading characters are not interpreted with their reserved meaning;
>    in some cases, this results in illegal URLs.

I just tried a simple examlpe with "#" not at the beginning of
a relative URL, and it works as (I) expected, namely it was
interpreted as "#". And I guess almost everybody on the web
would expect my example to work as expected. What I did was
to create an <A NAME="next">, and in the same document (called
text.html), have a link <A HREF="aaa/../text.html#next">.

What I think was the intention is to say was something like:

Note that within a relative URL, "?", ";", and "#" that are not
leading characters are not a priori interpreted with their
reserved meanings.

It would be nice if we could find some more precise wording
for "a priori", but I can't figure it out at the moment.


The above diff also shows that there are no differences with
respect to internationalization. I, and many others, have
repeatedly said that this is not sufficient. As the movement
towards using UTF-8 for internationalizing URLs is getting
stronger and stronger [the two main browser vendors are
currently seriously investigating the issue], it would be a
nice curtesy to readers of the draft to include a note saying
(at the end of 2.1):

NOTE: More systematic treatment of character encoding within
	URLs is currently under study and development [xxx].
	The single encoding with the best chances to be used
	for this systematic treatment is UTF-8 [RFC 2044].

By the fact that the document says, just before:

   While
   there is a strong desire to provide for a general and uniform
   mapping between more general scripts and URLs, the standard for
   such use is outside of the scope of this document.

it is very clear that this NOTE is not normative. Those that
may claim that it is not clear enough please suggest better
wording. Every reader of the draft interested in the topic
will be glad to see the note and the references to get
additional information, while we don't commit to anything
in the case suddenly a better solution should be found or
it should be discovered than nobody on the world needs
internationalized URLs.

Regards,	Martin.