Relative URL diffs (draft 03 to 04)

Roy T. Fielding (fielding@avron.ICS.UCI.EDU)
Wed, 18 Jan 1995 09:05:53 -0800


To: uri@bunyip.com
Subject: Relative URL diffs (draft 03 to 04)
Date: Wed, 18 Jan 1995 09:05:53 -0800
From: "Roy T. Fielding" <fielding@avron.ICS.UCI.EDU>
Message-Id:  <9501180905.aa14978@paris.ics.uci.edu>

3c3
< Expires July 9, 1995                                    January 9, 1995
---
> Expires July 18, 1995                                  January 18, 1995
7c7
<                  <draft-ietf-uri-relative-url-03.txt>
---
>                  <draft-ietf-uri-relative-url-04.txt>
53,61d52
<    This work is derived from concepts introduced by the World-Wide Web
<    global information initiative, whose use of such objects dates from
<    1990 and is described in "Universal Resource Identifiers in WWW",
<    RFC 1630 [3].  This document is a companion to RFC 1738, 
<    "Uniform Resource Locators (URL)" [4], which specifies the
<    syntax and semantics of absolute URLs.  A URL is "absolute" if it
<    can be interpreted consistently and unambiguously, with global scope,
<    independent of any other URL.
< 
65,66c56,57
<    The syntax of relative URLs is a subset of that defined for
<    Uniform Resource Locators.
---
>    It is a companion to RFC 1738, "Uniform Resource Locators (URL)" [2],
>    which specifies the syntax and semantics of absolute URLs.
103,109c94,99
<    The syntax for relative URLs is a subset of that for absolute
<    URLs [4].  Relative URLs are distinct in that some prefix of the URL
<    is missing and certain path components ("." and "..") have a special
<    meaning when interpreting a relative path.  Because a relative URL
<    may appear in any context that could hold an absolute URL, systems
<    that support relative URLs must be able to recognize them as part
<    of the URL parsing process. 
---
>    The syntax for relative URLs is a shortened form of that for absolute
>    URLs [2], where some prefix of the URL is missing and certain path
>    components ("." and "..") have a special meaning when interpreting a
>    relative path.  Because a relative URL may appear in any context that
>    could hold an absolute URL, systems that support relative URLs must
>    be able to recognize them as part of the URL parsing process. 
119c109
<    have abnormal base URLs.
---
>    have unsuitable base URLs.
136c126
<       scheme ":"   ::= scheme name, as per Section 2.1 of [4].
---
>       scheme ":"   ::= scheme name, as per Section 2.1 of [2].
139c129
<                        Section 3.1 of [4].
---
>                        Section 3.1 of [2].
141c131
<       "/" path     ::= URL path, as per Section 3.1 of [4].
---
>       "/" path     ::= URL path, as per Section 3.1 of [2].
144c134
<                        Section 3.2.2 of [4]).
---
>                        Section 3.2.2 of [2]).
146c136
<       "?" query    ::= query information, as per Section 3.3 of [4].
---
>       "?" query    ::= query information, as per Section 3.3 of [2].
149a140,145
>    Note that the fragment identifier (and the "#" that precedes it) is
>    not considered part of the URL.  However, since it is commonly used
>    within the same string context as a URL, a parser must be able to
>    recognize the fragment when it is present and set it aside as part
>    of the parsing process.
> 
157c153
<    Locator syntax, using the conventions of RFC 822 [7], except that
---
>    Locator syntax, using the conventions of RFC 822 [5], except that
222c218
<    have a defined URL syntax in [4].  The following schemes are never
---
>    have a defined URL syntax in [2].  The following schemes are never
225,226c221,222
<       mailto     Electronic Mail [7]
<       telnet     TELNET Protocol for Interactive Sessions [13]
---
>       mailto     Electronic Mail
>       telnet     TELNET Protocol for Interactive Sessions
231c227
<    base URL is restricted to the generic syntax.
---
>    base URL follows the generic syntax.
233,237c229,233
<       gopher     Gopher and Gopher+ Protocols [1, 2]
<       news       USENET news [9]
<       nntp       USENET news using NNTP access [10]
<       prospero   Prospero Directory Service [12]
<       wais       Wide Area Information Servers Protocol [8,15]
---
>       gopher     Gopher and Gopher+ Protocols
>       news       USENET news
>       nntp       USENET news using NNTP access
>       prospero   Prospero Directory Service
>       wais       Wide Area Information Servers Protocol
243,244c239,240
<       ftp        File Transfer Protocol [14]
<       http       Hypertext Transfer Protocol [6]
---
>       ftp        File Transfer Protocol
>       http       Hypertext Transfer Protocol
249c245
<    when a new scheme is registered, as per Section 4 of [4].
---
>    when a new scheme is registered, as per Section 4 of [2].
342c338
<    how this is done for the Hypertext Markup Language (HTML) [5] is
---
>    how this is done for the Hypertext Markup Language (HTML) [3] is
347,348c343,344
<    For schemes which make use of message headers like those described
<    in RFC 822 [7], a second method for identifying the base URL of a
---
>    For protocols that make use of message headers like those described
>    in RFC 822 [5], a second method for identifying the base URL of a
352c348
<       Base-URL: "<" absoluteURL ">"
---
>       base  = "Base" ":" "<URL:" absoluteURL ">"
354c350
<    where "Base-URL" is case-insensitive.  For example,
---
>    where "Base" is case-insensitive.  For example,
356c352
<       Base-URL: <http://www.ics.uci.edu/Test/a/b/c>
---
>       Base: <URL:http://www.ics.uci.edu/Test/a/b/c>
364,365c360,361
<    Section 3.1) and a "Base-URL" message header are present, the
<    embedded base URL takes precedence.
---
>    Section 3.1) and a "Base" message header are present, the embedded
>    base URL takes precedence.
369c365
<    If neither an embedded base URL nor a "Base-URL" message header
---
>    If neither an embedded base URL nor a "Base" message header
386a383,392
> 3.5.  Base URL for Composite Media Types
> 
>    Composite media types, such as the "multipart/*" and "message/*"
>    media types defined by MIME (RFC 1521, [4]), require special
>    processing in order to determine the base URL of a component part.
>    For these types, the base URL of the composite entity should be
>    determined first; this base is then considered the default for any
>    component part that does not define its own base via one of the
>    methods described in Sections 3.1 and 3.2.
> 
472c478
<       <URL:http://a/b/c/d;p?q#f>
---
>       Base: <URL:http://a/b/c/d;p?q#f>
505c511,523
<       <>         = <URL:http://a/b/c/d;p?q#f>    [an empty reference]
---
>    Although the following abnormal examples are unlikely to occur
>    in normal practice, all URL parsers should be capable of resolving
>    them consistently.  Each example uses the same base as above.
> 
>    An empty reference resolves to the complete base URL:
> 
>       <>         = <URL:http://a/b/c/d;p?q#f>
> 
>    Parsers must be careful in handling the case where there are more
>    relative path ".." segments than there are hierarchical levels in
>    the base URL's path.  Note that the ".." syntax cannot be used to
>    change the <net_loc> of a URL.
> 
507,508c525,528
<       ./../g     = <URL:http://a/b/g>
<       ./g/.      = <URL:http://a/b/c/g/>
---
> 
>    Similarly, parsers must avoid treating "." and ".." as special when
>    they are not complete components of a relative path.
> 
510,511c530
<       g/./h      = <URL:http://a/b/c/g/h>
<       g/../h     = <URL:http://a/b/c/h>
---
>       /../g      = <URL:http://a/../g>
515a535,548
> 
>    Less likely are cases where the relative URL uses unnecessary or
>    nonsensical forms of the "." and ".." complete path segments.
> 
>       ./../g     = <URL:http://a/b/g>
>       ./g/.      = <URL:http://a/b/c/g/>
>       g/./h      = <URL:http://a/b/c/g/h>
>       g/../h     = <URL:http://a/b/c/h>
> 
>    Finally, some older parsers allow the scheme name to be present in
>    a relative URL if it is the same as the base URL scheme.  This is
>    considered to be a loophole in prior specifications of partial
>    URLs [1] and should be avoided by future parsers.
> 
519,522d551
<    Note that, although the abnormal examples are not likely to occur
<    for a normal relative URL, all URL parsers should be capable of
<    resolving them consistently.
< 
540c569,570
<    the ";type=d" parameter value not be used.
---
>    the ";type=d" parameter value not be used within contexts that allow
>    relative URLs.
547c577
<    RFC 1738 [4].
---
>    RFC 1738 [2].
553c583
<    described as "Partial URLs" in RFC 1630 [3].  That description was
---
>    described as "Partial URLs" in RFC 1630 [1].  That description was
555c585
<    "Uniform Resource Locators (URL)" [4].  However, after further
---
>    "Uniform Resource Locators (URL)" [2].  However, after further
560c590
<    Resource Locators as stated in [11].  It has benefited greatly from
---
>    Resource Locators as stated in [6].  It has benefited greatly from
567,579c597
<    [1] F. Anklesaria, M. McCahill, P. Lindner, D. Johnson,
<        D. Torrey, and B. Alberti, "The Internet Gopher Protocol:
<        A distributed document search and retrieval protocol",
<        RFC 1436, University of Minnesota, March 1993.
<        <URL:ftp://ds.internic.net/rfc/rfc1436.txt>
< 
<    [2] F. Anklesaria, P. Lindner, M. McCahill, D. Torrey,
<        D. Johnson, and B. Alberti, "Gopher+: Upward compatible
<        enhancements to the Internet Gopher protocol", University of
<        Minnesota, July 1993.  <URL:ftp://boombox.micro.umn.edu
<        /pub/gopher/gopher_protocol/Gopher+/Gopher+.txt>, July 1993.
< 
<    [3] T. Berners-Lee, "Universal Resource Identifiers in WWW:
---
>    [1] T. Berners-Lee, "Universal Resource Identifiers in WWW:
584c602
<    [4] T. Berners-Lee, L. Masinter, and M. McCahill, Editors,
---
>    [2] T. Berners-Lee, L. Masinter, and M. McCahill, Editors,
589c607
<    [5] T. Berners-Lee and D. Connolly, "HyperText Markup Language
---
>    [3] T. Berners-Lee and D. Connolly, "HyperText Markup Language
594,597c612,615
<    [6] T. Berners-Lee, R. T. Fielding, and H. Frystyk Nielsen,
<        "Hypertext Transfer Protocol -- HTTP/1.0" , Work in Progress,
<        MIT, UC Irvine, CERN, December 1993.
<        <URL:http://www.ics.uci.edu/pub/ietf/http/>
---
>    [4] N. Borenstein and N. Freed, "MIME (Multipurpose Internet Mail
>        Extensions): Mechanisms for Specifying and Describing the Format
>        of Internet Message Bodies", RFC 1521, Bellcore, Innosoft,
>        September 1993.  <URL:ftp://ds.internic.net/rfc/rfc1521.txt>
599c617
<    [7] D. H. Crocker, "Standard for the Format of ARPA Internet
---
>    [5] D. H. Crocker, "Standard for the Format of ARPA Internet
603,618c621
<    [8] F. Davis, B. Kahle, H. Morris, J. Salem, T. Shen, R. Wang,
<        J. Sui, and M. Grinbaum, "WAIS Interface Protocol Prototype
<        Functional Specification", (v1.5), Thinking Machines Corporation,
<        April 1990. <URL:ftp://quake.think.com/pub/wais/doc/protspec.txt>
< 
<    [9] M. Horton and R. Adams, "Standard For Interchange of USENET
<        Messages", RFC 1036, AT&T Bell Laboratories, Center for
<        Seismic Studies, December 1987.
<        <URL:ftp://ds.internic.net/rfc/rfc1036.txt>
< 
<   [10] B. Kantor and P. Lapsley, "Network News Transfer Protocol:
<        A Proposed Standard for the Stream-Based Transmission of News",
<        RFC 977, UC San Diego & UC Berkeley, February 1986.
<        <URL:ftp://ds.internic.net/rfc/rfc977.txt>
< 
<   [11] J. Kunze, "Functional Requirements for Internet Resource
---
>    [6] J. Kunze, "Functional Requirements for Internet Resource
623,641d625
<   [12] B. C. Neuman and S. Augart, "The Prospero Protocol",
<        USC/Information Sciences Institute, June 1993.
<        <URL:ftp://prospero.isi.edu/pub/prospero/doc/
<        prospero-protocol.PS.Z>
< 
<   [13] J. Postel and J. K. Reynolds, "TELNET Protocol Specification",
<        RFC 854, USC/Information Sciences Institute, May 1983.
<        <URL:ftp://ds.internic.net/rfc/rfc854.txt>
< 
<   [14] J. Postel and J. K. Reynolds, "File Transfer Protocol (FTP)",
<        STD 9, RFC 959, USC/Information Sciences Institute, October 1985.
<        <URL:ftp://ds.internic.net/rfc/rfc959.txt>
< 
<   [15] M. St. Pierre, J. Fullton, K. Gamiel, J. Goldman, B. Kahle,
<        J. Kunze, H. Morris, and F. Schiettecatte,
<        "WAIS over Z39.50-1988", RFC 1625, WAIS, Inc., CNIDR,
<        Thinking Machines Corp., UC Berkeley, FS Consulting, June 1994.
<        <URL:ftp://ds.internic.net/rfc/rfc1625.txt>
< 
654c638
<    This Internet-Draft expires July 9, 1995.
---
>    This Internet-Draft expires July 18, 1995.
662c646
<    Language (HTML) [5] can include an embedded base URL.  This appendix
---
>    Language (HTML) [3] can include an embedded base URL.  This appendix