Re: [ftpext] New Version of FTP HASH, RANG, LOCK, and HOST

Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com> Mon, 28 January 2013 17:21 UTC

Return-Path: <tatsuhiro.t@gmail.com>
X-Original-To: ftpext@ietfa.amsl.com
Delivered-To: ftpext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86C3121F870A for <ftpext@ietfa.amsl.com>; Mon, 28 Jan 2013 09:21:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gj1Cau613BFl for <ftpext@ietfa.amsl.com>; Mon, 28 Jan 2013 09:21:52 -0800 (PST)
Received: from mail-ea0-f180.google.com (mail-ea0-f180.google.com [209.85.215.180]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1AB21F86CE for <ftpext@ietf.org>; Mon, 28 Jan 2013 09:21:52 -0800 (PST)
Received: by mail-ea0-f180.google.com with SMTP id c1so1231291eaa.11 for <ftpext@ietf.org>; Mon, 28 Jan 2013 09:21:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=n2V2iOQFPltMeQPa3BYW0cVCYwgo0NuLenDI6fK4nm8=; b=h+fxPJ9ptQnW+ZU7YmrYfh/m6558soIl+cOGKzzktvLmGu5tjeLt0aTkU5RbjvEmkI 8f0JiO/Y1TnoQnlhJpt6orG38UkdlBRQC+hLZ5mb1+rUGkkKYHSqo4O+1H6zQF9qC2gl JNJ/G/+GEpkDAmPb3H0wYGEC9C1fudzezxt1l9WILypjO5NP48RMF38izUD5r+wrYemc bDEfjigM2TBS7RXxULcMXyAaYh1BCP5eNwNrL90ddPbZqs9H7QqlRTZWCQRqJ5c7+FZ0 6B5WZp4o6aFBlmyTicp9r+miuUdtq+W2IFxZ5Bw40c8O4E52wJKfTrnLEhmzxaywNZwx B7rw==
X-Received: by 10.14.4.194 with SMTP id 42mr43143143eej.35.1359393705455; Mon, 28 Jan 2013 09:21:45 -0800 (PST)
MIME-Version: 1.0
Received: by 10.14.28.142 with HTTP; Mon, 28 Jan 2013 09:21:25 -0800 (PST)
In-Reply-To: <0LmKCI-1UYNXY3SwU-00ZqXB@mrelay.perfora.net>
References: <0LmKCI-1UYNXY3SwU-00ZqXB@mrelay.perfora.net>
From: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
Date: Tue, 29 Jan 2013 02:21:25 +0900
Message-ID: <CAPyZ6=JRBtn12PtG-X_oFwaXn-esHZjTiQy9S1J+=OTY=iqLBg@mail.gmail.com>
To: Alun Jones <alun@texis.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "ftpext@ietf.org" <ftpext@ietf.org>
Subject: Re: [ftpext] New Version of FTP HASH, RANG, LOCK, and HOST
X-BeenThere: ftpext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <ftpext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Mon, 28 Jan 2013 17:21:53 -0000

Hi,

On Tue, Jan 29, 2013 at 2:00 AM, Alun Jones <alun@texis.com>; wrote:
> Was there a reason not to simply use RANG without parameters? Or even 0 0
> (which would mean no bytes to be transferred), if you insist that the
> command has to have two numbers.
>

We chose 2 numbers solution just for make the parser easier: it always
gets 2 numbers,
without exception.
Because 2nd number of RANG is an end offset from the start of the file
and it is included in the transfer,
much like HTTP Range header field, "RANG 0 0" is valid command and
means transfer the
first byte (offset 0).

But I'm open to this issue now, including the choice of numbers and
without them.
What do you guys think about this?

Best regards,

Tatsuhiro Tsujikawa

________________________________
> From: Tatsuhiro Tsujikawa
> Sent: 1/28/2013 8:45 AM
> To: Alun Jones
> Cc: Anthony Bryan; ftpext@ietf.org
> Subject: Re: [ftpext] New Version of FTP HASH, RANG, LOCK, and HOST
>
>
> Hi,
>
> On Mon, Jan 28, 2013 at 9:01 AM, Alun Jones <alun@texis.com>; wrote:
>> After reading the RANG spec, I note that there isn't anything to state
>> what
>> errors are given by RETR if the range specified is incorrect, or by STOR /
>> APPE if the range specified starts more than one byte after the end of the
>> existing file on the server (and therefore, presumably, incorrect?).
>>
>> I also think that a simple "RANG" on its own should serve to clear out the
>> range on a request. "RANG 1 0" seems an arbitrary choice of numbers (why
>> not
>> "RANG 0 -1" or "RANG 0 Inf"?).
>>
>
> We discussed internally how to reset ranges set by RANG command.
> First we said that "REST 0" resets ranges for RANG too. But, later we
> decided
> not to use REST because in the future we can completely replace REST with
> RANG.
> And we chose invalid range pattern, like "RANG 1 0"
> to reset range since it is the obvious parser pattern and checking
> range is very easy.
> Yes, the numbers are arbitrary. We just chose them. But we avoided negative
> numbers or non-digits because the range is inherently non-negative
> numbers, we don't want
> to make parser accept other than digits just for this.
>
> Best regards,
>
> Tatsuhiro Tsujikawa
>
>> Alun.
>> ~~~~
>>
>>> -----Original Message-----
>>> From: ftpext-bounces@ietf.org [mailto:ftpext-bounces@ietf.org] On Behalf
>>> Of Anthony Bryan
>>> Sent: Sunday, January 20, 2013 9:01 AM
>>> To: ftpext@ietf.org
>>> Subject: [ftpext] New Version of FTP HASH, RANG, LOCK, and HOST
>>>
>>> we updated the FTP HASH, RANG, and LOCK drafts, while the authors of
>>> HOST have updated their (hopefully final, get any comments or reviews in
>>> ASAP) draft.
>>>
>>> we are mostly interested in finishing up HASH & RANG, but also feel free
>> to
>>> comment on LOCK. fancy diffs are available. HASH, RANG, & LOCK changes
>>> are all editorial or just updating the draft.
>>>
>>>
>>> HASH FTP command to be used by clients to request cryptographic hashes of
>>> files.
>>> http://tools.ietf.org/html/draft-bryan-ftpext-hash
>>>
>>>
>>> RANG command to be used by clients to designate a start and end point to
>>> permit restarts and repairs of interrupted data transfers in STREAM mode.
>>> http://tools.ietf.org/html/draft-bryan-ftp-range
>>>
>>>
>>> LOCK command to be used by clients to request the server to use the
>> control
>>> connection for data transfers, using a single port instead of two.
>>> http://tools.ietf.org/html/draft-bryan-ftp-lock
>>>
>>>
>>> also, HOST has been updated:
>>>
>>> FTP command that provides a mechanism for FTP clients and servers to
>>> identify individual virtual hosts on an FTP server.
>>>
>>> http://datatracker.ietf.org/doc/draft-hethmon-mcmurray-ftpext-ftp-hosts/
>>> http://tools.ietf.org/html/draft-hethmon-mcmurray-ftpext-ftp-hosts
>>> (diffs)
>>>
>>> --
>>> (( Anthony Bryan ... Metalink [ http://www.metalinker.org ]
>>>   )) Easier, More Reliable, Self Healing Downloads
>>> _______________________________________________
>>> ftpext mailing list
>>> ftpext@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ftpext
>>
>> _______________________________________________
>> ftpext mailing list
>> ftpext@ietf.org
>> https://www.ietf.org/mailman/listinfo/ftpext