PageRenderTime 71ms CodeModel.GetById 28ms RepoModel.GetById 1ms app.codeStats 0ms

/lib/www_tools/doc/rfc_info.html

https://github.com/babo/jungerl
HTML | 1052 lines | 1041 code | 0 blank | 11 comment | 0 complexity | 74eca4e15114ccc9719b40839c568ba5 MD5 | raw file
Possible License(s): LGPL-2.1, BSD-3-Clause, AGPL-1.0

Large files files are truncated, but you can click here to view the full file

    

  1. <!-- received="Thu Aug  4 18:04:06 1994 MST" -->
    2. 

  2. <!-- sent="Thu, 4 Aug 1994 15:46:18 PDT" -->
    3. 

  3. <!-- name="Larry Masinter" -->
    4. 

  4. <!-- email="masinter@parc.xerox.com" -->
    5. 

  5. <!-- subject="Draft URL document, for last call to be proposed standard RFC" -->
    6. 

  6. <!-- id="94Aug4.154628pdt.2760@golden.parc.xerox.com" -->
    7. 

  7. <!-- inreplyto="" -->
    8. 

  8. <title>uri-94q3: Draft URL document, for last call to be proposed standard RFC</title>
    9. 

  9. <h1>Draft URL document, for last call to be proposed standard RFC</h1>
    10. 

  10. Larry Masinter (<i>masinter@parc.xerox.com</i>)<br>
    11. 

  11. <i>Thu, 4 Aug 1994 15:46:18 PDT</i>
    12. 

  12. <p>
    13. 

  13. <ul>
    14. 

  14. <li> <b>Messages sorted by:</b> <a href="index.html#150">[ date ]</a><a href="thread.html#150">[ thread ]</a><a href="subject.html#150">[ subject ]</a><a href="author.html#150">[ author ]</a>
    15. 

  15. <!-- next="start" -->
    16. 

  16. <li> <b>Next message:</b> <a href="0151.html">Mitra: "Latest URL draft - diffs please"</a>
    17. 

  17. <li> <b>Previous message:</b> <a href="0149.html">Internet-Drafts@CNRI.Reston.VA.US: "I-D ACTION:draft-ietf-uri-resource-names-02.txt"</a>
    18. 

  18. <!-- nextthread="start" -->
    19. 

  19. <li> <b>Next in thread:</b> <a href="0170.html">John A. Kunze: "Re: Draft URL document, for last call to be proposed standard RFC"</a>
    20. 

  20. <li> <b>Maybe reply:</b> <a href="0170.html">John A. Kunze: "Re: Draft URL document, for last call to be proposed standard RFC"</a>
    21. 

  21. <li> <b>Maybe reply:</b> <a href="0173.html">John A. Kunze: "Re: Draft URL document, for last call to be proposed standard RFC"</a>
    22. 

  22. <!-- reply="end" -->
    23. 

  23. </ul>
    24. 

  24. <!-- body="start" -->
    25. 

  25. Uniform Resource Locators                                 T. Berners-Lee<br>
    26. 

  26. draft-ietf-uri-url-06.txt                                    L. Masinter<br>
    27. 

  27. Expires March 4, 1995                                        M. McCahill<br>
    28. 

  28.                                                                  Editors<br>
    29. 

  29.                                                           August 4, 1994<br>
    30. 

  30. <p>
    31. 

  31.                   Uniform Resource Locators (URL)<br>
    32. 

  32. <p>
    33. 

  33. Status of this memo<br>
    34. 

  34. <p>
    35. 

  35.      This document is an Internet-Draft.  Internet-Drafts are<br>
    36. 

  36.      working documents of the Internet Engineering Task Force<br>
    37. 

  37.      (IETF), its areas, and its working groups.  Note that other<br>
    38. 

  38.      groups may also distribute working documents as<br>
    39. 

  39.      Internet-Drafts.<br>
    40. 

  40.  <br>
    41. 

  41.      Internet-Drafts are draft documents valid for a maximum of six<br>
    42. 

  42.      months.  Internet-Drafts may be updated, replaced, or obsoleted<br>
    43. 

  43.      by other documents at any time.  It is not appropriate to use<br>
    44. 

  44.      Internet-Drafts as reference material or to cite them other<br>
    45. 

  45.      than as a ``working draft'' or ``work in progress.''<br>
    46. 

  46.  <br>
    47. 

  47.      To learn the current status of any Internet-Draft, please check<br>
    48. 

  48.      the 1id-abstracts.txt listing contained in the Internet-Drafts<br>
    49. 

  49.      Shadow Directories on ds.internic.net, nic.nordu.net,<br>
    50. 

  50.      ftp.isi.edu, or munnari.oz.au.<br>
    51. 

  51. <p>
    52. 

  52.      This Internet Draft expires March 4, 1995.<br>
    53. 

  53. <p>
    54. 

  54. 0. Abstract<br>
    55. 

  55. <p>
    56. 

  56.    This document specifies a Uniform Resource Locator (URL), the<br>
    57. 

  57.    syntax and semantics of formalized information for location and<br>
    58. 

  58.    access of resources on the Internet.<br>
    59. 

  59. <p>
    60. 

  60. 1. Introduction<br>
    61. 

  61. <p>
    62. 

  62.    The work is derived from concepts introduced by the World-Wide Web<br>
    63. 

  63.    global information initiative,  whose use of  such objects dates<br>
    64. 

  64.    from 1990 and is described in "Universal Resource Identifiers in<br>
    65. 

  65.    WWW", RFC 1630.<br>
    66. 

  66. <p>
    67. 

  67.    This document was written by the URI working group of the Internet<br>
    68. 

  68.    Engineering Task Force.  Comments may be addressed to the editor,<br>
    69. 

  69.    Tim Berners-Lee &lt;timbl@info.cern.ch&gt;, or to the URI-WG<br>
    70. 

  70.    &lt;uri@bunyip.com&gt;. Discussions of the group are archived at<br>
    71. 

  71.    &lt;URL:<a href="http://www.acl.lanl.gov/URI/archive/uri-archive.index.html">http://www.acl.lanl.gov/URI/archive/uri-archive.index.html</a>&gt;<br>
    72. 

  72. <p>
    73. 

  73. 2. Recommendations<br>
    74. 

  74. <p>
    75. 

  75.    This document describes the syntax for "Uniform Resource Locators"<br>
    76. 

  76.    (URLs): a compact representation of the location and access method<br>
    77. 

  77.    for a resource available on the Internet. Just as there are many<br>
    78. 

  78.    different methods of access to resources, there are several<br>
    79. 

  79.    _schemes_ for describing the location of such resources.<br>
    80. 

  80. <p>
    81. 

  81.    The generic syntax provides a framework for new URL schemes to be<br>
    82. 

  82.    resolved using as yet undefined protocols.<br>
    83. 

  83. <p>
    84. 

  84.    The syntax is described in two parts. First, we give the syntax<br>
    85. 

  85.    rules of a completely specified URL; second, we give the rules<br>
    86. 

  86.    under which parts of the URL may be omitted in a well-defined<br>
    87. 

  87.    context.<br>
    88. 

  88. <p>
    89. 

  89. 2.1. URL SYNTAX<br>
    90. 

  90. <p>
    91. 

  91.    URLs are written as follows:<br>
    92. 

  92. <p>
    93. 

  93.        &lt;scheme&gt;:&lt;scheme-specific-part&gt;<br>
    94. 

  94. <p>
    95. 

  95.    A the URL contains the name of the scheme being used (&lt;scheme&gt;)<br>
    96. 

  96.    followed by a colon and then a string (the &lt;scheme-specific-part&gt;)<br>
    97. 

  97.    whose interpretation depends on the scheme.<br>
    98. 

  98. <p>
    99. 

  99.    Scheme names consist of lower case letters "a"--"z", digits, and<br>
    100. 

  100.    the characters plus ("+"), period ("."), and hyphen ("-"). For<br>
    101. 

  101.    resiliency, programs interpreting URLs should allow upper case<br>
    102. 

  102.    letters as equivalent to lower case in scheme names (e.g., allow<br>
    103. 

  103.    "HTTP" as well as "http").<br>
    104. 

  104. <p>
    105. 

  105.    A BNF description of the URL syntax is given in Section 5.<br>
    106. 

  106. <p>
    107. 

  107. 2.2. Reserved, unsafe, and encoded characters<br>
    108. 

  108. <p>
    109. 

  109.    URLs are represented as a sequence of characters.  Characters are<br>
    110. 

  110.    used to represent the 8-bit byte that corresponds to their ASCII<br>
    111. 

  111.    encoding.<br>
    112. 

  112.  <br>
    113. 

  113.    There is a standard way, known as `URL-encoding', to encode bytes<br>
    114. 

  114.    that are otherwise disallowed: bytes are encoded by representing<br>
    115. 

  115.    them as a percent sign "%" followed by two hexadecimal digits (0-9,<br>
    116. 

  116.    A-F).<br>
    117. 

  117. <p>
    118. 

  118.    In any circumstance, only printable ASCII characters are allowed:<br>
    119. 

  119.    URLs may not contain space or other non-printable characters. These<br>
    120. 

  120.    and the character "%" must always be encoded.<br>
    121. 

  121.    <br>
    122. 

  122.    Many URL schemes reserve certain characters for a special meaning;<br>
    123. 

  123.    their appearance in the scheme-specific part of the URL has a<br>
    124. 

  124.    designated semantics. If it is necessary to designate a byte in a<br>
    125. 

  125.    component of a URL that would otherwise be represented by a<br>
    126. 

  126.    reserved character, it is necessary to represent that byte encoded.<br>
    127. 

  127.    The characters ";", "/", "?", ":", "@", "=" and "&amp;" are the<br>
    128. 

  128.    characters which may be reserved for special meaning within a<br>
    129. 

  129.    scheme.  No other characters may be reserved within a scheme.<br>
    130. 

  130. <p>
    131. 

  131.    Most characters mean the same thing when represented as themselves<br>
    132. 

  132.    as when represented encoded; however, this is not true for reserved<br>
    133. 

  133.    characters: encoding a reserved character for a particular scheme<br>
    134. 

  134.    may change the semantics of a URL.<br>
    135. 

  135. <p>
    136. 

  136.    There are a number of characters whose use in URLs is _unsafe_;<br>
    137. 

  137.    characters can be unsafe for a number of reasons.  The characters<br>
    138. 

  138.    "&lt;" and "&gt;" are unsafe because they are used as the delimiters<br>
    139. 

  139.    around URLs in free text; the quote mark (""") is used to delimit<br>
    140. 

  140.    URLs in other systems. The character "#" is unsafe because it is<br>
    141. 

  141.    used in World Wide Web and in other systems to delimit a URL from a<br>
    142. 

  142.    fragment identifier that might follow it.  Other characters are<br>
    143. 

  143.    unsafe because gateways and other transport agents are sometimes<br>
    144. 

  144.    known to modify such characters. All unsafe characters should<br>
    145. 

  145.    always be encoded within a URL. For example, the character "#"<br>
    146. 

  146.    should always be encoded within URLs, even in systems that do not<br>
    147. 

  147.    normally deal with fragment identifiers, so that if the URL is<br>
    148. 

  148.    copied into another system that does use fragments it will not be<br>
    149. 

  149.    necessary to change the URL encoding.<br>
    150. 

  150.     <br>
    151. 

  151.    In general, only alphanumerics, reserved characters used for their<br>
    152. 

  152.    reserved purposes, "$", "-", "_", ".", and "+" are safe and may be<br>
    153. 

  153.    transmitted unencoded. Even so, safe characters _may_ be encoded<br>
    154. 

  154.    within the scheme specific part of a URL.<br>
    155. 

  155. <p>
    156. 

  156. 3. Specific Schemes<br>
    157. 

  157. <p>
    158. 

  158.    The mapping for some existing standard and experimental protocols<br>
    159. 

  159.    is outlined in the BNF syntax definition.  Notes on particular<br>
    160. 

  160.    protocols follow. The schemes covered are:<br>
    161. 

  161. <p>
    162. 

  162.    ftp                     File Transfer protocol<br>
    163. 

  163.    http                    Hypertext Transfer Protocol<br>
    164. 

  164.    gopher                  The Gopher protocol<br>
    165. 

  165.    mailto                  Electronic mail address<br>
    166. 

  166.    news                    USENET news<br>
    167. 

  167.    nntp                    USENET news using NNTP access<br>
    168. 

  168.    telnet                  Reference to interactive sessions<br>
    169. 

  169.    wais                    Wide Area Information Servers<br>
    170. 

  170.    file                    Host-specific file names<br>
    171. 

  171.    prospero                Prospero Directory Service<br>
    172. 

  172. <p>
    173. 

  173.    Other schemes may be specified by future specifications. Section 4<br>
    174. 

  174.    of this document describes how new schemes may be registered, and<br>
    175. 

  175.    lists some scheme names that are under development.<br>
    176. 

  176. <p>
    177. 

  177. 3.1. Common Internet Scheme Syntax<br>
    178. 

  178. <p>
    179. 

  179.    While the syntax for the rest of the URL may vary depending on the<br>
    180. 

  180.    particular scheme selected, URL schemes that involve the direct use<br>
    181. 

  181.    of an IP-based protocol to a specified host on the Internet use a<br>
    182. 

  182.    common syntax for the initial part of the scheme-specific data:<br>
    183. 

  183. <p>
    184. 

  184.         //&lt;user&gt;:&lt;password&gt;@&lt;host&gt;:&lt;port&gt;<br>
    185. 

  185.         //&lt;user&gt;:&lt;password&gt;@&lt;host&gt;:&lt;port&gt;/&lt;url-path&gt;<br>
    186. 

  186. <p>
    187. 

  187.    This initial part starts with a double slash "//" to indicate its<br>
    188. 

  188.    presence, and continues until the following slash "/", if any.<br>
    189. 

  189.    Within this section are:<br>
    190. 

  190. <p>
    191. 

  191.     user<br>
    192. 

  192.         An optional user name. Some schemes (e.g., ftp) allow the<br>
    193. 

  193.         specification of a user name.<br>
    194. 

  194. <p>
    195. 

  195.     password<br>
    196. 

  196.         An optional password. If present, it follows the user<br>
    197. 

  197.         name separated from it by a colon.<br>
    198. 

  198. <p>
    199. 

  199.    The user name (and password), if present, are followed by a<br>
    200. 

  200.    commercial at-sign "@". Within the user and password field, any<br>
    201. 

  201.    ":", "@", or "/" must be encoded.<br>
    202. 

  202. <p>
    203. 

  203.    Note that an empty user name or password is different than no user<br>
    204. 

  204.    name or password; there is no way to specify a password without<br>
    205. 

  205.    specifying a user name. E.g., &lt;URL:<a href="ftp://@host.com/">ftp://@host.com/</a>&gt; has an empty<br>
    206. 

  206.    user name and no password, &lt;URL:<a href="ftp://host.com/">ftp://host.com/</a>&gt; has no user name,<br>
    207. 

  207.    while &lt;URL:<a href="ftp://foo:@host.com/">ftp://foo:@host.com/</a>&gt; has a user name of "foo" and an<br>
    208. 

  208.    empty password.<br>
    209. 

  209. <p>
    210. 

  210.     host<br>
    211. 

  211.         The fully qualified domain name of a network host, or its IP<br>
    212. 

  212.         address as a set of four decimal digits separated by periods. <br>
    213. 

  213.         Fully qualified domain names take the form as described in<br>
    214. 

  214.         Section 3.5 of RFC 1034: a sequence of parts separated by<br>
    215. 

  215.         period.<br>
    216. 

  216. <p>
    217. 

  217.     port<br>
    218. 

  218.         The (optional) port number to connect to. Most schemes<br>
    219. 

  219.         designate protocols that have a default port number. Another<br>
    220. 

  220.         port number may optionally be supplied, in decimal, separated<br>
    221. 

  221.         from the host by a colon.<br>
    222. 

  222. <p>
    223. 

  223.     url-path<br>
    224. 

  224.         The rest of the locator consists of data specific to the<br>
    225. 

  225.         scheme, and is known as the "url-path". It supplies the<br>
    226. 

  226.         details of how the specified resource can be accessed. Note<br>
    227. 

  227.         that the "/" between the host (or port) and the url-path is<br>
    228. 

  228.         NOT part of the url-path.<br>
    229. 

  229. <p>
    230. 

  230.    The url-path is interpreted in a manner dependent on the scheme<br>
    231. 

  231.    being used.<br>
    232. 

  232. <p>
    233. 

  233. 3.2. FTP<br>
    234. 

  234. <p>
    235. 

  235.    The FTP URL scheme is used to designate files and directories on<br>
    236. 

  236.    Internet hosts accessible using the FTP protocol (RFC959).<br>
    237. 

  237. <p>
    238. 

  238.    A FTP URL follow the syntax described in Section 3.1.  If :&lt;port&gt;<br>
    239. 

  239.    is omitted, the port defaults to 21.<br>
    240. 

  240. <p>
    241. 

  241. 3.2.1. FTP Name and Password<br>
    242. 

  242. <p>
    243. 

  243.    A user name and password may be supplied. If no user name or<br>
    244. 

  244.    password is supplied and one is requested by the FTP server, the<br>
    245. 

  245.    conventions for "anonymous" FTP are to be used, as follows:<br>
    246. 

  246. <p>
    247. 

  247.         The user name "anonymous" is supplied.<br>
    248. 

  248. <p>
    249. 

  249.         The password is supplied as the Internet e-mail address<br>
    250. 

  250.         of the end user accessing the resource.<br>
    251. 

  251. <p>
    252. 

  252.    If the URL supplies a user name but no password, and the remote<br>
    253. 

  253.    server requests a password, the program interpreting the FTP URL<br>
    254. 

  254.    should request one from the user.<br>
    255. 

  255. <p>
    256. 

  256. 3.2.2. FTP url-path<br>
    257. 

  257. <p>
    258. 

  258.    The url-path of a FTP URL has the following syntax:<br>
    259. 

  259. <p>
    260. 

  260.         &lt;cwd1&gt;/&lt;cwd2&gt;/.../&lt;cwdN&gt;/&lt;name&gt;;type=&lt;typecode&gt;<br>
    261. 

  261. <p>
    262. 

  262.    Where &lt;cwd1&gt; through &lt;cwdN&gt; and &lt;name&gt; are (possibly encoded)<br>
    263. 

  263.    strings and &lt;typecode&gt; is one of the characters "a", "i", or "d".<br>
    264. 

  264. <p>
    265. 

  265.    The url-path is interpreted as a series of FTP commands as follows:<br>
    266. 

  266. <p>
    267. 

  267.       Each of the &lt;cwd&gt; elements is to be supplied, sequentially, as<br>
    268. 

  268.       the argument to a CWD (change working directory) command.<br>
    269. 

  269. <p>
    270. 

  270.       If the typecode is "d", perform a NLST (name list) command with<br>
    271. 

  271.       &lt;name&gt; as the argument, and interpret the results as a file<br>
    272. 

  272.       directory listing.<br>
    273. 

  273. <p>
    274. 

  274.       Otherwise, perform a TYPE command with &lt;typecode&gt; as the<br>
    275. 

  275.       argument, and then access the file whose name is &lt;name&gt; (for<br>
    276. 

  276.       example, using the RETR command.)<br>
    277. 

  277. <p>
    278. 

  278.    Within a name or CWD component, the characters "/" and ";" are<br>
    279. 

  279.    reserved and must be encoded. The components are decoded prior to<br>
    280. 

  280.    their use in the FTP protocol.  In particular, if the appropriate<br>
    281. 

  281.    FTP sequence to access a particular file requires supplying a<br>
    282. 

  282.    string containing a "/" as an argument to a CWD or RETR command, it<br>
    283. 

  283.    is necessary to encode each "/" as %2F.<br>
    284. 

  284. <p>
    285. 

  285.    For example, the URL &lt;URL:<a href="ftp://myname@host.dom/%2Fetc/motd">ftp://myname@host.dom/%2Fetc/motd</a>&gt; is<br>
    286. 

  286.    interpreted by FTP-ing to "host.dom", logging in as "myname"<br>
    287. 

  287.    (prompting for a password if it is asked for), and then executing<br>
    288. 

  288.    "CWD /etc" and then "RETR motd". This has a different meaning from<br>
    289. 

  289.    &lt;URL:<a href="ftp://myname@host.dom/etc/motd">ftp://myname@host.dom/etc/motd</a>&gt; which would "CWD etc",<br>
    290. 

  290.    relative to the default directory for "myname", or &lt;URL:ftp:<br>
    291. 

  291.    //myname@host.dom//etc/motd&gt;, which would "CWD " with a null<br>
    292. 

  292.    argument and then "RETR motd".<br>
    293. 

  293. <p>
    294. 

  294. 3.2.3. FTP Typecode is Optional<br>
    295. 

  295. <p>
    296. 

  296.    The entire ;type=&lt;typecode&gt; part of a FTP URL is optional. If it is<br>
    297. 

  297.    omitted, the client program interpreting the URL must guess the<br>
    298. 

  298.    appropriate mode to use. In general, the data content type of a<br>
    299. 

  299.    file can only be guessed from the name, e.g., from the suffix of<br>
    300. 

  300.    the name; the appropriate type code to be used for transfer of the<br>
    301. 

  301.    file can then be deduced from the data content of the file.<br>
    302. 

  302. <p>
    303. 

  303. 3.2.4 Hierarchy<br>
    304. 

  304. <p>
    305. 

  305.    For some file systems, the "/" used to denote the hierarchical<br>
    306. 

  306.    structure of the URL corresponds to the delimiter used to construct<br>
    307. 

  307.    a file name hierarchy, and thus, the filename will look similar to<br>
    308. 

  308.    the URL path. This does NOT mean that the URL is a Unix filename.<br>
    309. 

  309. <p>
    310. 

  310. 3.2.5. Optimization<br>
    311. 

  311. <p>
    312. 

  312.    Clients accessing resources via FTP may employ additional<br>
    313. 

  313.    heuristics to optimize the interaction. For some FTP servers, for<br>
    314. 

  314.    example, it may be reasonable to keep the control connection open<br>
    315. 

  315.    while accessing multiple URLs from the same server. However, there<br>
    316. 

  316.    is no common hierarchical model to the FTP protocol, so if a<br>
    317. 

  317.    directory change command has been given, it is impossible in<br>
    318. 

  318.    general to deduce what sequence should be given to navigate to<br>
    319. 

  319.    another directory for a second retrieval, if the paths are<br>
    320. 

  320.    different.  The only reliable algorithm is to disconnect and<br>
    321. 

  321.    reestablish the control connection.<br>
    322. 

  322. <p>
    323. 

  323. 3.3. HTTP<br>
    324. 

  324. <p>
    325. 

  325.    The HTTP URL scheme is used to designate Internet resources<br>
    326. 

  326.    accessible using HTTP (HyperText Transfer Protocol).<br>
    327. 

  327. <p>
    328. 

  328.    The HTTP protocol is specified elsewhere. This specification only<br>
    329. 

  329.    describes the syntax of HTTP URLs. <br>
    330. 

  330. <p>
    331. 

  331.    An HTTP URL takes the form:<br>
    332. 

  332. <p>
    333. 

  333.       <a href="http://">http://</a>&lt;host&gt;:&lt;port&gt;/&lt;path&gt;?&lt;searchpart&gt;<br>
    334. 

  334. <p>
    335. 

  335.    where &lt;host&gt; and &lt;port&gt; are as described in Section 3.1. If :&lt;port&gt;<br>
    336. 

  336.    is omitted, the port defaults to 80.  No user name or password is<br>
    337. 

  337.    allowed.  &lt;path&gt; is an HTTP selector, and &lt;searchpart&gt; is a query<br>
    338. 

  338.    string. The &lt;path&gt; is optional, as is the &lt;searchpart&gt; and its<br>
    339. 

  339.    preceding "?". If neither &lt;path&gt; nor &lt;searchpart&gt; is present, the<br>
    340. 

  340.    "/" may also be omitted.<br>
    341. 

  341. <p>
    342. 

  342.    Within the &lt;path&gt; and &lt;searchpart&gt; components, "/", ";", "?" are<br>
    343. 

  343.    reserved.  The "/" character may be used within HTTP to designate a<br>
    344. 

  344.    hierarchical structure.<br>
    345. 

  345. <p>
    346. 

  346. 3.4. GOPHER<br>
    347. 

  347. <p>
    348. 

  348.    The Gopher URL scheme is used to designate Internet resources<br>
    349. 

  349.    accessible using the Gopher protocol.<br>
    350. 

  350. <p>
    351. 

  351.    The base Gopher protocol is specified in RFC 1436 and supports<br>
    352. 

  352.    items and collections of items (directories). The Gopher+ protocol<br>
    353. 

  353.    is a set of upward compatible extensions to the base Gopher<br>
    354. 

  354.    protocol and is specified in [2]. Gopher+ supports associating<br>
    355. 

  355.    arbitrary sets of attributes and alternate data representations<br>
    356. 

  356.    with Gopher items. Gopher URLs accommodate both Gopher and Gopher+<br>
    357. 

  357.    items and item attributes.<br>
    358. 

  358. <p>
    359. 

  359. 3.4.1. Gopher URL syntax<br>
    360. 

  360. <p>
    361. 

  361.    A Gopher URL takes the form: <br>
    362. 

  362. <p>
    363. 

  363.       <a href="gopher://">gopher://</a>&lt;host&gt;:&lt;port&gt;/&lt;gopher-path&gt;<br>
    364. 

  364. <p>
    365. 

  365.    where &lt;gopher-path&gt; is one of<br>
    366. 

  366. <p>
    367. 

  367.        &lt;gophertype&gt;&lt;selector&gt;<br>
    368. 

  368.        &lt;gophertype&gt;&lt;selector&gt;%09&lt;search&gt;<br>
    369. 

  369.        &lt;gophertype&gt;&lt;selector&gt;%09&lt;gopher+_string&gt;<br>
    370. 

  370.        &lt;gophertype&gt;&lt;selector&gt;%09&lt;search&gt;%09&lt;gopher+_string&gt;<br>
    371. 

  371. <p>
    372. 

  372.    If :&lt;port&gt; is omitted, the port defaults to 70.  &lt;gophertype&gt; is<br>
    373. 

  373.    single-character field to denote the Gopher type of the resource to<br>
    374. 

  374.    which the URL refers. The entire &lt;gopher-path&gt; may also be empty,<br>
    375. 

  375.    in which case the delimiting "/" is also optional and the<br>
    376. 

  376.    &lt;gophertype&gt; defaults to "1".<br>
    377. 

  377. <p>
    378. 

  378.    &lt;selector&gt; is the Gopher selector string.  In the Gopher protocol,<br>
    379. 

  379.    gopher selector strings are a sequence of 8-bit bytes which may<br>
    380. 

  380.    contain any characters other than tab, return, or linefeed.  Gopher<br>
    381. 

  381.    clients specify which item to retrieve by sending the gopher<br>
    382. 

  382.    selector string to a gopher server.<br>
    383. 

  383.    <br>
    384. 

  384.    Within the &lt;gopher-path&gt;, no additional characters have a reserved<br>
    385. 

  385.    interpretation.<br>
    386. 

  386. <p>
    387. 

  387.    Note that some gopher &lt;selector&gt; strings begin with a copy of the<br>
    388. 

  388.    &lt;gophertype&gt; character, in which case that character will occur<br>
    389. 

  389.    twice consecutively. The gopher selector string may be an empty<br>
    390. 

  390.    string; this is how gopher clients refer to the top-level directory<br>
    391. 

  391.    on a gopher server.<br>
    392. 

  392. <p>
    393. 

  393. 3.4.2 Specifying URLs for Gopher Search Engines<br>
    394. 

  394. <p>
    395. 

  395.    If the URL refers to a search to be submitted to a gopher search<br>
    396. 

  396.    engine, the selector is followed by an encoded tab (%09) and the<br>
    397. 

  397.    search string. To submit a search to a gopher search engine, the<br>
    398. 

  398.    gopher client sends the selector string, a tab, and the search<br>
    399. 

  399.    string to the gopher server.<br>
    400. 

  400. <p>
    401. 

  401. 3.4.3 URL syntax for Gopher+ items<br>
    402. 

  402. <p>
    403. 

  403.    URLs for Gopher+ items are have a second encoded tab and a<br>
    404. 

  404.    gopher+ string. Note that in this case, the %09&lt;search&gt; string must<br>
    405. 

  405.    be supplied, although the &lt;search&gt; element may be the empty string.<br>
    406. 

  406. <p>
    407. 

  407.    The &lt;gopher+_string&gt; is used to represent information required for<br>
    408. 

  408.    retrieval of the Gopher+ item. Gopher+ items may have alternate<br>
    409. 

  409.    views, arbitrary sets of attributes, and may have electronic forms<br>
    410. 

  410.    associated with them.<br>
    411. 

  411. <p>
    412. 

  412.    To retrieve the data associated with a Gopher+ URL, a client will<br>
    413. 

  413.    connect to the server and send the gopher selector, followed<br>
    414. 

  414.    optionally by a tab and the search string, followed by a tab and<br>
    415. 

  415.    the Gopher+ commands.<br>
    416. 

  416. <p>
    417. 

  417.    More explicitly, if the Gopher+ URL refers to a Gopher search type<br>
    418. 

  418.    (that is, if the Gopher type is 7), the client sends to the gopher<br>
    419. 

  419.    server the gopher selector string, followed by a tab, followed the<br>
    420. 

  420.    search string, followed by a tab, followed by the gopher+ commands.<br>
    421. 

  421. <p>
    422. 

  422.    If the Gopher+ URL does _not_ refer to a Gopher search (when the<br>
    423. 

  423.    Gopher type is not 7), the Gopher client sends to the server the<br>
    424. 

  424.    gopher selector string, followed by a tab, followed by the gopher+<br>
    425. 

  425.    commands.<br>
    426. 

  426. <p>
    427. 

  427. 3.4.4 Default Gopher+ data representation<br>
    428. 

  428. <p>
    429. 

  429.    When a Gopher server returns a directory listing to a client, the<br>
    430. 

  430.    Gopher+ items are tagged with either a "+" (denoting gopher+ items)<br>
    431. 

  431.    or a "?" (denoting Gopher+ items which have a +ASK form associated <br>
    432. 

  432.    with them). A Gopher URL with a Gopher+ string consisting of only <br>
    433. 

  433.    a "+" refers to the default view (data representation) of the item <br>
    434. 

  434.    while a Gopher+ string containing only a "?" refer to an item with<br>
    435. 

  435.    a Gopher electronic form associated with it.<br>
    436. 

  436. <p>
    437. 

  437. 3.4.5 Gopher+ items with electronic forms<br>
    438. 

  438. <p>
    439. 

  439.    Gopher+ items which have a +ASK associated with them (i.e. Gopher+<br>
    440. 

  440.    items tagged with a "?") require the client to fetch the item's<br>
    441. 

  441.    +ASK attribute to get the form definition, and then ask the user to<br>
    442. 

  442.    fill out the form and return the user's responses along with the<br>
    443. 

  443.    selector string to retrieve the item.  Gopher+ clients know how to<br>
    444. 

  444.    do this but depend on the "?" tag in the gopher+ item description<br>
    445. 

  445.    to know when to handle this case. The "?" is used in the Gopher+<br>
    446. 

  446.    string to be consistent with Gopher+ protocol's use of this symbol.<br>
    447. 

  447. <p>
    448. 

  448. 3.4.6 Gopher+ item attribute collections<br>
    449. 

  449. <p>
    450. 

  450.    To refer to the Gopher+ attributes of an item, the Gopher URL's <br>
    451. 

  451.    Gopher+ string consists of "!" or "$". "!" refers to the all of a <br>
    452. 

  452.    Gopher+ item's attributes. "$" refers to all the item attributes for<br>
    453. 

  453.    all items in a Gopher directory.<br>
    454. 

  454. <p>
    455. 

  455. 3.4.7 Referring to specific Gopher+ attributes<br>
    456. 

  456. <p>
    457. 

  457.    To refer to specific attributes, the URL's gopher+_string is<br>
    458. 

  458.    "!attribute_name" or "$attribute_name". For example, to refer to<br>
    459. 

  459.    the attribute containing the abstract of an item, the <br>
    460. 

  460.    gopher+_string would be "!+ABSTRACT". <br>
    461. 

  461. <p>
    462. 

  462.    To refer to several attributes, the gopher+_string consists of <br>
    463. 

  463.    the attribute names separated by coded spaces. For example, <br>
    464. 

  464.    "!+ABSTRACT%20+SMELL" refers to the +ABSTRACT and +SMELL attributes <br>
    465. 

  465.    of an item.<br>
    466. 

  466. <p>
    467. 

  467. 3.4.8 URL syntax for Gopher+ alternate views<br>
    468. 

  468. <p>
    469. 

  469.    Gopher+ allows for optional alternate data representations<br>
    470. 

  470.    (alternate views) of items. To retrieve a Gopher+ alternate view,<br>
    471. 

  471.    a Gopher+ client sends the appropriate view and language<br>
    472. 

  472.    identifier (found in the item's +VIEW attribute). To refer to a<br>
    473. 

  473.    specific Gopher+ alternate view, the URL's Gopher+ string would <br>
    474. 

  474.    be in the form:<br>
    475. 

  475. <p>
    476. 

  476.         +view_name%20language_name<br>
    477. 

  477. <p>
    478. 

  478.    For example, a Gopher+ string of "+application/postscript%20Es_ES" <br>
    479. 

  479.    refers to the Spanish language postscript alternate view of a <br>
    480. 

  480.    Gopher+ item. <br>
    481. 

  481. <p>
    482. 

  482. 3.4.9 URL syntax for Gopher+ electronic forms<br>
    483. 

  483. <p>
    484. 

  484.    The gopher+ string for a URL that refers to an item referenced by<br>
    485. 

  485.    a Gopher+ electronic form (an ASK block) filled out with specific <br>
    486. 

  486.    values is a coded version of what the client sends to the server.<br>
    487. 

  487.    The gopher+ string is of the form:<br>
    488. 

  488. <p>
    489. 

  489.    +%091%0D%0A+-1%0D%0Aask_item1_value%0D%0Aask_item2_value%0D%0A.%0D%0A<br>
    490. 

  490. <p>
    491. 

  491.    To retrieve this item, the gopher client sends:<br>
    492. 

  492. <p>
    493. 

  493.        a_gopher_selector&lt;tab&gt;+&lt;tab&gt;1&lt;cr&gt;&lt;lf&gt;<br>
    494. 

  494.        +-1&lt;cr&gt;&lt;lf&gt;<br>
    495. 

  495.        ask_item1_value&lt;cr&gt;&lt;lf&gt;<br>
    496. 

  496.        ask_item2_value&lt;cr&gt;&lt;lf&gt;<br>
    497. 

  497.        .&lt;cr&gt;&lt;lf&gt;<br>
    498. 

  498. <p>
    499. 

  499.    to the gopher server.<br>
    500. 

  500. <p>
    501. 

  501. 3.5. MAILTO<br>
    502. 

  502. <p>
    503. 

  503.    The mailto URL scheme is used to designate the Internet mailing<br>
    504. 

  504.    address of an individual or service. No additional information<br>
    505. 

  505.    other than an Internet mailing address is present or implied.<br>
    506. 

  506. <p>
    507. 

  507.    A mailto URL takes the form:<br>
    508. 

  508. <p>
    509. 

  509.         <a href="mailto:">mailto:</a>&lt;rfc822-addr-spec&gt;<br>
    510. 

  510. <p>
    511. 

  511.    where &lt;rfc822-addr-spec&gt; is (the encoding of an) addr-spec, as<br>
    512. 

  512.    specified in RFC 822. Within mailto URLs, no additional characters<br>
    513. 

  513.    are reserved within the &lt;rfc822-addr-spec&gt; component.<br>
    514. 

  514. <p>
    515. 

  515.    Note that the percent sign ("%") is commonly used within RFC 822<br>
    516. 

  516.    addresses and must be URL-encoded.<br>
    517. 

  517. <p>
    518. 

  518.    Unlike many URLs, the mailto scheme does not represent a data<br>
    519. 

  519.    object to be accessed directly; there is no sense in which it<br>
    520. 

  520.    designates an object. It has a different use than the<br>
    521. 

  521.    message/external-body type in MIME.<br>
    522. 

  522. <p>
    523. 

  523. 3.6. NEWS<br>
    524. 

  524. <p>
    525. 

  525.    The news URL scheme is used to refer to either news groups or<br>
    526. 

  526.    individual articles of USENET news, as specified in RFC 1036.<br>
    527. 

  527. <p>
    528. 

  528.    A news URL takes one of two forms:<br>
    529. 

  529. <p>
    530. 

  530.      <a href="news:">news:</a>&lt;newsgroup-name&gt;<br>
    531. 

  531.      <a href="news:">news:</a>&lt;message-id&gt;<br>
    532. 

  532. <p>
    533. 

  533.    A &lt;newsgroup-name&gt; is a period-delimited hierarchical name, such as<br>
    534. 

  534.    "comp.infosystems.www.misc". A &lt;message-id&gt; corresponds to the<br>
    535. 

  535.    Message-ID of section 2.1.5 of RFC 1036, without the enclosing "&lt;"<br>
    536. 

  536.    and "&gt;"; it takes the form &lt;unique&gt;@&lt;full_domain_name&gt;.  A message<br>
    537. 

  537.    identifier may be distinguished from a news group name by the<br>
    538. 

  538.    presence of the commercial at "@" character. No additional<br>
    539. 

  539.    characters are reserved within the components of a news URL.<br>
    540. 

  540. <p>
    541. 

  541.    If &lt;newsgroup-name&gt; is "*" (as in &lt;URL:<a href="news:">news:</a>*&gt;), it is used to<br>
    542. 

  542.    refer to "all available news groups".<br>
    543. 

  543. <p>
    544. 

  544.    The news URLs are unusual in that by themselves, they do not<br>
    545. 

  545.    contain sufficient information to locate a single resource, but,<br>
    546. 

  546.    rather, are location-independent.<br>
    547. 

  547. <p>
    548. 

  548. 3.7. NNTP<br>
    549. 

  549. <p>
    550. 

  550.    The nntp URL scheme is an alternative method of referencing news<br>
    551. 

  551.    articles, useful for specifying news articles from NNTP servers<br>
    552. 

  552.    (RFC 977). <br>
    553. 

  553. <p>
    554. 

  554.    A nntp URL take the form:<br>
    555. 

  555. <p>
    556. 

  556.       nntp://&lt;host&gt;:&lt;port&gt;/&lt;newsgroup-name&gt;/&lt;article-number&gt;<br>
    557. 

  557. <p>
    558. 

  558.    where &lt;host&gt; and &lt;port&gt; are as described in Section 3.1. If :&lt;port&gt;<br>
    559. 

  559.    is omitted, the port defaults to 119.<br>
    560. 

  560. <p>
    561. 

  561.    The &lt;newsgroup-name&gt; is the name of the group, while the<br>
    562. 

  562.    &lt;article-number&gt; is the numeric id of the article within that<br>
    563. 

  563.    newsgroup.<br>
    564. 

  564. <p>
    565. 

  565.    Note that while nntp: URLs specify a unique location for the<br>
    566. 

  566.    article resource, most NNTP servers currently on the Internet today<br>
    567. 

  567.    are configured only to allow access from local clients, and thus<br>
    568. 

  568.    nntp URLs do not designate globally accessible resources. Thus, the<br>
    569. 

  569.    <a href="news:">news:</a> form of URL is preferred as a way of identifying news<br>
    570. 

  570.    articles.<br>
    571. 

  571. <p>
    572. 

  572. 3.8. TELNET<br>
    573. 

  573. <p>
    574. 

  574.    The Telnet URL scheme is used to designate interactive services<br>
    575. 

  575.    that may be accessed by the Telnet protocol.<br>
    576. 

  576. <p>
    577. 

  577.    A telnet URL takes the form:<br>
    578. 

  578. <p>
    579. 

  579.        telnet://&lt;user&gt;:&lt;password&gt;@&lt;host&gt;:&lt;port&gt; [ / ]<br>
    580. 

  580. <p>
    581. 

  581.    as specified in Section 3.1. The port defaults to 23; the &lt;user&gt;<br>
    582. 

  582.    and &lt;password&gt; segments are completely optional (a &lt;password&gt;<br>
    583. 

  583.    requires a &lt;user&gt; element.)<br>
    584. 

  584. <p>
    585. 

  585.    This URL does not designate a data object, but rather an<br>
    586. 

  586.    interactive service. In practice, the &lt;user&gt; and &lt;password&gt;<br>
    587. 

  587.    supplied are advisory only.<br>
    588. 

  588. <p>
    589. 

  589. 3.9.  WAIS<br>
    590. 

  590. <p>
    591. 

  591.    The WAIS URL scheme is used to designate WAIS databases, searches,<br>
    592. 

  592.    or individual documents available from a WAIS database. WAIS is<br>
    593. 

  593.    described in [6]; the WAIS protocol is described in RFC 1625 [19].<br>
    594. 

  594. <p>
    595. 

  595.    A WAIS URLs takes one the following forms:<br>
    596. 

  596. <p>
    597. 

  597.      <a href="wais://">wais://</a>&lt;host&gt;:&lt;port&gt;/&lt;database&gt;<br>
    598. 

  598.      <a href="wais://">wais://</a>&lt;host&gt;:&lt;port&gt;/&lt;database&gt;?&lt;search&gt;<br>
    599. 

  599.      <a href="wais://">wais://</a>&lt;host&gt;:&lt;port&gt;/&lt;database&gt;/&lt;wtype&gt;/&lt;wpath&gt;<br>
    600. 

  600. <p>
    601. 

  601.    where &lt;host&gt; and &lt;port&gt; are as described in Section 3.1. If :&lt;port&gt;<br>
    602. 

  602.    is omitted, the port defaults to 210.  The first form designates a<br>
    603. 

  603.    WAIS database that is available for searching. The second form<br>
    604. 

  604.    designates a particular search.  &lt;database&gt; is the name of the WAIS<br>
    605. 

  605.    database being queried.<br>
    606. 

  606. <p>
    607. 

  607.    The third form designates a particular document within a WAIS<br>
    608. 

  608.    database to be retrieved. In this form &lt;wtype&gt; is the WAIS<br>
    609. 

  609.    designation of the type of the object. Many WAIS implementations<br>
    610. 

  610.    require that a client know the "type" of an object prior to<br>
    611. 

  611.    retrieval, the type being returned along with the internal object<br>
    612. 

  612.    identifier in the search response.  The &lt;wtype&gt; is included in the<br>
    613. 

  613.    URL in order to allow the client interpreting the URL adequate<br>
    614. 

  614.    information to actually retrieve the document.<br>
    615. 

  615. <p>
    616. 

  616.    The &lt;wpath&gt; of a WAIS URL consists of the WAIS document-id, encoded<br>
    617. 

  617.    as necessary using the method described in Section 2.2. The WAIS<br>
    618. 

  618.    document-id should be treated opaquely; it may only be decomposed<br>
    619. 

  619.    by the server that issued it.<br>
    620. 

  620. <p>
    621. 

  621. 3.10 FILES<br>
    622. 

  622. <p>
    623. 

  623.    The file URL scheme is used to designate files accessible on<br>
    624. 

  624.    a particular host computer. This scheme, unlike most other <br>
    625. 

  625.    URL schemes, does not designate a resource that is universally<br>
    626. 

  626.    accessible over the Internet.<br>
    627. 

  627. <p>
    628. 

  628.    A file URL takes the form:<br>
    629. 

  629. <p>
    630. 

  630.        <a href="file://">file://</a>&lt;host&gt;/&lt;path&gt;<br>
    631. 

  631. <p>
    632. 

  632.    where &lt;host&gt; is the fully qualified domain name of the system on<br>
    633. 

  633.    which the &lt;path&gt; is accessible, and &lt;path&gt; is a hierarchical<br>
    634. 

  634.    directory path of the form &lt;directory&gt;/&lt;directory&gt;/&lt;name&gt;.<br>
    635. 

  635. <p>
    636. 

  636.    For example, a VMS file<br>
    637. 

  637. <p>
    638. 

  638.      DISK$USER:[MY.NOTES]NOTE123456.TXT<br>
    639. 

  639. <p>
    640. 

  640.    might become<br>
    641. 

  641. <p>
    642. 

  642.      &lt;URL:<a href="file://vms.host.edu/disk$user/my/notes/note12345.txt">file://vms.host.edu/disk$user/my/notes/note12345.txt</a>&gt;<br>
    643. 

  643. <p>
    644. 

  644.    As a special case, &lt;host&gt; can be the string "localhost" or the<br>
    645. 

  645.    empty string; this is interpreted as `the machine from which the<br>
    646. 

  646.    URL is being interpreted'.<br>
    647. 

  647. <p>
    648. 

  648.    The file URL scheme is unusual in that it does not specify an<br>
    649. 

  649.    Internet protocol or access method for such files; as such, its<br>
    650. 

  650.    utility in network protocols between hosts is limited.<br>
    651. 

  651. <p>
    652. 

  652. 3.11 PROSPERO<br>
    653. 

  653. <p>
    654. 

  654.    The Prospero URL scheme is used to designate resources that are<br>
    655. 

  655.    accessed via the Prospero Directory Service. The Prospero protocol<br>
    656. 

  656.    is described elsewhere [16].<br>
    657. 

  657. <p>
    658. 

  658.    A prospero URLs takes the form:<br>
    659. 

  659. <p>
    660. 

  660.       prospero://&lt;host&gt;:&lt;port&gt;/&lt;hsoname&gt;;&lt;field&gt;=&lt;value&gt;<br>
    661. 

  661. <p>
    662. 

  662.    where &lt;host&gt; and &lt;port&gt; are as described in Section 3.1. If :&lt;port&gt;<br>
    663. 

  663.    is omitted, the port defaults to 1525. No username or password is<br>
    664. 

  664.    allowed.<br>
    665. 

  665. <p>
    666. 

  666.    The &lt;hsoname&gt; is the host-specific object name in the Prospero<br>
    667. 

  667.    protocol, suitably encoded.  This name is opaque and interpreted by<br>
    668. 

  668.    the Prospero server.  The semicolon ";" is reserved and may not<br>
    669. 

  669.    appear without quoting in the &lt;hsoname&gt;.<br>
    670. 

  670. <p>
    671. 

  671.    Prospero URLs are interpreted by contacting a Prospero directory<br>
    672. 

  672.    server on the specified host and port to determine appropriate<br>
    673. 

  673.    access methods for a resource, which might themselves be<br>
    674. 

  674.    represented as different URLs. External Prospero links are<br>
    675. 

  675.    represented as URLs of the underlying access method and are not<br>
    676. 

  676.    represented as Prospero URLs.<br>
    677. 

  677. <p>
    678. 

  678.    Note that a slash "/" may appear in the &lt;hsoname&gt; without quoting<br>
    679. 

  679.    and no significance may be assumed by the application.  Though<br>
    680. 

  680.    slashes may indicate hierarchical structure on the server, such<br>
    681. 

  681.    structure is not guaranteed. Note that many &lt;hsoname&gt;s begin with a<br>
    682. 

  682.    slash, in which case the host or port will be followed by a double<br>
    683. 

  683.    slash: the slash from the URL syntax, followed by the initial slash<br>
    684. 

  684.    from the &lt;hsoname&gt;. (E.g., &lt;URL:prospero://host.dom//pros/name&gt;<br>
    685. 

  685.    designates a &lt;hsoname&gt; of "/pros/name".)<br>
    686. 

  686. <p>
    687. 

  687.    In addition, after the &lt;hsoname&gt;, optional fields and values<br>
    688. 

  688.    associated with a Prospero link may be specified as part of the<br>
    689. 

  689.    URL.  When present, each field/value pair is separated from each<br>
    690. 

  690.    other and from the rest of the URL by a ";" (semicolon).  The name<br>
    691. 

  691.    of the field and its value are separated by a "=" (equal sign). If<br>
    692. 

  692.    present, these fields serve to identify the target of the URL.  For<br>
    693. 

  693.    example, the OBJECT-VERSION field can be specified to identify a<br>
    694. 

  694.    specific version of an object.<br>
    695. 

  695. <p>
    696. 

  696. 4. REGISTRATION OF NEW SCHEMES<br>
    697. 

  697. <p>
    698. 

  698.    A new scheme may be introduced by defining a mapping onto a<br>
    699. 

  699.    conforming URL syntax, using a new prefix. Experimental prefixes<br>
    700. 

  700.    may be used by mutual agreement between parties. Scheme names<br>
    701. 

  701.    starting with the characters "x-" are reserved for experimental<br>
    702. 

  702.    purposes.<br>
    703. 

  703. <p>
    704. 

  704.    The Internet Assigned Numbers Authority (IANA) will maintain a<br>
    705. 

  705.    registry of URL schemes. Any submission of a new URL scheme must<br>
    706. 

  706.    include a definition of an algorithm for accessing of resources<br>
    707. 

  707.    within that scheme and the syntax for representing such a scheme.<br>
    708. 

  708. <p>
    709. 

  709.    URL schemes must have demonstrable utility and operability.  One<br>
    710. 

  710.    way to provide such a demonstration is via a gateway which provides<br>
    711. 

  711.    objects in the new scheme for clients using an existing protocol.<br>
    712. 

  712.    If the new scheme does not locate resources that are data objects,<br>
    713. 

  713.    the properties of names in the new space must be clearly defined.<br>
    714. 

  714. <p>
    715. 

  715.    New schemes should try to follow the same syntactic conventions of<br>
    716. 

  716.    existing schemes, where appropriate.  It is likewise recommended<br>
    717. 

  717.    that, where a protocol allows for retrieval by URL, that the client<br>
    718. 

  718.    software have provision for being configured to use specific<br>
    719. 

  719.    gateway locators for indirect access through new naming schemes.<br>
    720. 

  720. <p>
    721. 

  721.    The following scheme have been proposed at various times, but this<br>
    722. 

  722.    document does not define their syntax or use at this time. It is<br>
    723. 

  723.    suggested that IANA reserve their scheme names for future<br>
    724. 

  724.    definition:<br>
    725. 

  725. <p>
    726. 

  726.    afs	            Andrew File System global file names.<br>
    727. 

  727.    mid              Message identifiers for electronic mail.<br>
    728. 

  728.    cid              Content identifiers for MIME body parts.<br>
    729. 

  729.    nfs              Network File System (NFS) file names.<br>
    730. 

  730.    tn3270           Interactive 3270 emulation sessions.<br>
    731. 

  731.    mailserver       Access to data available from mail servers.<br>
    732. 

  732.    z39.50           Access to ANSI Z39.50 services.<br>
    733. 

  733. <p>
    734. 

  734. 5. BNF for specific URL schemes<br>
    735. 

  735. <p>
    736. 

  736.    This is a BNF-like description of the Uniform Resource Locator<br>
    737. 

  737.    syntax, using the conventions of RFC822, except that "|" is used to<br>
    738. 

  738.    designate alternatives, and brackets [] are used around optional or<br>
    739. 

  739.    repeated elements. Briefly, literals are quoted with "", optional<br>
    740. 

  740.    elements are enclosed in [brackets], and elements may be preceded<br>
    741. 

  741.    with &lt;n&gt;* to designate n or more repetitions of the following<br>
    742. 

  742.    element; n defaults to 0.<br>
    743. 

  743. <p>
    744. 

  744.    url            = httpurl | ftpurl | newsurl |<br>
    745. 

  745.                     nntpurl | telneturl | gopherurl |<br>
    746. 

  746.                     waisurl | mailtourl | fileurl |<br>
    747. 

  747.                     prosperourl | otherurl<br>
    748. 

  748.    otherurl       = scheme ":" schemepart<br>
    749. 

  749.    scheme         = 1*[ lowalpha | digit | "+" | "-" | "." ]<br>
    750. 

  750.    schemepart     = *xchar<br>
    751. 

  751. <p>
    752. 

  752.    login          = [ user [ ":" password ] "@" ] hostport<br>
    753. 

  753.    hostport       = host [ ":" port ]<br>
    754. 

  754.    host           = hostname | hostnumber<br>
    755. 

  755.    hostname       = alpha *uchar<br>
    756. 

  756.    hostnumber     = digits "." digits "." digits "." digits<br>
    757. 

  757.    port           = digits<br>
    758. 

  758.    user           = *[ uchar | ";" | "?" | "&amp;" | "=" ]<br>
    759. 

  759.    password       = *[ uchar | ";" | "?" | "&amp;" | "=" ]<br>
    760. 

  760. <p>
    761. 

  761.    ftpurl         = "<a href="ftp://">ftp://</a>" login [ "/" fpath [ ";type=" ftptype ]]<br>
    762. 

  762.    fpath          = fsegment *[ "/" fsegment ]<br>
    763. 

  763.    fsegment       = *[ uchar | "?" | ":" | "@" | "&amp;" | "=" ]<br>
    764. 

  764.    ftptype        = "A" | "I" | "D" | "a" | "i" | "d"<br>
    765. 

  765. <p>
    766. 

  766.    fileurl        = "<a href="file://">file://</a>" host [ "/" fpath ]<br>
    767. 

  767. <p>
    768. 

  768.    httpurl        = "<a href="http://">http://</a>" hostport [ "/" hpath [ "?" search ]]<br>
    769. 

  769.    hpath          = hsegment *[ "/" hsegment ]<br>
    770. 

  770.    hsegment       = *[ uchar | ";" | ":" | "@" | "&amp;" | "=" ]<br>
    771. 

  771.    search         = *[ uchar | ";" | ":" | "@" | "&amp;" | "=" ]<br>
    772. 

  772. <p>
    773. 

  773.    gopherurl      = "<a href="gopher://">gopher://</a>" hostport [ / [ gtype [ selector<br>
    774. 

  774.                     [ "%09" search [ "%09" gopher+_string ] ] ] ] ]<br>
    775. 

  775.    gtype          = xchar<br>
    776. 

  776.    selector       = *xchar<br>
    777. 

  777.    gopher+_string = *xchar<br>
    778. 

  778. <p>
    779. 

  779.    mailtourl      = "<a href="mailto:">mailto:</a>" encoded822addr<br>
    780. 

  780.    encoded822addr = 1*xchar<br>
    781. 

  781. <p>
    782. 

  782.    newsurl        = "<a href="news:">news:</a>" grouppart<br>
    783. 

  783.    grouppart      = "*" | group | article<br>
    784. 

  784.    group          = alpha *[ alpha | digit | "-" | "." ]<br>
    785. 

  785.    article        = 1*[ uchar | ";" | "/" | "?" | ":" | "&amp;" | "=" ] "@" host<br>
    786. 

  786. <p>
    787. 

  787.    nntpurl        = "nntp://" hostport "/" group [ "/" digits ]<br>
    788. 

  788. <p>
    789. 

  789.    telneturl      = "<a href="telnet://">telnet://</a>" login [ "/" ]<br>
    790. 

  790. <p>
    791. 

  791.    waisurl        = waisdatabase | waisindex | waisdoc<br>
    792. 

  792.    waisdatabase   = "<a href="wais://">wais://</a>" hostport "/" database<br>
    793. 

  793.    waisindex      = "<a href="wais://">wais://</a>" hostport "/" database "?" search<br>
    794. 

  794.    waisdoc        = "<a href="wais://">wais://</a>" hostport "/" database "/" wtype "/" wpath<br>
    795. 

  795.    database       = *uchar<br>
    796. 

  796.    wtype          = *uchar<br>
    797. 

  797.    wpath          = *uchar<br>
    798. 

  798. <p>
    799. 

  799.    prosperourl    = "prospero://" hostport "/" ppath *[ fieldspec ]<br>
    800. 

  800.    ppath          = psegment *[ "/" psegment ]<br>
    801. 

  801.    psegment       = *[ uchar | "?" | ":" | "@" | "&amp;" | "=" ]<br>
    802. 

  802.    fieldspec      = ";" fieldname "=" fieldvalue<br>
    803. 

  803.    fieldname      = *[ uchar | "?" | ":" | "@" | "&amp;" ]<br>
    804. 

  804.    fieldvalue     = *[ uchar | "?" | ":" | "@" | "&amp;" ]<br>
    805. 

  805. <p>
    806. 

  806.    lowalpha       = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" |<br>
    807. 

  807.                     "i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" |<br>
    808. 

  808.                     "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" |<br>
    809. 

  809.                     "y" | "z"<br>
    810. 

  810.    hialpha        = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" | <br>
    811. 

  811.                     "J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" | <br>
    812. 

  812.                     "S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z"<br>
    813. 

  813.    alpha          = lowalpha | hialpha<br>
    814. 

  814.    digit          = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |<br>
    815. 

  815.                     "8" | "9"<br>
    816. 

  816.    safe           = "$" | "-" | "_" | "." | "+"<br>
    817. 

  817.    extra          = "!" | "*" | "'" | "(" | ")" | "," | "="<br>
    818. 

  818.    national       = "{" | "}" | "|" | "\" | "^" | "~" | "[" | "]"<br>
    819. 

  819.    punctuation    = "&lt;" | "&gt;" | """ | "#"<br>
    820. 

  820.    reserved       = ";" | "/" | "?" | ":" | "@" | "&amp;" | "="<br>
    821. 

  821.    hex            = digit | "A" | "B" | "C" | "D" | "E" | "F" |<br>
    822. 

  822. 		    "a" | "b" | "c" | "d" | "e" | "f"<br>
    823. 

  823.    escape         = "%" hex hex<br>
    824. 

  824. <p>
    825. 

  825.    unreserved     = alpha | digit | safe | extra | national<br>
    826. 

  826.    uchar          = unreserved | escape<br>
    827. 

  827.    xchar          = unreserved | reserved | escape<br>
    828. 

  828.    digits         = 1*digit<br>
    829. 

  829. <p>
    830. 

  830. <p>
    831. 

  831. 6. Security considerations<br>
    832. 

  832. <p>
    833. 

  833.    The URL scheme does not in itself pose a security threat. Users<br>
    834. 

  834.    should beware that there is no general guarantee that a URL which<br>
    835. 

  835.    at one time points to a given object continues to do so, and does<br>
    836. 

  836.    not even at some later time point to a different object due to the<br>
    837. 

  837.    movement of objects on servers.<br>
    838. 

  838. <p>
    839. 

  839.    A URL-related security threat is that it is sometimes possible to<br>
    840. 

  840.    construct a URL such that an attempt to perform a harmless<br>
    841. 

  841.    idempotent operation such as the retrieval of the object will in<br>
    842. 

  842.    fact cause a possibly damaging remote operation to occur.  The<br>
    843. 

  843.    unsafe URL is typically constructed by specifying a port number<br>
    844. 

  844.    other than that reserved for the network protocol in question.  The<br>
    845. 

  845.    client unwittingly contacts a server which is in fact running a<br>
    846. 

  846.    different protocol.  The content of the URL contains instructions<br>
    847. 

  847.    which when interpreted according to this other protocol cause an<br>
    848. 

  848.    unexpected operation. An example has been the use of gopher URLs<br>
    849. 

  849.    to cause a rude message to be sent via a SMTP server.  Caution<br>
    850. 

  850.    should be used when using any URL which specifies a port number<br>
    851. 

  851.    other than the default for the protocol, especially when it is a<br>
    852. 

  852.    number within the reserved space.<br>
    853. 

  853. <p>
    854. 

  854.    Care should be taken when URLs contain embedded encoded delimiters<br>
    855. 

  855.    for a given protocol (for example, CR and LF characters for telnet<br>
    856. 

  856.    protocols) that these are not unencoded before transmission.  This<br>
    857. 

  857.    would violate the protocol but could be used to simulate an extra<br>
    858. 

  858.    operation or parameter, again causing an unexpected and possible<br>
    859. 

  859.    harmful remote operation to be performed.<br>
    860. 

  860. <p>
    861. 

  861.    The use of URLs containing passwords that should be secret is<br>
    862. 

  862.    clearly unwise.<br>
    863. 

  863. <p>
    864. 

  864. 7. Acknowledgements<br>
    865. 

  865. <p>
    866. 

  866.    This paper builds on the basic W3 design and much discussion of<br>
    867. 

  867.    these issues by many people on the network. The discussion was<br>
    868. 

  868.    particularly stimulated by articles by Clifford Lynch (1991),<br>
    869. 

  869.    Brewster Kahle (1991) and Wengyik Yeong (1991b). Contributions from<br>
    870. 

  870.    John Curran (NEARNET), Clifford Neuman (ISI) Ed Vielmetti (MSEN)<br>
    871. 

  871.    and later the IETF URL BOF and URI working group have been<br>
    872. 

  872.    incorporated into this issue of this paper.<br>
    873. 

  873. <p>
    874. 

  874.    The draft url4 (Internet Draft 00) was generated from url3<br>
    875. 

  875.    following discussion and overall approval of the URL working group<br>
    876. 

  876.    on 29 March 1993. The paper url3 had been generated from udi2 in<br>
    877. 

  877.    the light of discussion at the UDI BOF meeting at the Boston IETF<br>
    878. 

  878.    in July 1992. Draft url4 was Internet Draft 00. Draft url5<br>
    879. 

  879.    incorporated changes suggested by Clifford Neuman, and draft url6<br>
    880. 

  880.    (ID 01) incorporated character group changes and a few other fixes<br>
    881. 

  881.    defined by the IETF URI WG in submitting it as a proposed standard.<br>
    882. 

  882.    URL7 (Internet Draft 02) incorporated changes introduced at the<br>
    883. 

  883.    Amsterdam IETF and refined in net discussion.<br>
    884. 

  884. <p>
    885. 

  885.    The draft 03 includes changes made at Houston in Nov 93, and on the<br>
    886. 

  886.    net before Seattle March 1994.  Draft 04 responded to various<br>
    887. 

  887.    suggestions and remarks made since the Seattle March 1994 meeting,<br>
    888. 

  888.    special thanks to Dan Connolly, Ned Freed, Roy Fielding, and Guido<br>
    889. 

  889.    van Rossum for their careful readings and corrections.  Draft 05<br>
    890. 

  890.    makes a number of minor modifications suggested at or just before<br>
    891. 

  891.    the Toronto July 1994 IETF meeting. This draft incorporates<br>
    892. 

  892.    numerous revisions and edits as suggested by the active members of<br>
    893. 

  893.    the IETF URI Working Group.<br>
    894. 

  894. <p>
    895. 

  895. APPENDIX: Recommendations for URLs in Context<br>
    896. 

  896. <p>
    897. 

  897.    URIs, including URLs, are intended to be transmitted though<br>
    898. 

  898.    protocols which provide a context for their interpretation.<br>
    899. 

  899. <p>
    900. 

  900.    In some cases, it will be necessary to distinguish URLs from other<br>
    901. 

  901.    possible data structures in a syntactic structure. In this case, is<br>
    902. 

  902.    recommended that URLs be preceeded with a prefix consisting of the<br>
    903. 

  903.    characters "URL:". For example, this prefix may be used to<br>
    904. 

  904.    distinguish URLs from other kinds of URIs.<br>
    905. 

  905. <p>
    906. 

  906.    In addition, there are many occasions when URLs are included in<br>
    907. 

  907.    plain, non-marked-up text; examples include electronic mail, USENET<br>
    908. 

  908.    news messages, or printed papers. In such cases, it is convenient<br>
    909. 

  909.    to have a separate syntactic wrapper that delimits the URL and<br>
    910. 

  910.    separates it from the rest of the text. For this purpose, is<br>
    911. 

  911.    recommended that angle brackets ("&lt;" and "&gt;"), along with the<br>
    912. 

  912.    prefix "URL:", be used to delimit the boundaries of the URL.  This<br>
    913. 

  913.    wrapper does not form part of the URL and should not be used in<br>
    914. 

  914.    contexts in which delimiters are already specified.<br>
    915. 

  915. <p>
    916. 

  916.    In some cases, extra whitespace may need to be added to break long<br>
    917. 

  917.    URLs across lines. The whitespace is ignored when extracting the<br>
    918. 

  918.    URL. In the case where a fragment identifier is associated with a<br>
    919. 

  919.    URL (following a "#"), the identifier would be placed within the<br>
    920. 

  920.    brackets as well.<br>
    921. 

  921. <p>
    922. 

  922.    Examples<br>
    923. 

  923. <p>
    924. 

  924.    Yes, Jim, I found it under &lt;URL:<a href="ftp://info.cern.ch/pub/www/doc">ftp://info.cern.ch/pub/www/doc</a><br>
    925. 

  925.    ;type=d&gt; but you can probably pick it up from &lt;URL:<a href="ftp://ds.inter">ftp://ds.inter</a><br>
    926. 

  926.    nic.net/rfc&gt;.  Note the warning in &lt;URL:<a href="http://ds.internic.net/">http://ds.internic.net/</a><br>
    927. 

  927.    instructions/overview.html#WARNING&gt;.<br>
    928. 

  928. <p>
    929. 

  929. REFERENCES<br>
    930. 

  930. <p>
    931. 

  931.    [1] Anklesaria, F., et al. (1993) "The Internet Gopher Protocol",<br>
    932. 

  932.        RFC 1436. &lt;URL:<a href="ftp://ds.internic.net/rfc/rfc1436.txt">ftp://ds.internic.net/rfc/rfc1436.txt</a>&gt;.<br>
    933. 

  933. <p>
    934. 

  934.    [2] Anklesaria, F., et al. (1993) "Gopher+ upward compatible<br>
    935. 

  935.        enhancements to the Internet Gopher protocol", University of<br>
    936. 

  936.        Minnesota, July 1993, &lt;URL:<a href="ftp://boombox.micro.umn.edu">ftp://boombox.micro.umn.edu</a><br>
    937. 

  937.        /pub/gopher/gopher_protocol/Gopher+/Gopher+.txt&gt;.  See also:<br>
    938. 

  938.        &lt;URL:<a href="gopher://boombox.micro.umn.edu/11/gopher/">gopher://boombox.micro.umn.edu/11/gopher/</a><br>
    939. 

  939.        gopher_protocol&gt;.<br>
    940. 

  940. <p>
    941. 

  941.    [3] Berners-Lee, T., (1994) "Universal Resource Identifiers in<br>
    942. 

  942.        WWW".  RFC 1630, &lt;URL:<a href="ftp://ds.internic.net/rfc/rfc1630.txt">ftp://ds.internic.net/rfc/rfc1630.txt</a>&gt;.<br>
    943. 

  943. <p>
    944. 

  944.    [4] Berners-Lee, T ., (1993) "Hypertext Transfer Protocol (HTTP)" ,<br>
    945. 

  945.        CERN, November 1993, as updated from time to time,<br>
    946. 

  946.        &lt;URL:<a href="ftp://info.cern.ch/pub/www/doc/http-spec.txt.Z">ftp://info.cern.ch/pub/www/doc/http-spec.txt.Z</a>&gt;.<br>
    947. 

  947. <p>
    948. 

  948.    [5] Crocker, D. H., (1982) "Standard for ARPA Internet Text<br>
    949. 

  949.        Messages".  RFC822, &lt;URL:<a href="ftp://ds.internic.net/rfc/rfc822.txt">ftp://ds.internic.net/rfc/rfc822.txt</a>&gt;.<br>
    950. 

  950. <p>
    951. 

  951.    [6] Davis, F, et al., (1990) "WAIS Interface Protocol Prototype<br>
    952. 

  952.        Functional Specification", Thinking Machines Corporation, April<br>
    953. 

  953.        23, 1990 &lt;URL:<a href="ftp://quake.think.com/pub/wais/doc/protspec.txt">ftp://quake.think.com/pub/wais/doc/protspec.txt</a>&gt;.<br>
    954. 

  954. <p>
    955. 

  955.    [7] Deutsch, P., Emtage, A. &amp; Marine, A. (1994) "How to Use<br>
    956. 

  956.        Anonymous FTP." RFC1635. &lt;URL:<a href="ftp://ds.internic.net/">ftp://ds.internic.net/</a><br>
    957. 

  957.        rfc/rfc1635.txt&gt;.<br>
    958. 

  958. <p>
    959. 

  959.    [8] International Standards Organization, (1991) Information and<br>
    960. 

  960.        Documentation - Search and Retrieve Application Protocol<br>
    961. 

  961.        Specification for Open Systems Interconnection, ISO-10163.<br>
    962. 

  962. <p>
    963. 

  963.    [9] Horton, M., Adams, R., (1987)"Standard For Interchange of<br>
    964. 

  964.        USENET messages", RFC1036. &lt;URL:<a href="ftp://ds.internic.net">ftp://ds.internic.net</a><br>
    965. 

  965.        /rfc/rfc1036.txt&gt;.<br>
    966. 

  966. <p>
    967. 

  967.   [10] Huitema, C., (1991) "Naming: strategies and techniques",<br>
    968. 

  968.        Computer Networks and ISDN Systems 23 (1991) 107-110.<br>
    969. 

  969. <p>
    970. 

  970.   [11] Kahle, B. (1991) "Document Identifiers, or International<br>
    971. 

  971.        Standard Book Numbers for the Electronic Age".<br>
    972. 

  972.        &lt;URL:<a href="ftp://quake.think.com/pub/wais/doc/doc-ids.txt">ftp://quake.think.com/pub/wais/doc/doc-ids.txt</a>&gt;<br>
    973. 

  973. <p>
    974. 

  974.   [12] Kantor, B., and Lapsley, P., (1986) "Network News Transfer <br>
    975. 

  975.        Protocol", RFC977.  &lt;URL:<a href="ftp://ds.internic.net/rfc/rfc977.txt">ftp://ds.internic.net/rfc/rfc977.txt</a>&gt;<br>
    976. 

  976. <p>
    977. 

  977.   [13] Kunze, J., "Functional Requirements for Internet Resource<br>
    978. 

  978.        Locators", to be published as RFC????. Available as an internet<br>
    979. 

  979.        draft &lt;URL:<a href="ftp://ds.internic.net/internet-drafts/">ftp://ds.internic.net/internet-drafts/</a><br>
    980. 

  980.        draft-ietf-uri-fun-req-00.txt&gt;<br>
    981. 

  981. <p>
    982. 

  982.   [14] Lynch, C., (1991) Coalition for Networked Information.<br>
    983. 

  983.        "Workshop on ID and Reference Structures for Networked<br>
    984. 

  984.        Information", November 1991. See<br>
    985. 

  985.        &lt;URL:<a href="wais://quake.think.com/wais-discussion-archives?lynch">wais://quake.think.com/wais-discussion-archives?lynch</a>&gt;<br>
    986. 

  986. <p>
    987. 

  987.   [15] Mockapetris, P. (1987) "Domain Names - Concepts and <br>
    988. 

  988.        Facilities." RFC1034, USC-ISI,<br>
    989. 

  989.        &lt;URL:<a href="ftp://ds.internic.net/rfc/rfc1034.txt">ftp://ds.internic.net/rfc/rfc1034.txt</a>&gt;<br>
    990. 

  990. <p>
    991. 

  991.   [16] Neuman, B. Clifford, and Augart, Steven (1993). "The Prospero<br>…
    992.

Large files files are truncated, but you can click here to view the full file