Re: [ftpext] End byte of transfer in FTP

Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com> Wed, 08 December 2010 12:33 UTC

Return-Path: <tatsuhiro.t@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 865DC3A6907 for <ftpext@core3.amsl.com>; Wed, 8 Dec 2010 04:33:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.179
X-Spam-Level:
X-Spam-Status: No, score=-3.179 tagged_above=-999 required=5 tests=[AWL=0.420, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 EUVLij7q3r2L for <ftpext@core3.amsl.com>; Wed, 8 Dec 2010 04:33:26 -0800 (PST)
Received: from mail-fx0-f43.google.com (mail-fx0-f43.google.com [209.85.161.43]) by core3.amsl.com (Postfix) with ESMTP id 5DD063A690A for <ftpext@ietf.org>; Wed, 8 Dec 2010 04:33:26 -0800 (PST)
Received: by fxm18 with SMTP id 18so994972fxm.16 for <ftpext@ietf.org>; Wed, 08 Dec 2010 04:34:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=52moXN/8jxNPD+mW3BJqJlOfzUnUCPVn4YXjKPFqU4M=; b=DLjoXlC4UqM8oXuPtjzAG8YiKV/iZknDW46P6i9n3f+XQX+7ZEtlre7r7mzuwMZlc0 oR4palrBU1BHiYcfywnwjklqPpyrdMSOq2iEz98WfeW6kaS2sqMXT0EU+zM1bb0nAJgu xuqJQDF4sRHaJIzQTGaXRi3O6ViJQCkKOeaO8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=Q0LyYOadMAs8c684EBIXKGc9aDg9+ViPwEYAYbXpyYbioyew59G5mwjewUKB/pOjEG 2uPxoVLNEnkQ7fz5P1RxlAOAX3bY+zARBy6MskZzDEcHqCCV3Ml5qZ4GewqGJRESww3p 4N/U+BBw8NjhalF5kklI/38YX6DClqFogsAZM=
Received: by 10.223.93.142 with SMTP id v14mr2721334fam.49.1291811692963; Wed, 08 Dec 2010 04:34:52 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.83.200 with HTTP; Wed, 8 Dec 2010 04:34:32 -0800 (PST)
In-Reply-To: <4CFD028C.6050105@ts.fujitsu.com>
References: <AANLkTi=_OsGPMsC=BHtOyHzTTM5vJ1=yW9fYk_Tp1xm7@mail.gmail.com> <alpine.DEB.2.00.1012011959520.21860@tvnag.unkk.fr> <AANLkTikGmtyrcpbEabBXZAo3ai=z8082RBSrvKSQrzq6@mail.gmail.com> <alpine.DEB.2.00.1012060855010.19637@tvnag.unkk.fr> <A6BF1C5A1E1A999D1A7D33E3@PST.JCK.COM> <4CFD028C.6050105@ts.fujitsu.com>
From: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
Date: Wed, 8 Dec 2010 21:34:32 +0900
Message-ID: <AANLkTinWUwrQ-21qQvXr9P4GG2DB+SzYUCDEuCwP-6Kw@mail.gmail.com>
To: "ftpext@ietf.org" <ftpext@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [ftpext] End byte of transfer in FTP
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: Wed, 08 Dec 2010 12:33:27 -0000

2010/12/7 Richard Koenning <Richard.Koenning@ts.fujitsu.com>:
> John C Klensin wrote:
>
>> Yes.  I'm still not convinced trying to specify fragments of
>> stream files is a good idea at all but, if it is to be done,
>> let's do it with a new command and very clearly-specified
>> semantics.  Remember that, if transfers are done in TYPE I,
>>        -- not only can one have any of the usual
>>        line-separation characters, but one can have other sorts
>>        of record markers or length-delimited lines or blocks.
>>
>>        -- if Unicode is being sent consistent with the base
>>        spec), one gets internal storage forms (often UTF-16LE
>>        or UTF-16BE) not only UTF-8, and certainly does not get
>>        one octet per character.
>>
>> So specifying fragments clearly is not a trivial piece of work
>> unless the new command also requires a new file STRUcture
>> variation.
>
> I don't see a problem on FTP protocol level, with TYPE I the transfered data
> is an unstructured stream of bytes, in which REST currently defines a
> starting point and in which a RANGE specification would additionally define
> an endpoint.

Agree.

> FTP clients and servers operating on files which are not simply a stream of
> bytes but e.g. have some length-delimited record structure may have hard
> work to do, but this problem exists already with the current REST command.
>

Agree.
RFC3659 5.1 states about this problem:

In other representation types and structures
 more effort will be required, but it remains always possible to
 determine the offset with finite, but perhaps non-negligible, effort.


The transfer modes other than STREAM mode use marker to specify restart point
and the marker is sent from sending host.
Then we have no way to know the end point marker because it is not sent.
Because of this, I think it is very hard or impossible to define this
RANGE specification
for other than STREAM mode.
Is it possible to define RANGE specification only in STREAM mode?

Best regards,

Tatsuhiro Tsujikawa