URI共通構文（G）

   Section 4 (URI References) was added to stem the confusion regarding
   "what is a URI" and how to describe fragment identifiers given that
   they are not part of the URI, but are part of the URI syntax and
   parsing concerns.  In addition, it provides a reference definition
   for use by other IETF specifications (HTML, HTTP, etc.) that have
   previously attempted to redefine the URI syntax in order to account
   for the presence of fragment identifiers in URI references.

   Section 2.4 was rewritten to clarify a number of misinterpretations
   and to leave room for fully internationalized URI.

   Appendix F on abbreviated URLs was added to describe the shortened
   references often seen on television and magazine advertisements and
   explain why they are not used in other contexts.

   Changed to URI syntax instead of just URL.

   Confusion regarding the terms "character encoding", the URI
   "character set", and the escaping of characters with %<hex><hex>
   equivalents has (hopefully) been reduced.  Many of the BNF rule names
   regarding the character sets have been changed to more accurately
   describe their purpose and to encompass all "characters" rather than
   just US-ASCII octets.  Unless otherwise noted here, these
   modifications do not affect the URI syntax.

   Both RFC 1738 and RFC 1808 refer to the "reserved" set of characters
   as if URI-interpreting software were limited to a single set of
   characters with a reserved purpose (i.e., as meaning something other
   than the data to which the characters correspond), and that this set
   was fixed by the URI scheme.  However, this has not been true in
   practice; any character that is interpreted differently when it is
   escaped is, in effect, reserved.  Furthermore, the interpreting
   engine on a HTTP server is often dependent on the resource, not just
   the URI scheme.  The description of reserved characters has been
   changed accordingly.

   The plus "+", dollar "$", and comma "," characters have been added to
   those in the "reserved" set, since they are treated as reserved
   within the query component.

   The tilde "~" character was added to those in the "unreserved" set,
   since it is extensively used on the Internet in spite of the
   difficulty to transcribe it with some keyboards.

   The syntax for URI scheme has been changed to require that all
   schemes begin with an alpha character.

   The "user:password" form in the previous BNF was changed to a
   "userinfo" token, and the possibility that it might be
   "user:password" made scheme specific. In particular, the use of
   passwords in the clear is not even suggested by the syntax.

   The question-mark "?" character was removed from the set of allowed
   characters for the userinfo in the authority component, since testing
   showed that many applications treat it as reserved for separating the
   query component from the rest of the URI.

   The semicolon ";" character was added to those stated as being
   reserved within the authority component, since several new schemes
   are using it as a separator within userinfo to indicate the type of
   user authentication.

   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
      <foo:/bar>   and   <foo:bar>
   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.

   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.

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

   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 <net_loc> has been replaced with <authority>, 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 <hier_part> syntax.