To: fielding@avron.ics.uci.edu
In-Reply-To: fielding@avron.ics.uci.edu's message of Fri, 16 Sep 1994 09:21:05 -0700 <94Sep16.092115pdt.2763@golden.parc.xerox.com>
Subject: Re: Outstanding Issues for Relative URL draft
From: Larry Masinter <masinter@parc.xerox.com>
Message-Id: <94Sep17.135304pdt.2760@golden.parc.xerox.com>
Date: Sat, 17 Sep 1994 13:52:56 PDT
I think you already have my opinion on ISSUE 2 (scheme: ...) always
starts an absolute URL. I think simplifying the spec is important.
As for 'existing practice', you should separately evaluate:
1) does this require current browsers to change?
2) does this invalidate current documents.
1) Taking a case that was previously legal and making it illegal
doesn't require browsers to change: they might be able to accept
things that you now say aren't legal, but they're not out of
conformance if they do.
2) While there are a few documents around that use a scheme as part of
a relative URL, there aren't many, and, for the most part, I think
they are mistakes! Thus, this doesn't have a significant impact on
current practice.
Issue 4: I just think this might be an item that is more reasonably
specified in the HTML specification than the 'relative URL'
specification. I don't think your "Most useful RFC's have similar
appendices for examples" is factual (well, survey RFCs and see how
many have appendices at all, for example), and is incorrect in that
the appendix isn't an example, but a further specification.
Issue 4: I question this assertion:
"Since the URL spec has chosen to allow reserved
characters to have different meanings for each URL scheme, the
algorithm must be based upon each scheme."
The antecedent "Since the URL spec..." is true, but the consequence is
not ("the algorithm must be based upon each scheme"). In particular,
all that is necessary is to assert that "relative URLs only work with
URL schemes that reserve `/' to denote hierarchy, and where any
initial '//' denotes the introduction of syntax extending to a
following '/'.
Issue 6: I don't believe the statement of the issue (that Ascii 0x24
gets rendered as the British pound sign). ASCII defines 0x24 as a
dollar sign. Now, someone rendering URLs with some character set other
than ASCII might get different characters, but that would be true if
they rendered them with EBCDIC too.