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).






 
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.




 
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