Relative URL diffs (draft 02 to 03)

Roy T. Fielding (fielding@avron.ICS.UCI.EDU)
Mon, 09 Jan 1995 14:10:37 -0800


To: uri@bunyip.com
Subject: Relative URL diffs (draft 02 to 03)
Date: Mon, 09 Jan 1995 14:10:37 -0800
From: "Roy T. Fielding" <fielding@avron.ICS.UCI.EDU>
Message-Id:  <9501091410.aa22761@paris.ics.uci.edu>

3c3
< Expires May 27, 1995                                  November 27, 1994
---
> Expires July 9, 1995                                    January 9, 1995
7c7
<                  <draft-ietf-uri-relative-url-02.txt>
---
>                  <draft-ietf-uri-relative-url-03.txt>
25,27c25,27
<    Drafts Shadow Directories on ds.internic.net (US East Coast),
<    nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
<    munnari.oz.au (Pacific Rim).
---
>    Drafts Shadow Directories on ftp.is.co.za (Africa),
>    nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
>    ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
38c38
<    Uniform Resource Locators (URLs) are a compact representation of the
---
>    A Uniform Resource Locator (URL) is a compact representation of the
42,48c42,48
<    context of that base document's retrieval, including the access
<    scheme, network location, and parts of the url-path.  In situations
<    where the base URL is well-defined and known to the parser (human or
<    machine), it is useful to be able to embed URL references which
<    inherit that context rather than re-specifying it in every instance.
<    This document defines the syntax and semantics for such Relative
<    Uniform Resource Locators.
---
>    context of that base document's retrieval, including the scheme,
>    network location, and parts of the url-path.  In situations where the
>    base URL is well-defined and known to the parser (human or machine),
>    it is useful to be able to embed URL references which inherit that
>    context rather than re-specifying it in every instance.  This
>    document defines the syntax and semantics for such Relative Uniform
>    Resource Locators.
56,57c56,57
<    RFC 1630 [1].  This document is a companion to the Internet-Draft
<    "Uniform Resource Locators (URL)" [2], which specifies the
---
>    RFC 1630 [3].  This document is a companion to RFC 1738, 
>    "Uniform Resource Locators (URL)" [4], which specifies the
64,71c64,66
<    of the location and access method for a resource available via the
<    Internet relative to an absolute base URL.  The name space of
<    relative URLs is a superset of that defined in [2] for Uniform
<    Resource Locators, in that all absolute URLs can be interpreted
<    consistently relative to any Internet-accessible resource.  For the
<    sake of clarity, however, this document will only term "relative"
<    those URLs which obtain global scope only when interpreted relative
<    to a separate base URL.
---
>    of the location of a resource relative to an absolute base URL.
>    The syntax of relative URLs is a subset of that defined for
>    Uniform Resource Locators.
80,85c75,81
<    be known from the context of the base document's retrieval, 
<    including the access scheme, network location, and parts of the
<    URL path.  In situations where the base URL is well-defined and
<    known, it is useful to be able to embed a URL reference which
<    inherits that context rather than re-specifying it within each
<    instance.
---
>    be known from the context of the base document's retrieval,
>    including the scheme, network location, and parts of the URL path.
>    In situations where the base URL is well-defined and known, it is
>    useful to be able to embed a URL reference which inherits that
>    context rather than re-specifying it within each instance.
>    Similarly, relative URLs can be used within data-entry dialogs to
>    decrease the number of characters necessary to describe a location.
95c91
<    independent of their location and/or access scheme.  For instance,
---
>    independent of their location and access scheme.  For instance,
99,100c95,96
<    access schemes. Furthermore, document trees can be moved, as a whole,
<    without changing any of the embedded URLs. Experience within the
---
>    schemes. Furthermore, document trees can be moved, as a whole,
>    without changing any of the embedded URLs.  Experience within the
107,112c103,109
<    The syntax for relative URLs is the same as that for absolute URLs
<    [2], with the exception that portions of the URL may be missing, and
<    certain path components ("." and "..") have a special meaning when
<    interpreting a relative URL path.  Although this document does not
<    seek to define the overall URL syntax, some discussion of it is
<    necessary in order to describe the parsing of relative URLs.
---
>    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. 
113a111,120
>    Although this document does not seek to define the overall URL
>    syntax, some discussion of it is necessary in order to describe the
>    parsing of relative URLs.  In particular, base documents can only
>    make use of relative URLs when their base URL fits within the generic
>    syntax described below.  Although some URL schemes do not require
>    this generic syntax, it is assumed that any document which contains
>    a relative reference does have a base URL that obeys the syntax.
>    In other words, relative URLs cannot be used within documents that
>    have abnormal base URLs.
> 
116,121c123,128
<    Like absolute URLs, relative URL syntax is dependent upon the access
<    scheme.  Some schemes use "?" and ";" to indicate special reserved
<    components, while others just consider them to be part of the path.
<    However, there is enough uniformity in the syntax to allow a parser
<    to resolve relative URLs based upon a few syntactic categories.
<    These categories are described in Section 2.3.
---
>    The URL syntax is dependent upon the scheme.  Some schemes use
>    reserved characters like "?" and ";" to indicate special components,
>    while others just consider them to be part of the path.  However,
>    there is enough uniformity in the use of URLs to allow a parser
>    to resolve relative URLs based upon a single, generic syntax.
>    This generic syntax consists of six components:
123,124d129
<    In general, the relative URL syntax consists of six components:
< 
127,129c132,134
<    each of which may be absent or may be disallowed by a particular
<    scheme.  They are defined as follows (a complete BNF is provided in
<    Section 2.2):
---
>    each of which, except <scheme>, may be absent from a particular URL.
>    These components are defined as follows (a complete BNF is provided
>    in Section 2.2):
131c136
<       scheme ":"   ::= access scheme name, as per Section 2.1 of [2].
---
>       scheme ":"   ::= scheme name, as per Section 2.1 of [4].
134c139
<                        Section 3.1 of [2].
---
>                        Section 3.1 of [4].
136c141
<       "/" path     ::= URL path, as per Section 3.1 of [2].
---
>       "/" path     ::= URL path, as per Section 3.1 of [4].
139c144
<                        Section 3.2.2 of [2]).
---
>                        Section 3.2.2 of [4]).
141c146
<       "?" query    ::= query information, as per Section 3.3 of [2].
---
>       "?" query    ::= query information, as per Section 3.3 of [4].
143,144c148
<       "#" fragment ::= fragment identifier (currently only used within
<                        the World-Wide Web initiative).
---
>       "#" fragment ::= fragment identifier.
148,149c152
<    <params>.  Relative components are resolved from left-to-right,
<    according to the rules given in Section 4.
---
>    <params>.
155,159c158,162
<    "|" is used to designate alternatives, and brackets "[]" are used
<    around optional or repeated elements. Briefly, literals are quoted
<    with "", optional elements are enclosed in [brackets], and elements
<    may be preceded with <n>* to designate n or more repetitions of the
<    following element; n defaults to 0.
---
>    "|" is used to designate alternatives.  Briefly, literals are quoted
>    with "", parentheses "(" and ")" are used to group elements, optional
>    elements are enclosed in [brackets], and elements may be preceded
>    with <n>* to designate n or more repetitions of the following
>    element; n defaults to 0.
161,164c164
<    Because relative URLs are parsed within the context of the base URL,
<    this BNF is not sufficient to completely specify the allowed syntax
<    within any given context.  Section 2.4 describes a context-sensitive
<    parsing algorithm which disambiguates the grammar.
---
>    URL         = ( absoluteURL | relativeURL ) [ "#" fragment ]
165a166
>    absoluteURL = scheme ":" *( uchar | reserved )
167,168c168
<    relativeURL = [ absoluteURL | location | abs_path | rel_path ]
<                  [ "#" fragment ]
---
>    relativeURL = net_path | abs_path | rel_path
170,171c170
<    absoluteURL = scheme ":" *[ uchar | reserved ]
<    location    = "//" net_loc [ "/" rel_path ]
---
>    net_path    = "//" net_loc [ abs_path ]
175,176c174,176
<    path        = segment *[ "/" segment ]
<    segment     = *[ pchar | ";" ]
---
>    path        = fsegment *( "/" segment )
>    fsegment    = 1*pchar
>    segment     =  *pchar
178,179c178,179
<    params      = param *[ ";" param ]
<    param       = *[ pchar | "/" ]
---
>    params      = param *( ";" param )
>    param       = *( pchar | "/" )
181,184c181,184
<    scheme      = 1*[ alpha | digit | "+" | "-" | "." ]
<    net_loc     =  *[ pchar | ";" ]
<    query       =  *[ uchar | reserved ]
<    fragment    =  *[ uchar | reserved ]
---
>    scheme      = 1*( alpha | digit | "+" | "-" | "." )
>    net_loc     =  *( pchar | ";" | "?" )
>    query       =  *( uchar | reserved )
>    fragment    =  *( uchar | reserved )
186c186
<    pchar       = [ uchar | "?" | ":" | "@" | "&" | "=" ]
---
>    pchar       = uchar | ":" | "@" | "&" | "="
214,219c214,219
<    Each URL access scheme has its own rules regarding the presence or
<    absence of the syntactic components described in Section 2.1 and 2.2.
<    However, there is enough commonality among the schemes to be able
<    to group them into just a few categories.  These categories are
<    sufficiently general to allow new schemes to be added without 
<    substantial changes to the algorithm for resolving relative URLs.
---
>    Each URL scheme has its own rules regarding the presence or absence
>    of the syntactic components described in Section 2.1 and 2.2.
>    In addition, some schemes are never appropriate for use with relative
>    URLs.  However, since relative URLs will only be used within contexts
>    in which they are useful, these scheme-specific differences can be
>    ignored by the resolution process.
221,222c221,223
<    Within this section, we include as examples only those schemes 
<    which have a defined URL syntax in [2].  This includes:
---
>    Within this section, we include as examples only those schemes that
>    have a defined URL syntax in [4].  The following schemes are never
>    used with relative URLs:
224,226d224
<       ftp        File Transfer Protocol [3]
<       http       Hypertext Transfer Protocol [4]
<       gopher     Gopher and Gopher+ Protocols [5, 6]
228,233c226
<       news       USENET news [8]
<       nntp       USENET news using NNTP access [9]
<       telnet     TELNET Protocol for Interactive Sessions [10]
<       wais       Wide Area Information Servers Protocol [11,12]
<       file       Host-specific Files
<       prospero   Prospero Directory Service [13]
---
>       telnet     TELNET Protocol for Interactive Sessions [13]
235,239c228,231
<    It is recommended that new schemes include a description of their
<    membership in the following categories when they are registered,
<    as per Section 4 of [2].  Membership in the five categories is 
<    described in terms of named sets: Uses-Netloc, Non-Hierarchical,
<    Uses-Params, Uses-Query, and Uses-Fragment.
---
>    Some URL schemes allow the use of reserved characters for purposes
>    outside the generic grammar given above.  However, such use is rare.
>    Relative URLs can be used with these schemes whenever the applicable
>    base URL is restricted to the generic syntax.
241c233,237
< 2.3.1  The Uses-Netloc Set
---
>       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]
243,247c239,240
<    The Uses-Netloc set includes those access schemes which use the
<    Common Internet Scheme Syntax described in Section 3.1 of [2], where
<    the network location and/or login information starts with a
<    double-slash "//" to indicate its presence, and continues until the
<    following slash "/", if any.
---
>    Finally, the following schemes can always be parsed using the generic
>    syntax.
249,250c242,244
<       Uses-Netloc = {ftp, http, gopher, nntp, telnet, wais,
<                      file, prospero}
---
>       file       Host-specific Files
>       ftp        File Transfer Protocol [14]
>       http       Hypertext Transfer Protocol [6]
252c246,249
< 2.3.2  The Non-Hierarchical Set
---
>    It is recommended that new schemes be designed to be parsable via
>    the generic syntax if they are intended to be used with relative
>    URLs.  A description of the allowed relative forms should be included
>    when a new scheme is registered, as per Section 4 of [4].
254,310d250
<    The Non-Hierarchical set includes those access schemes which do not
<    use "/" to indicate hierarchical segments in the URL path.
< 
<       Non-Hierarchical = {gopher, wais, mailto, news, telnet, prospero}
< 
<    When resolving relative paths for schemes not in the Non-Hierarchical
<    set, the complete path segments ".." and "." have a significance
<    reserved for representing the path hierarchy, indicating up-one-level
<    and current-level, respectively.
< 
< 2.3.3  The Uses-Params Set
< 
<    The Uses-Params set includes those access schemes which allow the
<    semicolon ";" character to separate object parameters from the
<    URL path.  There may be more than one parameter, each being
<    separated by a semicolon ";".
< 
<       Uses-Params = {ftp, http, prospero}
< 
< 2.3.4  The Uses-Query Set
< 
<    The Uses-Query set includes those access schemes which allow the
<    question mark "?" character to separate query information from the
<    URL path.
< 
<       Uses-Query = {http, wais}
< 
< 2.3.5  The Uses-Fragment Set
< 
<    The Uses-Fragment set includes those access schemes which allow the
<    crosshatch "#" character to separate a fragment identifier from
<    the rest of the URL.  Within systems that use fragment identifiers,
<   
<       Uses-Fragment = {ftp, http, gopher, news, nntp, wais,
<                        file, prospero}
< 
<    Unlike the other sets, however, the fragment identifier is only
<    reserved within systems which use it.  Outside of those systems,
<    Uses-Fragment is equal to the empty set.
< 
< 2.3.6.  Summary of Categories by Scheme
< 
<                  Uses-   Non-Hier  Uses-    Uses-    Uses-
<                  Netloc  archical  Params   Query   Fragment
<                .--------------------------------------------.
<       ftp      |  XXXX  |        |  XXXX  |        |  XXXX  |
<       http     |  XXXX  |        |  XXXX  |  XXXX  |  XXXX  |
<       gopher   |  XXXX  |  XXXX  |        |        |  XXXX  |
<       mailto   |        |  XXXX  |        |        |        |
<       news     |        |  XXXX  |        |        |  XXXX  |
<       nntp     |  XXXX  |        |        |        |  XXXX  |
<       telnet   |  XXXX  |  XXXX  |        |        |        |
<       wais     |  XXXX  |  XXXX  |        |  XXXX  |  XXXX  |
<       file     |  XXXX  |        |        |        |  XXXX  |
<       prospero |  XXXX  |  XXXX  |  XXXX  |        |  XXXX  |
<                `--------------------------------------------'
< 
314c254
<    relative URL syntax of Section 2.2 and to describe the algorithm for
---
>    generic URL syntax of Section 2.2 and to describe the algorithm for
320c260
<    listed in the order in which they must be applied by the parser.
---
>    listed in the order in which they would be applied by the parser.
322c262
< 2.4.1.  Parsing the Scheme
---
> 2.4.1.  Parsing the Fragment Identifier
324,335d263
<    If the parse string contains a colon ":" after the first character
<    and before any characters not allowed as part of a scheme name
<    (i.e. any not an alphanumeric, plus "+", period ".", or hyphen "-"),
<    the scheme of the URL is the substring of characters up to but not
<    including the first colon.  These characters and the colon are then
<    removed from the parse string before continuing. 
<  
< 2.4.2.  Parsing the Fragment Identifier
< 
<    If the scheme is not a member of the Uses-Fragment set, this section
<    is skipped.
< 
337,338c265,266
<    substring after the last (right-most) crosshatch "#" and up to the
<    end of the parse string is the fragment identifier.  If the
---
>    substring after the first (left-most) crosshatch "#" and up to the
>    end of the parse string is the <fragment> identifier.  If the
348a277,285
> 2.4.2.  Parsing the Scheme
> 
>    If the parse string contains a colon ":" after the first character
>    and before any characters not allowed as part of a scheme name
>    (i.e. any not an alphanumeric, plus "+", period ".", or hyphen "-"),
>    the <scheme> of the URL is the substring of characters up to but not
>    including the first colon.  These characters and the colon are then
>    removed from the parse string before continuing. 
>  
351,353d287
<    If the scheme is not a member of the Uses-Netloc set, this section
<    is skipped.
< 
364,366d297
<    If the scheme is not a member of the Uses-Query set, this section
<    is skipped.
< 
369c300
<    end of the parse string is the query information.  If the question
---
>    end of the parse string is the <query> information.  If the question
377,379d307
<    If the scheme is not a member of the Uses-Params set, this section
<    is skipped.
< 
390c318
<    the URL path and the slash "/" that may precede it.  Even though
---
>    the URL <path> and the slash "/" that may precede it.  Even though
405c333
<    Within certain document content-types, the base URL of the document
---
>    Within certain document media types, the base URL of the document
409c337
<    others through schemes which do not support relative addressing
---
>    others through protocols other than their usual retrieval context
413,414c341,342
<    content-type, the base URL can be embedded.  However, an example of
<    how this is done for the Hypertext Markup Language (HTML) [14] is
---
>    media type, the base URL can be embedded.  However, an example of
>    how this is done for the Hypertext Markup Language (HTML) [5] is
419,422c347,350
<    For access schemes which make use of message headers like those
<    described in RFC 822 [7], a second method for identifying the base
<    URL of a document is to include that URL in the message headers.
<    It is recommended that the format of this header be:
---
>    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
>    document is to include that URL in the message headers.  It is
>    recommended that the format of this header be:
424c352
<       Base-URL: absoluteURL
---
>       Base-URL: "<" absoluteURL ">"
428c356
<       Base-URL: http://www.ics.uci.edu/Test/a/b/c
---
>       Base-URL: <http://www.ics.uci.edu/Test/a/b/c>
431a360,362
>    Any whitespace (including that used for line folding) inside the
>    angle brackets should be ignored.
> 
469c400,402
<            Section 3.
---
>            Section 3.  If the base URL is the empty string (unknown),
>            the embedded URL is interpreted as an absolute URL and
>            we are done.
471,474c404
<    Step 2: If the base URL is the empty string (unknown), the embedded
<            URL is interpreted as an absolute URL and we are done.
< 
<    Step 3: Both the base and embedded URLs are parsed into their
---
>    Step 2: Both the base and embedded URLs are parsed into their
477c407,411
<            a) If the embedded URL starts with a scheme name, it is
---
>            a) If the embedded URL is entirely empty, it inherits the
>               entire base URL (i.e. is set equal to the base URL)
>               and we are done.
> 
>            b) If the embedded URL starts with a scheme name, it is
480c414
<            b) Otherwise, the embedded URL inherits the scheme of
---
>            c) Otherwise, the embedded URL inherits the scheme of
483,484c417,419
<    Step 4: If the scheme is a member of the Uses-Netloc set
<            (Section 2.3.1), then
---
>    Step 3: If the embedded URL's <net_loc> is non-empty, we skip to
>            Step 7.  Otherwise, the embedded URL inherits the <net_loc>
>            (if any) of the base URL.
486,487c421,422
<            a) If the embedded URL's <net_loc> is non-empty, we skip to
<               Step 8.
---
>    Step 4: If the embedded URL path is preceded by a slash "/", the
>            path is not relative and we skip to Step 7.
489,490c424,426
<            b) Otherwise, the embedded URL inherits the <net_loc> of the
<               base URL.
---
>    Step 5: If the embedded URL path is empty (and not preceded by a
>            slash), then the embedded URL inherits the base URL path,
>            and
492,493c428,430
<    Step 5: If the embedded URL path is preceded by a slash "/", the
<            path is not relative and we skip to Step 8.
---
>            a) if the embedded URL's <params> is non-empty, we skip to
>               step 7; otherwise, it inherits the <params> of the base
>               URL (if any) and
495,496c432,434
<    Step 6: If the embedded URL path is empty (and not preceded by a
<            slash), then
---
>            b) if the embedded URL's <query> is non-empty, we skip to
>               step 7; otherwise, it inherits the <query> of the base
>               URL (if any) and we skip to step 7.
498,508c436
<            a) The embedded URL inherits the base URL path; and,
< 
<            b) If the embedded URL's <params> is empty, it
<               inherits the <params> of the base URL (if any); and,
< 
<            c) If the embedded URL's <query> is empty, it inherits
<               the <query> of the base URL (if any); and,
< 
<            d) We skip to Step 8.
< 
<    Step 7: The last path segment of the base URL's path (anything
---
>    Step 6: The last segment of the base URL's path (anything
512c440
<            then applied, in order, to the new URL path:
---
>            then applied, in order, to the new path:
517c445
<            b) If the URL path ends with "." as a complete path segment,
---
>            b) If the path ends with "." as a complete path segment,
526,527c454,455
<            d) If the URL path ends with "<segment>/..", that
<               "<segment>/.." is removed.
---
>            d) If the path ends with "<segment>/..", that "<segment>/.."
>               is removed.
529c457
<    Step 8: The resulting URL components, including any inherited from
---
>    Step 7: The resulting URL components, including any inherited from
537,538c465,466
<    to that URL.  Fragment identifiers are never inherited from the
<    base URL.
---
>    to that URL.  Fragment identifiers are only inherited from the base
>    URL when the entire embedded URL is empty.
544c472
<       <URL:http://a/b/c/d>
---
>       <URL:http://a/b/c/d;p?q#f>
556c484
<       ?y         = <URL:http://a/b/c/d?y>
---
>       ?y         = <URL:http://a/b/c/d;p?y>
558a487,493
>       #s         = <URL:http://a/b/c/d;p?q#s>
>       g#s        = <URL:http://a/b/c/g#s>
>       g#s/./x    = <URL:http://a/b/c/g#s/./x>
>       g?y#s      = <URL:http://a/b/c/g?y#s>
>       ;x         = <URL:http://a/b/c/d;x>
>       g;x        = <URL:http://a/b/c/g;x>
>       g;x?y#s    = <URL:http://a/b/c/g;x?y#s>
564a500
>       ../../     = <URL:http://a/>
568a505
>       <>         = <URL:http://a/b/c/d;p?q#f>    [an empty reference]
574a512,515
>       g.         = <URL:http://a/b/c/g.>
>       .g         = <URL:http://a/b/c/.g>
>       g..        = <URL:http://a/b/c/g..>
>       ..g        = <URL:http://a/b/c/..g>
592a534,541
>    There is an ambiguity in the semantics for the ftp URL scheme
>    regarding the use of a trailing slash ("/") character and/or a
>    parameter ";type=d" to indicate a resource that is an ftp directory.
>    If the result of retrieving that directory includes embedded 
>    relative URLs, it is necessary that the base URL path for that result
>    include a trailing slash.  For this reason, it is recommended that
>    the ";type=d" parameter value not be used.
> 
595c544,547
<    None.
---
>    There are no security considerations in the use or parsing of relative
>    URLs.  However, once a relative URL has been resolved to its absolute
>    form, the same security considerations apply as those described in
>    RFC 1738 [4].
601,603c553,555
<    described as "Partial URLs" in RFC 1630 [1].  That description was
<    expanded for inclusion as an appendix for the Internet-Draft
<    "Uniform Resource Locators (URL)" [2].  However, after further
---
>    described as "Partial URLs" in RFC 1630 [3].  That description was
>    expanded for inclusion as an appendix for an early draft of RFC 1738,
>    "Uniform Resource Locators (URL)" [4].  However, after further
608c560
<    Resource Locators as stated in [15].  It has benefited greatly from
---
>    Resource Locators as stated in [11].  It has benefited greatly from
615c567,579
<    [1] Berners-Lee, T., "Universal Resource Identifiers in WWW:
---
>    [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:
618c582
<        <URL:ftp://ds.internic.net/rfc/rfc1630.txt>, June 1994.
---
>        CERN, June 1994. <URL:ftp://ds.internic.net/rfc/rfc1630.txt>
620,623c584,587
<    [2] Berners-Lee, T., Masinter, L., and McCahill, M., Editors,
<        "Uniform Resource Locators (URL)", Internet-Draft (work in
<        progress), <URL:ftp://ds.internic.net/internet-drafts/
<        draft-ietf-uri-url-08.txt>, October 1994.
---
>    [4] T. Berners-Lee, L. Masinter, and M. McCahill, Editors,
>        "Uniform Resource Locators (URL)", RFC 1738, CERN, 
>        Xerox Corporation, University of Minnesota, December 1994. 
>        <URL:ftp://ds.internic.net/rfc/rfc1738.txt>
625,627c589,592
<    [3] Postel, J. and Reynolds, J.K., "File Transfer Protocol (FTP)",
<        STD 9, RFC 959, <URL:ftp://ds.internic.net/rfc/rfc959.txt>,
<        October 1985.
---
>    [5] T. Berners-Lee and D. Connolly, "HyperText Markup Language
>        Specification -- 2.0", Work in Progress, MIT, HaL Computer
>        Systems, November 1994.
>        <URL:http://www.ics.uci.edu/pub/ietf/html/>
629,631c594,597
<    [4] Berners-Lee, T ., "Hypertext Transfer Protocol (HTTP)" ,
<        CERN, <URL:ftp://info.cern.ch/pub/www/doc/http-spec.txt.Z>,
<        November 1993.
---
>    [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/>
633,637c599,601
<    [5] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D.,
<        Torrey, D., and Alberti, B., "The Internet Gopher Protocol:
<        A distributed document search and retrieval protocol",
<        RFC 1436, <URL:ftp://ds.internic.net/rfc/rfc1436.txt>,
<        March 1993.
---
>    [7] D. H. Crocker, "Standard for the Format of ARPA Internet
>        Text Messages", STD 11, RFC 822, UDEL, August 1982.
>        <URL:ftp://ds.internic.net/rfc/rfc822.txt>
639,643c603,606
<    [6] Anklesaria, F., Lindner, P., McCahill, M., Torrey, D.,
<        Johnson, D., and Alberti, B., "Gopher+: Upward compatible
<        enhancements to the Internet Gopher protocol",
<        University of Minnesota, <URL:ftp://boombox.micro.umn.edu
<        /pub/gopher/gopher_protocol/Gopher+/Gopher+.txt>, July 1993.
---
>    [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>
645,647c608,611
<    [7] Crocker, D. H., "Standard for the Format of ARPA Internet Text
<        Messages", STD 11, RFC 822,
<        <URL:ftp://ds.internic.net/rfc/rfc822.txt>, August 1982.
---
>    [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>
649,653c613
<    [8] Horton, M. and Adams, R., "Standard For Interchange of USENET
<        messages", RFC 1036, <URL:ftp://ds.internic.net/rfc/rfc1036.txt>,
<        December 1987.
< 
<    [9] Kantor, B. and Lapsley, P., "Network News Transfer Protocol:
---
>   [10] B. Kantor and P. Lapsley, "Network News Transfer Protocol:
655,656c615,616
<        RFC977, <URL:ftp://ds.internic.net/rfc/rfc977.txt>,
<        February 1986.
---
>        RFC 977, UC San Diego & UC Berkeley, February 1986.
>        <URL:ftp://ds.internic.net/rfc/rfc977.txt>
658,659c618,621
<   [10] Postel, J. and Reynolds, J.K., "TELNET Protocol Specification",
<        RFC 854, <URL:ftp://ds.internic.net/rfc/rfc854.txt>, May 1983.
---
>   [11] J. Kunze, "Functional Requirements for Internet Resource
>        Locators", Work in Progress, IS&T, UC Berkeley, November 1994.
>        <URL:ftp://ds.internic.net/internet-drafts/
>        draft-ietf-uri-irl-fun-req-02.txt>
661,665c623,626
<   [11] Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T., Wang, R.,
<        Sui, J., and Grinbaum, M., "WAIS Interface Protocol Prototype
<        Functional Specification", (v1.5), Thinking Machines Corporation, 
<        <URL:ftp://quake.think.com/pub/wais/doc/protspec.txt>,
<        April 1990.
---
>   [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>
667,670c628,630
<   [12] St. Pierre, M, Fullton, J., Gamiel, K., Goldman, J., Kahle, B.,
<        Kunze, J., Morris, H., and Schiettecatte, F.,
<        "WAIS over Z39.50-1988", RFC 1625,
<        <URL:ftp://ds.internic.net/rfc/rfc1625.txt>, June 1994.
---
>   [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>
672,675c632,634
<   [13] Neuman, B.C., and Augart, S. "The Prospero Protocol",
<        USC Information Sciences Institute, <URL:
<        ftp://prospero.isi.edu/pub/prospero/doc/prospero-protocol.PS.Z>,
<        June 1993.
---
>   [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>
677,679c636,640
<   [14] Berners-Lee, T., Connolly, D., et al. "HyperText Markup Language
<        Specification -- 2.0", Internet-Draft (work in progress),
<        <URL:ftp://www.ics.uci.edu/pub/ietf/html/>, November 1994.
---
>   [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>
681,685d641
<   [15] Kunze, J., "Functional Requirements for Internet Resource
<        Locators", Internet-Draft (work in progress),
<        <URL:ftp://ds.internic.net/internet-drafts/
<        draft-ietf-uri-irl-fun-req-01.txt>, July 1994.
< 
698c654
<    This Internet-Draft expires May 27, 1995.
---
>    This Internet-Draft expires July 9, 1995.
706c662
<    Language (HTML) [14] can include an embedded base URL.  This appendix
---
>    Language (HTML) [5] can include an embedded base URL.  This appendix