rio 0.4.2 → 0.5.1

data/doc/rfc1738.txt

@@ -1,1403 +0,0 @@
-
-
-
-
-
-
-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]
-