RFC 1738 specified that the path was separated from the authority
   portion of a URI by a slash.  RFC 1808 followed suit, but with a
   fudge of carrying around the separator as a "prefix" in order to
   describe the parsing algorithm.  RFC 1630 never had this problem,
   since it considered the slash to be part of the path.  In writing
   this specification, it was found to be impossible to accurately
   describe and retain the difference between the two URI
         and   
   without either considering the slash to be part of the path (as
   corresponds to actual practice) or creating a separate component just
   to hold that slash.  We chose the former.

G.3. Modifications from RFC 1738

   The definition of specific URL schemes and their scheme-specific
   syntax and semantics has been moved to separate documents.

   The URL host was defined as a fully-qualified domain name.  However,
   many URLs are used without fully-qualified domain names (in contexts
   for which the full qualification is not necessary), without any host
   (as in some file URLs), or with a host of "localhost".

   The URL port is now *digit instead of 1*digit, since systems are
   expected to handle the case where the ":" separator between host and
   port is supplied without a port.





 
RFC 2396                   URI Generic Syntax                August 1998


   The recommendations for delimiting URI in context (Appendix E) have
   been adjusted to reflect current practice.

G.4. Modifications from RFC 1808

   RFC 1808 (Section 4) defined an empty URL reference (a reference
   containing nothing aside from the fragment identifier) as being a
   reference to the base URL.  Unfortunately, that definition could be
   interpreted, upon selection of such a reference, as a new retrieval
   action on that resource.  Since the normal intent of such references
   is for the user agent to change its view of the current document to
   the beginning of the specified fragment within that document, not to
   make an additional request of the resource, a description of how to
   correctly interpret an empty reference has been added in Section 4.

   The description of the mythical Base header field has been replaced
   with a reference to the Content-Location header field defined by
   MHTML [RFC2110].

   RFC 1808 described various schemes as either having or not having the
   properties of the generic URI syntax.  However, the only requirement
   is that the particular document containing the relative references
   have a base URI that abides by the generic URI syntax, regardless of
   the URI scheme, so the associated description has been updated to
   reflect that.

   The BNF term  has been replaced with , since the
   latter more accurately describes its use and purpose.  Likewise, the
   authority is no longer restricted to the IP server syntax.

   Extensive testing of current client applications demonstrated that
   the majority of deployed systems do not use the ";" character to
   indicate trailing parameter information, and that the presence of a
   semicolon in a path segment does not affect the relative parsing of
   that segment.  Therefore, parameters have been removed as a separate
   component and may now appear in any path segment.  Their influence
   has been removed from the algorithm for resolving a relative URI
   reference.  The resolution examples in Appendix C have been modified
   to reflect this change.

   Implementations are now allowed to work around misformed relative
   references that are prefixed by the same scheme as the base URI, but
   only for schemes known to use the  syntax.









 
RFC 2396                   URI Generic Syntax                August 1998


H.  Full Copyright Statement

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this