Re: SFTP was Re: presence of authority was Re: SFTP URI issues

["Tom Petch" <nwnetworks%dial.pipex.com@localhost>]

My sense is that the Generic URI syntax has been retrofitted to a variety of
pre-existing paths and so looks a bit like Topsy, and would have looked
different had it come first:-)

I like RFC1738 as a (obsolescent) collection of schemes and syntax and, which I
had forgotten, does include, for ftp, %2F, differentiating
//etc as generating   CWD
/%2Fetc as generating   CWD /etc
/etc as generating   CWD etc
It says, and RFC3986 does not, that the first slash is not part of the path but
a separator, with another character for home directory

draft-hoffman-ftp-uri-04.txt, which is/was intended to supersede that piece,
says that most implementations put in a / anyway in conflict with RFC1738.  That
I-D did run into some difficulties which may be why I cannot see it as an RFC.
(There was an e-mail from Paul Hoffman to the URI list that he was abandoning
work on the file: scheme because consensus was impossible but I never saw such a
statement for ftp:)

In between came RFC2396 which warns us that / delimits parts of the hierarchy
and is not to be confused with the identical / which is used as part of a path.
IMHO, it is a mess because / was chosen as a URI delimiter when it already was
in use in file paths.

Still, RFC3986 is what matters and that allows us // at the start of a path (or
/// for that matter) to interpret as we will.  I think // for an absolute path
is fine.

I had always seen tilde ~ as the indicator of user directory.  It is an
unreserved character in most URI (tel being the exception) which is probably why
I cannot see its use being defined in any other URI.  Would it do, ie // for
absolute /~ for relative and /<anything else> being invalid? or does this run
into the same problem namely that the tilde may or may not already be there as
part of the path the end user wishes to provide via the URI to client and thence
to server?

Tom Petch

----- Original Message -----
From: "Salowey, Joe" <jsalowey%cisco.com@localhost>
To: "Tom Petch" <nwnetworks%dial.pipex.com@localhost>; <ietf-ssh%NetBSD.org@localhost>
Sent: Tuesday, January 10, 2006 6:34 PM
Subject: RE: SFTP was Re: presence of authority was Re: SFTP URI issues



<snip>
>
> a) The Generic Syntax for URI [RFC3986] says
>   "If a URI contains an authority component, then the path component
>    must either be empty or begin with a slash ("/") character.  "
> which is what <path-abempty> achieves.  The I-D goes on to say that
> if a path starts with a / then it is relative to the root of
> the file system,
> otherwise it is relative to the user's home or default
> directory.  But the
> Generic Syntax requires the path to start with a / or be
> empty, so you can never
> have a path relative to the user's home directory except for
> an empty one:-)
>
> b) In this section, the I-D says that / is a reserved
> character - I agree - and
> that it must be encoded - disagree.   In URI, reserved is not
> used in the way I
> would like to see it used -  it means that sometimes the
> character must be
> encoded, other times not:-{
>   " If data for a URI component would conflict with a reserved
>      character's purpose as a delimiter, then the conflicting
> data must be
>      percent-encoded before the URI is formed."
> The initial / of <path-abempty> is a delimiter between
> authority and path and so
> must be just that, / not %2F.
> So are you allowing
>    sftp://example.com/%2Fetc/protocols
> for absolute paths as opposed to
>    sftp://example.com/mylocalfile.txt
> for relative ones?
>

[Joe] Yes, that was the intent of the draft.  However this doesn't seem
to be the best way to handle this.  I think most people would rather not
have to enter in %2F into a URL to specify an absolute path.  Using "//"
to represent the absolute path is better and you confirm that it would
work fine.

Is this behavior consistent with other URLs? In RFC3986 these are
referred to as absolute paths so perhaps it would be better to have
paths default to root and define a special delimiter to indicate home
directory at the beginning of the path.  This would seem to make it more
likely that an HTTP URL path would also work as an SFTP URL path, but
perhaps the two cases are too different for this actually to work.





> I am unclear.
>
> (The end of <path-abempty> will be signalled by the end of
> the URI or the
> characters ? or # and so / is not a delimiter for that
> purpose and can appear as
> such as many times as it likes unencoded within such a path).
>
> Tom Petch
>
> <snip>
>