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

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

Joe

Expanding on my previous post, I think we have an intractable problem to which
there is no good solution:-(  I do see how you ended up with the use of %2F but
believe that the experience of ftp: suggests that such a scheme would not get
followed.

URIs should be easy to transcribe and convey protocol information.  So
draft-ietf-secsh-filexfer-10.txt can define filenames as an almost free string,
the only syntax being 'File names starting with a slash are absolute', wrap them
up in a string and transmit them.  URI cannot and must embed them in a syntax
where / already has a special meaning.

The logical approach is to make
 sftp://example.com//etc/protocol/
an absolute path and, with one fewer /,
 sftp://example.com/etc/protocol/
a relative one but draft-hoffman-ftp-uri-04.txt suggests that such an approach
has failed with ftp: since clients put in a / regardless.  (The ftp: scheme is
not that close a parallel since it does impose a syntax on path, parsing it with
/ and expecting each element to be sent in a separate CWD command, which
secsh-filexfer does not).

tftp [RFC3617] opts out of this problem specifying
tftp://host /file
interpret file how you like

smb: [draft-crhertel-smb-url-10.txt] requires the path to be <path-absolute> ie
starting with / but not //

http:, at least as defined in RFC2616, uses <abs_path>, which always starts with
a /

I suggested putting in a tilde or some such for paths relative to a user
directory  but it is only a half-hearted suggestion because I anticipate clients
doing something comparable to their behaviour with ftp:, failing to remove the
tilde when they should or doing the opposite and inserting it when they shoud
not.

We could insert something competely different, in effect saying path= whatever
comes next, ie
 sftp://example.com/path=/etc/protocol/
replacing path= with a character sequence tbd.

If only secsh-filexfer specified a tighter syntax - but it doesn't, so I see no
good solution.

Tom Petch

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


> 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>
> >
>