rio 0.3.1

data/doc/rfc1738.txt

@@ -0,0 +1,1403 @@
+
+
+
+
+
+
+Network Working Group                                     T. Berners-Lee
+Request for Comments: 1738                                          CERN
+Category: Standards Track                                    L. Masinter
+                                                       Xerox Corporation
+                                                             M. McCahill
+                                                 University of Minnesota
+                                                                 Editors
+                                                           December 1994
+
+
+                    Uniform Resource Locators (URL)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   This document specifies a Uniform Resource Locator (URL), the syntax
+   and semantics of formalized information for location and access of
+   resources via the Internet.
+
+1. Introduction
+
+   This document describes the syntax and semantics for a compact string
+   representation for a resource available via the Internet.  These
+   strings are called "Uniform Resource Locators" (URLs).
+
+   The specification is derived from concepts introduced by the World-
+   Wide Web global information initiative, whose use of such objects
+   dates from 1990 and is described in "Universal Resource Identifiers
+   in WWW", RFC 1630. The specification of URLs is designed to meet the
+   requirements laid out in "Functional Requirements for Internet
+   Resource Locators" [12].
+
+   This document was written by the URI working group of the Internet
+   Engineering Task Force.  Comments may be addressed to the editors, or
+   to the URI-WG <uri@bunyip.com>. Discussions of the group are archived
+   at <URL:http://www.acl.lanl.gov/URI/archive/uri-archive.index.html>
+
+
+
+
+
+
+
+
+Berners-Lee, Masinter & McCahill                                [Page 1]
+
+RFC 1738            Uniform Resource Locators (URL)        December 1994
+
+
+2. General URL Syntax
+
+   Just as there are many different methods of access to resources,
+   there are several schemes for describing the location of such
+   resources.
+
+   The generic syntax for URLs provides a framework for new schemes to
+   be established using protocols other than those defined in this
+   document.
+
+   URLs are used to `locate' resources, by providing an abstract
+   identification of the resource location.  Having located a resource,
+   a system may perform a variety of operations on the resource, as
+   might be characterized by such words as `access', `update',
+   `replace', `find attributes'. In general, only the `access' method
+   needs to be specified for any URL scheme.
+
+2.1. The main parts of URLs
+
+   A full BNF description of the URL syntax is given in Section 5.
+
+   In general, URLs are written as follows:
+
+       <scheme>:<scheme-specific-part>
+
+   A URL contains the name of the scheme being used (<scheme>) followed
+   by a colon and then a string (the <scheme-specific-part>) whose
+   interpretation depends on the scheme.
+
+   Scheme names consist of a sequence of characters. The lower case
+   letters "a"--"z", digits, and the characters plus ("+"), period
+   ("."), and hyphen ("-") are allowed. For resiliency, programs
+   interpreting URLs should treat upper case letters as equivalent to
+   lower case in scheme names (e.g., allow "HTTP" as well as "http").
+
+2.2. URL Character Encoding Issues
+
+   URLs are sequences of characters, i.e., letters, digits, and special
+   characters. A URLs may be represented in a variety of ways: e.g., ink
+   on paper, or a sequence of octets in a coded character set. The
+   interpretation of a URL depends only on the identity of the
+   characters used.
+
+   In most URL schemes, the sequences of characters in different parts
+   of a URL are used to represent sequences of octets used in Internet
+   protocols. For example, in the ftp scheme, the host name, directory
+   name and file names are such sequences of octets, represented by
+   parts of the URL.  Within those parts, an octet may be represented by
+
+
+
+Berners-Lee, Masinter & McCahill                                [Page 2]
+
+RFC 1738            Uniform Resource Locators (URL)        December 1994
+
+
+   the chararacter which has that octet as its code within the US-ASCII
+   [20] coded character set.
+
+   In addition, octets may be encoded by a character triplet consisting
+   of the character "%" followed by the two hexadecimal digits (from
+   "0123456789ABCDEF") which forming the hexadecimal value of the octet.
+   (The characters "abcdef" may also be used in hexadecimal encodings.)
+
+   Octets must be encoded if they have no corresponding graphic
+   character within the US-ASCII coded character set, if the use of the
+   corresponding character is unsafe, or if the corresponding character
+   is reserved for some other interpretation within the particular URL
+   scheme.
+
+   No corresponding graphic US-ASCII:
+
+   URLs are written only with the graphic printable characters of the
+   US-ASCII coded character set. The octets 80-FF hexadecimal are not
+   used in US-ASCII, and the octets 00-1F and 7F hexadecimal represent
+   control characters; these must be encoded.
+
+   Unsafe:
+
+   Characters can be unsafe for a number of reasons.  The space
+   character is unsafe because significant spaces may disappear and
+   insignificant spaces may be introduced when URLs are transcribed or
+   typeset or subjected to the treatment of word-processing programs.
+   The characters "<" and ">" are unsafe because they are used as the
+   delimiters around URLs in free text; the quote mark (""") is used to
+   delimit URLs in some systems.  The character "#" is unsafe and should
+   always be encoded because it is used in World Wide Web and in other
+   systems to delimit a URL from a fragment/anchor identifier that might
+   follow it.  The character "%" is unsafe because it is used for
+   encodings of other characters.  Other characters are unsafe because
+   gateways and other transport agents are known to sometimes modify
+   such characters. These characters are "{", "}", "|", "\", "^", "~",
+   "[", "]", and "`".
+
+   All unsafe characters must always be encoded within a URL. For
+   example, the character "#" must be encoded within URLs even in
+   systems that do not normally deal with fragment or anchor
+   identifiers, so that if the URL is copied into another system that
+   does use them, it will not be necessary to change the URL encoding.
+
+
+
+
+
+
+
+
+Berners-Lee, Masinter & McCahill                                [Page 3]
+
+RFC 1738            Uniform Resource Locators (URL)        December 1994
+
+
+   Reserved:
+
+   Many URL schemes reserve certain characters for a special meaning:
+   their appearance in the scheme-specific part of the URL has a
+   designated semantics. If the character corresponding to an octet is
+   reserved in a scheme, the octet must be encoded.  The characters ";",
+   "/", "?", ":", "@", "=" and "&" are the characters which may be
+   reserved for special meaning within a scheme. No other characters may
+   be reserved within a scheme.
+
+   Usually a URL has the same interpretation when an octet is
+   represented by a character and when it encoded. However, this is not
+   true for reserved characters: encoding a character reserved for a
+   particular scheme may change the semantics of a URL.
+
+   Thus, only alphanumerics, the special characters "$-_.+!*'(),", and
+   reserved characters used for their reserved purposes may be used
+   unencoded within a URL.
+
+   On the other hand, characters that are not required to be encoded
+   (including alphanumerics) may be encoded within the scheme-specific
+   part of a URL, as long as they are not being used for a reserved
+   purpose.
+
+2.3 Hierarchical schemes and relative links
+
+   In some cases, URLs are used to locate resources that contain
+   pointers to other resources. In some cases, those pointers are
+   represented as relative links where the expression of the location of
+   the second resource is in terms of "in the same place as this one
+   except with the following relative path". Relative links are not
+   described in this document. However, the use of relative links
+   depends on the original URL containing a hierarchical structure
+   against which the relative link is based.
+
+   Some URL schemes (such as the ftp, http, and file schemes) contain
+   names that can be considered hierarchical; the components of the
+   hierarchy are separated by "/".
+
+
+
+
+
+
+
+
+
+
+
+
+
+Berners-Lee, Masinter & McCahill                                [Page 4]
+
+RFC 1738            Uniform Resource Locators (URL)        December 1994
+
+
+3. Specific Schemes
+
+   The mapping for some existing standard and experimental protocols is
+   outlined in the BNF syntax definition.  Notes on particular protocols
+   follow. The schemes covered are:
+
+   ftp                     File Transfer protocol
+   http                    Hypertext Transfer Protocol
+   gopher                  The Gopher protocol
+   mailto                  Electronic mail address
+   news                    USENET news
+   nntp                    USENET news using NNTP access
+   telnet                  Reference to interactive sessions
+   wais                    Wide Area Information Servers
+   file                    Host-specific file names
+   prospero                Prospero Directory Service
+
+   Other schemes may be specified by future specifications. Section 4 of
+   this document describes how new schemes may be registered, and lists
+   some scheme names that are under development.
+
+3.1. Common Internet Scheme Syntax
+
+   While the syntax for the rest of the URL may vary depending on the
+   particular scheme selected, URL schemes that involve the direct use
+   of an IP-based protocol to a specified host on the Internet use a
+   common syntax for the scheme-specific data:
+
+        //<user>:<password>@<host>:<port>/<url-path>
+
+   Some or all of the parts "<user>:<password>@", ":<password>",
+   ":<port>", and "/<url-path>" may be excluded.  The scheme specific
+   data start with a double slash "//" to indicate that it complies with
+   the common Internet scheme syntax. The different components obey the
+   following rules:
+
+    user
+        An optional user name. Some schemes (e.g., ftp) allow the
+        specification of a user name.
+
+    password
+        An optional password. If present, it follows the user
+        name separated from it by a colon.
+
+   The user name (and password), if present, are followed by a
+   commercial at-sign "@". Within the user and password field, any ":",
+   "@", or "/" must be encoded.
+
+
+
+
+Berners-Lee, Masinter & McCahill                                [Page 5]
+
+RFC 1738            Uniform Resource Locators (URL)        December 1994
+
+
+   Note that an empty user name or password is different than no user
+   name or password; there is no way to specify a password without
+   specifying a user name. E.g., <URL:ftp://@host.com/> has an empty
+   user name and no password, <URL:ftp://host.com/> has no user name,
+   while <URL:ftp://foo:@host.com/> has a user name of "foo" and an
+   empty password.
+
+    host
+        The fully qualified domain name of a network host, or its IP
+        address as a set of four decimal digit groups separated by
+        ".". Fully qualified domain names take the form as described
+        in Section 3.5 of RFC 1034 [13] and Section 2.1 of RFC 1123
+        [5]: a sequence of domain labels separated by ".", each domain
+        label starting and ending with an alphanumerical character and
+        possibly also containing "-" characters. The rightmost domain
+        label will never start with a digit, though, which
+        syntactically distinguishes all domain names from the IP
+        addresses.
+
+    port
+        The port number to connect to. Most schemes designate
+        protocols that have a default port number. Another port number
+        may optionally be supplied, in decimal, separated from the
+        host by a colon. If the port is omitted, the colon is as well.
+
+    url-path
+        The rest of the locator consists of data specific to the
+        scheme, and is known as the "url-path". It supplies the
+        details of how the specified resource can be accessed. Note
+        that the "/" between the host (or port) and the url-path is
+        NOT part of the url-path.
+
+   The url-path syntax depends on the scheme being used, as does the
+   manner in which it is interpreted.
+
+3.2. FTP
+
+   The FTP URL scheme is used to designate files and directories on
+   Internet hosts accessible using the FTP protocol (RFC959).
+
+   A FTP URL follow the syntax described in Section 3.1.  If :<port> is
+   omitted, the port defaults to 21.
+
+
+
+
+
+
+
+
+
+Berners-Lee, Masinter & McCahill                                [Page 6]
+
+RFC 1738            Uniform Resource Locators (URL)        December 1994
+
+
+3.2.1. FTP Name and Password
+
+   A user name and password may be supplied; they are used in the ftp
+   "USER" and "PASS" commands after first making the connection to the
+   FTP server.  If no user name or password is supplied and one is
+   requested by the FTP server, the conventions for "anonymous" FTP are
+   to be used, as follows:
+
+        The user name "anonymous" is supplied.
+
+        The password is supplied as the Internet e-mail address
+        of the end user accessing the resource.
+
+   If the URL supplies a user name but no password, and the remote
+   server requests a password, the program interpreting the FTP URL
+   should request one from the user.
+
+3.2.2. FTP url-path
+
+   The url-path of a FTP URL has the following syntax:
+
+        <cwd1>/<cwd2>/.../<cwdN>/<name>;type=<typecode>
+
+   Where <cwd1> through <cwdN> and <name> are (possibly encoded) strings
+   and <typecode> is one of the characters "a", "i", or "d".  The part
+   ";type=<typecode>" may be omitted. The <cwdx> and <name> parts may be
+   empty. The whole url-path may be omitted, including the "/"
+   delimiting it from the prefix containing user, password, host, and
+   port.
+
+   The url-path is interpreted as a series of FTP commands as follows:
+
+      Each of the <cwd> elements is to be supplied, sequentially, as the
+      argument to a CWD (change working directory) command.
+
+      If the typecode is "d", perform a NLST (name list) command with
+      <name> as the argument, and interpret the results as a file
+      directory listing.
+
+      Otherwise, perform a TYPE command with <typecode> as the argument,
+      and then access the file whose name is <name> (for example, using
+      the RETR command.)
+
+   Within a name or CWD component, the characters "/" and ";" are
+   reserved and must be encoded. The components are decoded prior to
+   their use in the FTP protocol.  In particular, if the appropriate FTP
+   sequence to access a particular file requires supplying a string
+   containing a "/" as an argument to a CWD or RETR command, it is
+
+
+
+Berners-Lee, Masinter & McCahill                                [Page 7]
+
+RFC 1738            Uniform Resource Locators (URL)        December 1994
+
+
+   necessary to encode each "/".
+
+   For example, the URL <URL:ftp://myname@host.dom/%2Fetc/motd> is
+   interpreted by FTP-ing to "host.dom", logging in as "myname"
+   (prompting for a password if it is asked for), and then executing
+   "CWD /etc" and then "RETR motd". This has a different meaning from
+   <URL:ftp://myname@host.dom/etc/motd> which would "CWD etc" and then
+   "RETR motd"; the initial "CWD" might be executed relative to the
+   default directory for "myname". On the other hand,
+   <URL:ftp://myname@host.dom//etc/motd>, would "CWD " with a null
+   argument, then "CWD etc", and then "RETR motd".
+
+   FTP URLs may also be used for other operations; for example, it is
+   possible to update a file on a remote file server, or infer
+   information about it from the directory listings. The mechanism for
+   doing so is not spelled out here.
+
+3.2.3. FTP Typecode is Optional
+
+   The entire ;type=<typecode> part of a FTP URL is optional. If it is
+   omitted, the client program interpreting the URL must guess the
+   appropriate mode to use. In general, the data content type of a file
+   can only be guessed from the name, e.g., from the suffix of the name;
+   the appropriate type code to be used for transfer of the file can
+   then be deduced from the data content of the file.
+
+3.2.4 Hierarchy
+
+   For some file systems, the "/" used to denote the hierarchical
+   structure of the URL corresponds to the delimiter used to construct a
+   file name hierarchy, and thus, the filename will look similar to the
+   URL path. This does NOT mean that the URL is a Unix filename.
+
+3.2.5. Optimization
+
+   Clients accessing resources via FTP may employ additional heuristics
+   to optimize the interaction. For some FTP servers, for example, it
+   may be reasonable to keep the control connection open while accessing
+   multiple URLs from the same server. However, there is no common
+   hierarchical model to the FTP protocol, so if a directory change
+   command has been given, it is impossible in general to deduce what
+   sequence should be given to navigate to another directory for a
+   second retrieval, if the paths are different.  The only reliable
+   algorithm is to disconnect and reestablish the control connection.
+
+
+
+
+
+
+
+Berners-Lee, Masinter & McCahill                                [Page 8]
+
+RFC 1738            Uniform Resource Locators (URL)        December 1994
+
+
+3.3. HTTP
+
+   The HTTP URL scheme is used to designate Internet resources
+   accessible using HTTP (HyperText Transfer Protocol).
+
+   The HTTP protocol is specified elsewhere. This specification only
+   describes the syntax of HTTP URLs.
+
+   An HTTP URL takes the form:
+
+      http://<host>:<port>/<path>?<searchpart>
+
+   where <host> and <port> are as described in Section 3.1. If :<port>
+   is omitted, the port defaults to 80.  No user name or password is
+   allowed.  <path> is an HTTP selector, and <searchpart> is a query
+   string. The <path> is optional, as is the <searchpart> and its
+   preceding "?". If neither <path> nor <searchpart> is present, the "/"
+   may also be omitted.
+
+   Within the <path> and <searchpart> components, "/", ";", "?" are
+   reserved.  The "/" character may be used within HTTP to designate a
+   hierarchical structure.
+
+3.4. GOPHER
+
+   The Gopher URL scheme is used to designate Internet resources
+   accessible using the Gopher protocol.
+
+   The base Gopher protocol is described in RFC 1436 and supports items
+   and collections of items (directories). The Gopher+ protocol is a set
+   of upward compatible extensions to the base Gopher protocol and is
+   described in [2]. Gopher+ supports associating arbitrary sets of
+   attributes and alternate data representations with Gopher items.
+   Gopher URLs accommodate both Gopher and Gopher+ items and item
+   attributes.
+
+3.4.1. Gopher URL syntax
+
+   A Gopher URL takes the form:
+
+      gopher://<host>:<port>/<gopher-path>
+
+   where <gopher-path> is one of
+
+       <gophertype><selector>
+       <gophertype><selector>%09<search>
+       <gophertype><selector>%09<search>%09<gopher+_string>
+
+
+
+
+Berners-Lee, Masinter & McCahill                                [Page 9]
+
+RFC 1738            Uniform Resource Locators (URL)        December 1994
+
+
+   If :<port> is omitted, the port defaults to 70.  <gophertype> is a
+   single-character field to denote the Gopher type of the resource to
+   which the URL refers. The entire <gopher-path> may also be empty, in
+   which case the delimiting "/" is also optional and the <gophertype>
+   defaults to "1".
+
+   <selector> is the Gopher selector string.  In the Gopher protocol,
+   Gopher selector strings are a sequence of octets which may contain
+   any octets except 09 hexadecimal (US-ASCII HT or tab) 0A hexadecimal
+   (US-ASCII character LF), and 0D (US-ASCII character CR).
+
+   Gopher clients specify which item to retrieve by sending the Gopher
+   selector string to a Gopher server.
+
+   Within the <gopher-path>, no characters are reserved.
+
+   Note that some Gopher <selector> strings begin with a copy of the
+   <gophertype> character, in which case that character will occur twice
+   consecutively. The Gopher selector string may be an empty string;
+   this is how Gopher clients refer to the top-level directory on a
+   Gopher server.
+
+3.4.2 Specifying URLs for Gopher Search Engines
+
+   If the URL refers to a search to be submitted to a Gopher search
+   engine, the selector is followed by an encoded tab (%09) and the
+   search string. To submit a search to a Gopher search engine, the
+   Gopher client sends the <selector> string (after decoding), a tab,
+   and the search string to the Gopher server.
+
+3.4.3 URL syntax for Gopher+ items
+
+   URLs for Gopher+ items have a second encoded tab (%09) and a Gopher+
+   string. Note that in this case, the %09<search> string must be
+   supplied, although the <search> element may be the empty string.
+
+   The <gopher+_string> is used to represent information required for
+   retrieval of the Gopher+ item. Gopher+ items may have alternate
+   views, arbitrary sets of attributes, and may have electronic forms
+   associated with them.
+
+   To retrieve the data associated with a Gopher+ URL, a client will
+   connect to the server and send the Gopher selector, followed by a tab
+   and the search string (which may be empty), followed by a tab and the
+   Gopher+ commands.
+
+
+
+
+
+
+Berners-Lee, Masinter & McCahill                               [Page 10]
+
+RFC 1738            Uniform Resource Locators (URL)        December 1994
+
+
+3.4.4 Default Gopher+ data representation
+
+   When a Gopher server returns a directory listing to a client, the
+   Gopher+ items are tagged with either a "+" (denoting Gopher+ items)
+   or a "?" (denoting Gopher+ items which have a +ASK form associated
+   with them). A Gopher URL with a Gopher+ string consisting of only a
+   "+" refers to the default view (data representation) of the item
+   while a Gopher+ string containing only a "?" refer to an item with a
+   Gopher electronic form associated with it.
+
+3.4.5 Gopher+ items with electronic forms
+
+   Gopher+ items which have a +ASK associated with them (i.e. Gopher+
+   items tagged with a "?") require the client to fetch the item's +ASK
+   attribute to get the form definition, and then ask the user to fill
+   out the form and return the user's responses along with the selector
+   string to retrieve the item.  Gopher+ clients know how to do this but
+   depend on the "?" tag in the Gopher+ item description to know when to
+   handle this case. The "?" is used in the Gopher+ string to be
+   consistent with Gopher+ protocol's use of this symbol.
+
+3.4.6 Gopher+ item attribute collections
+
+   To refer to the Gopher+ attributes of an item, the Gopher URL's
+   Gopher+ string consists of "!" or "$". "!" refers to the all of a
+   Gopher+ item's attributes. "$" refers to all the item attributes for
+   all items in a Gopher directory.
+
+3.4.7 Referring to specific Gopher+ attributes
+
+   To refer to specific attributes, the URL's gopher+_string is
+   "!<attribute_name>" or "$<attribute_name>". For example, to refer to
+   the attribute containing the abstract of an item, the gopher+_string
+   would be "!+ABSTRACT".
+
+   To refer to several attributes, the gopher+_string consists of the
+   attribute names separated by coded spaces. For example,
+   "!+ABSTRACT%20+SMELL" refers to the +ABSTRACT and +SMELL attributes
+   of an item.
+
+3.4.8 URL syntax for Gopher+ alternate views
+
+   Gopher+ allows for optional alternate data representations (alternate
+   views) of items. To retrieve a Gopher+ alternate view, a Gopher+
+   client sends the appropriate view and language identifier (found in
+   the item's +VIEW attribute). To refer to a specific Gopher+ alternate
+   view, the URL's Gopher+ string would be in the form:
+
+
+
+
+Berners-Lee, Masinter & McCahill                               [Page 11]
+
+RFC 1738            Uniform Resource Locators (URL)        December 1994
+
+
+        +<view_name>%20<language_name>
+
+   For example, a Gopher+ string of "+application/postscript%20Es_ES"
+   refers to the Spanish language postscript alternate view of a Gopher+
+   item.
+
+3.4.9 URL syntax for Gopher+ electronic forms
+
+   The gopher+_string for a URL that refers to an item referenced by a
+   Gopher+ electronic form (an ASK block) filled out with specific
+   values is a coded version of what the client sends to the server.
+   The gopher+_string is of the form:
+
++%091%0D%0A+-1%0D%0A<ask_item1_value>%0D%0A<ask_item2_value>%0D%0A.%0D%0A
+
+   To retrieve this item, the Gopher client sends:
+
+       <a_gopher_selector><tab>+<tab>1<cr><lf>
+       +-1<cr><lf>
+       <ask_item1_value><cr><lf>
+       <ask_item2_value><cr><lf>
+       .<cr><lf>
+
+   to the Gopher server.
+
+3.5. MAILTO
+
+   The mailto URL scheme is used to designate the Internet mailing
+   address of an individual or service. No additional information other
+   than an Internet mailing address is present or implied.
+
+   A mailto URL takes the form:
+
+        mailto:<rfc822-addr-spec>
+
+   where <rfc822-addr-spec> is (the encoding of an) addr-spec, as
+   specified in RFC 822 [6]. Within mailto URLs, there are no reserved
+   characters.
+
+   Note that the percent sign ("%") is commonly used within RFC 822
+   addresses and must be encoded.
+
+   Unlike many URLs, the mailto scheme does not represent a data object
+   to be accessed directly; there is no sense in which it designates an
+   object. It has a different use than the message/external-body type in
+   MIME.
+
+
+
+
+
+Berners-Lee, Masinter & McCahill                               [Page 12]
+
+RFC 1738            Uniform Resource Locators (URL)        December 1994
+
+
+3.6. NEWS
+
+   The news URL scheme is used to refer to either news groups or
+   individual articles of USENET news, as specified in RFC 1036.
+
+   A news URL takes one of two forms:
+
+     news:<newsgroup-name>
+     news:<message-id>
+
+   A <newsgroup-name> is a period-delimited hierarchical name, such as
+   "comp.infosystems.www.misc". A <message-id> corresponds to the
+   Message-ID of section 2.1.5 of RFC 1036, without the enclosing "<"
+   and ">"; it takes the form <unique>@<full_domain_name>.  A message
+   identifier may be distinguished from a news group name by the
+   presence of the commercial at "@" character. No additional characters
+   are reserved within the components of a news URL.
+
+   If <newsgroup-name> is "*" (as in <URL:news:*>), it is used to refer
+   to "all available news groups".
+
+   The news URLs are unusual in that by themselves, they do not contain
+   sufficient information to locate a single resource, but, rather, are
+   location-independent.
+
+3.7. NNTP
+
+   The nntp URL scheme is an alternative method of referencing news
+   articles, useful for specifying news articles from NNTP servers (RFC
+   977).
+
+   A nntp URL take the form:
+
+      nntp://<host>:<port>/<newsgroup-name>/<article-number>
+
+   where <host> and <port> are as described in Section 3.1. If :<port>
+   is omitted, the port defaults to 119.
+
+   The <newsgroup-name> is the name of the group, while the <article-
+   number> is the numeric id of the article within that newsgroup.
+
+   Note that while nntp: URLs specify a unique location for the article
+   resource, most NNTP servers currently on the Internet today are
+   configured only to allow access from local clients, and thus nntp
+   URLs do not designate globally accessible resources. Thus, the news:
+   form of URL is preferred as a way of identifying news articles.
+
+
+
+
+
+Berners-Lee, Masinter & McCahill                               [Page 13]
+
+RFC 1738            Uniform Resource Locators (URL)        December 1994
+
+
+3.8. TELNET
+
+   The Telnet URL scheme is used to designate interactive services that
+   may be accessed by the Telnet protocol.
+
+   A telnet URL takes the form:
+
+       telnet://<user>:<password>@<host>:<port>/
+
+   as specified in Section 3.1. The final "/" character may be omitted.
+   If :<port> is omitted, the port defaults to 23.  The :<password> can
+   be omitted, as well as the whole <user>:<password> part.
+
+   This URL does not designate a data object, but rather an interactive
+   service. Remote interactive services vary widely in the means by
+   which they allow remote logins; in practice, the <user> and
+   <password> supplied are advisory only: clients accessing a telnet URL
+   merely advise the user of the suggested username and password.
+
+3.9.  WAIS
+
+   The WAIS URL scheme is used to designate WAIS databases, searches, or
+   individual documents available from a WAIS database. WAIS is
+   described in [7]. The WAIS protocol is described in RFC 1625 [17];
+   Although the WAIS protocol is based on Z39.50-1988, the WAIS URL
+   scheme is not intended for use with arbitrary Z39.50 services.
+
+   A WAIS URL takes one of the following forms:
+
+     wais://<host>:<port>/<database>
+     wais://<host>:<port>/<database>?<search>
+     wais://<host>:<port>/<database>/<wtype>/<wpath>
+
+   where <host> and <port> are as described in Section 3.1. If :<port>
+   is omitted, the port defaults to 210.  The first form designates a
+   WAIS database that is available for searching. The second form
+   designates a particular search.  <database> is the name of the WAIS
+   database being queried.
+
+   The third form designates a particular document within a WAIS
+   database to be retrieved. In this form <wtype> is the WAIS
+   designation of the type of the object. Many WAIS implementations
+   require that a client know the "type" of an object prior to
+   retrieval, the type being returned along with the internal object
+   identifier in the search response.  The <wtype> is included in the
+   URL in order to allow the client interpreting the URL adequate
+   information to actually retrieve the document.
+
+
+
+
+Berners-Lee, Masinter & McCahill                               [Page 14]
+
+RFC 1738            Uniform Resource Locators (URL)        December 1994
+
+
+   The <wpath> of a WAIS URL consists of the WAIS document-id, encoded
+   as necessary using the method described in Section 2.2. The WAIS
+   document-id should be treated opaquely; it may only be decomposed by
+   the server that issued it.
+
+3.10 FILES
+
+   The file URL scheme is used to designate files accessible on a
+   particular host computer. This scheme, unlike most other URL schemes,
+   does not designate a resource that is universally accessible over the
+   Internet.
+
+   A file URL takes the form:
+
+       file://<host>/<path>
+
+   where <host> is the fully qualified domain name of the system on
+   which the <path> is accessible, and <path> is a hierarchical
+   directory path of the form <directory>/<directory>/.../<name>.
+
+   For example, a VMS file
+
+     DISK$USER:[MY.NOTES]NOTE123456.TXT
+
+   might become
+
+     <URL:file://vms.host.edu/disk$user/my/notes/note12345.txt>
+
+   As a special case, <host> can be the string "localhost" or the empty
+   string; this is interpreted as `the machine from which the URL is
+   being interpreted'.
+
+   The file URL scheme is unusual in that it does not specify an
+   Internet protocol or access method for such files; as such, its
+   utility in network protocols between hosts is limited.
+
+3.11 PROSPERO
+
+   The Prospero URL scheme is used to designate resources that are
+   accessed via the Prospero Directory Service. The Prospero protocol is
+   described elsewhere [14].
+
+   A prospero URLs takes the form:
+
+      prospero://<host>:<port>/<hsoname>;<field>=<value>
+
+   where <host> and <port> are as described in Section 3.1. If :<port>
+   is omitted, the port defaults to 1525. No username or password is
+
+
+
+Berners-Lee, Masinter & McCahill                               [Page 15]
+
+RFC 1738            Uniform Resource Locators (URL)        December 1994
+
+
+   allowed.
+
+   The <hsoname> is the host-specific object name in the Prospero
+   protocol, suitably encoded.  This name is opaque and interpreted by
+   the Prospero server.  The semicolon ";" is reserved and may not
+   appear without quoting in the <hsoname>.
+
+   Prospero URLs are interpreted by contacting a Prospero directory
+   server on the specified host and port to determine appropriate access
+   methods for a resource, which might themselves be represented as
+   different URLs. External Prospero links are represented as URLs of
+   the underlying access method and are not represented as Prospero
+   URLs.
+
+   Note that a slash "/" may appear in the <hsoname> without quoting and
+   no significance may be assumed by the application.  Though slashes
+   may indicate hierarchical structure on the server, such structure is
+   not guaranteed. Note that many <hsoname>s begin with a slash, in
+   which case the host or port will be followed by a double slash: the
+   slash from the URL syntax, followed by the initial slash from the
+   <hsoname>. (E.g., <URL:prospero://host.dom//pros/name> designates a
+   <hsoname> of "/pros/name".)
+
+   In addition, after the <hsoname>, optional fields and values
+   associated with a Prospero link may be specified as part of the URL.
+   When present, each field/value pair is separated from each other and
+   from the rest of the URL by a ";" (semicolon).  The name of the field
+   and its value are separated by a "=" (equal sign). If present, these
+   fields serve to identify the target of the URL.  For example, the
+   OBJECT-VERSION field can be specified to identify a specific version
+   of an object.
+
+4. REGISTRATION OF NEW SCHEMES
+
+   A new scheme may be introduced by defining a mapping onto a
+   conforming URL syntax, using a new prefix. URLs for experimental
+   schemes may be used by mutual agreement between parties. Scheme names
+   starting with the characters "x-" are reserved for experimental
+   purposes.
+
+   The Internet Assigned Numbers Authority (IANA) will maintain a
+   registry of URL schemes. Any submission of a new URL scheme must
+   include a definition of an algorithm for accessing of resources
+   within that scheme and the syntax for representing such a scheme.
+
+   URL schemes must have demonstrable utility and operability.  One way
+   to provide such a demonstration is via a gateway which provides
+   objects in the new scheme for clients using an existing protocol.  If
+
+
+
+Berners-Lee, Masinter & McCahill                               [Page 16]
+
+RFC 1738            Uniform Resource Locators (URL)        December 1994
+
+
+   the new scheme does not locate resources that are data objects, the
+   properties of names in the new space must be clearly defined.
+
+   New schemes should try to follow the same syntactic conventions of
+   existing schemes, where appropriate.  It is likewise recommended
+   that, where a protocol allows for retrieval by URL, that the client
+   software have provision for being configured to use specific gateway
+   locators for indirect access through new naming schemes.
+
+   The following scheme have been proposed at various times, but this
+   document does not define their syntax or use at this time. It is
+   suggested that IANA reserve their scheme names for future definition:
+
+   afs              Andrew File System global file names.
+   mid              Message identifiers for electronic mail.
+   cid              Content identifiers for MIME body parts.
+   nfs              Network File System (NFS) file names.
+   tn3270           Interactive 3270 emulation sessions.
+   mailserver       Access to data available from mail servers.
+   z39.50           Access to ANSI Z39.50 services.
+
+5. BNF for specific URL schemes
+
+   This is a BNF-like description of the Uniform Resource Locator
+   syntax, using the conventions of RFC822, except that "|" is used to
+   designate alternatives, and brackets [] are used around optional or
+   repeated elements. Briefly, literals are quoted with "", optional
+   elements are enclosed in [brackets], and elements may be preceded
+   with <n>* to designate n or more repetitions of the following
+   element; n defaults to 0.
+
+; The generic form of a URL is:
+
+genericurl     = scheme ":" schemepart
+
+; Specific predefined schemes are defined here; new schemes
+; may be registered with IANA
+
+url            = httpurl | ftpurl | newsurl |
+                 nntpurl | telneturl | gopherurl |
+                 waisurl | mailtourl | fileurl |
+                 prosperourl | otherurl
+
+; new schemes follow the general syntax
+otherurl       = genericurl
+
+; the scheme is in lower case; interpreters should use case-ignore
+scheme         = 1*[ lowalpha | digit | "+" | "-" | "." ]
+
+
+
+Berners-Lee, Masinter & McCahill                               [Page 17]
+
+RFC 1738            Uniform Resource Locators (URL)        December 1994
+
+
+schemepart     = *xchar | ip-schemepart
+
+
+; URL schemeparts for ip based protocols:
+
+ip-schemepart  = "//" login [ "/" urlpath ]
+
+login          = [ user [ ":" password ] "@" ] hostport
+hostport       = host [ ":" port ]
+host           = hostname | hostnumber
+hostname       = *[ domainlabel "." ] toplabel
+domainlabel    = alphadigit | alphadigit *[ alphadigit | "-" ] alphadigit
+toplabel       = alpha | alpha *[ alphadigit | "-" ] alphadigit
+alphadigit     = alpha | digit
+hostnumber     = digits "." digits "." digits "." digits
+port           = digits
+user           = *[ uchar | ";" | "?" | "&" | "=" ]
+password       = *[ uchar | ";" | "?" | "&" | "=" ]
+urlpath        = *xchar    ; depends on protocol see section 3.1
+
+; The predefined schemes:
+
+; FTP (see also RFC959)
+
+ftpurl         = "ftp://" login [ "/" fpath [ ";type=" ftptype ]]
+fpath          = fsegment *[ "/" fsegment ]
+fsegment       = *[ uchar | "?" | ":" | "@" | "&" | "=" ]
+ftptype        = "A" | "I" | "D" | "a" | "i" | "d"
+
+; FILE
+
+fileurl        = "file://" [ host | "localhost" ] "/" fpath
+
+; HTTP
+
+httpurl        = "http://" hostport [ "/" hpath [ "?" search ]]
+hpath          = hsegment *[ "/" hsegment ]
+hsegment       = *[ uchar | ";" | ":" | "@" | "&" | "=" ]
+search         = *[ uchar | ";" | ":" | "@" | "&" | "=" ]
+
+; GOPHER (see also RFC1436)
+
+gopherurl      = "gopher://" hostport [ / [ gtype [ selector
+                 [ "%09" search [ "%09" gopher+_string ] ] ] ] ]
+gtype          = xchar
+selector       = *xchar
+gopher+_string = *xchar
+
+
+
+
+Berners-Lee, Masinter & McCahill                               [Page 18]
+
+RFC 1738            Uniform Resource Locators (URL)        December 1994
+
+
+; MAILTO (see also RFC822)
+
+mailtourl      = "mailto:" encoded822addr
+encoded822addr = 1*xchar               ; further defined in RFC822
+
+; NEWS (see also RFC1036)
+
+newsurl        = "news:" grouppart
+grouppart      = "*" | group | article
+group          = alpha *[ alpha | digit | "-" | "." | "+" | "_" ]
+article        = 1*[ uchar | ";" | "/" | "?" | ":" | "&" | "=" ] "@" host
+
+; NNTP (see also RFC977)
+
+nntpurl        = "nntp://" hostport "/" group [ "/" digits ]
+
+; TELNET
+
+telneturl      = "telnet://" login [ "/" ]
+
+; WAIS (see also RFC1625)
+
+waisurl        = waisdatabase | waisindex | waisdoc
+waisdatabase   = "wais://" hostport "/" database
+waisindex      = "wais://" hostport "/" database "?" search
+waisdoc        = "wais://" hostport "/" database "/" wtype "/" wpath
+database       = *uchar
+wtype          = *uchar
+wpath          = *uchar
+
+; PROSPERO
+
+prosperourl    = "prospero://" hostport "/" ppath *[ fieldspec ]
+ppath          = psegment *[ "/" psegment ]
+psegment       = *[ uchar | "?" | ":" | "@" | "&" | "=" ]
+fieldspec      = ";" fieldname "=" fieldvalue
+fieldname      = *[ uchar | "?" | ":" | "@" | "&" ]
+fieldvalue     = *[ uchar | "?" | ":" | "@" | "&" ]
+
+; Miscellaneous definitions
+
+lowalpha       = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" |
+                 "i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" |
+                 "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" |
+                 "y" | "z"
+hialpha        = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" |
+                 "J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" |
+                 "S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z"
+
+
+
+Berners-Lee, Masinter & McCahill                               [Page 19]
+
+RFC 1738            Uniform Resource Locators (URL)        December 1994
+
+
+alpha          = lowalpha | hialpha
+digit          = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
+                 "8" | "9"
+safe           = "$" | "-" | "_" | "." | "+"
+extra          = "!" | "*" | "'" | "(" | ")" | ","
+national       = "{" | "}" | "|" | "\" | "^" | "~" | "[" | "]" | "`"
+punctuation    = "<" | ">" | "#" | "%" | <">
+
+
+reserved       = ";" | "/" | "?" | ":" | "@" | "&" | "="
+hex            = digit | "A" | "B" | "C" | "D" | "E" | "F" |
+                 "a" | "b" | "c" | "d" | "e" | "f"
+escape         = "%" hex hex
+
+unreserved     = alpha | digit | safe | extra
+uchar          = unreserved | escape
+xchar          = unreserved | reserved | escape
+digits         = 1*digit
+
+6. Security Considerations
+
+   The URL scheme does not in itself pose a security threat. Users
+   should beware that there is no general guarantee that a URL which at
+   one time points to a given object continues to do so, and does not
+   even at some later time point to a different object due to the
+   movement of objects on servers.
+
+   A URL-related security threat is that it is sometimes possible to
+   construct a URL such that an attempt to perform a harmless idempotent
+   operation such as the retrieval of the object will in fact cause a
+   possibly damaging remote operation to occur.  The unsafe URL is
+   typically constructed by specifying a port number other than that
+   reserved for the network protocol in question.  The client
+   unwittingly contacts a server which is in fact running a different
+   protocol.  The content of the URL contains instructions which when
+   interpreted according to this other protocol cause an unexpected
+   operation. An example has been the use of gopher URLs to cause a rude
+   message to be sent via a SMTP server.  Caution should be used when
+   using any URL which specifies a port number other than the default
+   for the protocol, especially when it is a number within the reserved
+   space.
+
+   Care should be taken when URLs contain embedded encoded delimiters
+   for a given protocol (for example, CR and LF characters for telnet
+   protocols) that these are not unencoded before transmission.  This
+   would violate the protocol but could be used to simulate an extra
+   operation or parameter, again causing an unexpected and possible
+   harmful remote operation to be performed.
+
+
+
+Berners-Lee, Masinter & McCahill                               [Page 20]
+
+RFC 1738            Uniform Resource Locators (URL)        December 1994
+
+
+   The use of URLs containing passwords that should be secret is clearly
+   unwise.
+
+7. Acknowledgements
+
+   This paper builds on the basic WWW design (RFC 1630) and much
+   discussion of these issues by many people on the network. The
+   discussion was particularly stimulated by articles by Clifford Lynch,
+   Brewster Kahle [10] and Wengyik Yeong [18]. Contributions from John
+   Curran, Clifford Neuman, Ed Vielmetti and later the IETF URL BOF and
+   URI working group were incorporated.
+
+   Most recently, careful readings and comments by Dan Connolly, Ned
+   Freed, Roy Fielding, Guido van Rossum, Michael Dolan, Bert Bos, John
+   Kunze, Olle Jarnefors, Peter Svanberg and many others have helped
+   refine this RFC.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Berners-Lee, Masinter & McCahill                               [Page 21]
+
+RFC 1738            Uniform Resource Locators (URL)        December 1994
+
+
+APPENDIX: Recommendations for URLs in Context
+
+   URIs, including URLs, are intended to be transmitted through
+   protocols which provide a context for their interpretation.
+
+   In some cases, it will be necessary to distinguish URLs from other
+   possible data structures in a syntactic structure. In this case, is
+   recommended that URLs be preceeded with a prefix consisting of the
+   characters "URL:". For example, this prefix may be used to
+   distinguish URLs from other kinds of URIs.
+
+   In addition, there are many occasions when URLs are included in other
+   kinds of text; examples include electronic mail, USENET news
+   messages, or printed on paper. In such cases, it is convenient to
+   have a separate syntactic wrapper that delimits the URL and separates
+   it from the rest of the text, and in particular from punctuation
+   marks that might be mistaken for part of the URL. For this purpose,
+   is recommended that angle brackets ("<" and ">"), along with the
+   prefix "URL:", be used to delimit the boundaries of the URL.  This
+   wrapper does not form part of the URL and should not be used in
+   contexts in which delimiters are already specified.
+
+   In the case where a fragment/anchor identifier is associated with a
+   URL (following a "#"), the identifier would be placed within the
+   brackets as well.
+
+   In some cases, extra whitespace (spaces, linebreaks, tabs, etc.) may
+   need to be added to break long URLs across lines.  The whitespace
+   should be ignored when extracting the URL.
+
+   No whitespace should be introduced after a hyphen ("-") character.
+   Because some typesetters and printers may (erroneously) introduce a
+   hyphen at the end of line when breaking a line, the interpreter of a
+   URL containing a line break immediately after a hyphen should ignore
+   all unencoded whitespace around the line break, and should be aware
+   that the hyphen may or may not actually be part of the URL.
+
+   Examples:
+
+      Yes, Jim, I found it under <URL:ftp://info.cern.ch/pub/www/doc;
+      type=d> but you can probably pick it up from <URL:ftp://ds.in
+      ternic.net/rfc>.  Note the warning in <URL:http://ds.internic.
+      net/instructions/overview.html#WARNING>.
+
+
+
+
+
+
+
+
+Berners-Lee, Masinter & McCahill                               [Page 22]
+
+RFC 1738            Uniform Resource Locators (URL)        December 1994
+
+
+References
+
+   [1] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D.,
+       Torrey, D., and B. Alberti, "The Internet Gopher Protocol
+       (a distributed document search and retrieval protocol)",
+       RFC 1436, University of Minnesota, March 1993.
+       <URL:ftp://ds.internic.net/rfc/rfc1436.txt;type=a>
+
+   [2] Anklesaria, F., Lindner, P., McCahill, M., Torrey, D.,
+       Johnson, D., and B. Alberti, "Gopher+: Upward compatible
+       enhancements to the Internet Gopher protocol",
+       University of Minnesota, July 1993.
+       <URL:ftp://boombox.micro.umn.edu/pub/gopher/gopher_protocol
+       /Gopher+/Gopher+.txt>
+
+   [3] Berners-Lee, T., "Universal Resource Identifiers in WWW: A
+       Unifying Syntax for the Expression of Names and Addresses of
+       Objects on the Network as used in the World-Wide Web", RFC
+       1630, CERN, June 1994.
+       <URL:ftp://ds.internic.net/rfc/rfc1630.txt>
+
+   [4] Berners-Lee, T., "Hypertext Transfer Protocol (HTTP)",
+       CERN, November 1993.
+       <URL:ftp://info.cern.ch/pub/www/doc/http-spec.txt.Z>
+
+   [5] Braden, R., Editor, "Requirements for Internet Hosts --
+       Application and Support", STD 3, RFC 1123, IETF, October 1989.
+       <URL:ftp://ds.internic.net/rfc/rfc1123.txt>
+
+   [6] Crocker, D. "Standard for the Format of ARPA Internet Text
+       Messages", STD 11, RFC 822, UDEL, April 1982.
+       <URL:ftp://ds.internic.net/rfc/rfc822.txt>
+
+   [7] Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T., Wang, R.,
+       Sui, J., and M. Grinbaum, "WAIS Interface Protocol Prototype
+       Functional Specification", (v1.5), Thinking Machines
+       Corporation, April 1990.
+       <URL:ftp://quake.think.com/pub/wais/doc/protspec.txt>
+
+   [8] Horton, M. and R. Adams, "Standard For Interchange of USENET
+       Messages", RFC 1036, AT&T Bell Laboratories, Center for Seismic
+       Studies, December 1987.
+       <URL:ftp://ds.internic.net/rfc/rfc1036.txt>
+
+   [9] Huitema, C., "Naming: Strategies and Techniques", Computer
+       Networks and ISDN Systems 23 (1991) 107-110.
+
+
+
+
+
+Berners-Lee, Masinter & McCahill                               [Page 23]
+
+RFC 1738            Uniform Resource Locators (URL)        December 1994
+
+
+  [10] Kahle, B., "Document Identifiers, or International Standard
+       Book Numbers for the Electronic Age", 1991.
+       <URL:ftp://quake.think.com/pub/wais/doc/doc-ids.txt>
+
+  [11] Kantor, B. and P. Lapsley, "Network News Transfer Protocol:
+       A Proposed Standard for the Stream-Based Transmission of News",
+       RFC 977, UC San Diego & UC Berkeley, February 1986.
+       <URL:ftp://ds.internic.net/rfc/rfc977.txt>
+
+  [12] Kunze, J., "Functional Requirements for Internet Resource
+       Locators", Work in Progress, December 1994.
+       <URL:ftp://ds.internic.net/internet-drafts
+       /draft-ietf-uri-irl-fun-req-02.txt>
+
+  [13] Mockapetris, P., "Domain Names - Concepts and Facilities",
+       STD 13, RFC 1034, USC/Information Sciences Institute,
+       November 1987.
+       <URL:ftp://ds.internic.net/rfc/rfc1034.txt>
+
+  [14] Neuman, B., and S. Augart, "The Prospero Protocol",
+       USC/Information Sciences Institute, June 1993.
+       <URL:ftp://prospero.isi.edu/pub/prospero/doc
+       /prospero-protocol.PS.Z>
+
+  [15] Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)",
+       STD 9, RFC 959, USC/Information Sciences Institute,
+       October 1985.
+       <URL:ftp://ds.internic.net/rfc/rfc959.txt>
+
+  [16] Sollins, K. and L. Masinter, "Functional Requirements for
+       Uniform Resource Names", RFC 1737, MIT/LCS, Xerox Corporation,
+       December 1994.
+       <URL:ftp://ds.internic.net/rfc/rfc1737.txt>
+
+  [17] St. Pierre, M, Fullton, J., Gamiel, K., Goldman, J., Kahle, B.,
+       Kunze, J., Morris, H., and F. Schiettecatte, "WAIS over
+       Z39.50-1988", RFC 1625, WAIS, Inc., CNIDR, Thinking Machines
+       Corp., UC Berkeley, FS Consulting, June 1994.
+       <URL:ftp://ds.internic.net/rfc/rfc1625.txt>
+
+  [18] Yeong, W. "Towards Networked Information Retrieval", Technical
+       report 91-06-25-01, Performance Systems International, Inc.
+       <URL:ftp://uu.psi.com/wp/nir.txt>, June 1991.
+
+  [19] Yeong, W., "Representing Public Archives in the Directory",
+       Work in Progress, November 1991.
+
+
+
+
+
+Berners-Lee, Masinter & McCahill                               [Page 24]
+
+RFC 1738            Uniform Resource Locators (URL)        December 1994
+
+
+  [20] "Coded Character Set -- 7-bit American Standard Code for
+       Information Interchange", ANSI X3.4-1986.
+
+Editors' Addresses
+
+Tim Berners-Lee
+World-Wide Web project
+CERN,
+1211 Geneva 23,
+Switzerland
+
+Phone: +41 (22)767 3755
+Fax: +41 (22)767 7155
+EMail: timbl@info.cern.ch
+
+
+Larry Masinter
+Xerox PARC
+3333 Coyote Hill Road
+Palo Alto, CA 94034
+
+Phone: (415) 812-4365
+Fax: (415) 812-4333
+EMail: masinter@parc.xerox.com
+
+
+Mark McCahill
+Computer and Information Services,
+University of Minnesota
+Room 152 Shepherd Labs
+100 Union Street SE
+Minneapolis, MN 55455
+
+Phone: (612) 625 1300
+EMail: mpm@boombox.micro.umn.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Berners-Lee, Masinter & McCahill                               [Page 25]
+