PageRenderTime 54ms CodeModel.GetById 17ms RepoModel.GetById 0ms app.codeStats 0ms

/docs/rfc1738.txt

https://bitbucket.org/nileshgr/cxxcms/
Plain Text | 1403 lines | 926 code | 477 blank | 0 comment | 0 complexity | 0f3b6b9122023d7d87547178eb3bacba MD5 | raw file
Possible License(s): GPL-3.0
  1. Network Working Group T. Berners-Lee
  2. Request for Comments: 1738 CERN
  3. Category: Standards Track L. Masinter
  4. Xerox Corporation
  5. M. McCahill
  6. University of Minnesota
  7. Editors
  8. December 1994
  9. Uniform Resource Locators (URL)
  10. Status of this Memo
  11. This document specifies an Internet standards track protocol for the
  12. Internet community, and requests discussion and suggestions for
  13. improvements. Please refer to the current edition of the "Internet
  14. Official Protocol Standards" (STD 1) for the standardization state
  15. and status of this protocol. Distribution of this memo is unlimited.
  16. Abstract
  17. This document specifies a Uniform Resource Locator (URL), the syntax
  18. and semantics of formalized information for location and access of
  19. resources via the Internet.
  20. 1. Introduction
  21. This document describes the syntax and semantics for a compact string
  22. representation for a resource available via the Internet. These
  23. strings are called "Uniform Resource Locators" (URLs).
  24. The specification is derived from concepts introduced by the World-
  25. Wide Web global information initiative, whose use of such objects
  26. dates from 1990 and is described in "Universal Resource Identifiers
  27. in WWW", RFC 1630. The specification of URLs is designed to meet the
  28. requirements laid out in "Functional Requirements for Internet
  29. Resource Locators" [12].
  30. This document was written by the URI working group of the Internet
  31. Engineering Task Force. Comments may be addressed to the editors, or
  32. to the URI-WG <uri@bunyip.com>. Discussions of the group are archived
  33. at <URL:http://www.acl.lanl.gov/URI/archive/uri-archive.index.html>
  34. Berners-Lee, Masinter & McCahill [Page 1]
  35. RFC 1738 Uniform Resource Locators (URL) December 1994
  36. 2. General URL Syntax
  37. Just as there are many different methods of access to resources,
  38. there are several schemes for describing the location of such
  39. resources.
  40. The generic syntax for URLs provides a framework for new schemes to
  41. be established using protocols other than those defined in this
  42. document.
  43. URLs are used to `locate' resources, by providing an abstract
  44. identification of the resource location. Having located a resource,
  45. a system may perform a variety of operations on the resource, as
  46. might be characterized by such words as `access', `update',
  47. `replace', `find attributes'. In general, only the `access' method
  48. needs to be specified for any URL scheme.
  49. 2.1. The main parts of URLs
  50. A full BNF description of the URL syntax is given in Section 5.
  51. In general, URLs are written as follows:
  52. <scheme>:<scheme-specific-part>
  53. A URL contains the name of the scheme being used (<scheme>) followed
  54. by a colon and then a string (the <scheme-specific-part>) whose
  55. interpretation depends on the scheme.
  56. Scheme names consist of a sequence of characters. The lower case
  57. letters "a"--"z", digits, and the characters plus ("+"), period
  58. ("."), and hyphen ("-") are allowed. For resiliency, programs
  59. interpreting URLs should treat upper case letters as equivalent to
  60. lower case in scheme names (e.g., allow "HTTP" as well as "http").
  61. 2.2. URL Character Encoding Issues
  62. URLs are sequences of characters, i.e., letters, digits, and special
  63. characters. A URLs may be represented in a variety of ways: e.g., ink
  64. on paper, or a sequence of octets in a coded character set. The
  65. interpretation of a URL depends only on the identity of the
  66. characters used.
  67. In most URL schemes, the sequences of characters in different parts
  68. of a URL are used to represent sequences of octets used in Internet
  69. protocols. For example, in the ftp scheme, the host name, directory
  70. name and file names are such sequences of octets, represented by
  71. parts of the URL. Within those parts, an octet may be represented by
  72. Berners-Lee, Masinter & McCahill [Page 2]
  73. RFC 1738 Uniform Resource Locators (URL) December 1994
  74. the chararacter which has that octet as its code within the US-ASCII
  75. [20] coded character set.
  76. In addition, octets may be encoded by a character triplet consisting
  77. of the character "%" followed by the two hexadecimal digits (from
  78. "0123456789ABCDEF") which forming the hexadecimal value of the octet.
  79. (The characters "abcdef" may also be used in hexadecimal encodings.)
  80. Octets must be encoded if they have no corresponding graphic
  81. character within the US-ASCII coded character set, if the use of the
  82. corresponding character is unsafe, or if the corresponding character
  83. is reserved for some other interpretation within the particular URL
  84. scheme.
  85. No corresponding graphic US-ASCII:
  86. URLs are written only with the graphic printable characters of the
  87. US-ASCII coded character set. The octets 80-FF hexadecimal are not
  88. used in US-ASCII, and the octets 00-1F and 7F hexadecimal represent
  89. control characters; these must be encoded.
  90. Unsafe:
  91. Characters can be unsafe for a number of reasons. The space
  92. character is unsafe because significant spaces may disappear and
  93. insignificant spaces may be introduced when URLs are transcribed or
  94. typeset or subjected to the treatment of word-processing programs.
  95. The characters "<" and ">" are unsafe because they are used as the
  96. delimiters around URLs in free text; the quote mark (""") is used to
  97. delimit URLs in some systems. The character "#" is unsafe and should
  98. always be encoded because it is used in World Wide Web and in other
  99. systems to delimit a URL from a fragment/anchor identifier that might
  100. follow it. The character "%" is unsafe because it is used for
  101. encodings of other characters. Other characters are unsafe because
  102. gateways and other transport agents are known to sometimes modify
  103. such characters. These characters are "{", "}", "|", "\", "^", "~",
  104. "[", "]", and "`".
  105. All unsafe characters must always be encoded within a URL. For
  106. example, the character "#" must be encoded within URLs even in
  107. systems that do not normally deal with fragment or anchor
  108. identifiers, so that if the URL is copied into another system that
  109. does use them, it will not be necessary to change the URL encoding.
  110. Berners-Lee, Masinter & McCahill [Page 3]
  111. RFC 1738 Uniform Resource Locators (URL) December 1994
  112. Reserved:
  113. Many URL schemes reserve certain characters for a special meaning:
  114. their appearance in the scheme-specific part of the URL has a
  115. designated semantics. If the character corresponding to an octet is
  116. reserved in a scheme, the octet must be encoded. The characters ";",
  117. "/", "?", ":", "@", "=" and "&" are the characters which may be
  118. reserved for special meaning within a scheme. No other characters may
  119. be reserved within a scheme.
  120. Usually a URL has the same interpretation when an octet is
  121. represented by a character and when it encoded. However, this is not
  122. true for reserved characters: encoding a character reserved for a
  123. particular scheme may change the semantics of a URL.
  124. Thus, only alphanumerics, the special characters "$-_.+!*'(),", and
  125. reserved characters used for their reserved purposes may be used
  126. unencoded within a URL.
  127. On the other hand, characters that are not required to be encoded
  128. (including alphanumerics) may be encoded within the scheme-specific
  129. part of a URL, as long as they are not being used for a reserved
  130. purpose.
  131. 2.3 Hierarchical schemes and relative links
  132. In some cases, URLs are used to locate resources that contain
  133. pointers to other resources. In some cases, those pointers are
  134. represented as relative links where the expression of the location of
  135. the second resource is in terms of "in the same place as this one
  136. except with the following relative path". Relative links are not
  137. described in this document. However, the use of relative links
  138. depends on the original URL containing a hierarchical structure
  139. against which the relative link is based.
  140. Some URL schemes (such as the ftp, http, and file schemes) contain
  141. names that can be considered hierarchical; the components of the
  142. hierarchy are separated by "/".
  143. Berners-Lee, Masinter & McCahill [Page 4]
  144. RFC 1738 Uniform Resource Locators (URL) December 1994
  145. 3. Specific Schemes
  146. The mapping for some existing standard and experimental protocols is
  147. outlined in the BNF syntax definition. Notes on particular protocols
  148. follow. The schemes covered are:
  149. ftp File Transfer protocol
  150. http Hypertext Transfer Protocol
  151. gopher The Gopher protocol
  152. mailto Electronic mail address
  153. news USENET news
  154. nntp USENET news using NNTP access
  155. telnet Reference to interactive sessions
  156. wais Wide Area Information Servers
  157. file Host-specific file names
  158. prospero Prospero Directory Service
  159. Other schemes may be specified by future specifications. Section 4 of
  160. this document describes how new schemes may be registered, and lists
  161. some scheme names that are under development.
  162. 3.1. Common Internet Scheme Syntax
  163. While the syntax for the rest of the URL may vary depending on the
  164. particular scheme selected, URL schemes that involve the direct use
  165. of an IP-based protocol to a specified host on the Internet use a
  166. common syntax for the scheme-specific data:
  167. //<user>:<password>@<host>:<port>/<url-path>
  168. Some or all of the parts "<user>:<password>@", ":<password>",
  169. ":<port>", and "/<url-path>" may be excluded. The scheme specific
  170. data start with a double slash "//" to indicate that it complies with
  171. the common Internet scheme syntax. The different components obey the
  172. following rules:
  173. user
  174. An optional user name. Some schemes (e.g., ftp) allow the
  175. specification of a user name.
  176. password
  177. An optional password. If present, it follows the user
  178. name separated from it by a colon.
  179. The user name (and password), if present, are followed by a
  180. commercial at-sign "@". Within the user and password field, any ":",
  181. "@", or "/" must be encoded.
  182. Berners-Lee, Masinter & McCahill [Page 5]
  183. RFC 1738 Uniform Resource Locators (URL) December 1994
  184. Note that an empty user name or password is different than no user
  185. name or password; there is no way to specify a password without
  186. specifying a user name. E.g., <URL:ftp://@host.com/> has an empty
  187. user name and no password, <URL:ftp://host.com/> has no user name,
  188. while <URL:ftp://foo:@host.com/> has a user name of "foo" and an
  189. empty password.
  190. host
  191. The fully qualified domain name of a network host, or its IP
  192. address as a set of four decimal digit groups separated by
  193. ".". Fully qualified domain names take the form as described
  194. in Section 3.5 of RFC 1034 [13] and Section 2.1 of RFC 1123
  195. [5]: a sequence of domain labels separated by ".", each domain
  196. label starting and ending with an alphanumerical character and
  197. possibly also containing "-" characters. The rightmost domain
  198. label will never start with a digit, though, which
  199. syntactically distinguishes all domain names from the IP
  200. addresses.
  201. port
  202. The port number to connect to. Most schemes designate
  203. protocols that have a default port number. Another port number
  204. may optionally be supplied, in decimal, separated from the
  205. host by a colon. If the port is omitted, the colon is as well.
  206. url-path
  207. The rest of the locator consists of data specific to the
  208. scheme, and is known as the "url-path". It supplies the
  209. details of how the specified resource can be accessed. Note
  210. that the "/" between the host (or port) and the url-path is
  211. NOT part of the url-path.
  212. The url-path syntax depends on the scheme being used, as does the
  213. manner in which it is interpreted.
  214. 3.2. FTP
  215. The FTP URL scheme is used to designate files and directories on
  216. Internet hosts accessible using the FTP protocol (RFC959).
  217. A FTP URL follow the syntax described in Section 3.1. If :<port> is
  218. omitted, the port defaults to 21.
  219. Berners-Lee, Masinter & McCahill [Page 6]
  220. RFC 1738 Uniform Resource Locators (URL) December 1994
  221. 3.2.1. FTP Name and Password
  222. A user name and password may be supplied; they are used in the ftp
  223. "USER" and "PASS" commands after first making the connection to the
  224. FTP server. If no user name or password is supplied and one is
  225. requested by the FTP server, the conventions for "anonymous" FTP are
  226. to be used, as follows:
  227. The user name "anonymous" is supplied.
  228. The password is supplied as the Internet e-mail address
  229. of the end user accessing the resource.
  230. If the URL supplies a user name but no password, and the remote
  231. server requests a password, the program interpreting the FTP URL
  232. should request one from the user.
  233. 3.2.2. FTP url-path
  234. The url-path of a FTP URL has the following syntax:
  235. <cwd1>/<cwd2>/.../<cwdN>/<name>;type=<typecode>
  236. Where <cwd1> through <cwdN> and <name> are (possibly encoded) strings
  237. and <typecode> is one of the characters "a", "i", or "d". The part
  238. ";type=<typecode>" may be omitted. The <cwdx> and <name> parts may be
  239. empty. The whole url-path may be omitted, including the "/"
  240. delimiting it from the prefix containing user, password, host, and
  241. port.
  242. The url-path is interpreted as a series of FTP commands as follows:
  243. Each of the <cwd> elements is to be supplied, sequentially, as the
  244. argument to a CWD (change working directory) command.
  245. If the typecode is "d", perform a NLST (name list) command with
  246. <name> as the argument, and interpret the results as a file
  247. directory listing.
  248. Otherwise, perform a TYPE command with <typecode> as the argument,
  249. and then access the file whose name is <name> (for example, using
  250. the RETR command.)
  251. Within a name or CWD component, the characters "/" and ";" are
  252. reserved and must be encoded. The components are decoded prior to
  253. their use in the FTP protocol. In particular, if the appropriate FTP
  254. sequence to access a particular file requires supplying a string
  255. containing a "/" as an argument to a CWD or RETR command, it is
  256. Berners-Lee, Masinter & McCahill [Page 7]
  257. RFC 1738 Uniform Resource Locators (URL) December 1994
  258. necessary to encode each "/".
  259. For example, the URL <URL:ftp://myname@host.dom/%2Fetc/motd> is
  260. interpreted by FTP-ing to "host.dom", logging in as "myname"
  261. (prompting for a password if it is asked for), and then executing
  262. "CWD /etc" and then "RETR motd". This has a different meaning from
  263. <URL:ftp://myname@host.dom/etc/motd> which would "CWD etc" and then
  264. "RETR motd"; the initial "CWD" might be executed relative to the
  265. default directory for "myname". On the other hand,
  266. <URL:ftp://myname@host.dom//etc/motd>, would "CWD " with a null
  267. argument, then "CWD etc", and then "RETR motd".
  268. FTP URLs may also be used for other operations; for example, it is
  269. possible to update a file on a remote file server, or infer
  270. information about it from the directory listings. The mechanism for
  271. doing so is not spelled out here.
  272. 3.2.3. FTP Typecode is Optional
  273. The entire ;type=<typecode> part of a FTP URL is optional. If it is
  274. omitted, the client program interpreting the URL must guess the
  275. appropriate mode to use. In general, the data content type of a file
  276. can only be guessed from the name, e.g., from the suffix of the name;
  277. the appropriate type code to be used for transfer of the file can
  278. then be deduced from the data content of the file.
  279. 3.2.4 Hierarchy
  280. For some file systems, the "/" used to denote the hierarchical
  281. structure of the URL corresponds to the delimiter used to construct a
  282. file name hierarchy, and thus, the filename will look similar to the
  283. URL path. This does NOT mean that the URL is a Unix filename.
  284. 3.2.5. Optimization
  285. Clients accessing resources via FTP may employ additional heuristics
  286. to optimize the interaction. For some FTP servers, for example, it
  287. may be reasonable to keep the control connection open while accessing
  288. multiple URLs from the same server. However, there is no common
  289. hierarchical model to the FTP protocol, so if a directory change
  290. command has been given, it is impossible in general to deduce what
  291. sequence should be given to navigate to another directory for a
  292. second retrieval, if the paths are different. The only reliable
  293. algorithm is to disconnect and reestablish the control connection.
  294. Berners-Lee, Masinter & McCahill [Page 8]
  295. RFC 1738 Uniform Resource Locators (URL) December 1994
  296. 3.3. HTTP
  297. The HTTP URL scheme is used to designate Internet resources
  298. accessible using HTTP (HyperText Transfer Protocol).
  299. The HTTP protocol is specified elsewhere. This specification only
  300. describes the syntax of HTTP URLs.
  301. An HTTP URL takes the form:
  302. http://<host>:<port>/<path>?<searchpart>
  303. where <host> and <port> are as described in Section 3.1. If :<port>
  304. is omitted, the port defaults to 80. No user name or password is
  305. allowed. <path> is an HTTP selector, and <searchpart> is a query
  306. string. The <path> is optional, as is the <searchpart> and its
  307. preceding "?". If neither <path> nor <searchpart> is present, the "/"
  308. may also be omitted.
  309. Within the <path> and <searchpart> components, "/", ";", "?" are
  310. reserved. The "/" character may be used within HTTP to designate a
  311. hierarchical structure.
  312. 3.4. GOPHER
  313. The Gopher URL scheme is used to designate Internet resources
  314. accessible using the Gopher protocol.
  315. The base Gopher protocol is described in RFC 1436 and supports items
  316. and collections of items (directories). The Gopher+ protocol is a set
  317. of upward compatible extensions to the base Gopher protocol and is
  318. described in [2]. Gopher+ supports associating arbitrary sets of
  319. attributes and alternate data representations with Gopher items.
  320. Gopher URLs accommodate both Gopher and Gopher+ items and item
  321. attributes.
  322. 3.4.1. Gopher URL syntax
  323. A Gopher URL takes the form:
  324. gopher://<host>:<port>/<gopher-path>
  325. where <gopher-path> is one of
  326. <gophertype><selector>
  327. <gophertype><selector>%09<search>
  328. <gophertype><selector>%09<search>%09<gopher+_string>
  329. Berners-Lee, Masinter & McCahill [Page 9]
  330. RFC 1738 Uniform Resource Locators (URL) December 1994
  331. If :<port> is omitted, the port defaults to 70. <gophertype> is a
  332. single-character field to denote the Gopher type of the resource to
  333. which the URL refers. The entire <gopher-path> may also be empty, in
  334. which case the delimiting "/" is also optional and the <gophertype>
  335. defaults to "1".
  336. <selector> is the Gopher selector string. In the Gopher protocol,
  337. Gopher selector strings are a sequence of octets which may contain
  338. any octets except 09 hexadecimal (US-ASCII HT or tab) 0A hexadecimal
  339. (US-ASCII character LF), and 0D (US-ASCII character CR).
  340. Gopher clients specify which item to retrieve by sending the Gopher
  341. selector string to a Gopher server.
  342. Within the <gopher-path>, no characters are reserved.
  343. Note that some Gopher <selector> strings begin with a copy of the
  344. <gophertype> character, in which case that character will occur twice
  345. consecutively. The Gopher selector string may be an empty string;
  346. this is how Gopher clients refer to the top-level directory on a
  347. Gopher server.
  348. 3.4.2 Specifying URLs for Gopher Search Engines
  349. If the URL refers to a search to be submitted to a Gopher search
  350. engine, the selector is followed by an encoded tab (%09) and the
  351. search string. To submit a search to a Gopher search engine, the
  352. Gopher client sends the <selector> string (after decoding), a tab,
  353. and the search string to the Gopher server.
  354. 3.4.3 URL syntax for Gopher+ items
  355. URLs for Gopher+ items have a second encoded tab (%09) and a Gopher+
  356. string. Note that in this case, the %09<search> string must be
  357. supplied, although the <search> element may be the empty string.
  358. The <gopher+_string> is used to represent information required for
  359. retrieval of the Gopher+ item. Gopher+ items may have alternate
  360. views, arbitrary sets of attributes, and may have electronic forms
  361. associated with them.
  362. To retrieve the data associated with a Gopher+ URL, a client will
  363. connect to the server and send the Gopher selector, followed by a tab
  364. and the search string (which may be empty), followed by a tab and the
  365. Gopher+ commands.
  366. Berners-Lee, Masinter & McCahill [Page 10]
  367. RFC 1738 Uniform Resource Locators (URL) December 1994
  368. 3.4.4 Default Gopher+ data representation
  369. When a Gopher server returns a directory listing to a client, the
  370. Gopher+ items are tagged with either a "+" (denoting Gopher+ items)
  371. or a "?" (denoting Gopher+ items which have a +ASK form associated
  372. with them). A Gopher URL with a Gopher+ string consisting of only a
  373. "+" refers to the default view (data representation) of the item
  374. while a Gopher+ string containing only a "?" refer to an item with a
  375. Gopher electronic form associated with it.
  376. 3.4.5 Gopher+ items with electronic forms
  377. Gopher+ items which have a +ASK associated with them (i.e. Gopher+
  378. items tagged with a "?") require the client to fetch the item's +ASK
  379. attribute to get the form definition, and then ask the user to fill
  380. out the form and return the user's responses along with the selector
  381. string to retrieve the item. Gopher+ clients know how to do this but
  382. depend on the "?" tag in the Gopher+ item description to know when to
  383. handle this case. The "?" is used in the Gopher+ string to be
  384. consistent with Gopher+ protocol's use of this symbol.
  385. 3.4.6 Gopher+ item attribute collections
  386. To refer to the Gopher+ attributes of an item, the Gopher URL's
  387. Gopher+ string consists of "!" or "$". "!" refers to the all of a
  388. Gopher+ item's attributes. "$" refers to all the item attributes for
  389. all items in a Gopher directory.
  390. 3.4.7 Referring to specific Gopher+ attributes
  391. To refer to specific attributes, the URL's gopher+_string is
  392. "!<attribute_name>" or "$<attribute_name>". For example, to refer to
  393. the attribute containing the abstract of an item, the gopher+_string
  394. would be "!+ABSTRACT".
  395. To refer to several attributes, the gopher+_string consists of the
  396. attribute names separated by coded spaces. For example,
  397. "!+ABSTRACT%20+SMELL" refers to the +ABSTRACT and +SMELL attributes
  398. of an item.
  399. 3.4.8 URL syntax for Gopher+ alternate views
  400. Gopher+ allows for optional alternate data representations (alternate
  401. views) of items. To retrieve a Gopher+ alternate view, a Gopher+
  402. client sends the appropriate view and language identifier (found in
  403. the item's +VIEW attribute). To refer to a specific Gopher+ alternate
  404. view, the URL's Gopher+ string would be in the form:
  405. Berners-Lee, Masinter & McCahill [Page 11]
  406. RFC 1738 Uniform Resource Locators (URL) December 1994
  407. +<view_name>%20<language_name>
  408. For example, a Gopher+ string of "+application/postscript%20Es_ES"
  409. refers to the Spanish language postscript alternate view of a Gopher+
  410. item.
  411. 3.4.9 URL syntax for Gopher+ electronic forms
  412. The gopher+_string for a URL that refers to an item referenced by a
  413. Gopher+ electronic form (an ASK block) filled out with specific
  414. values is a coded version of what the client sends to the server.
  415. The gopher+_string is of the form:
  416. +%091%0D%0A+-1%0D%0A<ask_item1_value>%0D%0A<ask_item2_value>%0D%0A.%0D%0A
  417. To retrieve this item, the Gopher client sends:
  418. <a_gopher_selector><tab>+<tab>1<cr><lf>
  419. +-1<cr><lf>
  420. <ask_item1_value><cr><lf>
  421. <ask_item2_value><cr><lf>
  422. .<cr><lf>
  423. to the Gopher server.
  424. 3.5. MAILTO
  425. The mailto URL scheme is used to designate the Internet mailing
  426. address of an individual or service. No additional information other
  427. than an Internet mailing address is present or implied.
  428. A mailto URL takes the form:
  429. mailto:<rfc822-addr-spec>
  430. where <rfc822-addr-spec> is (the encoding of an) addr-spec, as
  431. specified in RFC 822 [6]. Within mailto URLs, there are no reserved
  432. characters.
  433. Note that the percent sign ("%") is commonly used within RFC 822
  434. addresses and must be encoded.
  435. Unlike many URLs, the mailto scheme does not represent a data object
  436. to be accessed directly; there is no sense in which it designates an
  437. object. It has a different use than the message/external-body type in
  438. MIME.
  439. Berners-Lee, Masinter & McCahill [Page 12]
  440. RFC 1738 Uniform Resource Locators (URL) December 1994
  441. 3.6. NEWS
  442. The news URL scheme is used to refer to either news groups or
  443. individual articles of USENET news, as specified in RFC 1036.
  444. A news URL takes one of two forms:
  445. news:<newsgroup-name>
  446. news:<message-id>
  447. A <newsgroup-name> is a period-delimited hierarchical name, such as
  448. "comp.infosystems.www.misc". A <message-id> corresponds to the
  449. Message-ID of section 2.1.5 of RFC 1036, without the enclosing "<"
  450. and ">"; it takes the form <unique>@<full_domain_name>. A message
  451. identifier may be distinguished from a news group name by the
  452. presence of the commercial at "@" character. No additional characters
  453. are reserved within the components of a news URL.
  454. If <newsgroup-name> is "*" (as in <URL:news:*>), it is used to refer
  455. to "all available news groups".
  456. The news URLs are unusual in that by themselves, they do not contain
  457. sufficient information to locate a single resource, but, rather, are
  458. location-independent.
  459. 3.7. NNTP
  460. The nntp URL scheme is an alternative method of referencing news
  461. articles, useful for specifying news articles from NNTP servers (RFC
  462. 977).
  463. A nntp URL take the form:
  464. nntp://<host>:<port>/<newsgroup-name>/<article-number>
  465. where <host> and <port> are as described in Section 3.1. If :<port>
  466. is omitted, the port defaults to 119.
  467. The <newsgroup-name> is the name of the group, while the <article-
  468. number> is the numeric id of the article within that newsgroup.
  469. Note that while nntp: URLs specify a unique location for the article
  470. resource, most NNTP servers currently on the Internet today are
  471. configured only to allow access from local clients, and thus nntp
  472. URLs do not designate globally accessible resources. Thus, the news:
  473. form of URL is preferred as a way of identifying news articles.
  474. Berners-Lee, Masinter & McCahill [Page 13]
  475. RFC 1738 Uniform Resource Locators (URL) December 1994
  476. 3.8. TELNET
  477. The Telnet URL scheme is used to designate interactive services that
  478. may be accessed by the Telnet protocol.
  479. A telnet URL takes the form:
  480. telnet://<user>:<password>@<host>:<port>/
  481. as specified in Section 3.1. The final "/" character may be omitted.
  482. If :<port> is omitted, the port defaults to 23. The :<password> can
  483. be omitted, as well as the whole <user>:<password> part.
  484. This URL does not designate a data object, but rather an interactive
  485. service. Remote interactive services vary widely in the means by
  486. which they allow remote logins; in practice, the <user> and
  487. <password> supplied are advisory only: clients accessing a telnet URL
  488. merely advise the user of the suggested username and password.
  489. 3.9. WAIS
  490. The WAIS URL scheme is used to designate WAIS databases, searches, or
  491. individual documents available from a WAIS database. WAIS is
  492. described in [7]. The WAIS protocol is described in RFC 1625 [17];
  493. Although the WAIS protocol is based on Z39.50-1988, the WAIS URL
  494. scheme is not intended for use with arbitrary Z39.50 services.
  495. A WAIS URL takes one of the following forms:
  496. wais://<host>:<port>/<database>
  497. wais://<host>:<port>/<database>?<search>
  498. wais://<host>:<port>/<database>/<wtype>/<wpath>
  499. where <host> and <port> are as described in Section 3.1. If :<port>
  500. is omitted, the port defaults to 210. The first form designates a
  501. WAIS database that is available for searching. The second form
  502. designates a particular search. <database> is the name of the WAIS
  503. database being queried.
  504. The third form designates a particular document within a WAIS
  505. database to be retrieved. In this form <wtype> is the WAIS
  506. designation of the type of the object. Many WAIS implementations
  507. require that a client know the "type" of an object prior to
  508. retrieval, the type being returned along with the internal object
  509. identifier in the search response. The <wtype> is included in the
  510. URL in order to allow the client interpreting the URL adequate
  511. information to actually retrieve the document.
  512. Berners-Lee, Masinter & McCahill [Page 14]
  513. RFC 1738 Uniform Resource Locators (URL) December 1994
  514. The <wpath> of a WAIS URL consists of the WAIS document-id, encoded
  515. as necessary using the method described in Section 2.2. The WAIS
  516. document-id should be treated opaquely; it may only be decomposed by
  517. the server that issued it.
  518. 3.10 FILES
  519. The file URL scheme is used to designate files accessible on a
  520. particular host computer. This scheme, unlike most other URL schemes,
  521. does not designate a resource that is universally accessible over the
  522. Internet.
  523. A file URL takes the form:
  524. file://<host>/<path>
  525. where <host> is the fully qualified domain name of the system on
  526. which the <path> is accessible, and <path> is a hierarchical
  527. directory path of the form <directory>/<directory>/.../<name>.
  528. For example, a VMS file
  529. DISK$USER:[MY.NOTES]NOTE123456.TXT
  530. might become
  531. <URL:file://vms.host.edu/disk$user/my/notes/note12345.txt>
  532. As a special case, <host> can be the string "localhost" or the empty
  533. string; this is interpreted as `the machine from which the URL is
  534. being interpreted'.
  535. The file URL scheme is unusual in that it does not specify an
  536. Internet protocol or access method for such files; as such, its
  537. utility in network protocols between hosts is limited.
  538. 3.11 PROSPERO
  539. The Prospero URL scheme is used to designate resources that are
  540. accessed via the Prospero Directory Service. The Prospero protocol is
  541. described elsewhere [14].
  542. A prospero URLs takes the form:
  543. prospero://<host>:<port>/<hsoname>;<field>=<value>
  544. where <host> and <port> are as described in Section 3.1. If :<port>
  545. is omitted, the port defaults to 1525. No username or password is
  546. Berners-Lee, Masinter & McCahill [Page 15]
  547. RFC 1738 Uniform Resource Locators (URL) December 1994
  548. allowed.
  549. The <hsoname> is the host-specific object name in the Prospero
  550. protocol, suitably encoded. This name is opaque and interpreted by
  551. the Prospero server. The semicolon ";" is reserved and may not
  552. appear without quoting in the <hsoname>.
  553. Prospero URLs are interpreted by contacting a Prospero directory
  554. server on the specified host and port to determine appropriate access
  555. methods for a resource, which might themselves be represented as
  556. different URLs. External Prospero links are represented as URLs of
  557. the underlying access method and are not represented as Prospero
  558. URLs.
  559. Note that a slash "/" may appear in the <hsoname> without quoting and
  560. no significance may be assumed by the application. Though slashes
  561. may indicate hierarchical structure on the server, such structure is
  562. not guaranteed. Note that many <hsoname>s begin with a slash, in
  563. which case the host or port will be followed by a double slash: the
  564. slash from the URL syntax, followed by the initial slash from the
  565. <hsoname>. (E.g., <URL:prospero://host.dom//pros/name> designates a
  566. <hsoname> of "/pros/name".)
  567. In addition, after the <hsoname>, optional fields and values
  568. associated with a Prospero link may be specified as part of the URL.
  569. When present, each field/value pair is separated from each other and
  570. from the rest of the URL by a ";" (semicolon). The name of the field
  571. and its value are separated by a "=" (equal sign). If present, these
  572. fields serve to identify the target of the URL. For example, the
  573. OBJECT-VERSION field can be specified to identify a specific version
  574. of an object.
  575. 4. REGISTRATION OF NEW SCHEMES
  576. A new scheme may be introduced by defining a mapping onto a
  577. conforming URL syntax, using a new prefix. URLs for experimental
  578. schemes may be used by mutual agreement between parties. Scheme names
  579. starting with the characters "x-" are reserved for experimental
  580. purposes.
  581. The Internet Assigned Numbers Authority (IANA) will maintain a
  582. registry of URL schemes. Any submission of a new URL scheme must
  583. include a definition of an algorithm for accessing of resources
  584. within that scheme and the syntax for representing such a scheme.
  585. URL schemes must have demonstrable utility and operability. One way
  586. to provide such a demonstration is via a gateway which provides
  587. objects in the new scheme for clients using an existing protocol. If
  588. Berners-Lee, Masinter & McCahill [Page 16]
  589. RFC 1738 Uniform Resource Locators (URL) December 1994
  590. the new scheme does not locate resources that are data objects, the
  591. properties of names in the new space must be clearly defined.
  592. New schemes should try to follow the same syntactic conventions of
  593. existing schemes, where appropriate. It is likewise recommended
  594. that, where a protocol allows for retrieval by URL, that the client
  595. software have provision for being configured to use specific gateway
  596. locators for indirect access through new naming schemes.
  597. The following scheme have been proposed at various times, but this
  598. document does not define their syntax or use at this time. It is
  599. suggested that IANA reserve their scheme names for future definition:
  600. afs Andrew File System global file names.
  601. mid Message identifiers for electronic mail.
  602. cid Content identifiers for MIME body parts.
  603. nfs Network File System (NFS) file names.
  604. tn3270 Interactive 3270 emulation sessions.
  605. mailserver Access to data available from mail servers.
  606. z39.50 Access to ANSI Z39.50 services.
  607. 5. BNF for specific URL schemes
  608. This is a BNF-like description of the Uniform Resource Locator
  609. syntax, using the conventions of RFC822, except that "|" is used to
  610. designate alternatives, and brackets [] are used around optional or
  611. repeated elements. Briefly, literals are quoted with "", optional
  612. elements are enclosed in [brackets], and elements may be preceded
  613. with <n>* to designate n or more repetitions of the following
  614. element; n defaults to 0.
  615. ; The generic form of a URL is:
  616. genericurl = scheme ":" schemepart
  617. ; Specific predefined schemes are defined here; new schemes
  618. ; may be registered with IANA
  619. url = httpurl | ftpurl | newsurl |
  620. nntpurl | telneturl | gopherurl |
  621. waisurl | mailtourl | fileurl |
  622. prosperourl | otherurl
  623. ; new schemes follow the general syntax
  624. otherurl = genericurl
  625. ; the scheme is in lower case; interpreters should use case-ignore
  626. scheme = 1*[ lowalpha | digit | "+" | "-" | "." ]
  627. Berners-Lee, Masinter & McCahill [Page 17]
  628. RFC 1738 Uniform Resource Locators (URL) December 1994
  629. schemepart = *xchar | ip-schemepart
  630. ; URL schemeparts for ip based protocols:
  631. ip-schemepart = "//" login [ "/" urlpath ]
  632. login = [ user [ ":" password ] "@" ] hostport
  633. hostport = host [ ":" port ]
  634. host = hostname | hostnumber
  635. hostname = *[ domainlabel "." ] toplabel
  636. domainlabel = alphadigit | alphadigit *[ alphadigit | "-" ] alphadigit
  637. toplabel = alpha | alpha *[ alphadigit | "-" ] alphadigit
  638. alphadigit = alpha | digit
  639. hostnumber = digits "." digits "." digits "." digits
  640. port = digits
  641. user = *[ uchar | ";" | "?" | "&" | "=" ]
  642. password = *[ uchar | ";" | "?" | "&" | "=" ]
  643. urlpath = *xchar ; depends on protocol see section 3.1
  644. ; The predefined schemes:
  645. ; FTP (see also RFC959)
  646. ftpurl = "ftp://" login [ "/" fpath [ ";type=" ftptype ]]
  647. fpath = fsegment *[ "/" fsegment ]
  648. fsegment = *[ uchar | "?" | ":" | "@" | "&" | "=" ]
  649. ftptype = "A" | "I" | "D" | "a" | "i" | "d"
  650. ; FILE
  651. fileurl = "file://" [ host | "localhost" ] "/" fpath
  652. ; HTTP
  653. httpurl = "http://" hostport [ "/" hpath [ "?" search ]]
  654. hpath = hsegment *[ "/" hsegment ]
  655. hsegment = *[ uchar | ";" | ":" | "@" | "&" | "=" ]
  656. search = *[ uchar | ";" | ":" | "@" | "&" | "=" ]
  657. ; GOPHER (see also RFC1436)
  658. gopherurl = "gopher://" hostport [ / [ gtype [ selector
  659. [ "%09" search [ "%09" gopher+_string ] ] ] ] ]
  660. gtype = xchar
  661. selector = *xchar
  662. gopher+_string = *xchar
  663. Berners-Lee, Masinter & McCahill [Page 18]
  664. RFC 1738 Uniform Resource Locators (URL) December 1994
  665. ; MAILTO (see also RFC822)
  666. mailtourl = "mailto:" encoded822addr
  667. encoded822addr = 1*xchar ; further defined in RFC822
  668. ; NEWS (see also RFC1036)
  669. newsurl = "news:" grouppart
  670. grouppart = "*" | group | article
  671. group = alpha *[ alpha | digit | "-" | "." | "+" | "_" ]
  672. article = 1*[ uchar | ";" | "/" | "?" | ":" | "&" | "=" ] "@" host
  673. ; NNTP (see also RFC977)
  674. nntpurl = "nntp://" hostport "/" group [ "/" digits ]
  675. ; TELNET
  676. telneturl = "telnet://" login [ "/" ]
  677. ; WAIS (see also RFC1625)
  678. waisurl = waisdatabase | waisindex | waisdoc
  679. waisdatabase = "wais://" hostport "/" database
  680. waisindex = "wais://" hostport "/" database "?" search
  681. waisdoc = "wais://" hostport "/" database "/" wtype "/" wpath
  682. database = *uchar
  683. wtype = *uchar
  684. wpath = *uchar
  685. ; PROSPERO
  686. prosperourl = "prospero://" hostport "/" ppath *[ fieldspec ]
  687. ppath = psegment *[ "/" psegment ]
  688. psegment = *[ uchar | "?" | ":" | "@" | "&" | "=" ]
  689. fieldspec = ";" fieldname "=" fieldvalue
  690. fieldname = *[ uchar | "?" | ":" | "@" | "&" ]
  691. fieldvalue = *[ uchar | "?" | ":" | "@" | "&" ]
  692. ; Miscellaneous definitions
  693. lowalpha = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" |
  694. "i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" |
  695. "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" |
  696. "y" | "z"
  697. hialpha = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" |
  698. "J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" |
  699. "S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z"
  700. Berners-Lee, Masinter & McCahill [Page 19]
  701. RFC 1738 Uniform Resource Locators (URL) December 1994
  702. alpha = lowalpha | hialpha
  703. digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
  704. "8" | "9"
  705. safe = "$" | "-" | "_" | "." | "+"
  706. extra = "!" | "*" | "'" | "(" | ")" | ","
  707. national = "{" | "}" | "|" | "\" | "^" | "~" | "[" | "]" | "`"
  708. punctuation = "<" | ">" | "#" | "%" | <">
  709. reserved = ";" | "/" | "?" | ":" | "@" | "&" | "="
  710. hex = digit | "A" | "B" | "C" | "D" | "E" | "F" |
  711. "a" | "b" | "c" | "d" | "e" | "f"
  712. escape = "%" hex hex
  713. unreserved = alpha | digit | safe | extra
  714. uchar = unreserved | escape
  715. xchar = unreserved | reserved | escape
  716. digits = 1*digit
  717. 6. Security Considerations
  718. The URL scheme does not in itself pose a security threat. Users
  719. should beware that there is no general guarantee that a URL which at
  720. one time points to a given object continues to do so, and does not
  721. even at some later time point to a different object due to the
  722. movement of objects on servers.
  723. A URL-related security threat is that it is sometimes possible to
  724. construct a URL such that an attempt to perform a harmless idempotent
  725. operation such as the retrieval of the object will in fact cause a
  726. possibly damaging remote operation to occur. The unsafe URL is
  727. typically constructed by specifying a port number other than that
  728. reserved for the network protocol in question. The client
  729. unwittingly contacts a server which is in fact running a different
  730. protocol. The content of the URL contains instructions which when
  731. interpreted according to this other protocol cause an unexpected
  732. operation. An example has been the use of gopher URLs to cause a rude
  733. message to be sent via a SMTP server. Caution should be used when
  734. using any URL which specifies a port number other than the default
  735. for the protocol, especially when it is a number within the reserved
  736. space.
  737. Care should be taken when URLs contain embedded encoded delimiters
  738. for a given protocol (for example, CR and LF characters for telnet
  739. protocols) that these are not unencoded before transmission. This
  740. would violate the protocol but could be used to simulate an extra
  741. operation or parameter, again causing an unexpected and possible
  742. harmful remote operation to be performed.
  743. Berners-Lee, Masinter & McCahill [Page 20]
  744. RFC 1738 Uniform Resource Locators (URL) December 1994
  745. The use of URLs containing passwords that should be secret is clearly
  746. unwise.
  747. 7. Acknowledgements
  748. This paper builds on the basic WWW design (RFC 1630) and much
  749. discussion of these issues by many people on the network. The
  750. discussion was particularly stimulated by articles by Clifford Lynch,
  751. Brewster Kahle [10] and Wengyik Yeong [18]. Contributions from John
  752. Curran, Clifford Neuman, Ed Vielmetti and later the IETF URL BOF and
  753. URI working group were incorporated.
  754. Most recently, careful readings and comments by Dan Connolly, Ned
  755. Freed, Roy Fielding, Guido van Rossum, Michael Dolan, Bert Bos, John
  756. Kunze, Olle Jarnefors, Peter Svanberg and many others have helped
  757. refine this RFC.
  758. Berners-Lee, Masinter & McCahill [Page 21]
  759. RFC 1738 Uniform Resource Locators (URL) December 1994
  760. APPENDIX: Recommendations for URLs in Context
  761. URIs, including URLs, are intended to be transmitted through
  762. protocols which provide a context for their interpretation.
  763. In some cases, it will be necessary to distinguish URLs from other
  764. possible data structures in a syntactic structure. In this case, is
  765. recommended that URLs be preceeded with a prefix consisting of the
  766. characters "URL:". For example, this prefix may be used to
  767. distinguish URLs from other kinds of URIs.
  768. In addition, there are many occasions when URLs are included in other
  769. kinds of text; examples include electronic mail, USENET news
  770. messages, or printed on paper. In such cases, it is convenient to
  771. have a separate syntactic wrapper that delimits the URL and separates
  772. it from the rest of the text, and in particular from punctuation
  773. marks that might be mistaken for part of the URL. For this purpose,
  774. is recommended that angle brackets ("<" and ">"), along with the
  775. prefix "URL:", be used to delimit the boundaries of the URL. This
  776. wrapper does not form part of the URL and should not be used in
  777. contexts in which delimiters are already specified.
  778. In the case where a fragment/anchor identifier is associated with a
  779. URL (following a "#"), the identifier would be placed within the
  780. brackets as well.
  781. In some cases, extra whitespace (spaces, linebreaks, tabs, etc.) may
  782. need to be added to break long URLs across lines. The whitespace
  783. should be ignored when extracting the URL.
  784. No whitespace should be introduced after a hyphen ("-") character.
  785. Because some typesetters and printers may (erroneously) introduce a
  786. hyphen at the end of line when breaking a line, the interpreter of a
  787. URL containing a line break immediately after a hyphen should ignore
  788. all unencoded whitespace around the line break, and should be aware
  789. that the hyphen may or may not actually be part of the URL.
  790. Examples:
  791. Yes, Jim, I found it under <URL:ftp://info.cern.ch/pub/www/doc;
  792. type=d> but you can probably pick it up from <URL:ftp://ds.in
  793. ternic.net/rfc>. Note the warning in <URL:http://ds.internic.
  794. net/instructions/overview.html#WARNING>.
  795. Berners-Lee, Masinter & McCahill [Page 22]
  796. RFC 1738 Uniform Resource Locators (URL) December 1994
  797. References
  798. [1] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D.,
  799. Torrey, D., and B. Alberti, "The Internet Gopher Protocol
  800. (a distributed document search and retrieval protocol)",
  801. RFC 1436, University of Minnesota, March 1993.
  802. <URL:ftp://ds.internic.net/rfc/rfc1436.txt;type=a>
  803. [2] Anklesaria, F., Lindner, P., McCahill, M., Torrey, D.,
  804. Johnson, D., and B. Alberti, "Gopher+: Upward compatible
  805. enhancements to the Internet Gopher protocol",
  806. University of Minnesota, July 1993.
  807. <URL:ftp://boombox.micro.umn.edu/pub/gopher/gopher_protocol
  808. /Gopher+/Gopher+.txt>
  809. [3] Berners-Lee, T., "Universal Resource Identifiers in WWW: A
  810. Unifying Syntax for the Expression of Names and Addresses of
  811. Objects on the Network as used in the World-Wide Web", RFC
  812. 1630, CERN, June 1994.
  813. <URL:ftp://ds.internic.net/rfc/rfc1630.txt>
  814. [4] Berners-Lee, T., "Hypertext Transfer Protocol (HTTP)",
  815. CERN, November 1993.
  816. <URL:ftp://info.cern.ch/pub/www/doc/http-spec.txt.Z>
  817. [5] Braden, R., Editor, "Requirements for Internet Hosts --
  818. Application and Support", STD 3, RFC 1123, IETF, October 1989.
  819. <URL:ftp://ds.internic.net/rfc/rfc1123.txt>
  820. [6] Crocker, D. "Standard for the Format of ARPA Internet Text
  821. Messages", STD 11, RFC 822, UDEL, April 1982.
  822. <URL:ftp://ds.internic.net/rfc/rfc822.txt>
  823. [7] Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T., Wang, R.,
  824. Sui, J., and M. Grinbaum, "WAIS Interface Protocol Prototype
  825. Functional Specification", (v1.5), Thinking Machines
  826. Corporation, April 1990.
  827. <URL:ftp://quake.think.com/pub/wais/doc/protspec.txt>
  828. [8] Horton, M. and R. Adams, "Standard For Interchange of USENET
  829. Messages", RFC 1036, AT&T Bell Laboratories, Center for Seismic
  830. Studies, December 1987.
  831. <URL:ftp://ds.internic.net/rfc/rfc1036.txt>
  832. [9] Huitema, C., "Naming: Strategies and Techniques", Computer
  833. Networks and ISDN Systems 23 (1991) 107-110.
  834. Berners-Lee, Masinter & McCahill [Page 23]
  835. RFC 1738 Uniform Resource Locators (URL) December 1994
  836. [10] Kahle, B., "Document Identifiers, or International Standard
  837. Book Numbers for the Electronic Age", 1991.
  838. <URL:ftp://quake.think.com/pub/wais/doc/doc-ids.txt>
  839. [11] Kantor, B. and P. Lapsley, "Network News Transfer Protocol:
  840. A Proposed Standard for the Stream-Based Transmission of News",
  841. RFC 977, UC San Diego & UC Berkeley, February 1986.
  842. <URL:ftp://ds.internic.net/rfc/rfc977.txt>
  843. [12] Kunze, J., "Functional Requirements for Internet Resource
  844. Locators", Work in Progress, December 1994.
  845. <URL:ftp://ds.internic.net/internet-drafts
  846. /draft-ietf-uri-irl-fun-req-02.txt>
  847. [13] Mockapetris, P., "Domain Names - Concepts and Facilities",
  848. STD 13, RFC 1034, USC/Information Sciences Institute,
  849. November 1987.
  850. <URL:ftp://ds.internic.net/rfc/rfc1034.txt>
  851. [14] Neuman, B., and S. Augart, "The Prospero Protocol",
  852. USC/Information Sciences Institute, June 1993.
  853. <URL:ftp://prospero.isi.edu/pub/prospero/doc
  854. /prospero-protocol.PS.Z>
  855. [15] Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)",
  856. STD 9, RFC 959, USC/Information Sciences Institute,
  857. October 1985.
  858. <URL:ftp://ds.internic.net/rfc/rfc959.txt>
  859. [16] Sollins, K. and L. Masinter, "Functional Requirements for
  860. Uniform Resource Names", RFC 1737, MIT/LCS, Xerox Corporation,
  861. December 1994.
  862. <URL:ftp://ds.internic.net/rfc/rfc1737.txt>
  863. [17] St. Pierre, M, Fullton, J., Gamiel, K., Goldman, J., Kahle, B.,
  864. Kunze, J., Morris, H., and F. Schiettecatte, "WAIS over
  865. Z39.50-1988", RFC 1625, WAIS, Inc., CNIDR, Thinking Machines
  866. Corp., UC Berkeley, FS Consulting, June 1994.
  867. <URL:ftp://ds.internic.net/rfc/rfc1625.txt>
  868. [18] Yeong, W. "Towards Networked Information Retrieval", Technical
  869. report 91-06-25-01, Performance Systems International, Inc.
  870. <URL:ftp://uu.psi.com/wp/nir.txt>, June 1991.
  871. [19] Yeong, W., "Representing Public Archives in the Directory",
  872. Work in Progress, November 1991.
  873. Berners-Lee, Masinter & McCahill [Page 24]
  874. RFC 1738 Uniform Resource Locators (URL) December 1994
  875. [20] "Coded Character Set -- 7-bit American Standard Code for
  876. Information Interchange", ANSI X3.4-1986.
  877. Editors' Addresses
  878. Tim Berners-Lee
  879. World-Wide Web project
  880. CERN,
  881. 1211 Geneva 23,
  882. Switzerland
  883. Phone: +41 (22)767 3755
  884. Fax: +41 (22)767 7155
  885. EMail: timbl@info.cern.ch
  886. Larry Masinter
  887. Xerox PARC
  888. 3333 Coyote Hill Road
  889. Palo Alto, CA 94034
  890. Phone: (415) 812-4365
  891. Fax: (415) 812-4333
  892. EMail: masinter@parc.xerox.com
  893. Mark McCahill
  894. Computer and Information Services,
  895. University of Minnesota
  896. Room 152 Shepherd Labs
  897. 100 Union Street SE
  898. Minneapolis, MN 55455
  899. Phone: (612) 625 1300
  900. EMail: mpm@boombox.micro.umn.edu
  901. Berners-Lee, Masinter & McCahill [Page 25]