and in the context of the URI

                           magic://a/b/c//d/e/

   the results would be exactly the same.

Fragment-id

   This represents a part of, fragment of, or a sub-function within, an
   object.  Its syntax and semantics are defined by the application
   responsible for the object, or the specification of the content type
   of the object.  The only definition here is of the allowed characters
   by which it may be represented in a URL.




 
RFC 1630                      URIs in WWW                      June 1994


   Specific syntaxes for representing fragments in text documents by
   line and character range, or in graphics by coordinates, or in
   structured documents using ladders, are suitable for standardization
   but not defined here.

   The fragment-id follows the URL of the whole object from which it is
   separated by a hash sign (#).  If the fragment-id is void, the hash
   sign may be omitted: A void fragment-id with or without the hash sign
   means that the URL refers to the whole object.

   While this hook is allowed for identification of fragments, the
   question of addressing of parts of objects, or of the grouping of
   objects and relationship between continued and containing objects, is
   not addressed by this document.

   Fragment identifiers do NOT address the question of objects which are
   different versions of a "living" object, nor of expressing the
   relationships between different versions and the living object.

   There is no implication that a fragment identifier refers to anything
   which can be extracted as an object in its own right.  It may, for
   example, refer to an indivisible point within an object.

Specific Schemes

   The mapping for URIs onto some existing standard and experimental
   protocols is outlined in the BNF syntax definition.  Notes on
   particular protocols follow.  These URIs are frequently referred to
   as URLs, though the exact definition of the term URL is still under
   discussion (March 1993).  The schemes covered are:

   http                    Hypertext Transfer Protocol (examples)

   ftp                     File Transfer protocol

   gopher                  Gopher protocol

   mailto                  Electronic mail address

   news                    Usenet news

   telnet, rlogin and tn3270
                           Reference to interactive sessions

   wais                    Wide Area Information Servers

   file                    Local file access





 
RFC 1630                      URIs in WWW                      June 1994


   The following schemes are proposed as essential to the unification of
   the web with electronic mail, but not currently (to the author's
   knowledge) implemented:

   mid                     Message identifiers for electronic mail

   cid                     Content identifiers for MIME body part

   The schemes for X.500, network management database, and Whois++ have
   not been specified and may be the subject of further study.  Schemes
   for Prospero, and restricted NNTP use are not currently implemented
   as far as the author is aware.

   The "urn" prefix is reserved for use in encoding a Uniform Resource
   Name when that has been developed by the IETF working group.

   New schemes may be registered at a later time.

HTTP

   The HTTP protocol specifies that the path is handled transparently by
   those who handle URLs, except for the servers which de-reference