headers
Douglas J. Papenthien | 1 Nov 03:10
Favicon

Re: Followup on IETF72 discussion of FTP protocol extensions andupdates

>>RFC2228 is certainly supported by multiple implementations,
>
> That's good to hear; I had heard the opposite a few years ago.

RFC2228 has been implemented in our FTP server and client products since
2002.  I'm quite sure that many of our major competitors included it around
the same time.  The same can be said about RFCs 2640 and 3659.  The addition
of the MLST and MLSD commands were very welcome by us and many others in our
field.

>>Personally, I'd rather see SFTP (or FTP over SSH) improved enough to
>>make FTP go away.  But I don't think I mind this proposed WG.
>
> Yep.

I don't know that I particularly agree with this sentiment.  Much like the
"transition" to IPv6, I think you're going to be hard pressed to have much
luck stamping out FTP in favor of anything else regardless of the pros and
cons.

Douglas J. Papenthien - Vice President
http://www.RhinoSoft.com
Voice: +1(262) 560-9627
FAX: +1(262) 560-9628
Permalink | Reply | 10 comments |
headers
Nicolas Williams | 3 Nov 08:36
Picon

Re: Followup on IETF72 discussion of FTP protocol extensions andupdates

On Fri, Oct 31, 2008 at 09:10:09PM -0500, Douglas J. Papenthien wrote:
> >>Personally, I'd rather see SFTP (or FTP over SSH) improved enough to
> >>make FTP go away.  But I don't think I mind this proposed WG.
> >
> >Yep.
> 
> I don't know that I particularly agree with this sentiment.  Much like the
> "transition" to IPv6, I think you're going to be hard pressed to have much
> luck stamping out FTP in favor of anything else regardless of the pros and
> cons.

SSHv2 and SFTP have pretty widespread deployment.  The situation is not
remotely comparable to IPv6.

Also, good old protocols never die.  TELNET is still around, and so is
rsh.  That does not justify continuing to standardize extensions to
them.

That said, there may well be good reasons for wanting to extend FTP in
spite of the existence of SSHv2/SFTP.  I suspect that some will argue
that SSHv2/SFTP have performance issues, and though I believe those are
the result of implementation issues, not protocol design, perception
sometimes carries the day.  If there are enough people who want to do
this work, and the IESG does not object, then a WG may well get
chartered to do the work.

I take no stand yet on the issue of whether a WG should be chartered to
work on FTP, but I do wish those who want to work on it worked on SFTP
instead.
(Continue reading)

Permalink | Reply | 9 comments |
headers
John C Klensin | 3 Nov 14:31

Re: Followup on IETF72 discussion of FTP protocol extensions andupdates

--On Monday, 03 November, 2008 01:36 -0600 Nicolas Williams
<Nicolas.Williams <at> sun.com> wrote:

>... 
> That said, there may well be good reasons for wanting to
> extend FTP in spite of the existence of SSHv2/SFTP.  I suspect
> that some will argue that SSHv2/SFTP have performance issues,
> and though I believe those are the result of implementation
> issues, not protocol design, perception sometimes carries the
> day.  If there are enough people who want to do this work, and
> the IESG does not object, then a WG may well get chartered to
> do the work.
> 
> I take no stand yet on the issue of whether a WG should be
> chartered to work on FTP, but I do wish those who want to work
> on it worked on SFTP instead.

Let me suggest a different approach to thinking about this.
Extensions happen because they serve a perceived need and people
care enough about them to create multiple implementations,
standardized or not.  Conversely, if the IETF standardizes
something that no one cares about, we won't see more
implementations than if we had not touched it.  The IETF can
contribute only three things:
  (i) community review, which sometimes improves the technical
quality of a specification and sometimes filters out bad ideas, 
  (ii) a clear and standardized specification that facilitates
having implementations of the extensions be interoperable,
  (iii) standardization of verb and parameter strings to
increase the odds that they are used the same way in different
(Continue reading)

Permalink | Reply | 8 comments |
headers
Barry Leiba | 3 Nov 14:03
Picon
Favicon

Re: Followup on IETF72 discussion of FTP protocol extensions andupdates

> My personal criteria for a WG follow closely on that observation
> about implementations and those three possible contributions.
> There need to be people, groups, or organizations who are
> interested in implementing any given extension, so it is not
> just a single-company/ single-product idea.  There need to be
> people who are willing to do serious and significant work on the
> specification in the IETF, in review, discussion, and
> document-editing.

As co-instigator here, let me note that I absolutely agree with John on this.  If 
there's a reasonable group that thinks these (and/or other) FTP extensions should 
be standardized -- even if there are also some who don't -- I'd like to go ahead 
with this.  And/but I need to see that there is such consensus on proceeding.

> With regard to comparison with other protocols, FTP has two key,
> closely-related, characteristics that differentiates it from
> SFTP, TFTP, file transfer over HTTP, and so on.   Those
> characteristics are the use of separate command and data
> streams/connections and the asynchronous command design that
> facilitates.  That arrangement has distinct advantages in some
> situations, such as when files are large or transfers slow.

I've never understood this argument, really.
Why is it that much more useful to have this model:

  Channel 1: login, get F1, get F2, get F3
  Channel 2: transfer F1
  Channel 3: transfer F2
  Channel 4: transfer F3
(Continue reading)

Permalink | Reply | 3 comments |
headers
Tony Finch | 3 Nov 15:12
Picon
Favicon

Re: Followup on IETF72 discussion of FTP protocol extensions andupdates

On Mon, 3 Nov 2008, Barry Leiba wrote:

> > With regard to comparison with other protocols, FTP has two key,
> > closely-related, characteristics that differentiates it from SFTP,
> > TFTP, file transfer over HTTP, and so on.  Those characteristics are
> > the use of separate command and data streams/connections and the
> > asynchronous command design that facilitates.  That arrangement has
> > distinct advantages in some situations, such as when files are large
> > or transfers slow.
>
> I've never understood this argument, really.
> Why is it that much more useful to have this model:
>
>   Channel 1: login, get F1, get F2, get F3
>   Channel 2: transfer F1
>   Channel 3: transfer F2
>   Channel 4: transfer F3
>
> ...than this model (à la HTTP):
>
>   Channel 1: login, get F1, transfer F1
>   Channel 2: login, get F2, transfer F2
>   Channel 3: login, get F3, transfer F3
>
> ?  The former avoids authenticating separately in each parallel channel, but
> that's really a minor point (and there are ways to make it lighter-weight).
> Otherwise, I don't see why it makes any real difference.

HTTP also has the advantage for small files that you can pipeline multiple
requests down the same connection so you only need to crank open the TCP
(Continue reading)

Permalink | Reply | 0 comments |
headers
John C Klensin | 3 Nov 15:59

Re: Followup on IETF72 discussion of FTP protocol extensions andupdates


--On Monday, 03 November, 2008 09:03 -0400 Barry Leiba
<leiba <at> watson.ibm.com> wrote:

>> With regard to comparison with other protocols, FTP has two
>> key, closely-related, characteristics that differentiates it
>> from SFTP, TFTP, file transfer over HTTP, and so on.   Those
>> characteristics are the use of separate command and data
>> streams/connections and the asynchronous command design that
>> facilitates.  That arrangement has distinct advantages in some
>> situations, such as when files are large or transfers slow.
> 
> I've never understood this argument, really.
> Why is it that much more useful to have this model:
> 
>   Channel 1: login, get F1, get F2, get F3
>   Channel 2: transfer F1
>   Channel 3: transfer F2
>   Channel 4: transfer F3
> 
> ...than this model (à la HTTP):
> 
>   Channel 1: login, get F1, transfer F1
>   Channel 2: login, get F2, transfer F2
>   Channel 3: login, get F3, transfer F3
> 
> ?  The former avoids authenticating separately in each
> parallel channel, but that's really a minor point (and there
> are ways to make it lighter-weight). Otherwise, I don't see
> why it makes any real difference.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Barry Leiba | 3 Nov 15:30
Picon
Favicon

Re: Followup on IETF72 discussion of FTP protocol extensions andupdates

>> Why is it that much more useful to have this model:
>>
>>   Channel 1: login, get F1, get F2, get F3
>>   Channel 2: transfer F1
>>   Channel 3: transfer F2
>>   Channel 4: transfer F3
>>
>> ...than this model (à la HTTP):
>>
>>   Channel 1: login, get F1, transfer F1
>>   Channel 2: login, get F2, transfer F2
>>   Channel 3: login, get F3, transfer F3
>
> For the example you have given, consider the variation:
>
>   Channel 1: login, get F1, get F2, get F3, go-to-lunch
>   Channel 2: transfer F1
>   Channel 3: transfer F2
>   Channel 4: transfer F3
>
> (a variation that the second option does not permit absent
> scripting or an asynchronous HTTP client).

Well, but it *is* all the client, not the model.  The second protocol model 
certainly *does* permit this scenario, if the client supports it.  And the first 
model doesn't permit it either if the client is synchronous.

It gets down to what you say later, which I'll characterize as a need for 
implementors to "think outside the protocol"... that is, not to tie the client 
behaviour so closely to the protocol that it restricts what the user can do.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nicolas Williams | 3 Nov 17:27
Picon

Re: Followup on IETF72 discussion of FTP protocol extensions andupdates

On Mon, Nov 03, 2008 at 08:31:59AM -0500, John C Klensin wrote:
> Let me suggest a different approach to thinking about this.
> 
> [...]

So far so good.

> With regard to comparison with other protocols, FTP has two key,
> closely-related, characteristics that differentiates it from
> SFTP, TFTP, file transfer over HTTP, and so on.   Those
> characteristics are the use of separate command and data
> streams/connections and the asynchronous command design that
> facilitates.  That arrangement has distinct advantages in some
> situations, such as when files are large or transfers slow.  It
> is pathological for deep-NAT environments, but that is at least
> one of the reasons we have other protocols for file transfer.
> But, e.g., SFTP seems to be to be a possible good argument
> against an extension that makes FTP single-stream, but not
> against other extensions to FTP.

SFTP is most certainly asynchronous.  You may want to revise your
position.  (Commands and data may be interleaved, and multiple transfers
may proceed concurrently.)

Nico
--

--
Permalink | Reply | 3 comments |
headers
John C Klensin | 3 Nov 18:16

Re: Followup on IETF72 discussion of FTP protocol extensions andupdates


--On Monday, 03 November, 2008 10:27 -0600 Nicolas Williams
<Nicolas.Williams <at> sun.com> wrote:

> SFTP is most certainly asynchronous.  You may want to revise
> your position.  (Commands and data may be interleaved, and
> multiple transfers may proceed concurrently.)

Nico, 

I have probably just been using weak implementations of SFTP,
but have yet to see one that permits me to get the status or, or
cancel, a transfer that is in progress without killing off the
connection, that are able to initiate multiple transfers
concurrently, etc.  I confess not having studied the protocol
itself but, if SFTP has those facilities, we may be dealing with
insufficient implementations of both SFTP and FTP rather than a
need for at least some extensions to either (other extensions,
and the probable need for extension registries, may be another
matter).

    john

p.s. if SFTP is also in need of an extension registry, I'd be
happy to sign you up as co-author, send you the XML for
modifications, and try to push both extension registries through
at the same time and with the same document.   No need to
duplicate _that_ particular part of that work.
Permalink | Reply | 2 comments |
headers
Nicolas Williams | 3 Nov 18:32
Picon

Re: Followup on IETF72 discussion of FTP protocol extensions andupdates

On Mon, Nov 03, 2008 at 12:16:46PM -0500, John C Klensin wrote:
> > SFTP is most certainly asynchronous.  You may want to revise
> > your position.  (Commands and data may be interleaved, and
> > multiple transfers may proceed concurrently.)
> 
> I have probably just been using weak implementations of SFTP,
> but have yet to see one that permits me to get the status or, or
> cancel, a transfer that is in progress without killing off the
> connection, that are able to initiate multiple transfers
> concurrently, etc.  I confess not having studied the protocol
> itself but, if SFTP has those facilities, we may be dealing with
> insufficient implementations of both SFTP and FTP rather than a
> need for at least some extensions to either (other extensions,
> and the probable need for extension registries, may be another
> matter).

The SFTP protocol is more like a remote filesystem protocol than a file
transfer protocol.  This is where SFTP used to fall flat, incidentally,
since remote filesystem protocols typically don't include support for
end-of-line conversion, for example.  Newer versions of SFTP have added
support for such conversions, but most implementations don't have it.

You open a file, read from/write to it, close it.  If you wish to
interrupt a file transfer then you just stop initiating I/O to that
file.  Multiple outstanding READs and WRITEs are allowed concurrently,
over a single channel, to the same file and to many files.

Most SFTP clients are rather simplistic however, and simply transfer a
single file at a time, and keep a small number of concurrent I/Os in
flight (older clients kept a single I/O in flight).
(Continue reading)

Permalink | Reply | 1 comment |

Gmane