Less likely are cases where the relative URL uses unnecessary or
   nonsensical forms of the "." and ".." complete path segments.

      ./../g        = <URL:http://a/b/g>
      ./g/.         = <URL:http://a/b/c/g/>
      g/./h         = <URL:http://a/b/c/g/h>
      g/../h        = <URL:http://a/b/c/h>

   Finally, some older parsers allow the scheme name to be present in a
   relative URL if it is the same as the base URL scheme.  This is
   considered to be a loophole in prior specifications of partial URLs
   [1] and should be avoided by future parsers.

      http:g        = 
      http:         = 

5.3.  Recommended Practice

   Authors should be aware that path names which contain a colon ":"
   character cannot be used as the first component of a relative URL
   path (e.g., "this:that") because they will likely be mistaken for a
   scheme name.  It is therefore necessary to precede such cases with
   other components (e.g., "./this:that"), or to escape the colon
   character (e.g., "this%3Athat"), in order for them to be correctly
   parsed.  The former solution is preferred because it does not affect
   the absolute form of the URL.




 
RFC 1808           Relative Uniform Resource Locators          June 1995


   There is an ambiguity in the semantics for the ftp URL scheme
   regarding the use of a trailing slash ("/") character and/or a
   parameter ";type=d" to indicate a resource that is an ftp directory.
   If the result of retrieving that directory includes embedded relative
   URLs, it is necessary that the base URL path for that result include
   a trailing slash.  For this reason, we recommend that the ";type=d"
   parameter value not be used within contexts that allow relative URLs.

6.  Security Considerations

   There are no security considerations in the use or parsing of
   relative URLs.  However, once a relative URL has been resolved to its
   absolute form, the same security considerations apply as those
   described in RFC 1738 [2].

7.  Acknowledgements

   This work is derived from concepts introduced by Tim Berners-Lee and
   the World-Wide Web global information initiative.  Relative URLs are
   described as "Partial URLs" in RFC 1630 [1].  That description was
   expanded for inclusion as an appendix for an early draft of RFC 1738,
   "Uniform Resource Locators (URL)" [2].  However, after further
   discussion, the URI-WG decided to specify Relative URLs separately
   from the primary URL draft.

   This document is intended to fulfill the recommendations for Internet
   Resource Locators as stated in [6].  It has benefited greatly from
   the comments of all those participating in the URI-WG.  Particular
   thanks go to Larry Masinter, Michael A. Dolan, Guido van Rossum, Dave
   Kristol, David Robinson, and Brad Barber for identifying
   problems/deficiencies in earlier drafts.

8.  References

   [1] Berners-Lee, T., "Universal Resource Identifiers in WWW: A
       Unifying Syntax for the Expression of Names and Addresses of
       Objects on the Network as used in the World-Wide Web", RFC 1630,
       CERN, June 1994.

   [2] Berners-Lee, T., Masinter, L., and M. McCahill, Editors, "Uniform
       Resource Locators (URL)", RFC 1738, CERN, Xerox Corporation,
       University of Minnesota, December 1994.

   [3] Berners-Lee T., and D. Connolly, "HyperText Markup Language
       Specification -- 2.0", Work in Progress, MIT, HaL Computer
       Systems, February 1995.
       <URL:http://www.ics.uci.edu/pub/ietf/html/>





 
RFC 1808           Relative Uniform Resource Locators          June 1995


   [4] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail
       Extensions): Mechanisms for Specifying and Describing the Format
       of Internet Message Bodies", RFC 1521, Bellcore, Innosoft,
       September 1993.

   [5] Crocker, D., "Standard for the Format of ARPA Internet Text
       Messages", STD 11, RFC 822, UDEL, August 1982.

   [6] Kunze, J., "Functional Recommendations for Internet Resource
       Locators", RFC 1736, IS&T, UC Berkeley, February 1995.