From anthonybryan@gmail.com Sun Jan 20 09:01:02 2013 Return-Path: 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 22E3021F85C8 for ; Sun, 20 Jan 2013 09:01:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 FNwqZ9wEr4FD for ; Sun, 20 Jan 2013 09:01:01 -0800 (PST) Received: from mail-ia0-x236.google.com (ia-in-x0236.1e100.net [IPv6:2607:f8b0:4001:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 799E721F8598 for ; Sun, 20 Jan 2013 09:00:57 -0800 (PST) Received: by mail-ia0-f182.google.com with SMTP id w33so2295941iag.41 for ; Sun, 20 Jan 2013 09:00:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=zB2+TgWIw+4w+JeX1XOcZChzFt2ahw1Ev474ftTaCgE=; b=msafvigiZH5Gu+T7Qtg078rJZkbVPgtQ6mxwrUH6vuSQHnVEIfjvgm2P86TRDzJhiN tSTnE7G8b3h8Ez9PDO9NlCTqbH/5cnBizTJAr53Ah0mB3ogjbDcJv4WuDAgSuoyzEd4r lKN2SS0zzZ8G7QbfTbiMstHg2FUQIGPHKdtR7bOV/3BXlt0uL6vPNFA1cu2puuvB0Xq5 gCeGo4fYWpVlWeXkOIXjgLRfaP1xCEmVxojiFOqWLWmcIZLEYiAzuTl1FvWOIThrZg4Z j3sDq0voJrKe3C0s2SyZoyXXy8lnzyf4kkDB6wnK0KORQSv+YNyf/2waLqK48qHgXhh9 j77Q== MIME-Version: 1.0 X-Received: by 10.50.183.227 with SMTP id ep3mr6852512igc.107.1358701256951; Sun, 20 Jan 2013 09:00:56 -0800 (PST) Received: by 10.50.1.116 with HTTP; Sun, 20 Jan 2013 09:00:56 -0800 (PST) Date: Sun, 20 Jan 2013 12:00:56 -0500 Message-ID: From: Anthony Bryan To: "ftpext@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jan 2013 17:01:02 -0000 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 From bblackshaw@gmail.com Wed Jan 23 17:45:52 2013 Return-Path: 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 259D921F8700 for ; Wed, 23 Jan 2013 17:45:52 -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 U4H7VijB9bfQ for ; Wed, 23 Jan 2013 17:45:51 -0800 (PST) Received: from mail-pb0-f52.google.com (mail-pb0-f52.google.com [209.85.160.52]) by ietfa.amsl.com (Postfix) with ESMTP id 933EE21F86CD for ; Wed, 23 Jan 2013 17:45:50 -0800 (PST) Received: by mail-pb0-f52.google.com with SMTP id uo5so158620pbc.11 for ; Wed, 23 Jan 2013 17:45:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:reply-to:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=BWcozkwNWDZcXUq5wQoSdajtxi8AIL2wb/06VUVOmAo=; b=KdX3QxTIxwpKfyUfWmkJYNV1vvZcBFgguH1R4Hegp27NUuPYDzAby3ceOu3DLqlcsW 71fupQBpKj0bOK/VMAntkOJPP96nRrEGj5zdBJZVh6bkV0GNb8nOfyW54kdRsdWT+nD0 evMgopRosFYtcoET/veN1WYyHsq/lnbD4JCaHIkkXxx5bRNz5Aqi/jk3kJPq8z7VHc+L H9uIO9EVIqlXhDQxUoKWX7cj2M+JQz+LyFhp22pvAeb0aYrGFiaMYuOy8YUa5FXJgsU8 +jeuiZv6tFY227xjLHxCCICvgwBI5KKGHteo8FKf/MTRAXhUgbEoiZi63o7BXEe3zS7M KggQ== X-Received: by 10.68.231.41 with SMTP id td9mr522847pbc.128.1358991949277; Wed, 23 Jan 2013 17:45:49 -0800 (PST) Received: from [192.168.1.4] (ppp167-208-56.static.internode.on.net. [59.167.208.56]) by mx.google.com with ESMTPS id sy1sm13798480pbc.66.2013.01.23.17.45.45 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Jan 2013 17:45:47 -0800 (PST) Message-ID: <51009243.4080809@gmail.com> Date: Thu, 24 Jan 2013 11:45:39 +1000 From: Bruce Blackshaw User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: ftpext@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 Reply-To: bblackshaw@gmail.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 01:45:52 -0000 Re LOCK, I think it would be useful to have an alternative to "boundary" called "size", that could provide the size of the raw data for binary transfers. That might provide quite a performance advantage compared to having to search for the boundary. regards Bruce Blackshaw EnterpriseDT http://www.enterprisedt.com On 21/01/2013 3:00 AM, Anthony Bryan wrote: > 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 > From keisial@gmail.com Sun Jan 27 09:29:38 2013 Return-Path: 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 A8B8621F84E8 for ; Sun, 27 Jan 2013 09:29:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.472 X-Spam-Level: * X-Spam-Status: No, score=1.472 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_ALMOST_IP=1.889, MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.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 XtZtngBHQwmo for ; Sun, 27 Jan 2013 09:29:38 -0800 (PST) Received: from mail-we0-x22e.google.com (we-in-x022e.1e100.net [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 07BC521F85A1 for ; Sun, 27 Jan 2013 09:29:37 -0800 (PST) Received: by mail-we0-f174.google.com with SMTP id r6so1027463wey.33 for ; Sun, 27 Jan 2013 09:29:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=lcP8BxmqwhftgUg0jcBWiS63HtxnKpZ9TfevYsSVTu8=; b=w9yVnuZwm3Um+wO1tCMf2CnTwBHPpPV4ziz/GuDY4I91SnUkvetXlZYdXi4kZPu7U6 uv+8tYZXM/n/vaI8WM/0UD6vF4+JZVSVE598dxeCkj7aHUqpeN87TPNsCxy/hnOYbKgm DOuOPXcuu5zZow9PfLo2sifcbqKotUjp+YmLwCp+2TiUHO2gNYCAzbkoaamhGGOmZFYd RXxJ04FMylgPsSfIPQzsyGcnsw5xrwXM2igbwXuXKJJ7FL75bzU6hHyBEKKOGPhnP2vk HGHo1zu4L8ODagQdlaRNQ3qbSnJG5GOWFQ0dad8J+4cEUBHmAD9mPCiHqqWi7WMBexb9 NhLw== X-Received: by 10.180.79.37 with SMTP id g5mr5777957wix.8.1359307777050; Sun, 27 Jan 2013 09:29:37 -0800 (PST) Received: from [192.168.1.26] (117.red-80-28-65.adsl.dynamic.ccgg.telefonica.net. [80.28.65.117]) by mx.google.com with ESMTPS id be1sm8943235wib.10.2013.01.27.09.29.35 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 27 Jan 2013 09:29:35 -0800 (PST) Message-ID: <51056391.2070901@gmail.com> Date: Sun, 27 Jan 2013 18:27:45 +0100 From: =?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?= User-Agent: Thunderbird MIME-Version: 1.0 To: bblackshaw@gmail.com References: <51009243.4080809@gmail.com> In-Reply-To: <51009243.4080809@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2013 17:29:38 -0000 Bruce Blackshaw wrote: > Re LOCK, I think it would be useful to have an alternative to > "boundary" called "size", that could provide the size of the raw data > for binary transfers. That might provide quite a performance > advantage compared to having to search for the boundary. > > regards Good point. I think it would be much more useful than the boundary method. The value of such size parameter should be the amount of data sent on the wire. From alun@texis.com Sun Jan 27 10:32:45 2013 Return-Path: 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 2FB0D21F84D1 for ; Sun, 27 Jan 2013 10:32:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.81 X-Spam-Level: X-Spam-Status: No, score=-0.81 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, MIME_8BIT_HEADER=0.3] 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 jfJ2EblEcey4 for ; Sun, 27 Jan 2013 10:32:44 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id A8A2321F84C8 for ; Sun, 27 Jan 2013 10:32:44 -0800 (PST) Received: from rocksolid (c-24-19-33-75.hsd1.wa.comcast.net [24.19.33.75]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MKYYR-1Tyi5P1Y6J-001ZWc; Sun, 27 Jan 2013 13:32:44 -0500 From: "Alun Jones" To: =?iso-8859-1?Q?'=C1ngel_Gonz=E1lez'?= , References: <51009243.4080809@gmail.com> <51056391.2070901@gmail.com> In-Reply-To: <51056391.2070901@gmail.com> Date: Sun, 27 Jan 2013 10:32:39 -0800 Organization: Texas Imperial Software Message-ID: <03ec01cdfcbc$b247bef0$16d73cd0$@texis.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQIt3E4NnXG8QPMl9Ih5faZkLyE7NwIU5rYDAdN4gr6Xfnz/oA== X-Provags-ID: V02:K0:Oj32U6XrwD3XOdHvX/x8eZf8ODL6fB9xK2nM0zT+EKw EOS6F7u9FWdnWcSiV5g+ofc1u658b6Kp0HgLXZXN2KJB4kHNsX RHJYY6hDG8GhaiPNraE/F5mXYAbLF/aagbkIf/9Yvhc+HhNM40 xn4qdSRwkgc4BEomDvvt+WqJ3L0QADfpcunUVWNKW89g9XQVNH 7Wmr/b8gFXBnVl5/x+TdFNCpJo8R3YUY74NPFIjpvlpGzup/lU xkNKvGxJfz2yYwLKxRx08cjZYzmvC9MQOUHl5ozpm9Jwkl8NHU cyksanZ4/wqtP18ZhRUzol0qSHNueJqaCMkV2RpB+x6lOeB5Jo XEd8HfKY4b/2NFtLaSvo= Cc: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2013 18:32:45 -0000 > Of =C1ngel Gonz=E1lez >=20 > Bruce Blackshaw wrote: > > Re LOCK, I think it would be useful to have an alternative to > > "boundary" called "size", that could provide the size of the raw = data > > for binary transfers. That might provide quite a performance > > advantage compared to having to search for the boundary. > > > > regards >=20 > Good point. I think it would be much more useful than the boundary > method. > The value of such size parameter should be the amount of data sent on = the > wire. This has an obvious problem - what if the size of the file changes = during the transfer? There are many uses of FTP (webcam being the one that comes immediately = to mind) where a "file" is retrieved, and is handled as if it is a potentially-infinite stream. We have a webcam at work that encodes video = as an animated GIF that never ends. Doesn't display in Internet Explorer, because IE is paranoid, but it's a use-case that should be considered. = The boundary method works for this use, where the size method doesn't. Alun. ~~~~ From keisial@gmail.com Sun Jan 27 13:22:08 2013 Return-Path: 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 0E6C521F874F for ; Sun, 27 Jan 2013 13:22:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.914 X-Spam-Level: X-Spam-Status: No, score=-0.914 tagged_above=-999 required=5 tests=[AWL=2.385, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 AXW-BT4cuqYF for ; Sun, 27 Jan 2013 13:22:07 -0800 (PST) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by ietfa.amsl.com (Postfix) with ESMTP id 2E83A21F841B for ; Sun, 27 Jan 2013 13:22:07 -0800 (PST) Received: by mail-wg0-f50.google.com with SMTP id es5so1353340wgb.29 for ; Sun, 27 Jan 2013 13:22:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=iUwWl4O2pClVeWqfXQKYBHGG7KUq1Ydn2uxglc2OWH4=; b=OWgtyXfZYI3LZASIAm1cqmi343EmK+fD6n+1xRiYwsFmPt+P4VsCaoRInZgsb/T2hY u2omttsGFv1T1SfCdTxfEtg9xMJUwSTwIg8sQy/MqG3T/ReZJSDBT/XXIJ7usPrc/oCr dnkq9YiQw9H8NmtI8D3LvraEwo0gcT8NI7Io1KWaP74FW63LEsi6JdfxMzAjeKpGfgVm MTGosW8lAgIhZFhVEY4Q8U/jcrHsVJE4kFmch9H20/MRcb8L6drxDjs6z2MVq2Bs4FTw jWJ+tR0npeJbndCatSBrHTkQUDqOqWdQTwgjhTeOQm1nbkyDh2AbSZxC2KYJE+wwxzT4 e0nA== X-Received: by 10.194.240.233 with SMTP id wd9mr17790247wjc.54.1359321726374; Sun, 27 Jan 2013 13:22:06 -0800 (PST) Received: from [192.168.1.26] (117.red-80-28-65.adsl.dynamic.ccgg.telefonica.net. [80.28.65.117]) by mx.google.com with ESMTPS id cu7sm9157605wib.8.2013.01.27.13.22.04 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 27 Jan 2013 13:22:05 -0800 (PST) Message-ID: <51059A0E.4020001@gmail.com> Date: Sun, 27 Jan 2013 22:20:14 +0100 From: =?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?= User-Agent: Thunderbird MIME-Version: 1.0 To: Alun Jones References: <51009243.4080809@gmail.com> <51056391.2070901@gmail.com> <03ec01cdfcbc$b247bef0$16d73cd0$@texis.com> In-Reply-To: <03ec01cdfcbc$b247bef0$16d73cd0$@texis.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2013 21:22:08 -0000 On 27/01/13 19:32, Alun Jones wrote: > This has an obvious problem - what if the size of the file changes during > the transfer? > > There are many uses of FTP (webcam being the one that comes immediately to > mind) where a "file" is retrieved, and is handled as if it is a > potentially-infinite stream. We have a webcam at work that encodes video as > an animated GIF that never ends. Doesn't display in Internet Explorer, > because IE is paranoid, but it's a use-case that should be considered. The > boundary method works for this use, where the size method doesn't. > > Alun. > ~~~~ Probably due to the reference to MIME, I was thinking in multiple chunks with a size attached, not in one big chunk with the size. In the later case, it would be possible (assuming it doesn't shrink below what you have already committed to send). From alun@texis.com Sun Jan 27 15:47:01 2013 Return-Path: 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 A638E21F87D7 for ; Sun, 27 Jan 2013 15:47:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.705 X-Spam-Level: X-Spam-Status: No, score=-1.705 tagged_above=-999 required=5 tests=[AWL=0.895, BAYES_00=-2.599] 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 tAaa7pFzGBLs for ; Sun, 27 Jan 2013 15:47:00 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id B5EC521F87D6 for ; Sun, 27 Jan 2013 15:47:00 -0800 (PST) Received: from rocksolid (c-24-19-33-75.hsd1.wa.comcast.net [24.19.33.75]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0LoWW2-1UfnVj3BIg-00ggSw; Sun, 27 Jan 2013 18:46:59 -0500 From: "Alun Jones" To: References: In-Reply-To: Date: Sun, 27 Jan 2013 15:46:56 -0800 Organization: Texas Imperial Software Message-ID: <041801cdfce8$98df0fa0$ca9d2ee0$@texis.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQIt3E4NnXG8QPMl9Ih5faZkLyE7N5edwMzQ X-Provags-ID: V02:K0:5hedMToex7vvVmb9bbe3orsVlurlbSWbZHZAxBAPok5 gUx2+KMNOISaYTD/N+qlRuePJunPUv//rueEkF6mlvDsGxgwIU gEdcKTkRXKtvjqwDPtcAZaWpwuotzPyNpbsPMXk6PXhXS+lvx0 SX/EPMvGLRltfFBpJYoj1gq7Z+A8kAaOKRUjhBdl5NCygUZtmJ GmuyPQGR/szzTglwab/4LIXvDleQeiHTod4ESWDKWIhdnI7v52 YEDtwq70Y27MXRn365A2XuM1s/nd061bIf07+uoWEmp5JVcSUC 1RjtDylQ312IdoFQl/Da0RwYA07zM/NyXjX1ISQOC23UneYO+w mqezNbzLib3QtlFT8j/U= 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2013 23:47:01 -0000 After reading the LOCK draft, I have a couple of comments: 0. RFC 959 already defines a mechanism - Block Mode over the default port - which doesn't require PORT or PASV to operate, and doesn't close connections between files. This means that under such a scheme, a firewall's life is made easier - you open 21 inbound, and allow outbound connections from port 20 on the server. Document this in your draft, and people may start using that, just because it already works on many servers. 1. You need an example showing how an upload works, just to make that clear. "When uploading files, the client MUST use end-of-marker solution." You don't explain this anywhere, or use the term "end-of-marker" anywhere else in the draft. 2. You need to answer at least the security questions of how a client is protected from a malicious server, and how a server is protected from a malicious client, as well as how the connection (client and server) is protected against a malicious file. Consider what happens if a file contains a number of predicted boundary values, and the server or client is not good at picking random numbers for those boundaries. Note, for instance, how SMTP does this in the DATA command - the DATA ends with a line containing only ".". Any line beginning with a "." in the data has to be prefixed by another ".". The receiver then simply strips out the first dot on each line. Don't give in to the idea that "random numbers can't be guessed", or that accidental occurrences or malicious action won't ever successfully reproduce the boundary condition. Make it IMPOSSIBLE. 3. At least three commands are documented to work while a transfer is in progress. STAT, which reports the status of the transfer, NOOP, which does nothing (but many clients use to keep the control connection open when a firewall might close it over a long data transfer), and ABOR, which stops an existing transfer. My suggestion would be that STAT will return a response after the data transfer has finished (after the response from the transfer completion); NOOP the same; ABOR will interrupt the transfer, the transfer's end response will be signaled as interrupted, and the ABOR command will send a 426 and 226. 4. Answering your question of "how to unlock" - the obvious way is to use a PORT or PASV (or similar) command to re-establish such behavior, or REIN if you want to go back to default port operation (and blow away your login, other settings, etc). 5. You should indicate in your examples whether the boundary and separator lines are sent by client or server, just to avoid confusion. 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 From bblackshaw@gmail.com Sun Jan 27 15:52:22 2013 Return-Path: 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 1E1DF21F84CA for ; Sun, 27 Jan 2013 15:52:22 -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 ZDPYArAmQ1rq for ; Sun, 27 Jan 2013 15:52:21 -0800 (PST) Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) by ietfa.amsl.com (Postfix) with ESMTP id 4145121F841D for ; Sun, 27 Jan 2013 15:52:15 -0800 (PST) Received: by mail-pa0-f53.google.com with SMTP id hz1so1168776pad.26 for ; Sun, 27 Jan 2013 15:52:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:reply-to:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=zlsKLHtG3eoIx71+IH+07MT2QTsh8eN+jhJpi9yrMsI=; b=ruNw6+431VCji4vvMrtRlC7t4ayBex7cELvmYOoZUyZnBxss/psHz0EKOxuzjM9dV6 ehJ0uD4uDvOR/GrfGZuTcL7Gf1h7dU6vx2Iim0i0TMkbRzK0Yfr2v+eVfqva5XoWeJC9 q8zpAfYFtdl5y4smGIvNhNs2pVq1j8Mx+EDoi/JnL4geR2UBu7fgqqjZcy3ef7AMqVMP 0qr1Zjk6TtKrIZLQsNfOxxc3e/jLZoRVUH5Sj4Gk1ihX5CCW/4flf83NVcofg95lQBaO +bVi9YdDftLnTppqpKBi1BCrZGfI/dRVRk+u+EuSX3E4ZM9wD6vAxAv2gQ0my8XtZZdo CrIA== X-Received: by 10.66.82.103 with SMTP id h7mr16570722pay.6.1359330735082; Sun, 27 Jan 2013 15:52:15 -0800 (PST) Received: from [192.168.1.4] (ppp167-208-56.static.internode.on.net. [59.167.208.56]) by mx.google.com with ESMTPS id vq4sm5090801pbc.67.2013.01.27.15.52.11 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 27 Jan 2013 15:52:13 -0800 (PST) Message-ID: <5105BDA8.7000006@gmail.com> Date: Mon, 28 Jan 2013 09:52:08 +1000 From: Bruce Blackshaw User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Alun Jones , ftpext@ietf.org References: <51009243.4080809@gmail.com> <51056391.2070901@gmail.com> <03ec01cdfcbc$b247bef0$16d73cd0$@texis.com> In-Reply-To: <03ec01cdfcbc$b247bef0$16d73cd0$@texis.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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 Reply-To: bblackshaw@gmail.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2013 23:52:22 -0000 It's true that you don't always know the size at the start. Nonetheless, it could be be specified that iff the size of the raw data is known, then "size" could be used. In the many cases that this is possible, performance should be faster (although I can't quantify by how much). regards Bruce Blackshaw On 28/01/2013 4:32 AM, Alun Jones wrote: >> Of Ángel González >> >> Bruce Blackshaw wrote: >>> Re LOCK, I think it would be useful to have an alternative to >>> "boundary" called "size", that could provide the size of the raw data >>> for binary transfers. That might provide quite a performance >>> advantage compared to having to search for the boundary. >>> >>> regards >> Good point. I think it would be much more useful than the boundary >> method. >> The value of such size parameter should be the amount of data sent on the >> wire. > This has an obvious problem - what if the size of the file changes during > the transfer? > > There are many uses of FTP (webcam being the one that comes immediately to > mind) where a "file" is retrieved, and is handled as if it is a > potentially-infinite stream. We have a webcam at work that encodes video as > an animated GIF that never ends. Doesn't display in Internet Explorer, > because IE is paranoid, but it's a use-case that should be considered. The > boundary method works for this use, where the size method doesn't. > > Alun. > ~~~~ > > From alun@texis.com Sun Jan 27 16:01:32 2013 Return-Path: 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 04C5B21F87F7 for ; Sun, 27 Jan 2013 16:01:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.152 X-Spam-Level: X-Spam-Status: No, score=-2.152 tagged_above=-999 required=5 tests=[AWL=0.447, BAYES_00=-2.599] 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 Q708LfBUUD7Z for ; Sun, 27 Jan 2013 16:01:31 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 2EAB621F86EA for ; Sun, 27 Jan 2013 16:01:31 -0800 (PST) Received: from rocksolid (c-24-19-33-75.hsd1.wa.comcast.net [24.19.33.75]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0MMkL9-1U5M7c0kMJ-008nTm; Sun, 27 Jan 2013 19:01:29 -0500 From: "Alun Jones" To: "'Anthony Bryan'" , References: In-Reply-To: Date: Sun, 27 Jan 2013 16:01:25 -0800 Organization: Texas Imperial Software Message-ID: <041a01cdfcea$9fa3a060$deeae120$@texis.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQIt3E4NnXG8QPMl9Ih5faZkLyE7N5eeG+0Q X-Provags-ID: V02:K0:/xvv5cYYQPtBZwiFFxllGQTPGcpH09JPDiHZrCOSXuR lfR5Qpbb00GkUK+DMb1FKSIJCsETrIGzItll3bUAri7bWP4xyL p+IxNePzC91hkxncZ3foRa4FSXP8q5MoLngITypeqklHY6D+Wp BdEDaswcWNqTvKKHZdBM+kOTSqKEZqkLF7v43+rgkL/D/9aMxg wXO240HMS1keA9vX+1ZyAVMQbYli9AcXvDqxUDUzocQFLeBzri hRUfUr/B2mFnVrlM9/rsVwRYLDEnmpNK+5ojZXnb+YU5Mec/gA Dgelzg9Umtb99/z9Mu4pfkh1iPekWqVLJVIkYcyynNc8HErlao R7QpXhHmaMQk0Vf+jf0o= 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 00:01:32 -0000 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"?). 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 From alun@texis.com Sun Jan 27 16:17:41 2013 Return-Path: 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 4419121F8C03 for ; Sun, 27 Jan 2013 16:17:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599] 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 qbZF+4v9ND63 for ; Sun, 27 Jan 2013 16:17:40 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 7087321F8B14 for ; Sun, 27 Jan 2013 16:17:40 -0800 (PST) Received: from rocksolid (c-24-19-33-75.hsd1.wa.comcast.net [24.19.33.75]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0LaoXw-1UjijS0aCm-00kXB6; Sun, 27 Jan 2013 19:17:39 -0500 From: "Alun Jones" To: References: In-Reply-To: Date: Sun, 27 Jan 2013 16:17:36 -0800 Organization: Texas Imperial Software Message-ID: <041d01cdfcec$e1c41d60$a54c5820$@texis.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQIt3E4NnXG8QPMl9Ih5faZkLyE7N5eeILtQ X-Provags-ID: V02:K0:Mpp2l453F+AG6AI2WhEREag0zAy8qIwdv3KnIXYvxw+ DxtGL8IwP5SOKqsatMFMDZcTCq7sOwRqWWg8b9xcHMPf94Jep1 ipI0X6tDBevyOgDaVlNHObaRA4Fl7zaTB02MI/GXdbIAwfaQNs /G+Ev8qhWIe/LCP9aNbnp+MViqBlwzumH8Rsd5P4pRTyVwMPAC QqIaDUANHkUDAsZMEbNxMVgVM9vNuaeUgxZPKb4Vgc3u+WPXYB mzxSFNSRRE8/dcREi682+ThGSuzZrXBUjUVt/Ragg5l263PseC yhYJjpKM7rHiP1Q7c/+wt4Ktx6V+1UUVtGUgP9jXVV3lQMhg+8 bLlt1m1ugeArTB9KI3q0= 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 00:17:41 -0000 Reviewing the HASH draft, I think it would be good to say that server implementors SHOULD use the name for the hash algorithm as defined in "Hash Function Textual Names" registry, if one exists - this is implied, but not stated. > -----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 From tatsuhiro.t@gmail.com Mon Jan 28 08:45:32 2013 Return-Path: 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 F268E21F89AE for ; Mon, 28 Jan 2013 08:45:32 -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 dbGW4a6HkOiF for ; Mon, 28 Jan 2013 08:45:30 -0800 (PST) Received: from mail-ea0-f179.google.com (mail-ea0-f179.google.com [209.85.215.179]) by ietfa.amsl.com (Postfix) with ESMTP id 38F7121F891D for ; Mon, 28 Jan 2013 08:45:30 -0800 (PST) Received: by mail-ea0-f179.google.com with SMTP id d12so1216108eaa.38 for ; Mon, 28 Jan 2013 08:45:29 -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=EdtqGZ4U/UzCFkpHHaJy0VAujznmKCb0s2y1lvxKNCg=; b=azgmu8AEnUkxQU90+WFHd0ilPwmFq2x9u/+xUc10Y0/BaM4VW7x+BL2xvZYmgS+ecw 9AGMQ0wW8QRT92O61eIb/x7UncttgHX2OpGZZYiMv2yz5SdbWu7xBizi3jSFMn4B9bkt X31MVZnemacidoCkOhWUXqKgjl/0mY7Rp65+yPTB3RLW9lHS0wCQYzqdHr+9a3XfwvzV 0HTWI8AoOtJnscAmwbXTlEDmG9Sj5NAGVXkiiN4YnnTzFkAwKCmaP2Y2UACDe9V4ucDb t+33Tlv4B5qJRqqxN2pBwusPxCXKq54JM6CUlynjhKO+31U6B3hpJj7nR9hoaraWGtEA 0//w== X-Received: by 10.14.4.194 with SMTP id 42mr42827717eej.35.1359391529301; Mon, 28 Jan 2013 08:45:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.14.28.142 with HTTP; Mon, 28 Jan 2013 08:45:08 -0800 (PST) In-Reply-To: <041a01cdfcea$9fa3a060$deeae120$@texis.com> References: <041a01cdfcea$9fa3a060$deeae120$@texis.com> From: Tatsuhiro Tsujikawa Date: Tue, 29 Jan 2013 01:45:08 +0900 Message-ID: To: Alun Jones Content-Type: text/plain; charset=ISO-8859-1 Cc: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 16:45:33 -0000 Hi, On Mon, Jan 28, 2013 at 9:01 AM, Alun Jones 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 From alun@texis.com Mon Jan 28 09:00:38 2013 Return-Path: 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 E115521F89E9 for ; Mon, 28 Jan 2013 09:00:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 H9Bk-wKPAmSB for ; Mon, 28 Jan 2013 09:00:37 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 94BF821F89C0 for ; Mon, 28 Jan 2013 09:00:37 -0800 (PST) Received: from [192.168.87.215] (74-202-210-82.static.twtelecom.net [74.202.210.82]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0LmKCI-1UYNXY3SwU-00ZqXB; Mon, 28 Jan 2013 12:00:34 -0500 MIME-Version: 1.0 From: Alun Jones Date: Mon, 28 Jan 2013 09:00:33 -0800 To: Tatsuhiro Tsujikawa Content-Type: multipart/alternative; boundary="_D9AE3774-E91C-20EE-DCBD-DF36707AD2B2_" Message-Id: <0LmKCI-1UYNXY3SwU-00ZqXB@mrelay.perfora.net> X-Provags-ID: V02:K0:cEgSrCmNl3zjmZLLM4WMP0nFOLxVei8intcJ9AU/K6P G+/xSUvI2ve/tv3MhsUdLvcUUVvNz1u+wqwHZeTagC2NWs7bOF 1BwgS7c0iBezSn54iTmx6qAaciGiqweBtO0qUeBcmurWvqU68S k5LLp0D0HtDp/SERWD5ipbV11ZN2d2eTMSgwmd1ZvmqNkdEJse zJsg0a/VTz1sFWI4spCquuIzQJ4CgvrHjsIAL0G1i0DlKjn9B/ 57XgQViRE+03rdl+R8QI/HDcvqCyHn4ajx8nZov/52cG9OQVo6 fnxiZTYdhULhu5r+SJOQh0lQr5tRRKyEo7U/iIh83l77ecNou5 Lc3mKrZh/mnsodfVLyW7F2pRhmVZmJoIm47JiQhvv Cc: "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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 17:00:39 -0000 --_D9AE3774-E91C-20EE-DCBD-DF36707AD2B2_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" 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 comman= d has to have two numbers. -----Original Message----- 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 wrote: > After reading the RANG spec, I note that there isn't anything to state wh= at > 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 th= e > existing file on the server (and therefore, presumably, incorrect?). > > I also think that a simple "RANG" on its own should serve to clear out th= e > 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 decid= ed not to use REST because in the future we can completely replace REST with R= ANG. 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 o= f >> 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 (diff= s) >> >> -- >> (( 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 --_D9AE3774-E91C-20EE-DCBD-DF36707AD2B2_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="iso-8859-1"
Was there a reason not to simply use RANG without pa= rameters? Or even 0 0 (which would mean no bytes to be transferred), if you= insist that the command has to have two numbers.
From: Tatsuhiro Tsujikawa
Sent: 1/28/2013 8:45 AMTo: Alun Jones
Cc: Anthony Bryan; ftpext@ietf.org
Subject: Re: [ftpext] New Version of FTP HASH, RANG, LOCK, an= d 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 s= pecified starts more than one byte after the end of the
> existing fi= le 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 RE= ST because in the future we can completely replace REST with RANG.
And w= e chose invalid range pattern, like "RANG 1 0"
to reset range since it i= s the obvious parser pattern and checking
range is very easy.
Yes, th= e numbers are arbitrary. We just chose them. But we avoided negative
num= bers 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-b= ounces@ietf.org [mailto:ftpext-bounces@ietf.org] On Behalf
>> Of A= nthony 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.<= br>>>
>> we are mostly interested in finishing up HASH &= RANG, but also feel free
> to
>> comment on LOCK. fancy dif= fs are available. HASH, RANG, & LOCK changes
>> are all editor= ial or just updating the draft.
>>
>>
>> HASH FT= P command to be used by clients to request cryptographic hashes of
>&= gt; files.
>> http://tools.ietf.org/html/draft-bryan-ftpext-hash>>
>>
>> RANG command to be used by clients to de= signate a start and end point to
>> permit restarts and repairs of= interrupted data transfers in STREAM mode.
>> http://tools.ietf.o= rg/html/draft-bryan-ftp-range
>>
>>
>> LOCK comm= and to be used by clients to request the server to use the
> control<= br>>> connection for data transfers, using a single port instead of t= wo.
>> http://tools.ietf.org/html/draft-bryan-ftp-lock
>>=
>>
>> also, HOST has been updated:
>>
>&g= t; 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-ftpex= t-ftp-hosts (diffs)
>>
>> --
>> (( Anthony Bryan= ... Metalink [ http://www.metalinker.org ]
>>   )) Easi= er, More Reliable, Self Healing Downloads
>> _____________________= __________________________
>> ftpext mailing list
>> ftpe= xt@ietf.org
>> https://www.ietf.org/mailman/listinfo/ftpext
>= ;
> _______________________________________________
> ftpext ma= iling list
> ftpext@ietf.org
> https://www.ietf.org/mailman/lis= tinfo/ftpext
= --_D9AE3774-E91C-20EE-DCBD-DF36707AD2B2_-- From tatsuhiro.t@gmail.com Mon Jan 28 09:21:53 2013 Return-Path: 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 ; 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 ; 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 ; Mon, 28 Jan 2013 09:21:52 -0800 (PST) Received: by mail-ea0-f180.google.com with SMTP id c1so1231291eaa.11 for ; 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 Date: Tue, 29 Jan 2013 02:21:25 +0900 Message-ID: To: Alun Jones Content-Type: text/plain; charset=ISO-8859-1 Cc: "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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 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 From keisial@gmail.com Mon Jan 28 13:06:13 2013 Return-Path: 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 641FE21F8967 for ; Mon, 28 Jan 2013 13:06:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.649 X-Spam-Level: *** X-Spam-Status: No, score=3.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_ALMOST_IP=1.889, FH_HOST_EQ_DYNAMICIP=2.177, MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.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 aVsCOLCumEOD for ; Mon, 28 Jan 2013 13:06:12 -0800 (PST) Received: from mail-wg0-x229.google.com (wg-in-x0229.1e100.net [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6FB21F881A for ; Mon, 28 Jan 2013 13:06:12 -0800 (PST) Received: by mail-wg0-f41.google.com with SMTP id ds1so1530284wgb.0 for ; Mon, 28 Jan 2013 13:06:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=oAnVlH4FzlnRiu7vKdL1RFkmg3zEe33EgG8Srg0CTf0=; b=TNHoA0pCWXDE0BcsXK63+jA4LJ9/Fn8FaZlpjX0tgs7GOirOxPyYslW1g8NoTXuqYW Mp20X0/fwb5QwCEscncz9FooVB64nGa/J3Wm1qVjHO+HfIlc0kGwK7hsFfW21TIMn3UY I9zD+ffBufrRhk6dm671cES+dPvc3XLdgbyAULWb30hQfIzLCl2hEoQmn8rBlTvuWvf9 jg+CGv1c3WW2FnnspWc0eTtsNR7VV9A1KSVLyj5q9SLl2XohcRy3PrgIFjArQEi8KsTi Q1c+rVD0PcxSPpe8wFEtR3bqxlf98AnyAkw4js5YxSNP9NLEWcH8gTrQMoX6QvEUSOHY QFcg== X-Received: by 10.180.106.34 with SMTP id gr2mr12091408wib.18.1359407171383; Mon, 28 Jan 2013 13:06:11 -0800 (PST) Received: from [192.168.1.26] (15.Red-83-49-114.dynamicIP.rima-tde.net. [83.49.114.15]) by mx.google.com with ESMTPS id hu8sm13913857wib.6.2013.01.28.13.06.09 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jan 2013 13:06:10 -0800 (PST) Message-ID: <5106E7D4.9010505@gmail.com> Date: Mon, 28 Jan 2013 22:04:20 +0100 From: =?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?= User-Agent: Thunderbird MIME-Version: 1.0 To: Alun Jones References: <041a01cdfcea$9fa3a060$deeae120$@texis.com> In-Reply-To: <041a01cdfcea$9fa3a060$deeae120$@texis.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 21:06:13 -0000 On 28/01/13 01:01, Alun Jones 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 think it should be documented that the server must fill the gap with nul bytes, with a note that it may use it as a hint to do that using a sparse file. From anthonybryan@gmail.com Tue Jan 29 09:14:12 2013 Return-Path: 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 A504D21F8820 for ; Tue, 29 Jan 2013 09:14:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 Ld+jlxZX1n5c for ; Tue, 29 Jan 2013 09:14:11 -0800 (PST) Received: from mail-ia0-x22a.google.com (mail-ia0-x22a.google.com [IPv6:2607:f8b0:4001:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id CF90521F8816 for ; Tue, 29 Jan 2013 09:14:11 -0800 (PST) Received: by mail-ia0-f170.google.com with SMTP id k20so896539iak.1 for ; Tue, 29 Jan 2013 09:14:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=yiePuptsFvp3fE83+1epI4nB6tkLQmo+o/KW1g4IT0I=; b=uef2ZL+zY2TjkECqSJsF+f5ztj9EduCsNqrWxxwkb4B6dXvjQY1BEI0oQF6LGPcxMn LjqF+eOa9keEwoU3KXmRhW2CKssrR/a5ileAgniMn6bLZoeKMnx2ARBT9OOAAY6muC15 gLx6uinJiFF7kBOUm/wy5ENAQYHXESztZ3o5CC9mdH+WsmvIvJ/lqneyd0q1EqTmLSWd BZsIogmzCtcoqol0Fb+QHzo+cs8xU+j50NPL8asKuEj8s+t2WPB/LHqnMuXi0ldothWx mHfZMvH/xDKgZ1VlQPQXca0SM6aO2/JoGmwcmqxLBhzONiM/P6/JBI3+diX12OfdXQ4A ZGYA== MIME-Version: 1.0 X-Received: by 10.50.151.176 with SMTP id ur16mr1309769igb.30.1359479651084; Tue, 29 Jan 2013 09:14:11 -0800 (PST) Received: by 10.50.191.231 with HTTP; Tue, 29 Jan 2013 09:14:10 -0800 (PST) In-Reply-To: <041d01cdfcec$e1c41d60$a54c5820$@texis.com> References: <041d01cdfcec$e1c41d60$a54c5820$@texis.com> Date: Tue, 29 Jan 2013 12:14:10 -0500 Message-ID: From: Anthony Bryan To: Alun Jones Content-Type: text/plain; charset=ISO-8859-1 Cc: "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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 17:14:12 -0000 thanks for the review! the registry is here: http://www.iana.org/assignments/hash-function-text-names/hash-function-text-names.xml how does this work for you? The server-FTP process MUST use the "Hash Function Name" as defined in the IANA registry named "Hash Function Textual Names" for possible supported hash algorithms. in context: When replying to the FEAT command [RFC2389], a server-FTP process that supports the HASH command MUST include a feature line indicating that the HASH command is supported, along with a list of all supported hash algorithms, including the currently selected hash algorithm, in a semicolon separated list. The server-FTP process MUST use the "Hash Function Name" as defined in the IANA registry named "Hash Function Textual Names" for possible supported hash algorithms. On Sun, Jan 27, 2013 at 7:17 PM, Alun Jones wrote: > Reviewing the HASH draft, I think it would be good to say that server > implementors SHOULD use the name for the hash algorithm as defined in "Hash > Function Textual Names" registry, if one exists - this is implied, but not > stated. > >> -----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 -- (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads