From ftp-wg-owner@hethmon.com Fri Dec 7 11:04:19 2001 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23007 for ; Fri, 7 Dec 2001 11:04:17 -0500 (EST) Received: from mail.hethmon.com ([208.171.56.195] [208.171.56.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20011207110831-108-8 ; Fri, 07 Dec 2001 11:08:31 -0500 Received: from MailPost ([210.71.181.206] [210.71.181.206]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20011207110824-37569-8 ; Fri, 07 Dec 2001 11:08:26 -0500 Received: from tpts4 by pavo.seed.net.tw with SMTP id 5atiQyzyLN3jHYOEQNuTTWkx; Sat, 08 Dec 2001 00:03:18 +0800 Message-ID: <4BVff9oxf@giga.net.tw> MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_XeejHFGf8U6q4l5dD7IiESx40v1o" X-Mailer: 5t6SnQdOr1GS6uL5yDTEOKSlCCC X-Priority: 3 X-MSMail-Priority: Normal Date: Fri, 7 Dec 2001 11:08:27 -0500 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Net5.FateOnline To: Dear.Friends Subject: Ftp-WG: Net5 E-news This is a multi-part message in MIME format. ------=_NextPart_XeejHFGf8U6q4l5dD7IiESx40v1o Content-Type: multipart/alternative; boundary="----=_NextPart_XeejHFGf8U6q4l5dD7IiESx40v1oAA" ------=_NextPart_XeejHFGf8U6q4l5dD7IiESx40v1oAA Content-Type: text/html; charset="big5" Content-Transfer-Encoding: base64 PGh0bWw+DQo8ZnJhbWVzZXQgcm93cz0qIGZyYW1lYm9yZGVyPSJOTyIgYm9yZGVyPSIwIiBmcmFt ZXNwYWNpbmc9IjAiIGNvbHM9Kj4NCjxmcmFtZSBzY3JvbGxpbmc9InllcyIgc3JjPSJodHRwOi8v d3d3Lm5ldHM1LmNvbS9BRC8wMTEyMDdfanAuaHRtIj4NCjwvZnJhbWVzZXQ+DQo8L2h0bWw+ ------=_NextPart_XeejHFGf8U6q4l5dD7IiESx40v1oAA-- ------=_NextPart_XeejHFGf8U6q4l5dD7IiESx40v1o-- From ftp-wg-owner@hethmon.com Wed Dec 12 09:51:46 2001 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06141 for ; Wed, 12 Dec 2001 09:51:45 -0500 (EST) Received: from mail.hethmon.com ([208.171.56.195] [208.171.56.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20011212095652-11945-13 ; Wed, 12 Dec 2001 09:56:52 -0500 Received: from usagi.cts.com ([209.68.192.66] [209.68.192.66]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20011212095645-46829-10 ; Wed, 12 Dec 2001 09:56:45 -0500 Received: from miked.tbt.com (mikedo.cts.com [204.212.152.85]) by usagi.cts.com (8.9.3/8.9.3) with ESMTP id GAA70397 for ; Wed, 12 Dec 2001 06:49:15 -0800 (PST) Message-Id: <5.1.0.14.2.20011212064253.029d1a20@cts.com> X-Sender: miked@cts.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 In-Reply-To: <4BVff9oxf@giga.net.tw> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Date: Wed, 12 Dec 2001 09:56:46 -0500 X-OldDate: Wed, 12 Dec 2001 06:48:06 -0800 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: "Michael A. Dolan" To: IETF FTP WG Subject: Ftp-WG: streaming control commands Has anyone previously proposed adding streaming control commands as FTP extensions? For example, PAUSE, RESUME, REWIND? I realize this is dangerously close to media control like in other protocols, but it would be helpful to know if such a thing has been considered in the past for FTP, and if so, what was the general reaction of this WG. Any pointers/comments are appreciated. Thanks and regards, Mike ----------------------------------------------------- Michael A. Dolan TerraByte Technology (619)445-9070 PO Box 1673 Alpine, CA 91903 FAX: (208)545-6564 URL:http://www.tbt.com From ftp-wg-owner@hethmon.com Wed Dec 12 09:56:47 2001 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06521 for ; Wed, 12 Dec 2001 09:56:46 -0500 (EST) Received: from mail.hethmon.com ([208.171.56.195] [208.171.56.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20011212100226-44032-10 ; Wed, 12 Dec 2001 10:02:26 -0500 Received: from watsun.cc.columbia.edu ([128.59.39.2] [128.59.39.2]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20011212100223-25911-9 ; Wed, 12 Dec 2001 10:02:23 -0500 Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id JAA05476; Wed, 12 Dec 2001 09:54:54 -0500 (EST) In-Reply-To: Your message of Wed, 12 Dec 2001 09:56:46 -0500 Message-ID: Date: Wed, 12 Dec 2001 10:02:24 -0500 X-OldDate: Wed, 12 Dec 2001 9:54:54 EST Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Jeffrey Altman To: FTPEXT Working Group Subject: Ftp-WG: streaming control commands Are you asking if this was added to the protocol? If so, I'm not sure why it is needed. FTP deals with files. With the REST command (RESTART) the client can pickup at any point it desires. So PAUSE, RESUME, and REWIND become client side UI commands that do not affect the FTP protocol. > Has anyone previously proposed adding streaming control commands as FTP > extensions? For example, PAUSE, RESUME, REWIND? I realize this is > dangerously close to media control like in other protocols, but it would be > helpful to know if such a thing has been considered in the past for FTP, > and if so, what was the general reaction of this WG. > > Any pointers/comments are appreciated. > > Thanks and regards, > > Mike > > > ----------------------------------------------------- > Michael A. Dolan TerraByte Technology (619)445-9070 > PO Box 1673 Alpine, CA 91903 FAX: (208)545-6564 > URL:http://www.tbt.com > > Jeffrey Altman * Sr.Software Designer C-Kermit 8.0 Beta available The Kermit Project @ Columbia University includes Secure Telnet and FTP http://www.kermit-project.org/ using Kerberos, SRP, and kermit-support@kermit-project.org OpenSSL. SSH soon to follow. From ftp-wg-owner@hethmon.com Thu Dec 13 00:28:31 2001 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA29895 for ; Thu, 13 Dec 2001 00:28:30 -0500 (EST) Received: from mail.hethmon.com ([208.171.56.195] [208.171.56.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20011213003336-17139-9 ; Thu, 13 Dec 2001 00:33:36 -0500 Received: from usagi.cts.com ([209.68.192.66] [209.68.192.66]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20011213003331-55705-8 ; Thu, 13 Dec 2001 00:33:31 -0500 Received: from miked.tbt.com (mikedo.cts.com [204.212.152.85]) by usagi.cts.com (8.9.3/8.9.3) with ESMTP id VAA92648 for ; Wed, 12 Dec 2001 21:25:52 -0800 (PST) Message-Id: <5.1.0.14.2.20011212075943.02940ba8@cts.com> X-Sender: miked@cts.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Date: Thu, 13 Dec 2001 00:33:33 -0500 X-OldDate: Wed, 12 Dec 2001 08:43:34 -0800 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: "Michael A. Dolan" To: FTPEXT Working Group Subject: Ftp-WG: streaming control commands Thanks for the reply. FYI, I am aware of the current work of this group, specifically the new extensions draft and the half dozen existing RFC's. So, the question was not specifically about this published work. The question was intended more of a philosophical and functional one about application layer control of the transfer and any discussions that may have occurred. REST is indeed helpful, and in block mode with restart markers may do everything needed for the contemplated functions (although we have not actually tried it yet). REST appears to be intended to provide restart (as the name implies), and not for implementing stream control (even though it might work). So, if there was a discussion in this group about this sort of stream control beyond the prima facia intent of REST, a pointer or thoughts would be appreciated. Thanks again. Regards, Mike At 10:02 AM 12/12/2001 -0500, Jeffrey Altman wrote: >Are you asking if this was added to the protocol? > >If so, I'm not sure why it is needed. FTP deals with files. With the >REST command (RESTART) the client can pickup at any point it desires. >So PAUSE, RESUME, and REWIND become client side UI commands that do >not affect the FTP protocol. > > > > > Has anyone previously proposed adding streaming control commands as FTP > > extensions? For example, PAUSE, RESUME, REWIND? I realize this is > > dangerously close to media control like in other protocols, but it > would be > > helpful to know if such a thing has been considered in the past for FTP, > > and if so, what was the general reaction of this WG. > > > > Any pointers/comments are appreciated. > > > > Thanks and regards, > > > > Mike > > > > > > ----------------------------------------------------- > > Michael A. Dolan TerraByte Technology (619)445-9070 > > PO Box 1673 Alpine, CA 91903 FAX: (208)545-6564 > > URL:http://www.tbt.com > > > > > > > > Jeffrey Altman * Sr.Software Designer C-Kermit 8.0 Beta available > The Kermit Project @ Columbia University includes Secure Telnet and FTP > http://www.kermit-project.org/ using Kerberos, SRP, and > kermit-support@kermit-project.org OpenSSL. SSH soon to follow. ----------------------------------------------------- Michael A. Dolan TerraByte Technology (619)445-9070 PO Box 1673 Alpine, CA 91903 FAX: (208)545-6564 URL:http://www.tbt.com From ftp-wg-owner@hethmon.com Tue Dec 18 03:47:16 2001 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA15982 for ; Tue, 18 Dec 2001 03:47:15 -0500 (EST) Received: from mail.hethmon.com ([208.171.56.195] [208.171.56.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20011218035242-62814-9 ; Tue, 18 Dec 2001 03:52:43 -0500 Received: from brandenburg.cs.mu.OZ.AU ([202.28.96.1] [202.28.96.1]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20011218035214-47463-8 ; Tue, 18 Dec 2001 03:52:38 -0500 Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id fBI8l4U02419; Tue, 18 Dec 2001 15:47:04 +0700 (ICT) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <2417.1008665224@brandenburg.cs.mu.OZ.AU> Date: Tue, 18 Dec 2001 03:52:40 -0500 X-OldDate: Tue, 18 Dec 2001 15:47:04 +0700 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Robert Elz To: ftp-wg@hethmon.com Subject: Ftp-WG: Last Call on MLST is over ... There were just two comments submitted (our AD managed to count none, but he's busy...) that I know of. The first, from zefram@fysh.org asked for clarification of a few issues... zefram@fysh.org said: | Section 2.4 states that "unless stated to the contrary, any reply to | any FTP command ... may be of the multi-line format". [...] | This makes those parts of the specification that provide a more | restricted syntax for certain replies ambiguous: it isn't clear where | multi-line responses are permitted. This happens in section 3.1 | (defining a successful MDTM reply) and 4.1 (SIZE): both give ABNF that | on its face allows only for a single-line reply, If the WG approves, to handle that, I propose putting the following short paragraph at the end of each of sections 3.1 and 4.1 ... Note that when the 213 response is issued, that is, when there is no error, the format MUST be exactly as specified. Multi-line responses are not permitted. That is then "stating to the contrary" and should solve the problem I believe. Zefram, is that sufficient? Also ... zefram@fysh.org said: | Section 3.1, on the MDTM command, says "Attempts to query the | modification time of files that are unable to be retrieved generate | undefined responses.". The phrase "undefined responses" sounds like | it permits what would otherwise be violations of the protocol, [...] For that, I propose changing: The "pathname" specifies an object in the NVFS which may be the object of a RETR command. Attempts to query the modification time of files that are unable to be retrieved generate undefined responses. from section 3.1 of mlst-13.txt into: The "pathname" specifies an object in the NVFS which may be the object of a RETR command. Attempts to query the modification time of files that are unable to be retrieved may generate an error-response, or can result in a positive response carrying a time-val with an unspecified value, the choice being made by the server-PI. in what will become mlst-14.txt once we have agreed on the changes (doing it this way to save on turnaround time for the I-D). Zefram, is that OK? Anyone in the WG have any problems with those changes? If so, what would be better wording? The second comment (sent only to the IESG and Paul and myself as editors) was from the RFC Editor. They don't like the abstract, it doesn't meet their current guidelines (which didn't exist when -13 was published I think, certainly not -12, which was the last draft with any editorial changes). Some of what they want certinly makes sense - having the abstract refer to references in the doc makes the abstract much less useful when red apart from the doc - which is really what the abstract should be for. To handle this, I suggest making the abstract be ... Abstract This document specifies new FTP commands to obtain listings of remote directories in a defined format. In order to allow consenting clients and servers to interact more freely, a quite basic, and optional, virtual file store structure is also defined. This proposal also extends the FTP protocol to allow character sets other than US-ASCII by allowing the transmission of 8-bit characters and recommending the use of UTF-8 encoding. Much implemented, but long undocumented, mechanisms to permit restarts of interrupted data transfers in STREAM mode, are also included here. I am awaiting a reply from the RFC Editor as to whether this would meet their guidelines or not. Assuming that it does, does the WG have any problems with that change? Or suggestions for something better? The new guidelines can be found from the rfc editor's web page. Aside from those, I made one cosmetic change - the list of old FTP commands in section 8 that are now required to handle UTF-8 path names has switched from being one column down the left of the page in semi-random order, to two columns, alphabetically sorted (column major I think it is - that is, down the left column, then continue down the right column). This actually ends up saving a page in the final doc... (or does as an I-D - actual final pagination for RFC format won't get done until the doc is IESG approved). Also, since the only mention of reference [1] (US-ASCII spec) used to be in the abstract, I added a couple of mentions of it other places... You will, of course, get time to read the revised draft and comment (perhaps not much time - or perhaps if the IESG decides to be dumb again, a lot more time...) after it is published - the point of this mail is to avoid having to submit too many more iterations of this doc if at all possible. If no-one objects to the changes here, I'll send in the new I-D in a day or two, then if there are still no objections, our chair can ask the IESG to progress the doc to a PS RFC (I will send the rfc editor the nroff sources for the doc, so once IESG approved, it should not take too long to appear). kre From ftp-wg-owner@hethmon.com Tue Dec 18 09:55:15 2001 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19414 for ; Tue, 18 Dec 2001 09:55:14 -0500 (EST) Received: from mail.hethmon.com ([208.171.56.195] [208.171.56.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20011218100030-32468-9 ; Tue, 18 Dec 2001 10:00:30 -0500 Received: from anvil.murkworks.com ([128.153.43.1] [128.153.43.1]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20011218100025-35231-8 ; Tue, 18 Dec 2001 10:00:25 -0500 Received: from coal.murkworks.com (coal.murkworks.com [128.153.43.3]) by anvil.murkworks.com (8.9.1/8.9.1) with ESMTP id JAA10300 for ; Tue, 18 Dec 2001 09:49:14 -0500 (EST) Received: from GIMPELSTIMER/SpoolDir by coal.murkworks.com (Mercury 1.44); 18 Dec 01 10:01:13 -0400 Received: from SpoolDir by GIMPELSTIMER (Mercury 1.44); 18 Dec 01 10:01:06 -0400 Organization: MurkWorks, Incorporated. MIME-Version: 1.0 Message-ID: <3C1F11E9.30977.3848AD2E@localhost> In-reply-to: <2417.1008665224@brandenburg.cs.mu.OZ.AU> X-mailer: Pegasus Mail for Windows (v4.01) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Date: Tue, 18 Dec 2001 10:00:27 -0500 X-OldDate: Tue, 18 Dec 2001 10:01:00 -0500 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: "Brad Clements" To: ftp-wg@hethmon.com Subject: Ftp-WG: Last Call on MLST is over ... Content-Transfer-Encoding: 7BIT On 18 Dec 2001 at 3:52, Robert Elz wrote: > from section 3.1 of mlst-13.txt into: > > The "pathname" specifies an object in the NVFS which may be the > object of a RETR command. Attempts to query the modification time of > files that are unable to be retrieved may generate an error-response, > or can result in a positive response carrying a time-val with an > unspecified value, the choice being made by the server-PI. Is there some particular reason why an MDTM call on a non-existing object should not always fail with a positive permanent error? I think I've seen some clients that use MDTM as a simple existance check, so I do not think that a random time-val response is appropriate if the file cannot be subsequently LIST,NLST (etc) In my opinion, if the file object will not be listed by NLST or LIST (etc), then MDTM should return a permanent error response. Note that I'm not tying this to RETR, since an object may exist, but be write-only for the currently authenticated object. Hmm.. In NetWare, we allow write-only without LIST or READ access as anonymous "drop boxes". In that case, MDTM would also be expected to return a failure response, even though the authenticated user could write to the object. Since MDTM returns information about an object (existance, and modtime), which is a subset of info returned from LIST (typically), it should be tied to LIST rights from an authentication standpoint. In all cases though, if the file doesn't exist or the user doesn't have that right, then I think an error response is the only appropriate response, not an unspecified timeval. Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax netmeeting: ils://ils.murkworks.com AOL-IM: BKClements From ftp-wg-owner@hethmon.com Tue Dec 18 13:14:56 2001 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23304 for ; Tue, 18 Dec 2001 13:14:55 -0500 (EST) Received: from mail.hethmon.com ([208.171.56.195] [208.171.56.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20011218131920-17713-9 ; Tue, 18 Dec 2001 13:19:20 -0500 Received: from mail15a.boca15-verio.com ([208.55.91.57] [208.55.91.57]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20011218131917-18233-8 ; Tue, 18 Dec 2001 13:19:17 -0500 Received: from www1525.boca15-verio.com (208.55.91.110) by mail15a.boca15-verio.com (RS ver 1.0.60s) with SMTP id 082746005 for ; Tue, 18 Dec 2001 13:10:48 -0500 (EST) Message-Id: <4.3.2.7.2.20011218115806.01d391b8@208.55.91.110> X-Sender: alun.texisc@208.55.91.110 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 In-Reply-To: <3C1F11E9.30977.3848AD2E@localhost> References: <2417.1008665224@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop-Detect: 1 Date: Tue, 18 Dec 2001 13:19:18 -0500 X-OldDate: Tue, 18 Dec 2001 12:09:45 -0600 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Alun Jones To: FTPEXT Working Group Subject: Ftp-WG: Last Call on MLST is over ... At 09:00 AM 12/18/2001, Brad Clements wrote: >On 18 Dec 2001 at 3:52, Robert Elz wrote: > > > from section 3.1 of mlst-13.txt into: > > > > The "pathname" specifies an object in the NVFS which may be the > > object of a RETR command. Attempts to query the modification time of > > files that are unable to be retrieved may generate an error-response, > > or can result in a positive response carrying a time-val with an > > unspecified value, the choice being made by the server-PI. > >Is there some particular reason why an MDTM call on a non-existing object >should not >always fail with a positive permanent error? Not non-existing, but "unable to be retrieved". Non-existant files should, of course, give the usual 550 error. >I think I've seen some clients that use MDTM as a simple existance check, >so I do not >think that a random time-val response is appropriate if the file cannot be >subsequently >LIST,NLST (etc) > >In my opinion, if the file object will not be listed by NLST or LIST >(etc), then MDTM >should return a permanent error response. Again, the language you quote says "the modification time of files that are unable to be retrieved", not "the modification time of files that do not exist / that will not be listed" >Note that I'm not tying this to RETR, since an object may exist, but be >write-only for the >currently authenticated object. Hmm.. In NetWare, we allow write-only >without LIST or >READ access as anonymous "drop boxes". In that case, MDTM would also be >expected to return a failure response, even though the authenticated user >could write to >the object. Since MDTM returns information about an object (existance, and >modtime), >which is a subset of info returned from LIST (typically), it should be >tied to LIST rights >from an authentication standpoint. A little further in the draft (the next paragraph), we see "The server-PI will respond to the MDTM command with ... a 550 reply if the file does not exist, ..." - apparently your objections have already been addressed. The possibility of a "213 " response seems to me to be more appropriate for an item which exists, can be listed, but whose modification time cannot reliably be established, to avoid the problem of an FTP client screwing up when it tries to MDTM a file as an existence check. F'rinstance, a volume root on Windows won't give you a valid date from CFile::GetStatus (which itself simply calls ::FindFirstFile). I suspect that the aim is that anything that shows up as an output line in NLST should also serve as an input to MDTM and result in a 213 response - anyone else care to contribute on this? Alun. ~~~~ -- Texas Imperial Software | Try WFTPD, the Windows FTP Server. Find us at 1602 Harvest Moon Place | http://www.wftpd.com or email alun@texis.com Cedar Park TX 78613-1419 | VISA/MC accepted. NT-based sites, be sure to Fax/Voice +1(512)258-9858 | read details of WFTPD Pro for NT. From ftp-wg-owner@hethmon.com Tue Dec 18 21:48:15 2001 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA04580 for ; Tue, 18 Dec 2001 21:48:14 -0500 (EST) Received: from mail.hethmon.com ([208.171.56.195] [208.171.56.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20011218215311-9415-9 ; Tue, 18 Dec 2001 21:53:11 -0500 Received: from brandenburg.cs.mu.OZ.AU ([202.28.96.1] [202.28.96.1]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20011218215305-10754-8 ; Tue, 18 Dec 2001 21:53:06 -0500 Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id fBJ2mAD01314 for ; Wed, 19 Dec 2001 09:48:11 +0700 (ICT) In-Reply-To: <3C1F11E9.30977.3848AD2E@localhost> References: <3C1F11E9.30977.3848AD2E@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <1312.1008730090@brandenburg.cs.mu.OZ.AU> Date: Tue, 18 Dec 2001 21:53:08 -0500 X-OldDate: Wed, 19 Dec 2001 09:48:10 +0700 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Robert Elz To: FTPEXT Working Group Subject: Ftp-WG: Last Call on MLST is over ... Date: Tue, 18 Dec 2001 10:00:27 -0500 From: "Brad Clements" Message-ID: <3C1F11E9.30977.3848AD2E@localhost> | Is there some particular reason why an MDTM call on a non-existing object | should not always fail with a positive permanent error? What Alun said, but, I could make the text be ... Attempts to query the modification time of files that exist but are unable to be retrieved may generate an error-response, [...] if that would make it more clear? | READ access as anonymous "drop boxes". In that case, MDTM would also be | expected to return a failure response, No, that's exactly the case where MDTM is expected to return whatever you decide to make it return. That is, you can check to see that it is un-retrievable if you like, and return an error, or you can return the last time someone dropped something in there, or you can return the epoch, or just about anything else that happens to be easy. | In all cases though, if the file doesn't exist or the user doesn't have | that right, then I think an error response is the only appropriate | response,not an unspecified timeval. Yes, the unspecified case was really meant to handle situations where the file does exist, the user has permissions, but what is there isn't a normal file (doing MDTM on a directory is one such situation). That is, the server isn't required to check that the object is one where it makes sense to look for a modification time. If you have a suggestion for improved wording, please send it soon. kre From ftp-wg-owner@hethmon.com Tue Dec 18 21:49:33 2001 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA04601 for ; Tue, 18 Dec 2001 21:49:33 -0500 (EST) Received: from mail.hethmon.com ([208.171.56.195] [208.171.56.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20011218215516-62314-13 ; Tue, 18 Dec 2001 21:55:16 -0500 Received: from brandenburg.cs.mu.OZ.AU ([202.28.96.1] [202.28.96.1]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20011218215511-51735-12 ; Tue, 18 Dec 2001 21:55:12 -0500 Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id fBJ2oGD01329 for ; Wed, 19 Dec 2001 09:50:16 +0700 (ICT) In-Reply-To: <2417.1008665224@brandenburg.cs.mu.OZ.AU> References: <2417.1008665224@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <1327.1008730216@brandenburg.cs.mu.OZ.AU> Date: Tue, 18 Dec 2001 21:55:13 -0500 X-OldDate: Wed, 19 Dec 2001 09:50:16 +0700 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Robert Elz To: FTPEXT Working Group Subject: Ftp-WG: Last Call on MLST is over ... Date: Tue, 18 Dec 2001 03:52:40 -0500 From: Robert Elz Message-ID: <2417.1008665224@brandenburg.cs.mu.OZ.AU> | I am awaiting a reply from the RFC Editor as to whether this would meet | their guidelines or not. The RFC Editor (or a part of it) has suggested ... Abstract This document specifies new FTP commands to obtain listings of remote directories in a defined format, to define a virtual file storage structure, to allow character sets other than US-ASCII, and to permit restarts of interrupted data transfers in STREAM mode. which looks fine to me - much shorter, and still covers pretty much everything (MDTM and SIZE can just be considered part of what is needed for restarts - for the purposes of the abstract anyway). Any problems with that version? kre From ftp-wg-owner@hethmon.com Wed Dec 19 10:35:24 2001 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29542 for ; Wed, 19 Dec 2001 10:35:23 -0500 (EST) Received: from mail.hethmon.com ([208.171.56.195] [208.171.56.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20011219104059-38529-10 ; Wed, 19 Dec 2001 10:40:59 -0500 Received: from anvil.murkworks.com ([128.153.43.1] [128.153.43.1]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20011219104056-15317-9 ; Wed, 19 Dec 2001 10:40:56 -0500 Received: from coal.murkworks.com (coal.murkworks.com [128.153.43.3]) by anvil.murkworks.com (8.9.1/8.9.1) with ESMTP id KAA13654 for ; Wed, 19 Dec 2001 10:29:43 -0500 (EST) Received: from GIMPELSTIMER/SpoolDir by coal.murkworks.com (Mercury 1.44); 19 Dec 01 10:41:49 -0400 Received: from SpoolDir by GIMPELSTIMER (Mercury 1.44); 19 Dec 01 10:41:22 -0400 Organization: MurkWorks, Incorporated. MIME-Version: 1.0 Message-ID: <3C206CD8.26761.3D93ECF1@localhost> References: <3C1F11E9.30977.3848AD2E@localhost> In-reply-to: <1312.1008730090@brandenburg.cs.mu.OZ.AU> X-mailer: Pegasus Mail for Windows (v4.01) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Date: Wed, 19 Dec 2001 10:40:57 -0500 X-OldDate: Wed, 19 Dec 2001 10:41:20 -0500 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: "Brad Clements" To: FTPEXT Working Group Subject: Ftp-WG: Last Call on MLST is over ... Content-Transfer-Encoding: 7BIT On 18 Dec 2001 at 21:53, Robert Elz wrote: > | Is there some particular reason why an MDTM call on a non-existing object > | should not always fail with a positive permanent error? > > What Alun said, but, I could make the text be ... > > Attempts to query the modification time of files that exist > but are unable to be retrieved may generate an error-response, [...] > > if that would make it more clear? I think the issue is being somewhat clouded because we are overloading the MDTM command with too many "uses". 1. MDTM on objects that exist, but don't have the concept of a modtime, such as a volume. I suppose the returned modtime should be up to the server implementation and could be any valid timeval. Why a client would request this I don't know, perhaps because the object was an element of a path? 2. MDTM on objects that do not exist should return an error response. 3. MDTM on objects that exist, but the authenticated user does not have "rights" to.. I'm not sure how best to handle this, seems that no single answer suites everyone. Our server implementation treats option 3 like option 2 if the user would not "see" the object in a LIST command. That is, if LIST,NLST, MLST would not return the object, then MDTM returns an error response. This is independent of read and write, rights. I think requiring that MDTM take "LIST access rights" into account is beyond the scope of this document. > If you have a suggestion for improved wording, please send it soon. Not specific wording, but in an earlier post was this text: > | Section 3.1, on the MDTM command, says "Attempts to query the > modification | time of files that are unable to be retrieved generate > undefined | responses.". The phrase "undefined responses" sounds like 1. I'm objecting to "unable to be retrieved" - Personally I think it should be tied to LIST or NLST if, indeed, the use of the word "retrieved" was implying RETR, rather than meaning that the OS could not provide the object modtime to the server implementation. If you meant "retrieved" as in, the OS couldn't provide the value, then I think the wording should be: "files for which a modification time is not available". If you meant "retrieved" as in, a subsequent RETR on the file would fail, then I think this needs to be cleared up. 2. undefined response should be: either an error response or a timeval whose value is implementation specific. You may also wish to add a cautionary statement that using MDTM to determine the existance of an object or the validity of a path is not appropriate. Or is it? If we expect clients to use MDTM as a shortcut to determine if a path is valid, or if a file 'exists', then we should clarify how that mechanism is supposed to work. Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax netmeeting: ils://ils.murkworks.com AOL-IM: BKClements From ftp-wg-owner@hethmon.com Wed Dec 19 11:13:24 2001 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00834 for ; Wed, 19 Dec 2001 11:13:24 -0500 (EST) Received: from mail.hethmon.com ([208.171.56.195] [208.171.56.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20011219111905-4265-9 ; Wed, 19 Dec 2001 11:19:05 -0500 Received: from d06lmsgate-4.uk.ibm.COM ([195.212.29.4] [195.212.29.4]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20011219111900-11126-8 ; Wed, 19 Dec 2001 11:19:01 -0500 Received: from d06relay01.portsmouth.uk.ibm.com (d06relay01.portsmouth.uk.ibm.com [9.166.84.147]) by d06lmsgate-4.uk.ibm.COM (1.0.0) with ESMTP id PAA94368 for ; Wed, 19 Dec 2001 15:59:09 GMT Received: from d06ml035.portsmouth.uk.ibm.com (d06ml035_cs0 [9.180.35.16]) by d06relay01.portsmouth.uk.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBJGB0G87042 for ; Wed, 19 Dec 2001 16:11:02 GMT MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: X-MIMETrack: Serialize by Router on D06ML035/06/M/IBM(Release 5.0.8 |June 18, 2001) at 19/12/2001 16:11:19, Serialize complete at 19/12/2001 16:11:19 Content-Type: text/plain; charset="us-ascii" Date: Wed, 19 Dec 2001 11:19:02 -0500 X-OldDate: Wed, 19 Dec 2001 16:06:19 +0000 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: "Paul V Ford-Hutchinson" To: FTPEXT Working Group Subject: Ftp-WG: Last Call on MLST is over ... Brad Clements wrote: > You may also wish to add a cautionary statement that using MDTM to > determine the existance of an object or the validity of a path is > not appropriate. I'm struggling to make my thoughts clear here - but .... how about "FTP command responses and object existance are not related" The only thing a command-response does is tell you about that command and the response _at that time_ by the time the next command is being processed - things may have changed. For example, I have an FTP server that doesn't reflect a filesystem at all, it reflects a 'receive and delete' mailbox. I.E. the act of a succesful RETR is that the object has gone. I don't consider that this breaks the FTP protocol at all. What it does sometimes break is client assumptions about the server. I think FTP is pretty good at trying to stop the client assuming things because UNIX/Windows/MVS/... does it that way. If a client uses MDTM (or DELE, or SITE CHMOD, or anything) to assume a generally applicable change or discovery of state of an object - that is OK - but an FTP server that doesn't share the same view of the world is not in violation of FTP, nor should we try to spec FTP to make it so. Paul -- Paul Ford-Hutchinson : eCommerce application security : paulfordh@uk.ibm.com MPT-6, IBM , PO Box 31, Birmingham Rd, Warwick, CV34 5JL +44 (0)1926 462005 http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html From ftp-wg-owner@hethmon.com Thu Dec 20 14:41:06 2001 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18318 for ; Thu, 20 Dec 2001 14:41:05 -0500 (EST) Received: from mail.hethmon.com ([208.171.56.195] [208.171.56.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20011220144611-21352-15 ; Thu, 20 Dec 2001 14:46:11 -0500 Received: from stat.com ([207.211.1.10] [207.211.1.10]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20011220144607-34725-8 ; Thu, 20 Dec 2001 14:46:08 -0500 Received: from brandenburg.cs.mu.OZ.AU [202.28.96.1] by stat.com with ESMTP (SMTPD32-7.05) id AA058531014E; Thu, 20 Dec 2001 02:06:13 -0700 Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id fBK96Ar02097 for ; Thu, 20 Dec 2001 16:06:18 +0700 (ICT) In-Reply-To: <3C206CD8.26761.3D93ECF1@localhost> References: <3C206CD8.26761.3D93ECF1@localhost> <3C1F11E9.30977.3848AD2E@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <2095.1008839170@brandenburg.cs.mu.OZ.AU> Date: Thu, 20 Dec 2001 14:46:08 -0500 X-OldDate: Thu, 20 Dec 2001 16:06:10 +0700 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: Robert Elz To: FTPEXT Working Group Subject: Ftp-WG: Last Call on MLST is over ... Date: Wed, 19 Dec 2001 10:40:57 -0500 From: "Brad Clements" Message-ID: <3C206CD8.26761.3D93ECF1@localhost> | I think the issue is being somewhat clouded because we are overloading | the MDTM command with too many "uses". Actually, "we're" not overloading it at all - its purpose is to check whether a file that was RETR'd previously which failed part way through, has been changed since. If not, then restarting the transfer (using REST) is probably going to be OK. If it has changed, then it isn't. And yes, there's still the race condition (the file might be altered between the MTDM and the subsequent REST/RETR). | 1. MDTM on objects that exist, but don't have the concept of a modtime, | such as a volume. I suppose the returned modtime should be up to the | server implementation and could be any valid timeval. That is what the text is trying to say. | Why a client would request this I don't know, perhaps | because the object was an element of a path? I don't know either ... and if the text makes it clear that what happens if a client does this is more or less unspecified, then clients will probably stop doing it (if any do). | 2. MDTM on objects that do not exist should return an error response. That's OK. | 3. MDTM on objects that exist, but the authenticated user does not | have "rights" to.. I don't care about this case at all. As MDTM is a support function for REST, it really doesn't matter. Whether the client restarts or not, the RETR that follows will fail... That's all that really matters. | If you meant "retrieved" as in, a subsequent RETR on the file would fail, | then I think this needs to be cleared up. That was the intention - that is, for MDTM's purpose, if RETR won't work, then what MDTM returns is simply irrelevant (it can return an error, or it can return any random time it likes). | You may also wish to add a cautionary statement that using MDTM to | determine the existance of an object or the validity of a path is not | appropriate. Perhaps. I'd much prefer to simply get this doc finished and stop continually fiddling with it... One might hope that when MLST gets implemented more, clients will start using that to find out about files. They get better information, just as cheaply. Specifying that MDTM can do anything it likes, except in the circumstance where it should be used should help dissuade people from using it inappropriately.. This is one of the drawbacks of having facilities like MDTM implemented, and in wide circulation, but undocumented. People know they exist, but there's no way to discover what is an appropriate use, and what isn't. So, if it seems to work, it must be OK... Note, the most common use of MDTM today is, I think, undoubtably that of setting the mod time on a fetched file to match the mod time of the file on the server. That is supported by this spec - the file was able to be RETR'd, so it should have an MDTM response that is sane. kre From ftp-wg-owner@hethmon.com Thu Dec 20 14:48:36 2001 Received: from mail.hethmon.com (mail.hethmon.com [208.171.56.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18521 for ; Thu, 20 Dec 2001 14:48:35 -0500 (EST) Received: from mail.hethmon.com ([208.171.56.195] [208.171.56.195]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20011220145412-46728-10 ; Thu, 20 Dec 2001 14:54:12 -0500 Received: from anvil.murkworks.com ([128.153.43.1] [128.153.43.1]) by mail.hethmon.com (Hethmon Brothers Smtpd) id 20011220145409-15261-8 ; Thu, 20 Dec 2001 14:54:09 -0500 Received: from coal.murkworks.com (coal.murkworks.com [128.153.43.3]) by anvil.murkworks.com (8.9.1/8.9.1) with ESMTP id OAA17426 for ; Thu, 20 Dec 2001 14:42:52 -0500 (EST) Received: from GIMPELSTIMER/SpoolDir by coal.murkworks.com (Mercury 1.44); 20 Dec 01 14:55:07 -0400 Received: from SpoolDir by GIMPELSTIMER (Mercury 1.44); 20 Dec 01 14:54:43 -0400 Organization: MurkWorks, Incorporated. MIME-Version: 1.0 Message-ID: <3C21FBAE.22954.2287C7@localhost> References: <3C206CD8.26761.3D93ECF1@localhost> In-reply-to: <2095.1008839170@brandenburg.cs.mu.OZ.AU> X-mailer: Pegasus Mail for Windows (v4.01) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Date: Thu, 20 Dec 2001 14:54:10 -0500 X-OldDate: Thu, 20 Dec 2001 14:54:39 -0500 Sender: ftp-wg-owner X-Listname: ftp-wg@hethmon.com Reply-To: FTPEXT Working Group From: "Brad Clements" To: FTPEXT Working Group Subject: Ftp-WG: Last Call on MLST is over ... Content-Transfer-Encoding: 7BIT On 20 Dec 2001 at 14:46, Robert Elz wrote: > Actually, "we're" not overloading it at all - its purpose is to check whether > a file that was RETR'd previously which failed part way through, has been Many of our customers are using it to determine if the file has changed, a poor man's replication, even in STOR mode, but I digress > Perhaps. I'd much prefer to simply get this doc finished and stop > continually fiddling with it... I've been lurking on this list for quite and while and so far have had nothing to say. Sorry my comments have come so late in the game. I concur, get the doc finished and ship it. Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax netmeeting: ils://ils.murkworks.com AOL-IM: BKClements