Subject: [ftpext] Single Port FTP

From: Anthony Bryan <[email-masked]>
Date: Tue, 7 Jun 2011 19:21:36 -0400

fyi, some thoughts on single port FTP (i.e. avoiding opening a
separate data connection by doing data transfers over the control
connection).

heresy? :)

---------- Forwarded message ----------
From:  <[email-masked]>
Date: Tue, Jun 7, 2011 at 7:14 PM
Subject: New Version Notification for draft-bryan-ftp-lock-00.txt
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]

A new version of I-D, draft-bryan-ftp-lock-00.txt has been
successfully submitted by Anthony Bryan and posted to the IETF
repository.

Filename:        draft-bryan-ftp-lock
Revision:        00
Title:           File Transfer Protocol LOCK Command for Using a Single Port
Creation date:   2011-06-07
WG ID:           Individual Submission
Number of pages: 10

Abstract:
  One of the biggest hurdles for FTP in real life usage is its use of
  two connections.  First, it uses a primary connection to send control
  commands on, and when it sends or receives data, it opens a second
  TCP stream for that purpose.  This document specifies a new FTP LOCK
  command to be used by clients to request the server to use the
  control connection for data transfers, using a single port instead of
  two.

The IETF Secretariat

-- 
(( Anthony Bryan ... Metalink [ http://www.metalinker.org ]
  )) Easier, More Reliable, Self Healing Downloads

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 8 Jun 2011 01:25:35 +0200

> separate data connection by doing data transfers over the control

Isn't that called HTTP?

Seems to me that if you can open one connection you can open two. There is very little chance that many people are going to pay attention to new FTP specs. It's not like there aren't tons of old specs they haven't implemented (properly) yet.

---

From: John C Klensin <[email-masked]>
Date: Tue, 07 Jun 2011 21:15:22 -0400

--On Tuesday, June 07, 2011 19:21 -0400 Anthony Bryan
<[email-masked]> wrote:

> separate data connection by doing data transfers over the
> control connection).
> 
> heresy? :)

No, just not FTP.   TFTP and its various more secure variations
were designed for this, HTTP is often used to retrieve files and
provides similar single-port services, etc.  I see absolutely no
reason to clutter up FTP with the functional equivalent of an
architecturally completely different protocol.

   john

---

From: "Ángel González" <[email-masked]>
Date: Wed, 08 Jun 2011 17:09:26 +0200

> separate data connection by doing data transfers over the control

I don't think LOCK is an appropiate name.

You are doing two different things there.
- Using just one connection.
- Defining a new transfer mode.

A one-connection tranfer should be able to use a different
transfer mode, such as block mode. Also, another mode like a count of bytes
to be sent seems even easier.

The way some paragraphs are written seem too familiar for an standard, but
that's minor.

There seems to be a hidden assumption that the control
connection is binary safe.
What about 'headers' below the boundary?

There's no explanation about where is boundary-announce
expected to be provided.
I think it would better fit within the protocol if the boundary was 
passed as an
argument to a command/response code. It could also be auto-guessed from the
boundary-start.

References should list rfc2046 (MIME multipart type).

How should errors be handled?
I think that the server should send an error message, then close the 
control connection.
The client SHOULD in that case read the sent message for errors.
Another option would be that the server ignored anything after an error, 
the client
COULD stop its tranfer (by prematurely sending the boundary) on receving 
a server error,
but that may waste bandwidth for dumb clients.

---

From: Robert McMurray <[email-masked]>
Date: Fri, 10 Jun 2011 18:18:05 +0000

Single-port FTP is an interesting idea, though as John Klensin pointed out, HTTP definitely takes the place of FTP for most single-port transfers.

Just the same, I read through Anthony's draft and Ángel González's response a few times, and here is a quick brain dump of some additional thoughts that occurred to me while I was reading the draft. (I have to apologize up-front that several of these concepts are not fully thought-through, and as such I admit that they may have no merit - they're just what came to mind while I was reading over the draft and taking a few notes.)

First off, I like Anthony's idea of leveraging the MIME separator that everyone's already used to using in other areas.

Should the response to a post-LOCK command be 125 and not 150 since the channel is already open?

Should there be some sort of ABOR scenario?

Should the draft have examples of all the common transfer commands, not just RETR? For example:

RETR Example:
      C> TYPE I
      S> 200 Type set to I.
      C> LOCK
      S> 200 LOCK OK to current connection
      C> RETR filename.ext
      S> 125 Command connection already open; transfer starting
      S> boundary=separator189dhde78b287734237842g3847g
      S> --separator189dhde78b287734237842g3847g
      S> [raw binary data]
      S> --separator189dhde78b287734237842g3847g--
      S> 226 Transfer complete.

STOR Example:
      C> TYPE I
      S> 200 Type set to I.
      C> LOCK
      S> 200 LOCK OK to current connection
      C> STOR filename.ext
      S> 125 Command connection already open; transfer starting
      C> boundary=separator189dhde78b287734237842g3847g
      C> --separator189dhde78b287734237842g3847g
      C> [raw binary data]
      C> --separator189dhde78b287734237842g3847g--
      S> 226 Transfer complete.

How long is the LOCK in effect? The draft makes it seem like it's for a single command; perhaps there should be a corresponding UNLK command, so all post-LOCK commands are on a single channel until otherwise specified by the UNLK command. For example:

      C> TYPE I
      S> 200 Type set to I.
      C> LOCK
      S> 200 LOCK OK to current connection
      C> STOR file1.ext
      S> 125 Command connection already open; transfer starting
      C> boundary=separator189dhde78b287734237842g3847g
      C> --separator189dhde78b287734237842g3847g
      C> [raw binary data]
      C> --separator189dhde78b287734237842g3847g--
      S> 226 Transfer complete.
      C> STOR file2.ext
      S> 125 Command connection already open; transfer starting
      C> boundary=separator189dhde78b287734237842g3847g
      C> --separator189dhde78b287734237842g3847g
      C> [raw binary data]
      C> --separator189dhde78b287734237842g3847g--
      S> 226 Transfer complete.
      C> UNLK
      S> 200 UNLK OK from current connection

Instead of LOCK, how about a series of specific single-channel commands? So the matching list of dual-channel to single-channel commands might include:

      SRTR = RETR
      SSTR = STOR
      SLST = LIST
      SNLS = NLST
      SSTU = STOU
      SAPP = APPE

I obviously prefixed everything with an "S" for "single channel command"; perhaps "C" might be a better prefix for "control channel command". (e.g. CRTR, CSTR, etc.) For example:

      C> TYPE I
      S> 200 Type set to I.
      C> SSTR filename.ext
      S> 125 Command connection already open; transfer starting
      C> boundary=separator189dhde78b287734237842g3847g
      C> --separator189dhde78b287734237842g3847g
      C> [raw binary data]
      C> --separator189dhde78b287734237842g3847g--
      S> 226 Transfer complete.

Perhaps the boundary syntax could be simplified by one step - instead of declaring a boundary, there could declare an end-of-file marker, then start data immediately. For example:

      C> LOCK
      S> 200 LOCK OK to current connection
      C> STOR filename.ext
      S> 125 Command connection already open; transfer starting
      C> endoffile=marker189dhde78b287734237842g3847g
      C> [raw binary data]
      C> --marker189dhde78b287734237842g3847g--
      S> 226 Transfer complete.

That is, unless someone thinks that compound messages are feasible, which are not currently supported for FTP commands; this alludes somewhat to something that Ángel González mentioned about headers below the boundary. For example:

      C> LOCK
      S> 200 LOCK OK to current connection
      C> RETR /*.ext
      S> 125 Command connection already open; transfer starting
      C> boundary=separator189dhde78b287734237842g3847g
      C> --separator189dhde78b287734237842g3847g
      C> Content-Disposition: inline; filename="file1.ext"
      C> [raw binary data]
      C> --separator189dhde78b287734237842g3847g
      C> Content-Disposition: inline; filename=" file2.ext"
      C> [raw binary data]
      C> --separator189dhde78b287734237842g3847g--
      S> 226 Transfer complete.

Of course, that last example starts to look a lot like HTTP or SMTP over FTP, which brings us back to my opening liberally-worded paraphrase of John Klensin's earlier response that FTP doesn't need to resemble HTTP; otherwise we wouldn't need HTTP. ;-]

Thanks!

---

From: Sob <[email-masked]>
Date: Tue, 21 Jun 2011 07:07:50 +0200

>separate data connection by doing data transfers over the control

Draft-bryan-ftp-lock is more "single connection". There's also less 
heretic "single port, separate connections", now expired 
draft-rosenau-ftp-single-port.

The other draft solves problem that users have all the time. They 
install FTP server, forward only port 21 from NAT router and then 
wonder why it doesn't work. Well, it does in active mode, but active 
mode itself can be problematic when clients are also behind NAT.

Your draft solves it too, no problem, it's just that MIME separators 
don't exactly feel like FTP. Your additional bonus is saving time and 
resources by not establishing separate data connections. But it could 
be solved as well by using one permanent MODE B data connection (IIS 
FTP resurrected this mode recently, but unfortunately clients don't 
support it).

Personally I'd go with the other draft (it seems to be smaller change 
to how things work now) only with few updates (allow not just MODE S 
that it currently assumes, add FEAT line, remove strange/confusing section 6).

--