> RFC 1738 specifically states that the path for an FTP
> URI does not include the / which separates the URI
> path from the URI host. Example:
>
>    ftp://ftp.example.com/pub/ruby
>
> The above URI indicates that the client should connect
> to ftp.example.com then cd pub/ruby from the initial
> login directory, *not* cd /pub/ruby.
>
> Similarly, for an absolute FTP path such as cd
> /foo/bar, the leading / must be escaped as %2F.
>
> In other words, FTP URIs are interpreted differently
> from generic URIs (RFC2396). Currently the standard
> library treats them the same as generic URIs, so the
> path returned from parsing an FTP URI is wrong, and
> valid paths passed to build() result in errors.

    Just a few clarifications...

    First of all, RFC1738 described URLs, not URIs, and it was *updated*
by RFC1808 and RFC2396 to bring URLs under the URI umbrella.  The
statement "FTP URIs are interpreted differently from generic URIs" is
not correct, FTP URLs are now a subset of generic URIs.  As such, the
difference between a relative path and an absolute path is simply a
leading slash ("/"); it is not required to be encoded ("%2f").

    However the essence of what is being said is true: absolute
pathnames require an additional slash after the slash separating the
path from the hostname.  For example, the absolute pathname example
given above (i.e. "CWD /pub/ruby") should be
"ftp://ftp.example.com//pub/ruby".  "ftp://ftp.example.com/pub/ruby"
should only perform a "CWD pub/ruby".

    - Warren Brown