Re: [ftpext] I-D Action:draft-ietf-ftpext2-hash-00.txt

" Ángel González " <keisial@gmail.com> Fri, 26 November 2010 00:33 UTC

Return-Path: <keisial@gmail.com>
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 C08723A69B5 for <ftpext@core3.amsl.com>; Thu, 25 Nov 2010 16:33:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
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 xQBv3-F0O6Ab for <ftpext@core3.amsl.com>; Thu, 25 Nov 2010 16:33:53 -0800 (PST)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id EA88A3A69A0 for <ftpext@ietf.org>; Thu, 25 Nov 2010 16:33:52 -0800 (PST)
Received: by wwa36 with SMTP id 36so1449619wwa.13 for <ftpext@ietf.org>; Thu, 25 Nov 2010 16:34:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=HHHvw2paYEWmqoBPemFPHftvgVsLp8fli3IL63RxiJI=; b=FcXtg0vfeEd3ACeJEhpEosEYBjHMvM2yKDPzNNpYDPGzln2d8xlHUP1QPcSxrjUuM2 HKtxhCl+RqJ3hscyOOD+Mzt7Kuh1Fx6IBeEr0q912VY1CzaK3NBYaP1CcHRyfqMNQDWB VSZTDBaaT2zoMOFjM/GNqsABvzu6t0r+7vTL0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=Ye9WaUzh8FfU6+IHdCgHBslkopmkjlDreurjNw+sHxyxnrFnP5TS9wo+lNM0AtMJIv rk4gZ3OlmwTCrFroyZkF4/K56wWbxiRQl/wV8kI+u/rN0p6AdMRZGALJZ04m7HuX0+4g 7S94Z5s6ZYQ9FUR9y01jYuPxWfiUkV/hPoSaM=
Received: by 10.216.160.132 with SMTP id u4mr290528wek.11.1290731692876; Thu, 25 Nov 2010 16:34:52 -0800 (PST)
Received: from [192.168.1.26] (98.Red-83-54-100.dynamicIP.rima-tde.net [83.54.100.98]) by mx.google.com with ESMTPS id p4sm643073wej.4.2010.11.25.16.34.50 (version=SSLv3 cipher=RC4-MD5); Thu, 25 Nov 2010 16:34:51 -0800 (PST)
Message-ID: <4CEF00C0.5050200@gmail.com>
Date: Fri, 26 Nov 2010 01:35:12 +0100
From: "=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=" <keisial@gmail.com>
User-Agent: Thunderbird
MIME-Version: 1.0
To: Anthony Bryan <anthonybryan@gmail.com>, ftpext@ietf.org
References: <20101124224501.31531.96663.idtracker@localhost> <4CEDAA9A.8030303@kimmeringer.de> <AANLkTik8Bv9YKo+uPt0ntk9OS0qQW2T5_RJ56CFZxMnS@mail.gmail.com>
In-Reply-To: <AANLkTik8Bv9YKo+uPt0ntk9OS0qQW2T5_RJ56CFZxMnS@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [ftpext] I-D Action:draft-ietf-ftpext2-hash-00.txt
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: Fri, 26 Nov 2010 00:33:55 -0000

Anthony Bryan wrote:
>> I read the draft and tried to find the reason by searching the
>> archive. Why are startpoint and endpoint (SP and EP) missing?
> good question!
>
> as you say, some of the other commands (XCRC, XMD5, XSHA1) support
> partial file hashing.
>
> I remember this was on our list of known issues, and we authors
> brought it up a number of times. we never received any feedback on it
> (except for Mat from SmartFTP on his forum who was for it), so it was
> dropped.
>
> [for everyone's info, some of the older FTP drafts like HASH that were
> around before this mailing list were discussed on apps-discuss (going
> back to March for HASH):
> http://www.ietf.org/mail-archive/web/apps-discuss/current/maillist.html
> ]

I also think it is interesting to have hashes of partial content.
They key piece is 'partial verification'. You could have distributed
downloads
from several mirrors without being able to separatedly hash each piece.
Hash the file on all the mirrors (so it's the same), download the pieces,
join, hash the final file. If it's good, ok. If not, redownload
*everything* again.
Which is exactly what you would have to do if you did a normal download from
the ftp.
You download a big file (eg. a DVD iso) and it fails verification (the
server hash
command is analogous to the checksums usually provided in the dowload page).
That file is quite worthless now, even if you know that the error will
probably be
just a couple of bytes.
Let's assume now that the ftp server allos a hash range command. Then,
instead
of redownloading everything, your client starts bisecting the file,
finds a 1K block
where your local copy differs, and redownloading it you're done.

A couple of requirements:
* The user should not be required to know the file size in advance.
* The protocol should allow a server allowing full file hashes but
rejecting partial hashes.