# Relative URL diffs (draft 02 to 03)

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

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Paul Hoffman: "Second round for new URL scheme (mailserver)"
- Previous message: Gunter: "trigram vector for document similarity"

    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

     Next message: Paul Hoffman: "Second round for new URL scheme (mailserver)"
     Previous message: Gunter: "trigram vector for document similarity"