3c3 < Expires May 27, 1995 November 27, 1994 --- > Expires July 9, 1995 January 9, 1995 7c7 < --- > 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 , 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 < . Relative components are resolved from left-to-right, < according to the rules given in Section 4. --- > . 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 * 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 * 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 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 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 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 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: 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 is non-empty, we skip to > Step 7. Otherwise, the embedded URL inherits the > (if any) of the base URL. 486,487c421,422 < a) If the embedded URL's 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 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 is non-empty, we skip to > step 7; otherwise, it inherits the 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 is non-empty, we skip to > step 7; otherwise, it inherits the 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 is empty, it < inherits the of the base URL (if any); and, < < c) If the embedded URL's is empty, it inherits < the 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 "/..", that < "/.." is removed. --- > d) If the path ends with "/..", that "/.." > 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 < --- > 556c484 < ?y = --- > ?y = 558a487,493 > #s = > g#s = > g#s/./x = > g?y#s = > ;x = > g;x = > g;x?y#s = 564a500 > ../../ = 568a505 > <> = [an empty reference] 574a512,515 > g. = > .g = > g.. = > ..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. > > > [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. /pub/gopher/gopher_protocol/Gopher+/Gopher+.txt>, July 1993. > > [3] T. Berners-Lee, "Universal Resource Identifiers in WWW: 618c582 < , June 1994. --- > CERN, June 1994. 620,623c584,587 < [2] Berners-Lee, T., Masinter, L., and McCahill, M., Editors, < "Uniform Resource Locators (URL)", Internet-Draft (work in < progress), , 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. > 625,627c589,592 < [3] Postel, J. and Reynolds, J.K., "File Transfer Protocol (FTP)", < STD 9, RFC 959, , < October 1985. --- > [5] T. Berners-Lee and D. Connolly, "HyperText Markup Language > Specification -- 2.0", Work in Progress, MIT, HaL Computer > Systems, November 1994. > 629,631c594,597 < [4] Berners-Lee, T ., "Hypertext Transfer Protocol (HTTP)" , < CERN, , < 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. > 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, , < March 1993. --- > [7] D. H. Crocker, "Standard for the Format of ARPA Internet > Text Messages", STD 11, RFC 822, UDEL, August 1982. > 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, , 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. 645,647c608,611 < [7] Crocker, D. H., "Standard for the Format of ARPA Internet Text < Messages", STD 11, RFC 822, < , 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. > 649,653c613 < [8] Horton, M. and Adams, R., "Standard For Interchange of USENET < messages", RFC 1036, , < 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, , < February 1986. --- > RFC 977, UC San Diego & UC Berkeley, February 1986. > 658,659c618,621 < [10] Postel, J. and Reynolds, J.K., "TELNET Protocol Specification", < RFC 854, , May 1983. --- > [11] J. Kunze, "Functional Requirements for Internet Resource > Locators", Work in Progress, IS&T, UC Berkeley, November 1994. > 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, < , < April 1990. --- > [12] B. C. Neuman and S. Augart, "The Prospero Protocol", > USC/Information Sciences Institute, June 1993. > 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, < , June 1994. --- > [13] J. Postel and J. K. Reynolds, "TELNET Protocol Specification", > RFC 854, USC/Information Sciences Institute, May 1983. > 672,675c632,634 < [13] Neuman, B.C., and Augart, S. "The Prospero Protocol", < USC Information Sciences Institute, , < June 1993. --- > [14] J. Postel and J. K. Reynolds, "File Transfer Protocol (FTP)", > STD 9, RFC 959, USC/Information Sciences Institute, October 1985. > 677,679c636,640 < [14] Berners-Lee, T., Connolly, D., et al. "HyperText Markup Language < Specification -- 2.0", Internet-Draft (work in progress), < , 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. > 681,685d641 < [15] Kunze, J., "Functional Requirements for Internet Resource < Locators", Internet-Draft (work in progress), < , 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