Subject: SFTP URI issues

From: "Salowey, Joe" <[email-masked]>
Date: Tue, 27 Dec 2005 17:40:24 -0800

Several issues have been raised in the past month over the SFTP URI. 

Issue #1: On the IETF list several people expressed concern that the
scheme name "sftp" might be confused with RFC 913 (Simple FTP) or RFC
2228/4217 (FTP security extensions using TLS).  While I think 913 is
historic and unlikely to cause confusion I believe there are
implementations of TLS FTP around.  I think there are probably many more
implementations of sftp and many people would understand that SFTP is
file transfer in SSH, but there is room for confusion.  We could either
note the confusion and keep sftp or select some other scheme name such
as sshftp and reserve sftp so no other protocol uses it. 

Issue #2: The current draft states that if you specify a URL that begins
without a %2F (URL encoded /) it is relative to the home directory.
Several people have suggested that this is awkward and they would rather
see 

A) A URL that beings without a %2f to be an absolute URL, and choose
another delimiter such as ~ to indicate a path relative to the home
directory.

B) Allow / instead of %2F so sftp://[email-masked]/%2ffile becomes
sftp://[email-masked]//file 

I'm not sure B is legal URL encoding, but I think it may work.  A seems
like it would work. 

Any Recommendations?

Thanks,

Joe

---

From: "Tom Petch" <[email-masked]>
Date: Wed, 28 Dec 2005 11:55:00 +0100

----- Original Message -----
From: "Salowey, Joe" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, December 28, 2005 2:40 AM
Subject: SFTP URI issues

> as sshftp and reserve sftp so no other protocol uses it.

Choose another one! ideally one starting with ftp like ftps or ftpssh; for me it
is the ftp that matters most, with ssh being subsidiary to that (in an ssh WG,
it it tempting but I think misleading to put it the other way round:-)

> I'm not sure B is legal URL encoding, but I think it may work.  A seems
Legal URI since authority is always present (according to the syntax) and it
falls under the path-abempty construct of RFC3986, as opposed to the
path-absolute which begins with a single such character.  But I would go for
another character to indicate a relative path; solidus has so many different
uses in different contexts.

And I would change URL to URI throughout the I-D.

> Any Recommendations?

Gosh, shades of ITU-T:-)

Tom Petch

---

From: "Tom Petch" <[email-masked]>
Date: Wed, 28 Dec 2005 12:37:08 +0100

Mmmm

I should have added to my previous reply that I never find RFC3986 easy to
understand, perhaps because it is not easy to understand:-(

In RFC3986 is the following
hier-part     = "//" authority path-abempty
                 / path-absolute
                 / path-rootless
                 / path-empty
which means
    authority path-abempty OR
    path-absolute OR
    path-rootless OR
    path-empty
while the I-D has
hier-part     =  "//" authority ( path-empty / path-abempty )
which means
    authority path-empty OR
    authority path-abempty
Is this change intended?

Tom Petch

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 28 Dec 2005 16:04:42 -0500

On Wednesday, December 28, 2005 11:55:00 AM +0100 Tom Petch 
<[email-masked]> wrote:

> Choose another one! ideally one starting with ftp like ftps or ftpssh;
> for me it is the ftp that matters most, with ssh being subsidiary to that
> (in an ssh WG, it it tempting but I think misleading to put it the other
> way round:-)

The widely adopted convention for naming "protocol X over TLS" is to append 
an "s" to the name of protocol X (https, imaps, etc).  Using that name for 
this protocol would be highly misleading.

Second, it is worth noting that this protocol is _not_ FTP over SSH; it is 
the "SSH File Transfer Protocol", so named because it was originally 
intended to be carried over SSH, though I don't believe there is anything 
which prevents its use over other stream-oriented transports.  You could 
begin calling the protocol "SSHFTP" instead of "SFTP", but I think that's 
likely to cause more confusion than does the conflict with RFC913, not to 
mention being harder to say.  Calling the protocol "FTPSSH" or "FTPS" would 
be wrong; those aren't abbreviations for the name of the protocol, and are 
likely to confuse people into thinking you're talking about FTP-over-SSH or 
FTP-over-TLS, and this is neither.  Using either of those as URI keywords 
would have exactly the same problem.

Personally, I think as long as people refer to the protocol as "SFTP", the 
SSH subsystem name used by the protocol is "sftp", and multiple 
implementations call their client "sftp", it would be silly and confusing 
to use any other name in the construction of a URI scheme.

-- Jeff