Re: Interest in reviving WG on FTP(maybe ext?)

Iljitsch van Beijnum <iljitsch@muada.com> Wed, 15 July 2009 20:50 UTC

Return-Path: <iljitsch@muada.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5863B3A6808 for <apps-discuss@core3.amsl.com>; Wed, 15 Jul 2009 13:50:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.179
X-Spam-Level:
X-Spam-Status: No, score=-6.179 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vn1FDr+C2atV for <apps-discuss@core3.amsl.com>; Wed, 15 Jul 2009 13:50:19 -0700 (PDT)
Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id B2BE13A6995 for <apps-discuss@ietf.org>; Wed, 15 Jul 2009 13:50:18 -0700 (PDT)
Received: from [192.168.2.4] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n6FKOMbr051679 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 15 Jul 2009 22:24:23 +0200 (CEST) (envelope-from iljitsch@muada.com)
Message-Id: <500C2305-B995-4628-A6C9-C758771D5B35@muada.com>
From: Iljitsch van Beijnum <iljitsch@muada.com>
To: wmaton@ryouko.imsb.nrc.ca
In-Reply-To: <Pine.LNX.4.64.0907151601240.18753@ryouko.imsb.nrc.ca>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Subject: Re: Interest in reviving WG on FTP(maybe ext?)
Date: Wed, 15 Jul 2009 22:24:24 +0200
References: <Pine.LNX.4.64.0907011537130.11066@ryouko.imsb.nrc.ca> <000701ca0178$c300e700$0601a8c0@allison> <Pine.LNX.4.64.0907101403330.12664@ryouko.imsb.nrc.ca> <45CD4EB44CDFB32F772D8D6E@PST.JCK.COM> <Pine.LNX.4.64.0907151601240.18753@ryouko.imsb.nrc.ca>
X-Mailer: Apple Mail (2.935.3)
Cc: apps-discuss@ietf.org
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jul 2009 20:50:21 -0000

On 15 jul 2009, at 22:20, William F. Maton Sotomayor wrote:

> I don't know how many here are of the FTP slant,

Well, I think I found a bug in RFC 959. Might be nice to fix it.

   3.3.  DATA CONNECTION MANAGEMENT

      Default Data Connection Ports:  All FTP implementations must
      support use of the default data connection ports, and only the
      User-PI may initiate the use of non-default ports.

      Negotiating Non-Default Data Ports:   The User-PI may specify a
      non-default user side data port with the PORT command.  The
      User-PI may request the server side to identify a non-default
      server side data port with the PASV command.  Since a connection
      is defined by the pair of addresses, either of these actions is
      enough to get a different data connection, still it is permitted
      to do both commands to use new ports on both ends of the data
      connection.

However, you can't use both PORT and PASV because with PORT the server  
is supposed to initiate the data session and with PASV the client. If  
you do both it's unclear who does what. I also don't see any use cases  
for this.