Re: [ftpext] draft-ietf-ftpext2-hash - partial hashes

Daniel Stenberg <daniel@haxx.se> Tue, 25 January 2011 21:02 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 004473A689E for <ftpext@core3.amsl.com>; Tue, 25 Jan 2011 13:02:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.8
X-Spam-Level:
X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[AWL=-1.151, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_64=0.6]
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 uqFUDdZBOiAS for <ftpext@core3.amsl.com>; Tue, 25 Jan 2011 13:02:47 -0800 (PST)
Received: from giant.haxx.se (giant.haxx.se [80.67.6.50]) by core3.amsl.com (Postfix) with ESMTP id E820E3A6838 for <ftpext@ietf.org>; Tue, 25 Jan 2011 13:02:46 -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 p0PL5eiZ011442; Tue, 25 Jan 2011 22:05:41 +0100
Date: Tue, 25 Jan 2011 22:05:40 +0100 (CET)
From: Daniel Stenberg <daniel@haxx.se>
X-X-Sender: dast@giant.haxx.se
To: Mat Berchtold <mb@smartftp.com>
In-Reply-To: <FF57203CB9E6C34C91B833DA2765782F035B12@m.smartsoft.local>
Message-ID: <alpine.DEB.2.00.1101252156380.21228@tvnag.unkk.fr>
References: <F15941D3C8A2D54D92B341C20CACDF2311976FEB98@exchange> <AANLkTiktAfQuq_utOMXWS11zWiU6B=vzRPM3o7X_Sx9g@mail.gmail.com> <FF57203CB9E6C34C91B833DA2765782F035B12@m.smartsoft.local>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
X-fromdanielhimself: yes
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: "ftpext@ietf.org" <ftpext@ietf.org>, Robert Oslin <rto@globalscape.com>
Subject: Re: [ftpext] draft-ietf-ftpext2-hash - partial hashes
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: Tue, 25 Jan 2011 21:02:49 -0000

On Mon, 17 Jan 2011, Mat Berchtold wrote:

> I understand that RANG is a replacement for REST. Using the newly introduced 
> command now to extend other commands as HASH might not be what RANG has been 
> originally intended for.

It actually is. We just wanted to start slowly and gently and specified it for 
RETR only to start with, as that is certainly a major use case.

> One concern is how to announce the feature in the FEAT reply. Right now the 
> RANG draft proposed to use RANG STREAM. Assuming that the server now 
> supports RANG for HASH as well, how does the FEAT line look like? RANG 
> STREAM;HASH? What if another command that might be introduced in the future 
> wants to use the RANG concept as well?

I think we shouldn't try to look too far ahead and guess what the future might 
and might not bring for this. As RANG and HASH aren't even yet very far taken, 
I suggest we simply say that FEAT resports RANG when the server supports it, 
and then it expect that to mean for the commands we include in the RANG spec: 
RETR and HASH so far.

> The use of multiple commands for one function makes it more complex than it 
> needs to be.

(I assume you here talk about having to do both RANG and HASH to get a ranged 
hash output.)

Perhaps, but in my view RANG goes very well in hand with how RETR works 
already and that's a long established concept in FTP so I don't think this is 
a stretch.

Also, it could be seen as odd to have multiple commands allow a range instead 
of having a single command that sets a range...

> I think partial hashes should be a MUST and not optional. Hence there is no 
> need for a special FEAT response.

I quite agree. Also, since HASH allows a server to reject to respond with a 
hash at will, it can select to do that on ranges if it thinks that is cool.

-- 

  / daniel.haxx.se