Re: [ftpext] draft-ietf-ftpext2-hash command name and default algorithm

Sob <sob@nvnet.cz> Tue, 18 January 2011 16:18 UTC

Return-Path: <sob@nvnet.cz>
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 D774E3A7021 for <ftpext@core3.amsl.com>; Tue, 18 Jan 2011 08:18:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.445
X-Spam-Level:
X-Spam-Status: No, score=-0.445 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_CZ=0.445, RDNS_NONE=0.1, SARE_MILLIONSOF=0.315]
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 IUIJ15zGRJp0 for <ftpext@core3.amsl.com>; Tue, 18 Jan 2011 08:18:51 -0800 (PST)
Received: from mail.nvnet.cz (mail.nvnet.cz [IPv6:2002:d5d3:2ff6:80::3]) by core3.amsl.com (Postfix) with ESMTP id 609B53A7036 for <ftpext@ietf.org>; Tue, 18 Jan 2011 08:18:50 -0800 (PST)
X-AuthUser: sob@nvnet.cz
Received: from Sob-PC.nvnet.cz ([213.211.47.246]:53940) by mail.nvnet.cz with [XMail 1.25 ESMTP Server] id <S1B44> for <ftpext@ietf.org> from <sob@nvnet.cz>; Tue, 18 Jan 2011 17:21:24 +0100
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 18 Jan 2011 17:21:01 +0100
To: "ftpext@ietf.org" <ftpext@ietf.org>
From: Sob <sob@nvnet.cz>
In-Reply-To: <F15941D3C8A2D54D92B341C20CACDF2311976FF0A8@exchange>
References: <F15941D3C8A2D54D92B341C20CACDF2311976FECC9@exchange> <20110117175600.2F89028C1A2@core3.amsl.com> <F15941D3C8A2D54D92B341C20CACDF2311976FF0A8@exchange>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Message-Id: <20110118161850.609B53A7036@core3.amsl.com>
Subject: Re: [ftpext] draft-ietf-ftpext2-hash command name and default algorithm
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, 18 Jan 2011 16:18:51 -0000

At 15:40 18.1.2011, Robert Oslin wrote:
>I don't see why we need a reply that includes information the client 
>already knows (hash used, filename, etc.). Only the hash is needed, 
>hence option (a) below.

I have no strong opinion on this. While bare hash should be enough, 
including additional info might be good for something.

>Again, I'm not insisting on XCRC over HASH and CRC32 over SHA-1 as 
>the default algorithm; I'm simply make the case that doing so will 
>ease the path for adopting the new standard for most FTP server 
>client/server vendors.

Sure, "new, improved and backward compatible version of good old 
trusted XCRC command" sounds better than "unknown new HASH command". 
On the other hand, if someone advertises support for XCRC and it 
turns out that it means only very small subset of the specification 
(i.e. old XCRC), it wouldn't be so great.

And it shows another problem on the horizon, what about FEAT? What's 
the correct line for current XCRC anyway? I saw:

XCRC filename;start;end
XCRC "filename" SP EP

Even others maybe? Whichever we choose, we instantly get millions of 
servers violation the specification. Unless the XCRC line for FEAT is 
defined as "XCRC<anything>".

When you think about it, new and independent HASH command is not such bad idea.

--