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

Daniel Stenberg <daniel@haxx.se> Thu, 02 December 2010 11:16 UTC

Return-Path: <daniel@haxx.se>
X-Original-To: ftpext@core3.amsl.com
Delivered-To: ftpext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15D2428B797 for <ftpext@core3.amsl.com>; Thu, 2 Dec 2010 03:16:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.424
X-Spam-Level:
X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, HELO_EQ_SE=0.35]
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 AZDJkfUtXETS for <ftpext@core3.amsl.com>; Thu, 2 Dec 2010 03:16:16 -0800 (PST)
Received: from giant.haxx.se (giant.haxx.se [80.67.6.50]) by core3.amsl.com (Postfix) with ESMTP id 75D9B3A6915 for <ftpext@ietf.org>; Thu, 2 Dec 2010 03:16:16 -0800 (PST)
Received: from giant.haxx.se (giant.haxx.se [80.67.6.50]) by giant.haxx.se (8.14.3/8.14.3/Debian-9.1) with ESMTP id oB2BHTDM005381; Thu, 2 Dec 2010 12:17:30 +0100
Date: Thu, 02 Dec 2010 12:17:29 +0100
From: Daniel Stenberg <daniel@haxx.se>
X-X-Sender: dast@giant.haxx.se
To: "Mark P. Peterson" <mpp@rhinosoft.com>
In-Reply-To: <F1714E4C4C6E44CDAB8FD961B5C5368B@rhinooffice.net>
Message-ID: <alpine.DEB.2.00.1012021203180.15551@tvnag.unkk.fr>
References: <F1714E4C4C6E44CDAB8FD961B5C5368B@rhinooffice.net>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
X-fromdanielhimself: yes
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="1129329158-104651497-1291288650=:15551"
X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-4.3.5 (giant.haxx.se [80.67.6.50]); Thu, 02 Dec 2010 12:17:30 +0100 (CET)
Cc: ftpext@ietf.org
Subject: Re: [ftpext] draft-peterson-streamlined-ftp-command-extensions
X-BeenThere: ftpext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ftpext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ftpext>, <mailto:ftpext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ftpext>
List-Post: <mailto:ftpext@ietf.org>
List-Help: <mailto:ftpext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ftpext>, <mailto:ftpext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Dec 2010 11:16:18 -0000

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
   anything.

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.

-- 

  / daniel.haxx.se