Re: Ooops: generic syntax I-D bounced: ftp://ftp.parc.xerox.com/pub/masinter/draft-fielding-url-syntax-06.txt instead

	Section 5.2 says:

5.2. Resolving Relative References to Absolute Form
[...]
         "<segment>/.." is removed.

      h) If the resulting buffer string still begins with one or more
         complete path segments of "..", then the reference is
                                         ^^^^^^^^^^^^^^^^^^^^^
         considered to be in error.  Implementations may handle this
         ^^^^^^^^^^^^^^^^^||||||||
         error by retaining these components in the resolved path
         (i.e., treating them as part of the final URL), by removing
         them from the resolved path (i.e., discarding relative levels
         above the root), or by avoiding traversal of the reference.
[...]


	Appendix C.2 says:

C.2.  Abnormal Examples
[...]
   Parsers must be careful in handling the case where there are more
   relative path ".." segments than there are hierarchical levels in
   the base URL's path.  Note that the ".." syntax cannot be used to
   change the site component of a URL.

      ../../../g    =  http://a/../g
      ../../../../g =  http://a/../../g
[...]

   While the rules for resolving partial/relative URLs since the have
                                                       ??????????????
   been such that if relative symbolic elements end up at the
   beginning of paths they should be retained,

      /../s/x      =  http://a/../s/x

   in practice, most parsers will strip lead relative symbolic
   elements in the destination URL, such that

     /../s/x       = http://a/s/x

   Because of the ambiguity, such relative forms should be avoided.
[...]                                            ^^^^^^^^^^^^^^^^^

   Some parsers inappropriately strip a lead relative symbolic path
                |||||||||||||||^^^^^^
   element from resolved paths in requests with some schemes.

      http://a/../b/c =  http://a/b/c
[...]



	These various statements need to be brought into harmony with
each other.  In the case of the http/https scheme(s), lead relative
symbolic elements are likely to reflect a goof in a partial href, and
traditionally have been rejected by http servers.  For the ftp scheme,
it may or may not be a goof, and may or may not be rejected.  For
example,

	ftp://[email protected]/../
	ftp://[email protected]/../friend/
	
may or may not be rejected, depending on whether me has privileges to
access me's parent directory and friend's home, but they are not
necessarily "in error".   Are the previous URL specs being changed such
that in all cases resultant lead relative symbolic elements are to be
considered errors, or are they correct but ill-advised, or are specific
exceptions (e.g., http/https) being specified for which stripping should
be done?
 
				Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 [email protected]         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================