Re: [ftpext] draft-peterson-streamlined-ftp-command-extensions

"Mark P. Peterson" <> Thu, 02 December 2010 13:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EA20228C103 for <>; Thu, 2 Dec 2010 05:23:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2wqyOSccN3OV for <>; Thu, 2 Dec 2010 05:23:23 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 24BB328C100 for <>; Thu, 2 Dec 2010 05:22:54 -0800 (PST)
Received: from MPNOTEBOOK ([]) (authenticated user by ( []) (MDaemon PRO v11.0.3) with ESMTP id md50009943735.msg for <>; Thu, 02 Dec 2010 07:24:08 -0600
X-Spam-Processed:, Thu, 02 Dec 2010 07:24:08 -0600 (not processed: spam filter heuristic analysis disabled)
Message-ID: <>
From: "Mark P. Peterson" <>
To: Daniel Stenberg <>
References: <> <>
In-Reply-To: <>
Date: Thu, 02 Dec 2010 07:24:02 -0600
Organization: Rhino Software, Inc.
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 14.0.8089.726
X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726
Subject: Re: [ftpext] draft-peterson-streamlined-ftp-command-extensions
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 02 Dec 2010 13:23:26 -0000

Hi Daniel,

Thank you for your response and your comments.  The reason they're called
"streamlined" is because 4 out of the 5 commands could be performed via
other methods, these allow them to be performed in a single command.

Mark P. Peterson - President
Voice: +1(262) 560-9627
FAX: +1(262) 560-9628

From: "Daniel Stenberg" <>
Sent: Thursday, December 02, 2010 5:17 AM
To: "Mark P. Peterson" <>
Cc: <>
Subject: Re: [ftpext] draft-peterson-streamlined-ftp-command-extensions

On Tue, 16 Nov 2010, Mark P. Peterson wrote:

> I just wanted to mention that my document,
> "draft-peterson-streamlined-ftp-command-extensions" is alive and I would
> like it to remain in consideration within this discussion and the charter.
> Could we get some feedback regarding its priority and content.

Hi Mark,

I've been away, but here are my comments to the draft:

o The name "Streamlined FTP Command Extensions" reads very odd in my mind, as
   they are in fact new/additional commands, I don't see how they streamline

o RMDA - I think a 'rm -rf' version is a very good addition to FTP and it is
   in fact a generally requested operation by users in my experience.

o DSIZ - I see very little value for DSIZ in practise. Since the size of a
   given number of files is only true in that very instant, the returned value
   will just be a reason for misunderstandings and misuse. The way the command
   is described is however accurate and functional.

o AVBL - I see very little value for AVBL in practise. First off, this is
   only true the very moment the command is invoked and the next moment
   there may no longer be anything at all left so using the value for any logic
   will almost certainly be done wrongly. Further, disk space availibility
   depends on a lot of other factors as well besides just "available octets",
   så if there us 1000 bytes free you may be able to store a single 1000 byte
   file there, but perhaps not even be able to store 5 100 byte files. Alas,
   the value of such a command is questionable to me.

o THMB - I am firmly against this command. The idea that we would
   promote a command that makes a thumbnail for an image file is an abonimation
   in my mind. That's not the job of FTP, the "File Transfer Protocol". If you
   need thumbnails for whatever file format, then provide them either directly
   as plain files in your file system, or write an FTP server that provides
   "virtual" files that you generate on demand when the client asks for the
   files. I strongly oppose this command.

o CSID - fine with me. I don't see much benefit for many vendors to
   immediately start supporting it, but I don't see any harm in making a
   standard way to get/expose the information.