To: uri@bunyip.com
Subject: Outstanding Issues for Relative URL draft
Date: Fri, 16 Sep 1994 03:33:57 -0700
From: "Roy T. Fielding" <fielding@avron.ICS.UCI.EDU>
Message-Id: <9409160334.aa22711@paris.ics.uci.edu>
I am in the process of updating the Internet-Draft for Relative URLs
<URL:ftp://ds.internic.net/internet-drafts/draft-ietf-uri-relative-url-00.txt>
and would like to invite more comments before issuing a new draft.
Here is my list of outstanding issues. Please tell me if I have left
something out. If you believe an issue is not an issue, or is worded
incorrectly, or is something you disagree with, please let us all know
by responding to <uri@bunyip.com> with your comments.
ISSUE 1. Update references to draft URL 07 (including section numbers, etc.)
(no debate here)
ISSUE 2. Should relative URLs which start with "scheme:" ALWAYS be considered
absolute, even when the "scheme:" is the same as the Base URL?
PRO: Simplifies the resolution algorithm (slightly).
Prevents clueless authors from using a "scheme:" even when
they don't need to.
CON: Breaks with existing practice.
The ability to specify a "scheme:" is only a side-effect of the
parsing/resolution algorithm -- this change would just cause
abnormal URLs to fail.
STATUS: The current spec contains a paragraph which warns against this
kind of abnormal relative URL. The editor considers this
sufficient. Members who disagree should post to the list --
it will be changed if there is a clear consensus for doing so.
ISSUE 3. Should the appendix on the use of <BASE ...> in HTML be
removed from the Relative URL spec?
PRO: This is an HTML issue and not a URL issue.
There are many applications for relative URLs outside of HTML
(e.g., in Adobe Acrobat files with hyperlinks).
CON: The appendix provides a useful example for people not familiar
with the WWW and complements the section on determining
a base URL. It does not form a part of the Relative URL spec.
Most useful RFC's have similar appendices for examples.
STATUS: The appendix will remain in the spec.
ISSUE 4. It seems possible to define relative URLs independently of the
scheme to which they are relative, but to point out that the
algorithm for resolving a relative URL against an absolute one
won't work with some schemes like 'telnet' or 'news' or 'mailto',
will work with 'http', and may or may not work with 'gopher',
depending on the mood of the gopher server's implementation.
PRO: Vastly simplifies the resolution algorithm.
CON: It won't work. Parsing and resolving a URL (relative or absolute)
requires that the algorithm be able to find the beginning and end
of the URL path. 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 best we can do is
group the schemes into sets (which is what the current spec does)
and parse based upon those sets.
STATUS: This change will not be made unless the URL spec is changed to
allow scheme-independent parsing.
ISSUE 5. In section 2.2, the BNF for relativeURL makes this relative URL
impossible:
foo.html
The problem is with
[ "/" path ]
being a single option. Note that saying
... net_loc ] [ "/" ] [ path ]
doesn't work either, because if both net_loc and
path are present, "/" must also be present.
PRO: This is a bug in the BNF and should be fixed.
STATUS: It will be fixed (once I figure out how). Suggestions are welcome.
ISSUE 6. In Sect. 2.2, non-terminal safe, the $ symbol, ASCII 0x24, gets
rendered as the British pound (as in sterling) sign in the U.K.
That would seem to make it less than "safe".
STATUS: The Relative URL BNF uses the same terminology and character
sets as the URL spec. The question of whether or not "$" is
"safe" should be decided within the context of the URL spec.
ISSUE 7. Two minor typos:
1) Sect. 2, first sentence:
... of the URL may be missing and certain path ...
^-- insert ,
2) Sect. 3.3, first sentence:
If neither an ... nor a ... are present, ...
^^^- change to "is"
STATUS: These will be changed.
That's it. If you know of something else, send it to the list.
......Roy Fielding ICS Grad Student, University of California, Irvine USA
<fielding@ics.uci.edu>
<URL:http://www.ics.uci.edu/dir/grad/Software/fielding>