rfc1630.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.


RFC 1630                      URIs in WWW                      June 1994


      Where possible, this mail address should correspond to a usable
      mail address for the user, and preferably give a DNS host name
      which resolves to the IP address of the client.  Note that servers
      currently vary in their treatment of the anonymous password.

   Path

      The FTP protocol allows for a sequence of CWD commands (change
      working directory) and a TYPE command prior to service commands
      such as RETR (retrieve) or NLIST (etc.) which actually access a
      file.

      The arguments of any CWD commands are successive segment parts of
      the URL delimited by slash, and the final segment is suitable as
      the filename argument to the RETR command for retrieval or the
      directory argument to NLIST.

      For some file systems (Unix in particular), 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 the same as the URL path.  This does NOT mean that the
      URL is a Unix filename.

         Note: Retrieving subsequent URLs from the same host

      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.

   Data type

      The data content type of a file can only, in the general FTP case,
      be deduced from the name, normally the suffix of the name.  This
      is not standardized. An alternative is for it to be transferred in
      information outside the URL.  A suitable FTP transfer type (for
      example binary "I" or text "A") must in turn be deduced from the
      data content type.  It is recommended that conventions for
      suffixes of public archives be established, but it is outside the
      scope of this standard.

      An FTP URL may optionally specify the FTP data transfer type by
      which an object is to be retrieved. Most of the methods correspond
      to the FTP "Data Types" ASCII and IMAGE for the retrieval of a
      document, as specified in FTP by the TYPE command.  One method
      indicates directory access.



Berners-Lee                                                    [Page 15]

RFC 1630                      URIs in WWW                      June 1994


      The data type is specified by a suffix to the URL.  Possible
      suffixes are:

       ;type = <type-code>     Use FTP type as given to perform data
                               transfer.

       /                       Use FTP directory list commands to read
                               directory

      The type code is in the format defined in RFC 959 except that THE
      SPACE IS OMITTED FROM THE URL.

   Transfer Mode

      Stream Mode is always used.

Gopher

   The gopher URL specifies the host and optionally the port to which
   the client should connect. This is followed by a slash and a single
   gopher type code. This type code is used by the client to determine
   how to interpret the server's reply and is is not for sending to
   server.  The command string to be sent to the server immediately
   follows the gopher type character.  It consists of the gopher
   selector string followed by any "Gopher plus" syntax, but always
   omitting the trainling CR LF pair.

   When the gopher command string contains characters (such a embedded
   CR LF and HT characters) not allowed in a URL, these are encoded
   using the conventional encoding.

   Note that some gopher selector strings begin with a copy of the
   gopher type character, in which case that character will occur twice
   consecutively.  Also note that the gopher selector string may be an
   empty string since this is how gopher clients refer to the top-level
   directory on a gopher server.

   If the encoded command string (with trailing CR LF stripped) would be
   void then the gopher type character may be omiited and "1" (ASCII 31
   hex) is assumed.

   Note that slash "/" in gopher selector strings may not correspond to
   a level in a hierarchical structure.








Berners-Lee                                                    [Page 16]

RFC 1630                      URIs in WWW                      June 1994


Mailto

   This allows a URL to specify an RFC822 addr-spec mail address.  Note
   that use of % , for example as used in forming a gatewayed mail
   address, requires conversion to %25 in a URL.

News

   The news locators refer to either news group names or article message
   identifiers which must conform to the rules for a Message-Id of RFC
   1036 (Horton 1987).  A message identifier may be distinguished from a
   news group name by the presence of the commercial at "@" character.
   These rules imply that within an article, a reference to a news group
   or to another article will be a valid URL (in the partial form).

   A news URL may be dereferenced using NNTP (RFC 977, Kantor 1986)
   (The ARTICLE by message-id command ) or using any other protocol for
   the conveyance of usenet news articles, or by reference to a body of
   news articles already received.

   Note 1:

      Among URLs the "news" URLs are anomalous in that they are
      location-independent. They are unsuitable as URN candidates
      because the NNTP architecture relies on the expiry of articles and
      therefore a small number of articles being available at any time.
      When a news: URL is quoted, the assumption is that the reader will
      fetch the article or group from his or her local news host.  News
      host names are NOT part of news URLs.

   Note 2:

      An outstanding problem is that the message identifier is
      insufficient to allow the retrieval of an expired article, as no
      algorithm exists for deriving an archive site and file name.  The
      addition of the date and news group set to the article's URL would
      allow this if a directory existed of archive sites by news group.

      Suggested subject of study in conjunction with NNTP working group.
      Further extension possible may be to allow the naming of subject
      threads as addressable objects.

Telnet, rlogin, tn3270

   The use of URLs to represent interactive sessions is a convenient
   extension to their uses for objects.  This allows access to
   information systems which only provide an interactive service, and no
   information server.  As information within the service cannot be



Berners-Lee                                                    [Page 17]

RFC 1630                      URIs in WWW                      June 1994


   addressed individually or, in general, automatically retrieved, this
   is a less desirable, though currently common, solution.

URN

   The "Universal Resource Name" is currently (March 1993) under
   development in the IETF.  A requirements specification is in
   preparation. It currently looks as though it will be a short string
   suitable for encoding in URI syntax, for which case the "urn:" prefix
   is reserved.  The URN shall be encoded precisely as defined in the
   (future) URN standard, except in that:

      If the official description of the URN syntax includes any
      constant wrapper characters, then they shall not be omitted from
      the URI encoding of the URN;

      If the URN has a hierarchical nature, then the slash delimiter
      shall be used in the URI encoding;

      If the URN has a hierarchical nature, the most significant part
      shall be encoded on the left in the URI encoding;

      Any characters with reserved meanings in the URI syntax shall be
      escape encoded

   These rules of course apply to any URI scheme.  It is of course
   possible that the URN syntax will be chosen such that the URI
   encoding will be a 1-1 transcription.

   An example might be a name such as

         urn:/iana/dns/ch/cern/cn/techdoc/94/1642-3

   but the reader should refer to the latest URN drafts or
   specifications.

WAIS

   The current WAIS implementation public domain requires that a client
   know the "type" of a object prior to retrieval. This value is
   returned along with the internal object identifier in the search
   response. It has been encoded into the path part of the URL in order
   to make the URL sufficient for the retrieval of the object.

   Within the WAIS world, names do not of course need to be prefixed by
   "wais:" (by the partial form rules).





Berners-Lee                                                    [Page 18]

RFC 1630                      URIs in WWW                      June 1994


   The wpath of a WAIS URL consists of encoded fields of the WAIS
   identifier, in the same order as inthe WAIS identifier. For each
   field, the identifier field number is the digits before the equals
   sign, and the field contents follow, encoded in the conventional
   encoding, terminated by ";".

file

   The other URI schemes (except nntp) share the property that they are
   equally valid at any geographical place.

   There is however a real practical requirement to be able to generate
   a URL for an object in a machine's local file system.

   The syntax is similar to the ftp syntax, but in this case the slash
   is used to donate boundaries between directory levels of a
   hierarchical file system is used.  The "client" software converts the
   file URL into a file name in the local file name conventions.  This
   allows local files to be treated just as network objects without any
   necessity to use a network server for access.  This may be used for
   example for defining a user's "home" document in WWW.

   There is clearly a danger of confusion that a link made to a local
   file should be followed by someone on a different system, with
   unexpected and possibly harmful results.  Therefore, the convention
   is that even a "file" URL is provided with a host part.  This allows
   a client on another system to know that it cannot access the file
   system, or perhaps to use some other local mecahnism to access the
   file.

   The special value "localhost" is used in the host field to indicate
   that the filename should really be used on whatever host one is.
   This for example allows links to be made to files which are
   distribted on many machines, or to "your unix local password file"
   subject of course to consistency across the users of the data.

   A void host field is equivalent to "localhost".

Message-Id

   For systems which include information transferred using mail
   protocols, there is a need to be able to make cross-references
   between different items of information, even though, by the nature of
   mail, those items are only available to a restricted set of people.

   Two schemes are defined.  The first, "mid:", refers to the STD 11,
   RFC 822 Message-Id of a mail message.  This Identifier is already
   used in RFC 822 in for example the References and In-Reply-to field.



Berners-Lee                                                    [Page 19]

RFC 1630                      URIs in WWW                      June 1994


   The rest of the URL after the "mid:" is the RFC822 msg-id with the
   constant <> wrapper removed, leaving an identifier whose format in
   fact happens to be the same as addr-spec format for mailboxes (though
   the semantics are different).

   The use of a "mid" URL implies access to a body of mail already
   received. If a message has been distributed using NNTP or other
   usenet protocols over the news system, then the "news:" form should
   be used.

Content-Id

   The second scheme, "cid:", is similar to "mid:", but makes reference
   to a body part of a MIME message by the value of its content-id
   field.  This allows, for example, a master document being the first
   part of a multipart/related MIME message to refer to component parts
   which are transferred in the same message.

   Note

      Beware however, that content identifiers are only required to be
      unique within the context of a given MIME message, and so the cid:
      URL is only meaningful with the context the same MIME message. For
      a reference outside the message, it would need to be appended to
      the message-id of the whole message.  A syntax for this has not
      been defined.

Schemes for Further Study

   X500

      The mapping of x500 names onto URLs is not defined here.  A
      decision is required as to whether "distinguished names" or "user
      friendly names" (ufn), or both, should be allowed.  If any
      punctuation conversions are needed from the adopted x500
      representation (such as the use of slashes between parts of a ufn)
      they must be defined.  This is a subject for study.

   WHOIS

      This prefix describes the access using the "whois++" scheme in the
      process of definition.  The host name part is the same as for
      other IP based schemes.  The path part can be either a whois
      handle for a whois object, or it can be a valid whois query
      string. This is a subject for further study.






Berners-Lee                                                    [Page 20]

RFC 1630                      URIs in WWW                      June 1994


   NETWORK MANAGEMENT DATABASE

      This is a subject for study.

   NNTP

      This is an alternative form of reference for news articles,
      specifically to be used with NNTP servers, and particularly those
      incomplete server implementations which do not allow retrieval by
      message identifier.  In all other cases the "news" scheme should
      be used.

      The news server name, newsgroup name, and index number of an
      article within the newsgroup on that particular server are given.
      The NNTP protocol must be used.

      Note 1.

         This form of URL is not of global accessability, as typically
         NNTP servers only allow access from local clients.   Note that
         the article numbers within groups vary from server to server.

         This form or URL should not be quoted outside this local area.
         It should not be used within news articles for wider
         circulation than the one server.  This is a local identifier
         for a resource which is often available globally, and so is not
         recommended except in the case in which incomplete NNTP
         implementations on the local server force its adoption.

Prospero

   The Prospero (Neuman, 1991) directory service is used to resolve the
   URL yielding an access method for the object (which can then itself
   be represented as a URL if translated).  The host part contains a
   host name or internet address.  The port part is optional.

   The path part contains a host specific object name and an optional
   version number. If present, the version number is separated from the
   host specific object name by the characters "%00" (percent zero
   zero), this being an escaped string terminator (null).  External
   Prospero links are represented as URLs of the underlying access
   method and are not represented as Prospero URLs.

Registration of naming schemes

   A new naming scheme may be introduced by defining a mapping onto a
   conforming URL syntax, using a new prefix.  Experimental prefixes may
   be used by mutual agreement between parties, and must start with the



Berners-Lee                                                    [Page 21]