- From: Roy T. Fielding <fielding@avron.ICS.UCI.EDU>
- Date: Mon, 09 Jan 1995 14:10:37 -0800
- To: uri@bunyip.com
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
Received on Monday, 9 January 1995 17:18:35 UTC