From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri May 3 00:48:05 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA26044 for ; Fri, 3 May 2002 00:48:04 -0400 (EDT) Received: (qmail 20317 invoked by uid 605); 3 May 2002 04:48:01 -0000 Delivered-To: ietf-ssh@netbsd.org Message-ID: <20020503044801.20314.qmail@mail.netbsd.org> Received: (qmail 20300 invoked from network); 3 May 2002 04:47:57 -0000 Received: from unknown (HELO maktoob.com) (217.78.74.105) by mail.netbsd.org with SMTP; 3 May 2002 04:47:57 -0000 From: "Gen.H.Salama" To: Subject: BUSINESS RELATIONSHIP PROPOSAL Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Fri, 3 May 2002 06:27:50 +0200 Reply-To: "Gen.H.Salama" X-Priority: 1 (Highest) Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit General Hama Salama. Email:ghsa lama@makto ob.com, BUSINESS RELATIONSH IP PROPOSAL Dear Sir, I received encouragin g informatio n about you, hence I decided to contact you. I am Gen. Hama Salama, Military Commander with POLISARIO( Political Front for the Liberation of Western Sahara) and a member of council of the National Secretaria t of Western Sahara(Sah arawi Democratic Republic) . See web site: www.arso.o rg or www.arso.o rg/secr.na te99.htm to confirm about me and also know more about Western Sahara. Prior to my promotion to this command, I was the second in command to the former military boss. He was killed in battle in early January. Some private , religious and corporate organizati ons who recognize us assist/aid us always in the war prosecutio n. Before the death of my former boss, we were given some funds(US$5 5m) to procures ammunition s. My boss deposited it with a private security company in Europe. It was only I and him that are aware of thiscash deposit. I now want to claim this funds and I have all the relating documents needed to collect the deposit including the Certificat e of Deposit with which the Cash was deposited as Precious stones and The Deposit Agreement. I therefore want you to team up with me to collect the funds in Europe as I require a foreigner to perfect the operation. Let me know your terms. I will provide you with all the necessary documentat ion needed and there are no risks involved. It is a simple and straight transactio n but must bekept highly confidenti al.Upon the receipt of your positive response, further details and the method of operation will be communicat ed to you. Therefore if you are interested , please do reach me via an immediate reply mail. I will want everything about this transactio n to be treated in strictest confidence even if you are notinteres ted. I await your urgent response through my personal mailbox:Em ail:ghsala ma@maktoob .com, Yours Gen Hama Salama Military Commander Western Sahara From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue May 7 12:15:57 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14253 for ; Tue, 7 May 2002 12:15:56 -0400 (EDT) Received: (qmail 10211 invoked by uid 605); 7 May 2002 16:15:53 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10198 invoked from network); 7 May 2002 16:15:52 -0000 Received: from mail2.nrw.net (194.245.103.15) by mail.netbsd.org with SMTP; 7 May 2002 16:15:52 -0000 Received: (qmail 29941 invoked from network); 7 May 2002 16:15:39 -0000 Received: from unknown (HELO fileserver.ITinhaus.de) (194.176.6.50) by mail2.nrw.net with SMTP; 7 May 2002 16:15:39 -0000 Received: by FILESERVER with Internet Mail Service (5.5.2650.21) id ; Tue, 7 May 2002 18:12:25 +0200 Message-ID: <81F901A447CCD31182B900508B7160EC0B56D9@FILESERVER> From: Andre Weigandt To: "'info@linware.de'" Subject: Newsletter LinWare, Mai 2002 Date: Tue, 7 May 2002 18:12:09 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: ietf-ssh-owner@netbsd.org Precedence: list Andre Weigandt SojusIT Dennewartstr. 27 52068 Aachen email: aweigandt@sojusit.de www.sojusit.de tel.: 0241/9976775 fax: 0241/9976792 From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue May 7 17:30:58 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24698 for ; Tue, 7 May 2002 17:30:57 -0400 (EDT) Received: (qmail 19691 invoked by uid 605); 7 May 2002 21:31:00 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19683 invoked from network); 7 May 2002 21:30:59 -0000 Received: from service-66-28-45-3.321host-it.com (HELO camp.321host-it.com) (66.28.45.3) by mail.netbsd.org with SMTP; 7 May 2002 21:30:59 -0000 Received: (from www@localhost) by camp.321host-it.com (8.11.6/8.11.2) id g47LXfi10666; Tue, 7 May 2002 14:33:41 -0700 Date: Tue, 7 May 2002 14:33:41 -0700 Message-Id: <200205072133.g47LXfi10666@camp.321host-it.com> To: ietf-ssh@netbsd.org From: eClickz Subject: New search engine! eClickz.net http: //www.eclickz.net Sender: ietf-ssh-owner@netbsd.org Precedence: list eClickz is a brand new pay-per-click (ppc) search engine where users can find relevant information on any topic conceivable. Features lightning fast search results and an affiliate program where webmasters can earn money by placing a search box on their website. Enjoy ! From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri May 10 13:50:48 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07933 for ; Fri, 10 May 2002 13:50:48 -0400 (EDT) Received: (qmail 10264 invoked by uid 605); 10 May 2002 17:50:52 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10257 invoked from network); 10 May 2002 17:50:52 -0000 Received: from lespaul.process.com (192.42.95.27) by mail.netbsd.org with SMTP; 10 May 2002 17:50:52 -0000 Received: by lespaul.process.com with Internet Mail Service (5.5.2653.19) id ; Fri, 10 May 2002 13:52:36 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE86040AA36E@lespaul.process.com> From: Richard Whalen To: "'ietf-ssh@netbsd.org'" Subject: A text transfer mode is needed for the SSH File Transfer Protocol Date: Fri, 10 May 2002 13:52:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ietf-ssh-owner@netbsd.org Precedence: list We have had a few customers report problems when transferring text files between dissimilar systems with different implementations of the SSH File Transfer Protocol. I believe that these problems would not exist if the protocol was able to correctly deal with the differences in the way that different systems store text files. ---------------------- Richard Whalen Process Software 508-879-6994x261 From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri May 10 14:12:58 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09402 for ; Fri, 10 May 2002 14:12:58 -0400 (EDT) Received: (qmail 21959 invoked by uid 605); 10 May 2002 18:13:03 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21952 invoked from network); 10 May 2002 18:13:02 -0000 Received: from darkwing.uoregon.edu (128.223.142.13) by mail.netbsd.org with SMTP; 10 May 2002 18:13:02 -0000 Received: from twin.uoregon.edu (twin.uoregon.edu [128.223.214.27]) by darkwing.uoregon.edu (8.12.3/8.12.3) with ESMTP id g4AID1AJ000823; Fri, 10 May 2002 11:13:01 -0700 (PDT) Date: Fri, 10 May 2002 11:15:13 -0700 (PDT) From: Joel Jaeggli X-X-Sender: joelja@twin.uoregon.edu To: Richard Whalen cc: "'ietf-ssh@netbsd.org'" Subject: Re: A text transfer mode is needed for the SSH File Transfer Protocol In-Reply-To: <63D30D6E10CFD11190A90000F805FE86040AA36E@lespaul.process.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list which assumes that sftp should treat text files like ftp does rather than like rcp does. I'm not at all convinced that sftp should do that. joelja On Fri, 10 May 2002, Richard Whalen wrote: > We have had a few customers report problems when transferring text files > between dissimilar systems with different implementations of the SSH File > Transfer Protocol. I believe that these problems would not exist if the > protocol was able to correctly deal with the differences in the way that > different systems store text files. > > ---------------------- > Richard Whalen > Process Software > 508-879-6994x261 > -- -------------------------------------------------------------------------- Joel Jaeggli Academic User Services joelja@darkwing.uoregon.edu -- PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E -- In Dr. Johnson's famous dictionary patriotism is defined as the last resort of the scoundrel. With all due respect to an enlightened but inferior lexicographer I beg to submit that it is the first. -- Ambrose Bierce, "The Devil's Dictionary" From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri May 10 14:18:58 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09673 for ; Fri, 10 May 2002 14:18:57 -0400 (EDT) Received: (qmail 24212 invoked by uid 605); 10 May 2002 18:19:02 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24205 invoked from network); 10 May 2002 18:19:01 -0000 Received: from raptor.psccos.com (207.225.29.51) by mail.netbsd.org with SMTP; 10 May 2002 18:19:01 -0000 Received: from ntbsod.process.com ([207.225.29.50]) by RAPTOR.PSCCOS.COM (PMDF V6.1 #36649) with ESMTPA id <01KHK9B9XR0W8WWKMA@RAPTOR.PSCCOS.COM> for ietf-ssh@netbsd.org; Fri, 10 May 2002 12:18:59 -0700 (MST) Date: Fri, 10 May 2002 12:18:57 -0600 From: "Dan O'Reilly" Subject: Re: A text transfer mode is needed for the SSH File Transfer Protocol In-reply-to: X-Sender: oreilly@raptor.psccos.com To: Joel Jaeggli Cc: "'ietf-ssh@netbsd.org'" Message-id: <5.1.0.14.2.20020510121618.00aa7730@raptor.psccos.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Content-type: text/plain; format=flowed; charset=us-ascii References: <63D30D6E10CFD11190A90000F805FE86040AA36E@lespaul.process.com> Sender: ietf-ssh-owner@netbsd.org Precedence: list SCP = RCP on steroids Therefore, is it unreasonable to assume that sftp would be more robust to be able to handle all types of file formats, not just those common to the UNIX world? The root problem is that scp/sftp (in fact, all of SSH, for that matter) is VERY UNIX-centric, and unfortunately, that's not the total state of the world... At 12:15 PM 5/10/2002, Joel Jaeggli wrote: >which assumes that sftp should treat text files like ftp does rather than >like rcp does. > >I'm not at all convinced that sftp should do that. > >joelja > >On Fri, 10 May 2002, Richard Whalen wrote: > > > We have had a few customers report problems when transferring text files > > between dissimilar systems with different implementations of the SSH File > > Transfer Protocol. I believe that these problems would not exist if the > > protocol was able to correctly deal with the differences in the way that > > different systems store text files. > > > > ---------------------- > > Richard Whalen > > Process Software > > 508-879-6994x261 > > > >-- >-------------------------------------------------------------------------- >Joel Jaeggli Academic User Services joelja@darkwing.uoregon.edu >-- PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E -- > In Dr. Johnson's famous dictionary patriotism is defined as the last > resort of the scoundrel. With all due respect to an enlightened but > inferior lexicographer I beg to submit that it is the first. > -- Ambrose Bierce, "The Devil's Dictionary" ------ +-------------------------------+---------------------------------------+ | Dan O'Reilly | | | Principal Engineer | "Why should I care about posterity? | | Process Software | What's posterity ever done for me?" | | http://www.process.com | -- Groucho Marx | +-------------------------------+---------------------------------------+ From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri May 10 15:21:16 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13244 for ; Fri, 10 May 2002 15:21:15 -0400 (EDT) Received: (qmail 20461 invoked by uid 605); 10 May 2002 19:21:21 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20453 invoked from network); 10 May 2002 19:21:19 -0000 Received: from node.061-0.ty.link.si (HELO levitator.1div0.com) (213.250.43.61) by mail.netbsd.org with SMTP; 10 May 2002 19:21:19 -0000 Received: from idiomatic (idiomatic [10.1.1.3]) by levitator.1div0.com (8.11.6/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id g4AJL7a30195 for ; Fri, 10 May 2002 21:21:12 +0200 Reply-To: From: "denis bider" To: Subject: solving the SFTP text mode issue Date: Fri, 10 May 2002 21:19:11 +0200 Message-ID: <000701c1f857$91246810$0301010a@idiomatic> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Judging from the number of times that text file support has been requested for SFTP, we might as well do something about it. I suggest that, in the next version of the filexfer draft, we document a recommended way for client software to do text file conversion. (On its own, of course, without any ugly hacks into the protocol.) What if we provide an SFTP command that the client could execute to learn the line separator on the server machine? We could then document a text file conversion algorithm such as the following: 1. The client queries the server about the server's line separator. 2. If the server's line separator is the same as the client's, the file is transferred in binary mode. 3. Otherwise, the client determines whether the file is textual using, for instance, the Kermit 8 algorithms mentioned by Jeffrey earlier on this list. If the file is textual, the client converts it. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri May 10 15:34:33 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13919 for ; Fri, 10 May 2002 15:34:32 -0400 (EDT) Received: (qmail 27478 invoked by uid 605); 10 May 2002 19:34:38 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27471 invoked from network); 10 May 2002 19:34:38 -0000 Received: from lespaul.process.com (192.42.95.27) by mail.netbsd.org with SMTP; 10 May 2002 19:34:38 -0000 Received: by lespaul.process.com with Internet Mail Service (5.5.2653.19) id ; Fri, 10 May 2002 15:36:22 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE86040AA376@lespaul.process.com> From: Richard Whalen To: ietf-ssh@netbsd.org Subject: RE: solving the SFTP text mode issue Date: Fri, 10 May 2002 15:36:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ietf-ssh-owner@netbsd.org Precedence: list Good suggestions, though the 'client' should not be required to understand text storage modes. Text file conversion is best handled by the routines that access the file on the system that the file is stored on. Doing it in the file access routines makes it such that an implementation only needs to understand its storage method(s) and the common storage method. Requiring the 'client' to do conversion would mean that the client would have to have information about storage methods for all systems that it desires to interoperate with included in its (the clients) implementation. Some methods do not have explicit line separator(s), but have an implicit line break and the end of each record stored. There may be additional binary information that varies between the individual records (lines). -----Original Message----- From: denis bider [mailto:ietf-ssh@denisbider.com] Sent: Friday, May 10, 2002 3:19 PM To: ietf-ssh@netbsd.org Subject: solving the SFTP text mode issue Judging from the number of times that text file support has been requested for SFTP, we might as well do something about it. I suggest that, in the next version of the filexfer draft, we document a recommended way for client software to do text file conversion. (On its own, of course, without any ugly hacks into the protocol.) What if we provide an SFTP command that the client could execute to learn the line separator on the server machine? We could then document a text file conversion algorithm such as the following: 1. The client queries the server about the server's line separator. 2. If the server's line separator is the same as the client's, the file is transferred in binary mode. 3. Otherwise, the client determines whether the file is textual using, for instance, the Kermit 8 algorithms mentioned by Jeffrey earlier on this list. If the file is textual, the client converts it. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri May 10 15:45:02 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14395 for ; Fri, 10 May 2002 15:45:01 -0400 (EDT) Received: (qmail 2219 invoked by uid 605); 10 May 2002 19:45:07 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2212 invoked from network); 10 May 2002 19:45:06 -0000 Received: from node.061-0.ty.link.si (HELO levitator.1div0.com) (213.250.43.61) by mail.netbsd.org with SMTP; 10 May 2002 19:45:06 -0000 Received: from idiomatic (idiomatic [10.1.1.3]) by levitator.1div0.com (8.11.6/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id g4AJj3a30261 for ; Fri, 10 May 2002 21:45:03 +0200 Reply-To: From: "denis bider" To: Subject: RE: solving the SFTP text mode issue Date: Fri, 10 May 2002 21:43:06 +0200 Message-ID: <000801c1f85a$e8bf97e0$0301010a@idiomatic> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <000701c1f857$91246810$0301010a@idiomatic> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > What if we provide an SFTP command that the client could > execute to learn the line separator on the server machine? I know that this doesn't take care of record-based text file formats, but it does take care of Unix, Windows, and Mac, which is much better than nothing, and is probably what most people want, anyway. As for record-based text file formats... The basic assumption of SFTP is that a file is a single binary block of data that may be manipulated however one wants. I simply don't see how this can be reconciled with record-based text files. SFTP simply wasn't designed with that in mind, and I for one wouldn't like to see the protocol retrofitted with alien concepts. I think that the extension that I suggested would be easy to define, easy to understand, easy to implement, and would satisfy the majority of users. In contrast, a universal solution that would also support record-based file formats would be much more complex and would force this complexity down the throats of the majority of people who have no need for it. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri May 10 15:51:05 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14609 for ; Fri, 10 May 2002 15:51:04 -0400 (EDT) Received: (qmail 6019 invoked by uid 605); 10 May 2002 19:51:10 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6012 invoked from network); 10 May 2002 19:51:10 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 10 May 2002 19:51:10 -0000 Received: from jurassic.eng.sun.com ([129.146.17.55]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA15375; Fri, 10 May 2002 12:51:06 -0700 (PDT) Received: from quirm (vpn-129-149-242-78.SFBay.Sun.COM [129.149.242.78]) by jurassic.eng.sun.com (8.12.3+Sun/8.12.3) with SMTP id g4AJoG93716150; Fri, 10 May 2002 12:50:39 -0700 (PDT) Message-Id: <200205101950.g4AJoG93716150@jurassic.eng.sun.com> Date: Fri, 10 May 2002 12:49:55 -0700 (PDT) From: Darren Moffat Reply-To: Darren Moffat Subject: RE: solving the SFTP text mode issue To: ietf-ssh@netbsd.org, denis.bider@denisbider.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: +cpS7P1dCInHtQC+rYd4Dw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Sender: ietf-ssh-owner@netbsd.org Precedence: list >> What if we provide an SFTP command that the client could >> execute to learn the line separator on the server machine? > >I know that this doesn't take care of record-based text file formats, but it >does take care of Unix, Windows, and Mac, which is much better than nothing, >and is probably what most people want, anyway. I'm not sure it does actually solve the probelm for MacOS X unless it is done on a per file basis. On MacOS X the line separator could be either UNIX style or Mac style depending on the creator of the file. I'm no Mac expert but I believe that information is easy to find out. -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri May 10 15:53:07 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14645 for ; Fri, 10 May 2002 15:53:07 -0400 (EDT) Received: (qmail 7027 invoked by uid 605); 10 May 2002 19:53:13 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7020 invoked from network); 10 May 2002 19:53:12 -0000 Received: from lespaul.process.com (192.42.95.27) by mail.netbsd.org with SMTP; 10 May 2002 19:53:12 -0000 Received: by lespaul.process.com with Internet Mail Service (5.5.2653.19) id ; Fri, 10 May 2002 15:54:57 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE86040AA378@lespaul.process.com> From: Richard Whalen To: "'ietf-ssh@netbsd.org'" Subject: RE: solving the SFTP text mode issue Date: Fri, 10 May 2002 15:54:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ietf-ssh-owner@netbsd.org Precedence: list > > As for record-based text file formats... The basic assumption > of SFTP is > that a file is a single binary block of data that may be > manipulated however > one wants. I simply don't see how this can be reconciled with > record-based > text files. SFTP simply wasn't designed with that in mind, > and I for one > wouldn't like to see the protocol retrofitted with alien concepts. > Then SFTP does not define a file Transfer protocol, it defines a file Access protocol. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri May 10 16:02:44 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15065 for ; Fri, 10 May 2002 16:02:43 -0400 (EDT) Received: (qmail 12613 invoked by uid 605); 10 May 2002 20:02:50 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12606 invoked from network); 10 May 2002 20:02:48 -0000 Received: from node.061-0.ty.link.si (HELO levitator.1div0.com) (213.250.43.61) by mail.netbsd.org with SMTP; 10 May 2002 20:02:48 -0000 Received: from idiomatic (idiomatic [10.1.1.3]) by levitator.1div0.com (8.11.6/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id g4AK2ea30303 for ; Fri, 10 May 2002 22:02:45 +0200 Reply-To: From: "denis bider" To: Subject: RE: solving the SFTP text mode issue Date: Fri, 10 May 2002 22:00:44 +0200 Message-ID: <000901c1f85d$5f0c67a0$0301010a@idiomatic> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <63D30D6E10CFD11190A90000F805FE86040AA376@lespaul.process.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > Text file conversion is best handled by the routines that > access the file on the system that the file is stored on. That is true, but I see no nice way to implement this in SFTP, because it clashes with SFTP's assumption that all files are binary. It is incompatible with SFTP's random-access concept. A perfect solution to the text-file issue probably requires a mechanism completely independent of SFTP's read/write operations. But an independent mechanism for text files seems like an overkill for implementations that will only interact with mainstream platforms anyway. I would prefer to have standardized a simple solution that solves the problem for the mainstream platforms, and let the exotic people implement their own complicated extensions that I don't need to support. Unless someone can come up with a really straightforward solution that covers exotic formats as well. Perhaps this can be done, but it will have to be done by an ingenious someone who is well-acquainted with those formats. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri May 10 16:05:00 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15156 for ; Fri, 10 May 2002 16:04:59 -0400 (EDT) Received: (qmail 14108 invoked by uid 605); 10 May 2002 20:05:05 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14101 invoked from network); 10 May 2002 20:05:04 -0000 Received: from mx1.eskimo.com (204.122.16.48) by mail.netbsd.org with SMTP; 10 May 2002 20:05:04 -0000 Received: from eskimo.com (root@eskimo.com [204.122.16.13]) by mx1.eskimo.com (8.9.1a/8.8.8) with ESMTP id NAA10414; Fri, 10 May 2002 13:05:01 -0700 Received: (from weidai@localhost) by eskimo.com (8.9.1a/8.9.1) id NAA18102; Fri, 10 May 2002 13:01:57 -0700 (PDT) Date: Fri, 10 May 2002 13:01:56 -0700 From: Wei Dai To: denis.bider@denisbider.com Cc: ietf-ssh@netbsd.org Subject: Re: solving the SFTP text mode issue Message-ID: <20020510130155.A9475@eskimo.com> References: <000701c1f857$91246810$0301010a@idiomatic> <000801c1f85a$e8bf97e0$0301010a@idiomatic> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <000801c1f85a$e8bf97e0$0301010a@idiomatic>; from ietf-ssh@denisbider.com on Fri, May 10, 2002 at 09:43:06PM +0200 Sender: ietf-ssh-owner@netbsd.org Precedence: list Here's another simple suggestion for your consideration. Define a new pflags flag for SSH_FXP_OPEN: #define SSH_FXF_TEXT 0x00000040 It would have the following meaning: SSH_FXF_TEXT File SHOULD be encoded as UTF-8 using either CR, LF, or CR/LF to indicate line end, or converted to this encoding before transfer. File access MUST be sequential. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri May 10 16:06:05 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15182 for ; Fri, 10 May 2002 16:06:04 -0400 (EDT) Received: (qmail 14830 invoked by uid 605); 10 May 2002 20:06:10 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14823 invoked from network); 10 May 2002 20:06:09 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 10 May 2002 20:06:09 -0000 Received: from [127.0.0.1] (HELO mail) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 663156; Fri, 10 May 2002 14:06:08 -0600 Received: from dogfood.vandyke.com ([192.168.0.3]) by mail (MailMonitor for SMTP v1.1.0 ) ; Fri, 10 May 2002 14:06:08 -0600 (Mountain Daylight Time) Message-ID: <036201c1f85d$3b3f3690$4d00a8c0@galb.vandyke.com> From: "Joseph Galbraith" To: "Darren Moffat" , , References: <200205101950.g4AJoG93716150@jurassic.eng.sun.com> Subject: Re: solving the SFTP text mode issue Date: Fri, 10 May 2002 13:59:45 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > >> What if we provide an SFTP command that the client could > >> execute to learn the line separator on the server machine? > > > >I know that this doesn't take care of record-based text file formats, but it > >does take care of Unix, Windows, and Mac, which is much better than nothing, > >and is probably what most people want, anyway. > > I'm not sure it does actually solve the probelm for MacOS X unless it is > done on a per file basis. On MacOS X the line separator could be either > UNIX style or Mac style depending on the creator of the file. I'm no > Mac expert but I believe that information is easy to find out. It is easy to find out the creator, but I'm not so sure finding out what line termination the creator is using is easy. Last time I worked on the Mac, the creator attribute of a file was a four byte field, set to things like 'TEXT' or 'WRTE' or whatever. But that doesn't really say anything about what newline convention the creator is using. I don't think the MacOS X problem can be solved even on the server side, because while the server can determine who create the file (or at list a 4 byte tag representing the creator), it can't know what the creator uses for new-line. I'd love to be wrong on this, and learn that MaxOS X stores an attribute that tells what the newline convention is. I'd also be surprised if unix apps living in the MaxOS X world maintain creator information, or, if the mythical 'newline' file attribute exists, that they maintain it. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri May 10 16:06:16 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15197 for ; Fri, 10 May 2002 16:06:15 -0400 (EDT) Received: (qmail 15170 invoked by uid 605); 10 May 2002 20:06:21 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15163 invoked from network); 10 May 2002 20:06:21 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 10 May 2002 20:06:21 -0000 Received: from [127.0.0.1] (HELO mail) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 663172; Fri, 10 May 2002 14:06:20 -0600 Received: from dogfood.vandyke.com ([192.168.0.3]) by mail (MailMonitor for SMTP v1.1.0 ) ; Fri, 10 May 2002 14:06:20 -0600 (Mountain Daylight Time) Message-ID: <036301c1f85d$42285130$4d00a8c0@galb.vandyke.com> From: "Joseph Galbraith" To: , References: <000701c1f857$91246810$0301010a@idiomatic> Subject: Re: solving the SFTP text mode issue Date: Fri, 10 May 2002 13:59:56 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > Judging from the number of times that text file support has been requested > for SFTP, we might as well do something about it. I suggest that, in the > next version of the filexfer draft, we document a recommended way for client > software to do text file conversion. (On its own, of course, without any > ugly hacks into the protocol.) > > What if we provide an SFTP command that the client could execute to learn > the line separator on the server machine? > > We could then document a text file conversion algorithm such as the > following: > 1. The client queries the server about the server's line separator. > 2. If the server's line separator is the same as the client's, the file is > transferred in binary mode. > 3. Otherwise, the client determines whether the file is textual using, for > instance, the Kermit 8 algorithms mentioned by Jeffrey earlier on this list. > If the file is textual, the client converts it. This is what our server (and clients) do as an sftp connection. The server sends as part of it's init packet "new-line@vandyke.com" "\r\n" And the clients look for this to know what to do with files that are text. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri May 10 16:06:27 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15214 for ; Fri, 10 May 2002 16:06:26 -0400 (EDT) Received: (qmail 15811 invoked by uid 605); 10 May 2002 20:06:33 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15804 invoked from network); 10 May 2002 20:06:31 -0000 Received: from node.061-0.ty.link.si (HELO levitator.1div0.com) (213.250.43.61) by mail.netbsd.org with SMTP; 10 May 2002 20:06:31 -0000 Received: from idiomatic (idiomatic [10.1.1.3]) by levitator.1div0.com (8.11.6/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id g4AK6Ra30334 for ; Fri, 10 May 2002 22:06:28 +0200 Reply-To: From: "denis bider" To: Subject: RE: solving the SFTP text mode issue Date: Fri, 10 May 2002 22:04:31 +0200 Message-ID: <000a01c1f85d$e671cff0$0301010a@idiomatic> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <63D30D6E10CFD11190A90000F805FE86040AA378@lespaul.process.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > Then SFTP does not define a file Transfer protocol, > it defines a file Access protocol. YES! That is entirely correct. The commonly used term 'SFTP' is a horrible misnomer. I think we should document that somewhere, and perhaps also provide a less misleading official name. (Not 'filexfer'.) From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri May 10 16:13:36 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15442 for ; Fri, 10 May 2002 16:13:35 -0400 (EDT) Received: (qmail 19094 invoked by uid 605); 10 May 2002 20:13:40 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19085 invoked from network); 10 May 2002 20:13:39 -0000 Received: from raptor.psccos.com (207.225.29.51) by mail.netbsd.org with SMTP; 10 May 2002 20:13:39 -0000 Received: from ntbsod.process.com ([207.225.29.50]) by RAPTOR.PSCCOS.COM (PMDF V6.1 #36649) with ESMTPA id <01KHKDBDPONS8WWKMA@RAPTOR.PSCCOS.COM> for ietf-ssh@netbsd.org; Fri, 10 May 2002 14:13:36 -0700 (MST) Date: Fri, 10 May 2002 14:13:33 -0600 From: "Dan O'Reilly" Subject: RE: solving the SFTP text mode issue In-reply-to: <000901c1f85d$5f0c67a0$0301010a@idiomatic> X-Sender: oreilly@raptor.psccos.com To: denis.bider@denisbider.com Cc: ietf-ssh@netbsd.org Message-id: <5.1.0.14.2.20020510140707.00afc120@raptor.psccos.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Content-type: text/plain; format=flowed; charset=us-ascii References: <63D30D6E10CFD11190A90000F805FE86040AA376@lespaul.process.com> Sender: ietf-ssh-owner@netbsd.org Precedence: list At 02:00 PM 5/10/2002, denis bider wrote: > > Text file conversion is best handled by the routines that > > access the file on the system that the file is stored on. > >That is true, but I see no nice way to implement this in SFTP, because it >clashes with SFTP's assumption that all files are binary. It is incompatible >with SFTP's random-access concept. Perhaps this means that the fundamental concept was flawed...? >A perfect solution to the text-file issue probably requires a mechanism >completely independent of SFTP's read/write operations. But an independent >mechanism for text files seems like an overkill for implementations that >will only interact with mainstream platforms anyway. Ah, the chauvinism shows through. The issues being raised here are by real, live customers who need to make their UNIX systems interact with VMS platforms, not just between VMS platforms. Unless, of course, UNIX is gone from "mainstream" now. And by the way, I suggest you revisit your definition of "mainstream" after reviewing all the critical applications that exist and will continue to exist on VMS platforms in critical industries that REQUIRE security, such as banking, manufacturing and communications. But platform bias aside, the implementation of an adequate mechanism seems to be only moderately difficult. Why not take a chance and make a standard a REAL standard, not just one that applies to selective platforms? >I would prefer to have standardized a simple solution that solves the >problem for the mainstream platforms, and let the exotic people implement >their own complicated extensions that I don't need to support. "I don't need to support"? Hmmm...why is constant support required, once the standard is established and the basic coding complete? Surely aside from minimal maintenance, this would not be the support nightmare you seem to make it out to be. And text format files hardly qualify as "exotic". ------ +-------------------------------+---------------------------------------+ | Dan O'Reilly | | | Principal Engineer | "Why should I care about posterity? | | Process Software | What's posterity ever done for me?" | | http://www.process.com | -- Groucho Marx | +-------------------------------+---------------------------------------+ From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri May 10 16:16:20 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15511 for ; Fri, 10 May 2002 16:16:20 -0400 (EDT) Received: (qmail 20934 invoked by uid 605); 10 May 2002 20:16:05 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20729 invoked from network); 10 May 2002 20:15:58 -0000 Received: from pianosa.catch22.org (64.81.48.19) by mail.netbsd.org with SMTP; 10 May 2002 20:15:58 -0000 Received: by pianosa.catch22.org (Postfix, from userid 1000) id EF2092FA; Fri, 10 May 2002 13:15:57 -0700 (PDT) Date: Fri, 10 May 2002 13:15:57 -0700 From: David Terrell To: denis.bider@denisbider.com Cc: ietf-ssh@netbsd.org Subject: Re: solving the SFTP text mode issue Message-ID: <20020510131557.A11467@pianosa.catch22.org> Reply-To: David Terrell References: <63D30D6E10CFD11190A90000F805FE86040AA378@lespaul.process.com> <000a01c1f85d$e671cff0$0301010a@idiomatic> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <000a01c1f85d$e671cff0$0301010a@idiomatic>; from ietf-ssh@denisbider.com on Fri, May 10, 2002 at 10:04:31PM +0200 X-vi: Version 1.79 (10/23/96) The CSRG, University of California, Berkeley. X-Nethack: You feel like someone is making a pointless Nethack reference.--More-- X-Uptime: 1:14PM up 23 days, 17:58, 44 users, load averages: 0.89, 0.62, 0.65 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Fri, May 10, 2002 at 10:04:31PM +0200, denis bider wrote: > > Then SFTP does not define a file Transfer protocol, > > it defines a file Access protocol. > > YES! That is entirely correct. > > The commonly used term 'SFTP' is a horrible misnomer. I think we should > document that somewhere, and perhaps also provide a less misleading official > name. (Not 'filexfer'.) Considering that this is already a solved problem by one protocol out there, why don't we just define another subsystem (we might as well have _two_, oh boy) for Kermit and be done with it? -- David Terrell | Just another satan-worshipping Harry Potter reader. dbt@meat.net | Nebcorp Prime Minister | http://wwn.nebcorp.com | From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri May 10 16:30:11 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15953 for ; Fri, 10 May 2002 16:30:10 -0400 (EDT) Received: (qmail 609 invoked by uid 605); 10 May 2002 20:30:16 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 602 invoked from network); 10 May 2002 20:30:15 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 10 May 2002 20:30:15 -0000 Received: from [127.0.0.1] (HELO mail) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 663282 for ietf-ssh@netbsd.org; Fri, 10 May 2002 14:30:14 -0600 Received: from dogfood.vandyke.com ([192.168.0.3]) by mail (MailMonitor for SMTP v1.1.0 ) ; Fri, 10 May 2002 14:30:14 -0600 (Mountain Daylight Time) Message-ID: <038901c1f860$98bdf7e0$4d00a8c0@galb.vandyke.com> From: "Joseph Galbraith" To: Subject: Fw: solving the SFTP text mode issue Date: Fri, 10 May 2002 14:23:50 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Whoops, forgot my reply all button. - Joseph ----- Original Message ----- From: "Joseph Galbraith" To: Sent: Friday, May 10, 2002 14:23 Subject: Re: solving the SFTP text mode issue > > > Text file conversion is best handled by the routines that > > > access the file on the system that the file is stored on. > > > > That is true, but I see no nice way to implement this in SFTP, because it > > clashes with SFTP's assumption that all files are binary. It is > incompatible > > with SFTP's random-access concept. > > > > A perfect solution to the text-file issue probably requires a mechanism > > completely independent of SFTP's read/write operations. But an independent > > mechanism for text files seems like an overkill for implementations that > > will only interact with mainstream platforms anyway. > > > > I would prefer to have standardized a simple solution that solves the > > problem for the mainstream platforms, and let the exotic people implement > > their own complicated extensions that I don't need to support. > > > > Unless someone can come up with a really straightforward solution that > > covers exotic formats as well. Perhaps this can be done, but it will have > to > > be done by an ingenious someone who is well-acquainted with those formats. > > Hmm... I guess we could add > > SSH_FXP_READ_RECORD > uint32 start record number > uint32 number of records to read > > and the response would be > SSH_FXP_RECORD > uint32 start record number > string record[n] > > and > SSH_FXP_WRITE_RECORD > uint32 start record number > uint32 number of records to write > string record[n] > > and a flag to open a file in record mode. > SSH_FXF_RECORD_ORIENTED. > > Openning a text file in record mode would > resulting in recieveing each line as a > seperate record with no termination. > > A server could refuse to open an existing > file in record mode if it couldn't figure > out how to. > > I'm not sure I'm really advocating this > approach ... I haven't thought about it > for more than ten minutes... but it does > seem like it could solve the more > general problem? > > - Joseph > From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri May 10 16:30:33 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15984 for ; Fri, 10 May 2002 16:30:32 -0400 (EDT) Received: (qmail 1256 invoked by uid 605); 10 May 2002 20:30:39 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1248 invoked from network); 10 May 2002 20:30:38 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 10 May 2002 20:30:38 -0000 Received: from [127.0.0.1] (HELO mail) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 663286 for ietf-ssh@netbsd.org; Fri, 10 May 2002 14:30:37 -0600 Received: from dogfood.vandyke.com ([192.168.0.3]) by mail (MailMonitor for SMTP v1.1.0 ) ; Fri, 10 May 2002 14:30:37 -0600 (Mountain Daylight Time) Message-ID: <038e01c1f860$a6c21290$4d00a8c0@galb.vandyke.com> From: "Joseph Galbraith" To: Subject: Fw: solving the SFTP text mode issue Date: Fri, 10 May 2002 14:24:13 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Forgot it twice... - Joseph ----- Original Message ----- From: "Joseph Galbraith" To: Sent: Friday, May 10, 2002 14:14 Subject: Re: solving the SFTP text mode issue > > > Then SFTP does not define a file Transfer protocol, > > > it defines a file Access protocol. > > > > YES! That is entirely correct. > > > > The commonly used term 'SFTP' is a horrible misnomer. I think we should > > document that somewhere, and perhaps also provide a less misleading > official > > name. (Not 'filexfer'.) > > I concur. We need a new name. > "SSH Secure File Access Protocol - SFAP" > Well, that's just off the top of my head, > and maybe not the best idea in the world. > > If SFTP was really file transfer protocol > we would have operations like: > > SFTP_GET_FILE > uint32 request id > string file_path > uint32 starting offset > > and the response would be an arbitrary number of > SFTP_DATA packets followed by a status packet > > SFTP_DATA [n] > uint32 request id > string file_data > > SFTP_STATUS > uint32 request id > uint32 status > string text > string language. > > Joseph > From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri May 10 17:05:53 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17719 for ; Fri, 10 May 2002 17:05:53 -0400 (EDT) Received: (qmail 18168 invoked by uid 605); 10 May 2002 21:05:59 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18160 invoked from network); 10 May 2002 21:05:57 -0000 Received: from node.061-0.ty.link.si (HELO levitator.1div0.com) (213.250.43.61) by mail.netbsd.org with SMTP; 10 May 2002 21:05:57 -0000 Received: from idiomatic (idiomatic [10.1.1.3]) by levitator.1div0.com (8.11.6/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id g4AL5pa30505 for ; Fri, 10 May 2002 23:05:52 +0200 Reply-To: From: "denis bider" To: Subject: RE: solving the SFTP text mode issue Date: Fri, 10 May 2002 23:03:55 +0200 Message-ID: <000f01c1f866$32bc2bf0$0301010a@idiomatic> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <5.1.0.14.2.20020510140707.00afc120@raptor.psccos.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > > That is true, but I see no nice way to implement this in SFTP, > > because it clashes with SFTP's assumption that all files are > > binary. It is incompatible with SFTP's random-access concept. > > Perhaps this means that the fundamental concept was flawed...? I don't think SFTP's fundamental concept is flawed. On the contrary, I find it very appealing. It makes possible things that aren't at all possible with protocols that can only transfer a whole file at a time. The disadvantage of SFTP's design is that it assumes files to be binary, and this makes the protocol less suitable for files that are not. > Ah, the chauvinism shows through. [...] "I don't need to > support"? Hmmm...why is constant support required, once > the standard is established and the basic coding complete? I don't see why you need to be so bitter. It's not like I'm forcing anything down your throat. I'm just expressing my point of view, and that point of view isn't solid, but is updated by each new argument that you contribute. > But platform bias aside, the implementation of an adequate > mechanism seems to be only moderately difficult. Why not > take a chance and make a standard a REAL standard, not just > one that applies to selective platforms? Sure, why not? But people like you must take initiative and/or provide feedback, otherwise the problem won't be solved. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri May 10 17:21:19 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18507 for ; Fri, 10 May 2002 17:21:17 -0400 (EDT) Received: (qmail 26827 invoked by uid 605); 10 May 2002 21:21:24 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26820 invoked from network); 10 May 2002 21:21:23 -0000 Received: from raptor.psccos.com (207.225.29.51) by mail.netbsd.org with SMTP; 10 May 2002 21:21:23 -0000 Received: from ntbsod.process.com ([207.225.29.50]) by RAPTOR.PSCCOS.COM (PMDF V6.1 #36649) with ESMTPA id <01KHKFODG7NI8WWKMA@RAPTOR.PSCCOS.COM> for ietf-ssh@netbsd.org; Fri, 10 May 2002 15:21:20 -0700 (MST) Date: Fri, 10 May 2002 15:20:17 -0600 From: "Dan O'Reilly" Subject: RE: solving the SFTP text mode issue In-reply-to: <000f01c1f866$32bc2bf0$0301010a@idiomatic> X-Sender: oreilly@raptor.psccos.com To: denis.bider@denisbider.com Cc: ietf-ssh@netbsd.org Message-id: <5.1.0.14.2.20020510150707.00af2198@raptor.psccos.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Content-type: text/plain; format=flowed; charset=us-ascii References: <5.1.0.14.2.20020510140707.00afc120@raptor.psccos.com> Sender: ietf-ssh-owner@netbsd.org Precedence: list At 03:03 PM 5/10/2002, denis bider wrote: > > > That is true, but I see no nice way to implement this in SFTP, > > > because it clashes with SFTP's assumption that all files are > > > binary. It is incompatible with SFTP's random-access concept. > > > > Perhaps this means that the fundamental concept was flawed...? > >I don't think SFTP's fundamental concept is flawed. On the contrary, I find >it very appealing. It makes possible things that aren't at all possible with >protocols that can only transfer a whole file at a time. It's very obvious that the fundamental concept is based on the idea that any file can be transferred intact and not require translation via a fixed-length block format. 99.999% of the time, it's because the people doing the basic conceptual design don't know anything save for UNIX and occasionally, Windows. That's not a liability on their part (nobody knows everything about everything), but it does translate, at least in this case, to a liability on behalf of the concept which emerged. So now we have (at least, some of us believe, and not just people within my company) an expressed and rational reason why the concept is flawed, and why in needs to be reexamined and updated. The reaction: it's "exotic". It's not "mainstream". After all, the basic concept CAN'T be flawed! >The disadvantage of SFTP's design is that it assumes files to be binary, and >this makes the protocol less suitable for files that are not. Exactly - and this is the reason the design needs to be enhanced. > > But platform bias aside, the implementation of an adequate > > mechanism seems to be only moderately difficult. Why not > > take a chance and make a standard a REAL standard, not just > > one that applies to selective platforms? > >Sure, why not? But people like you must take initiative and/or provide >feedback, otherwise the problem won't be solved. It sounds, by the tone of your recent messages on this subject, that there's no problem to be solved, as everything outside the original concept for SFTP is an "exotic" or "outside of mainstream" system, and hence, not worth supporting. And along with we of the VMS world, I suspect that those in, for instance, the mainframe world would disagree with your definition and labelling of "exotic" and "mainstream". And hence, my responses to your messages. We are more than willing to work to see this issue gets addressed; what we expect is that the chauvinism be put on the back burner and move on to the problem at hand. If there are valid TECHNICAL reasons for something not to be done, so be it. But to label things outside of Windows or UNIX as "exotic" and "out of the mainstream" is counter-productive to getting anything changed. In other words, let's work the problem rather than label things you don't see the case for in a pejorative sense. The goal here is not to make this a VMS-centric protocol; rather, it's to ensure that VMS can participate fully in all transactions without regard to the file format. And that's simply not the case today, given the current state of the protocol. ------ +-------------------------------+---------------------------------------+ | Dan O'Reilly | | | Principal Engineer | "Why should I care about posterity? | | Process Software | What's posterity ever done for me?" | | http://www.process.com | -- Groucho Marx | +-------------------------------+---------------------------------------+ From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri May 10 17:22:33 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18593 for ; Fri, 10 May 2002 17:22:33 -0400 (EDT) Received: (qmail 27839 invoked by uid 605); 10 May 2002 21:22:40 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27830 invoked from network); 10 May 2002 21:22:37 -0000 Received: from node.061-0.ty.link.si (HELO levitator.1div0.com) (213.250.43.61) by mail.netbsd.org with SMTP; 10 May 2002 21:22:37 -0000 Received: from idiomatic (idiomatic [10.1.1.3]) by levitator.1div0.com (8.11.6/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id g4ALMUa30546 for ; Fri, 10 May 2002 23:22:31 +0200 Reply-To: From: "denis bider" To: Subject: RE: solving the SFTP text mode issue Date: Fri, 10 May 2002 23:20:34 +0200 Message-ID: <001001c1f868$861c66a0$0301010a@idiomatic> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <038901c1f860$98bdf7e0$4d00a8c0@galb.vandyke.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > SSH_FXP_READ_RECORD > uint32 start record number > uint32 number of records to read > > Openning a text file in record mode would > resulting in recieveing each line as a > seperate record with no termination. Doesn't sound half bad... Seeking to the middle of an LF-separated text file would require the server to manually count the lines, but I guess this isn't really a problem if we consider that the other possibilities don't offer random access in the first place. Also, we might offer a special record number, e.g. -1, for use with SSH_FXP_WRITE_RECORD to indicate that the record is to be appended. Or perhaps we could simply provide another packet type called SSH_FXP_APPEND_RECORD. How does this solution resonate with you all VMS people? From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri May 10 17:28:41 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19119 for ; Fri, 10 May 2002 17:28:39 -0400 (EDT) Received: (qmail 1838 invoked by uid 605); 10 May 2002 21:28:45 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1831 invoked from network); 10 May 2002 21:28:44 -0000 Received: from raptor.psccos.com (207.225.29.51) by mail.netbsd.org with SMTP; 10 May 2002 21:28:44 -0000 Received: from ntbsod.process.com ([207.225.29.50]) by RAPTOR.PSCCOS.COM (PMDF V6.1 #36649) with ESMTPA id <01KHKFXHEK5W8WWKMA@RAPTOR.PSCCOS.COM> for ietf-ssh@netbsd.org; Fri, 10 May 2002 15:28:41 -0700 (MST) Date: Fri, 10 May 2002 15:28:37 -0600 From: "Dan O'Reilly" Subject: RE: solving the SFTP text mode issue In-reply-to: <001001c1f868$861c66a0$0301010a@idiomatic> X-Sender: oreilly@raptor.psccos.com To: denis.bider@denisbider.com Cc: ietf-ssh@netbsd.org Message-id: <5.1.0.14.2.20020510152327.090160f0@raptor.psccos.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Content-type: text/plain; format=flowed; charset=us-ascii References: <038901c1f860$98bdf7e0$4d00a8c0@galb.vandyke.com> Sender: ietf-ssh-owner@netbsd.org Precedence: list At 03:20 PM 5/10/2002, denis bider wrote: > > SSH_FXP_READ_RECORD > > uint32 start record number > > uint32 number of records to read > > > > Openning a text file in record mode would > > resulting in recieveing each line as a > > seperate record with no termination. > >Doesn't sound half bad... Seeking to the middle of an LF-separated text file >would require the server to manually count the lines, but I guess this isn't >really a problem if we consider that the other possibilities don't offer >random access in the first place. > >Also, we might offer a special record number, e.g. -1, for use with >SSH_FXP_WRITE_RECORD to indicate that the record is to be appended. Or >perhaps we could simply provide another packet type called >SSH_FXP_APPEND_RECORD. > >How does this solution resonate with you all VMS people? I think it's close. There are 3 main fundamental formats we must deal with: - Stream LF (i.e., "UNIX" mode) - delimited, variable-length records (usually, CR/LF pairs) - variable-length records with a fixed-length binary record-size field at the beginning of each record There are other permutations of text files in VMS, but they're basically "variations on a theme", in that they're a derivation of one of the above formats, and so what works for the above should work for them as well. So, this solution would seem to apply to the 2nd format (the first format is obviously handled today), but I'm not sure of the 3rd format. We would need to examine this proposal and see what the implications are. ------ +-------------------------------+---------------------------------------+ | Dan O'Reilly | | | Principal Engineer | "Why should I care about posterity? | | Process Software | What's posterity ever done for me?" | | http://www.process.com | -- Groucho Marx | +-------------------------------+---------------------------------------+ From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri May 10 17:41:27 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19893 for ; Fri, 10 May 2002 17:41:26 -0400 (EDT) Received: (qmail 8307 invoked by uid 605); 10 May 2002 21:41:28 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8300 invoked from network); 10 May 2002 21:41:27 -0000 Received: from node.061-0.ty.link.si (HELO levitator.1div0.com) (213.250.43.61) by mail.netbsd.org with SMTP; 10 May 2002 21:41:27 -0000 Received: from idiomatic (idiomatic [10.1.1.3]) by levitator.1div0.com (8.11.6/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id g4ALfOa30589 for ; Fri, 10 May 2002 23:41:24 +0200 Reply-To: From: "denis bider" To: Subject: renaming SFTP to... Date: Fri, 10 May 2002 23:39:27 +0200 Message-ID: <001201c1f86b$29ac9590$0301010a@idiomatic> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <038e01c1f860$a6c21290$4d00a8c0@galb.vandyke.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > I concur. We need a new name. > "SSH Secure File Access Protocol - SFAP" I thought of that, but it sounds too much like "SPAM". :) I suggest FMP for 'File Manipulation Protocol'. The acronym would sound reasonably well, and the name wouldn't include the word 'Secure' because the protocol can run over anything and doesn't itself provide any security. [Please disregard my earlier message with the same subject if it arrives. It appears it got scheduled for moderator approval because I forgot to use the right email address.] From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri May 10 17:49:03 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20255 for ; Fri, 10 May 2002 17:49:02 -0400 (EDT) Received: (qmail 11439 invoked by uid 605); 10 May 2002 21:49:09 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11432 invoked from network); 10 May 2002 21:49:08 -0000 Received: from nuinfo.northwestern.edu (129.105.212.72) by mail.netbsd.org with SMTP; 10 May 2002 21:49:08 -0000 Received: (from lunde@localhost) by nuinfo.northwestern.edu (8.8.8/8.8.8) id QAA20599; Fri, 10 May 2002 16:49:07 -0500 (CDT) Message-Id: <200205102149.QAA20599@nuinfo.northwestern.edu> Subject: Re: solving the SFTP text mode issue To: ietf-ssh@netbsd.org Date: Fri, 10 May 2002 16:49:06 CDT In-Reply-To: <036201c1f85d$3b3f3690$4d00a8c0@galb.vandyke.com>; from "Joseph Galbraith" at May 10, 2002 1:59 pm From: Albert-Lunde@northwestern.edu (Albert Lunde) Reply-To: Albert-Lunde@northwestern.edu (Albert Lunde) X-Mailer: Elm [revision: 212.5] Sender: ietf-ssh-owner@netbsd.org Precedence: list > I don't think the MacOS X problem can be solved even > on the server side, because while the server can > determine who create the file (or at list a 4 byte > tag representing the creator), it can't know what the > creator uses for new-line. I'd love to be wrong > on this, and learn that MaxOS X stores an attribute > that tells what the newline convention is. As far as I know, there's no global convention for storing end-of-line representation. A counter-examples of sorts, is BBedit, which will default to any of the big-three end-of-line representations, as configured, and optionally store that fact in an application-specific resource. Ugly hacks might be required to determine end-of-line representation (or character encoding, or text vs. binary files) in the general case. (It seems to be that this is one more reason to keep any ugly hacks on the platform where the problem exists, (rather put lots of varients into a wire protocol for a text mode) and to make support for a text mode transfer optional.) -- Albert Lunde Albert-Lunde@northwestern.edu (new address) Albert-Lunde@nwu.edu (old address) From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri May 10 17:54:39 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20447 for ; Fri, 10 May 2002 17:54:39 -0400 (EDT) Received: (qmail 14387 invoked by uid 605); 10 May 2002 21:54:46 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14376 invoked from network); 10 May 2002 21:54:41 -0000 Received: from node.061-0.ty.link.si (HELO levitator.1div0.com) (213.250.43.61) by mail.netbsd.org with SMTP; 10 May 2002 21:54:41 -0000 Received: from idiomatic (idiomatic [10.1.1.3]) by levitator.1div0.com (8.11.6/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id g4ALsWa30628 for ; Fri, 10 May 2002 23:54:37 +0200 Reply-To: From: "denis bider" To: Subject: RE: solving the SFTP text mode issue Date: Fri, 10 May 2002 23:52:35 +0200 Message-ID: <001301c1f86c$ff5e2180$0301010a@idiomatic> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <5.1.0.14.2.20020510152327.090160f0@raptor.psccos.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > > How does this solution resonate with you all VMS people? > > variable-length records with a fixed-length binary record-size > field at the beginning of each record > > So, this solution would seem to apply to the 2nd format (the > first format is obviously handled today), but I'm not sure of > the 3rd format. What could be the problem? Random access? If so, then perhaps Wei's suggestion is best - simply open the file in "text mode", translate the lines to be LF-terminated if necessary, and enforce sequential access. Perhaps provide another mode for appending to the file, and that's it. How does that sound in the VMS context? As said, you VMS people must contribute actively, otherwise we'll just implement something that works on Windows, et voila. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri May 10 18:00:52 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA20633 for ; Fri, 10 May 2002 18:00:52 -0400 (EDT) Received: (qmail 17069 invoked by uid 605); 10 May 2002 22:00:58 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17062 invoked from network); 10 May 2002 22:00:54 -0000 Received: from raptor.psccos.com (207.225.29.51) by mail.netbsd.org with SMTP; 10 May 2002 22:00:54 -0000 Received: from ntbsod.process.com ([207.225.29.50]) by RAPTOR.PSCCOS.COM (PMDF V6.1 #36649) with ESMTPA id <01KHKH2CPXXG8WWKMA@RAPTOR.PSCCOS.COM> for ietf-ssh@netbsd.org; Fri, 10 May 2002 16:00:51 -0700 (MST) Date: Fri, 10 May 2002 16:00:22 -0600 From: "Dan O'Reilly" Subject: RE: solving the SFTP text mode issue In-reply-to: <001301c1f86c$ff5e2180$0301010a@idiomatic> X-Sender: oreilly@raptor.psccos.com To: denis.bider@denisbider.com Cc: ietf-ssh@netbsd.org Message-id: <5.1.0.14.2.20020510155909.00ac96b8@raptor.psccos.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Content-type: text/plain; format=flowed; charset=us-ascii References: <5.1.0.14.2.20020510152327.090160f0@raptor.psccos.com> Sender: ietf-ssh-owner@netbsd.org Precedence: list At 03:52 PM 5/10/2002, denis bider wrote: > > > How does this solution resonate with you all VMS people? > > > > variable-length records with a fixed-length binary record-size > > field at the beginning of each record > > > > So, this solution would seem to apply to the 2nd format (the > > first format is obviously handled today), but I'm not sure of > > the 3rd format. > >What could be the problem? Random access? > >If so, then perhaps Wei's suggestion is best - simply open the file in "text >mode", translate the lines to be LF-terminated if necessary, and enforce >sequential access. Perhaps provide another mode for appending to the file, >and that's it. > >How does that sound in the VMS context? > >As said, you VMS people must contribute actively, otherwise we'll just >implement something that works on Windows, et voila. and as I already said, we have to study it to make sure it's a good solution. We'll provide an answer when we have one, rather than just jumping off without thinking it through. ------ +-------------------------------+---------------------------------------+ | Dan O'Reilly | | | Principal Engineer | "Why should I care about posterity? | | Process Software | What's posterity ever done for me?" | | http://www.process.com | -- Groucho Marx | +-------------------------------+---------------------------------------+ From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri May 10 18:03:08 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA20745 for ; Fri, 10 May 2002 18:03:07 -0400 (EDT) Received: (qmail 19650 invoked by uid 605); 10 May 2002 22:03:09 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19643 invoked from network); 10 May 2002 22:03:07 -0000 Received: from watsun.cc.columbia.edu (128.59.39.2) by mail.netbsd.org with SMTP; 10 May 2002 22:03:07 -0000 Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id SAA17165; Fri, 10 May 2002 18:03:05 -0400 (EDT) Date: Fri, 10 May 2002 18:03:04 EDT From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: Albert-Lunde@northwestern.edu (Albert Lunde) Cc: ietf-ssh@netbsd.org Subject: Re: solving the SFTP text mode issue In-Reply-To: Your message of Fri, 10 May 2002 16:49:06 CDT Message-ID: Sender: ietf-ssh-owner@netbsd.org Precedence: list > > I don't think the MacOS X problem can be solved even > > on the server side, because while the server can > > determine who create the file (or at list a 4 byte > > tag representing the creator), it can't know what the > > creator uses for new-line. I'd love to be wrong > > on this, and learn that MaxOS X stores an attribute > > that tells what the newline convention is. > > As far as I know, there's no global convention for storing > end-of-line representation. A counter-examples of sorts, is > BBedit, which will default to any of the big-three end-of-line > representations, as configured, and optionally store that > fact in an application-specific resource. > > Ugly hacks might be required to determine end-of-line representation > (or character encoding, or text vs. binary files) in the general case. > > (It seems to be that this is one more reason to keep any ugly hacks > on the platform where the problem exists, (rather put lots of varients > into a wire protocol for a text mode) and to make support for a text mode > transfer optional.) > You do not need to have a bit that indicates the end of line format for a file. This can be determined along with the classification of character set by performing a file scan prior to the transfer. For example in C-Kermit 8.0 the output of DIR /XFERMODE for an arbitrary directory might look like: 1024 2000-09-15 03:46:16 .rnd (B) 1156 2001-09-21 11:36:08 adm3.txt (T)(7BIT) 219417 1999-09-11 11:31:34 all-escapes.txt (T)(7BIT) 40960 1998-12-12 09:16:46 apartm~1.doc (B) 262 1997-12-11 15:38:28 as400.txt (T)(7BIT) 147728 1999-11-18 12:04:00 ASYCFILT.DLL (B) 194 1999-09-10 12:25:22 authtest.ksc (T)(7BIT) 28745 1998-06-17 00:00:00 AUTOLAYT.DLL (B) 4559 1999-05-19 16:59:20 autotelnet.ksc (T)(7BIT) 18 2000-03-29 16:26:50 badprint.ksc (T)(7BIT) 531 1998-12-28 10:10:26 books.txt (T)(7BIT) 832 2001-10-19 18:02:40 bounce.bat (T)(7BIT) 2150 2001-03-10 08:53:56 console.reg (T)(UCS2LE) 4252 1999-12-07 20:07:12 COPYING.TXT (T)(7BIT) 3595 1999-12-08 17:19:52 crypto.html (T)(7BIT) 307 1999-10-13 14:42:24 url.c (T)(7BIT) 13398 2000-09-03 12:58:12 utf-8-demo.txt (T)(UTF8) 20263 2000-09-03 12:58:04 utf-8-test.txt (B) 801 1995-10-23 18:29:28 validate.cmd (T)(7BIT) This is all computed by performing scans of the files at runtime. C-Kermit then allows you to set default character sets to use for 7-bit and 8-bit files as well as specifying a transfer character set. The transfer character-set would be UTF8 or some other Unicode Transform. For details see http://www.kermit-project.org/ckermit80.html#x4 Jeffrey Altman * Sr.Software Designer Kermit 95 1.1.21 available now!!! The Kermit Project @ Columbia University SSH plus Telnet, FTP and HTTP http://www.kermit-project.org/ secured with Kerberos, SRP, and kermit-support@columbia.edu OpenSSL. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri May 10 18:28:17 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21280 for ; Fri, 10 May 2002 18:28:16 -0400 (EDT) Received: (qmail 2320 invoked by uid 605); 10 May 2002 22:28:23 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2313 invoked from network); 10 May 2002 22:28:22 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 10 May 2002 22:28:22 -0000 Received: from [127.0.0.1] (HELO mail) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 663574; Fri, 10 May 2002 16:28:21 -0600 Received: from chaos.vandyke.com ([192.168.0.77]) by mail (MailMonitor for SMTP v1.1.0 ) ; Fri, 10 May 2002 16:28:21 -0600 (Mountain Daylight Time) Message-ID: <03fb01c1f871$18e24740$4d00a8c0@galb.vandyke.com> From: "Joseph Galbraith" To: "Dan O'Reilly" , Cc: References: <038901c1f860$98bdf7e0$4d00a8c0@galb.vandyke.com> <5.1.0.14.2.20020510152327.090160f0@raptor.psccos.com> Subject: Re: solving the SFTP text mode issue Date: Fri, 10 May 2002 16:21:56 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > I think it's close. There are 3 main fundamental formats we must deal > with: > > - Stream LF (i.e., "UNIX" mode) > - delimited, variable-length records (usually, CR/LF pairs) > - variable-length records with a fixed-length binary record-size field > at the beginning of each record > > There are other permutations of text files in VMS, but they're basically > "variations on a theme", in that they're a derivation of one of the above > formats, and so what works for the above should work for them as well. > > So, this solution would seem to apply to the 2nd format (the first format > is obviously handled today), but I'm not sure of the 3rd format. We would > need to examine this proposal and see what the implications are. My model of the world in creating this was: 1. Binary files Protocol works as specified. 2. Record oriented files -- where record files have the following sub-cases: a. Fix length records b. Variable length records Variable length records might be either delimited or counted. In the delimited case, the delimiter doesn't really matter. It could be \n, \r, \r\n, or , -- it doesn't matter. (Both your stream LF and delimited variable-length records fit into this catagory.) The solution proposed works extremely well in the fixed length record cases -- in fact, I would say it is ideal. It provides, fast, efficient, random record based access. In the variable length record case, it isn't so great in terms of efficiency. The server would probably have to do some optimization -- for example, preread the file and record where the record breaks are, or, more likely, simply record where the last record ended and it's number, so sequential reads work well. Counted variable length maps pretty well, since each string in the array containing the records has its own count. I.e., on the wire it looks like: Byte SSH_FXP_RECORD uint32 32 # starting at record 32 uint32 3 # 3 records included uint32 45 # Record 32 is 45 bytes Byte[45] # The 45 bytes for record 32 uint32 143 # Record 33 is 143 BYTE[143] # The 143 bytes of data for recrd 33 uint32 1951 # Record 34 is 1951 bytes BYTE[1951] # The 1951 bytes of data for record 34 Delimited variable length records look to the client like counted records, so the client would probably need some other mechanism to recreate the original file attributes. I.e., something during stat that says this file is variable length, \r\n delimited. In addition, the delimited case has the additional challange that the server needs to determine what the delimiter is -- on VMS, it can probably retrieve that information from the file attributes. For the general case, we may want to add the additional flag: SSH_FXF_TEXT_MODE which implies RECORD_ORIENTED, variable length records, with the servers native newline character as the delimiter. - Joseph PS. Sorry Dan, I already sent this to you once-- I'm having a bad day with the 'reply all' thing. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri May 10 19:51:16 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA23291 for ; Fri, 10 May 2002 19:51:15 -0400 (EDT) Received: (qmail 8035 invoked by uid 605); 10 May 2002 23:51:20 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8028 invoked from network); 10 May 2002 23:51:19 -0000 Received: from node.061-0.ty.link.si (HELO levitator.1div0.com) (213.250.43.61) by mail.netbsd.org with SMTP; 10 May 2002 23:51:19 -0000 Received: from idiomatic (idiomatic [10.1.1.3]) by levitator.1div0.com (8.11.6/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id g4ANp9a31152 for ; Sat, 11 May 2002 01:51:10 +0200 Reply-To: From: "denis bider" To: Subject: RE: solving the SFTP text mode issue Date: Sat, 11 May 2002 01:51:09 +0200 Message-ID: <001501c1f87d$8f7933d0$0301010a@idiomatic> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <03fb01c1f871$18e24740$4d00a8c0@galb.vandyke.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > The solution proposed works extremely well in the > fixed length record cases -- in fact, I would say > it is ideal. It provides, fast, efficient, random > record based access. The question is: is there a need for random access to record-based files? After some consideration, I think that the READ_RECORD/WRITE_RECORD proposal is probably too enthusiastic. Implementing random access to files where records are lines of text will be difficult on most platforms. Most applications don't currently do random access in the first place, so it's hard to imagine it being done much with records. But if we dismiss random access, than the only remaining advantage of the readrecord/writerecord proposal is that it allows LF to be embedded in lines. I think that Wei's proposal is the most balanced of all I've considered today: - It does seem to support all kinds of text files reasonably well, including record-based text files. The latter is true as long as individual records don't contain LF characters, which I assume is reasonable to expect from a text file. - It is simple to implement on Windows and Unix. It resembles the approach taken by C/C++ standard libraries to solve the same problem. Translation between CRLF and LF is simple. No convoluted algorithms to support random access need to be implemented. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri May 10 20:04:32 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA23807 for ; Fri, 10 May 2002 20:04:31 -0400 (EDT) Received: (qmail 14173 invoked by uid 605); 11 May 2002 00:04:37 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14165 invoked from network); 11 May 2002 00:04:35 -0000 Received: from node.061-0.ty.link.si (HELO levitator.1div0.com) (213.250.43.61) by mail.netbsd.org with SMTP; 11 May 2002 00:04:35 -0000 Received: from idiomatic (idiomatic [10.1.1.3]) by levitator.1div0.com (8.11.6/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id g4B04Xa31184 for ; Sat, 11 May 2002 02:04:33 +0200 Reply-To: From: "denis bider" To: Subject: RE: renaming SFTP to... Date: Sat, 11 May 2002 02:04:33 +0200 Message-ID: <001601c1f87f$6e86fd40$0301010a@idiomatic> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <001201c1f86b$29ac9590$0301010a@idiomatic> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > I suggest FMP for 'File Manipulation Protocol'. > The acronym would sound reasonably well, and > the name wouldn't include the word 'Secure' > because the protocol can run over anything > and doesn't itself provide any security. Or perhaps: FXP - File Access Protocol RFX - Remote File Access (protocol) 'Access' sounds less awkward than 'Manipulation'. 'Management' also begins with M, but seems to carry a different meaning (managing whole files rather than their contents). Also, acronyms containing the letter X usually sound more seXy. Any votes? My vote currently goes to RFX, mainly because it sounds better. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri May 10 20:29:16 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA24767 for ; Fri, 10 May 2002 20:29:13 -0400 (EDT) Received: (qmail 28189 invoked by uid 605); 11 May 2002 00:29:19 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28182 invoked from network); 11 May 2002 00:29:18 -0000 Received: from node.061-0.ty.link.si (HELO levitator.1div0.com) (213.250.43.61) by mail.netbsd.org with SMTP; 11 May 2002 00:29:18 -0000 Received: from idiomatic (idiomatic [10.1.1.3]) by levitator.1div0.com (8.11.6/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id g4B0TFa31234 for ; Sat, 11 May 2002 02:29:15 +0200 Reply-To: From: "denis bider" To: Subject: FW: renaming SFTP to... Date: Sat, 11 May 2002 02:29:15 +0200 Message-ID: <001801c1f882$e20b68c0$0301010a@idiomatic> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit (forwarded from private email as it is relevant to the discussion) > I don't want to sound unsupportive (I hate the names sftp > and filexfer) but I don't think it actually matters, But I think it does. We might not be able to change the standard name of the command on deployed Unix boxes, but it isn't difficult to change the official name stated in the document, and I think we should. What is right is right. In a few years, people will catch up. > I do still wonder if this really is the correct group in > IETF to be solving this problem. What other group will? Whoever implements SFTP, apart from SSH2 vendors? From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri May 10 22:59:41 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA02950 for ; Fri, 10 May 2002 22:59:40 -0400 (EDT) Received: (qmail 2021 invoked by uid 605); 11 May 2002 02:59:46 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2014 invoked from network); 11 May 2002 02:59:45 -0000 Received: from nuinfo.northwestern.edu (129.105.212.72) by mail.netbsd.org with SMTP; 11 May 2002 02:59:45 -0000 Received: (from lunde@localhost) by nuinfo.northwestern.edu (8.8.8/8.8.8) id VAA06006; Fri, 10 May 2002 21:59:43 -0500 (CDT) Message-Id: <200205110259.VAA06006@nuinfo.northwestern.edu> Subject: Re: solving the SFTP text mode issue To: ietf-ssh@netbsd.org Date: Fri, 10 May 2002 21:59:42 CDT In-Reply-To: ; from "Jeffrey Altman" at May 10, 2002 6:03 pm From: Albert-Lunde@northwestern.edu (Albert Lunde) Reply-To: Albert-Lunde@northwestern.edu (Albert Lunde) X-Mailer: Elm [revision: 212.5] Sender: ietf-ssh-owner@netbsd.org Precedence: list > > Ugly hacks might be required to determine end-of-line representation > > (or character encoding, or text vs. binary files) in the general case. > > (It seems to be that this is one more reason to keep any ugly hacks > > on the platform where the problem exists, (rather put lots of varients > > into a wire protocol for a text mode) and to make support for a text mode > > transfer optional.) > You do not need to have a bit that indicates the end of line format > for a file. This can be determined along with the classification of > character set by performing a file scan prior to the transfer. For File scans _are_ an ugly hack compared to reliable file attributes... in my sordid past I've written one for determing character encoding and other attributes of files under CDC NOS, with 6/12 bit character encodings. ;) Anyway, with a single over-the-wire text encoding, or as few varients as possible, most of this stuff doesn't need to be in the wire protocol, or in interoperable clients on another OS. -- Albert Lunde Albert-Lunde@northwestern.edu (new address) Albert-Lunde@nwu.edu (old address) From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sat May 11 05:47:24 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA23916 for ; Sat, 11 May 2002 05:47:23 -0400 (EDT) Received: (qmail 20468 invoked by uid 605); 11 May 2002 09:47:26 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20461 invoked from network); 11 May 2002 09:47:25 -0000 Received: from darkwing.uoregon.edu (128.223.142.13) by mail.netbsd.org with SMTP; 11 May 2002 09:47:25 -0000 Received: from twin.uoregon.edu (twin.uoregon.edu [128.223.214.27]) by darkwing.uoregon.edu (8.12.3/8.12.3) with ESMTP id g4B9lPAJ012094; Sat, 11 May 2002 02:47:25 -0700 (PDT) Date: Sat, 11 May 2002 02:49:38 -0700 (PDT) From: Joel Jaeggli X-X-Sender: joelja@twin.uoregon.edu To: "Dan O'Reilly" cc: "'ietf-ssh@netbsd.org'" Subject: Re: A text transfer mode is needed for the SSH File Transfer Protocol In-Reply-To: <5.1.0.14.2.20020510121618.00aa7730@raptor.psccos.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Fri, 10 May 2002, Dan O'Reilly wrote: > SCP = RCP on steroids > > Therefore, is it unreasonable to assume that sftp would be more robust to > be able to handle all types of file formats, not just those common to the > UNIX world? a file transfer application should not alter files. it makes it very hard to do things like compute the md5sums of a file before and after transfer I think what seems to bug people is that sftp isn't a drop-in replacement ftp. why should it, there are lots of things that are obsolete or just plain bad about ftp. > The root problem is that scp/sftp (in fact, all of SSH, for > that matter) is VERY UNIX-centric, and unfortunately, that's not the total > state of the world... > > At 12:15 PM 5/10/2002, Joel Jaeggli wrote: > >which assumes that sftp should treat text files like ftp does rather than > >like rcp does. > > > >I'm not at all convinced that sftp should do that. > > > >joelja > > > >On Fri, 10 May 2002, Richard Whalen wrote: > > > > > We have had a few customers report problems when transferring text files > > > between dissimilar systems with different implementations of the SSH File > > > Transfer Protocol. I believe that these problems would not exist if the > > > protocol was able to correctly deal with the differences in the way that > > > different systems store text files. > > > > > > ---------------------- > > > Richard Whalen > > > Process Software > > > 508-879-6994x261 > > > > > > >-- > >-------------------------------------------------------------------------- > >Joel Jaeggli Academic User Services joelja@darkwing.uoregon.edu > >-- PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E -- > > In Dr. Johnson's famous dictionary patriotism is defined as the last > > resort of the scoundrel. With all due respect to an enlightened but > > inferior lexicographer I beg to submit that it is the first. > > -- Ambrose Bierce, "The Devil's Dictionary" > > ------ > +-------------------------------+---------------------------------------+ > | Dan O'Reilly | | > | Principal Engineer | "Why should I care about posterity? | > | Process Software | What's posterity ever done for me?" | > | http://www.process.com | -- Groucho Marx | > +-------------------------------+---------------------------------------+ > -- -------------------------------------------------------------------------- Joel Jaeggli Academic User Services joelja@darkwing.uoregon.edu -- PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E -- In Dr. Johnson's famous dictionary patriotism is defined as the last resort of the scoundrel. With all due respect to an enlightened but inferior lexicographer I beg to submit that it is the first. -- Ambrose Bierce, "The Devil's Dictionary" From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sat May 11 06:44:51 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA25423 for ; Sat, 11 May 2002 06:44:50 -0400 (EDT) Received: (qmail 16144 invoked by uid 605); 11 May 2002 10:44:57 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16137 invoked from network); 11 May 2002 10:44:56 -0000 Received: from ixion.tartarus.org (195.149.39.210) by mail.netbsd.org with SMTP; 11 May 2002 10:44:56 -0000 Received: from simon by ixion.tartarus.org with local (Exim 3.12 #1 (Debian)) id 176UMe-0007gv-00; Sat, 11 May 2002 11:44:36 +0100 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@netbsd.org In-Reply-To: Subject: Re: A text transfer mode is needed for the SSH File Transfer Protocol Message-Id: Date: Sat, 11 May 2002 11:44:36 +0100 Sender: ietf-ssh-owner@netbsd.org Precedence: list Joel Jaeggli wrote: > a file transfer application should not alter files. it makes it very hard > to do things like compute the md5sums of a file before and after transfer Err, but if you actually need to transfer a file in text mode, your ability to check its md5sum after transfer isn't really going to make up for the fact that the file hasn't arrived in the form you needed it in! > I think what seems to bug people is that sftp isn't a drop-in replacement > ftp. why should it, there are lots of things that are obsolete or just > plain bad about ftp. True. But the _ability_ to transfer files in text mode is not one of them. Among FTP's problems are the use of multiple network connections in today's NAT-and-firewall-heavy world, the absence of secure authentication, the difficulty of automating complex client scripts because servers aren't required to give back directory information in a standardised way, and the fact that text-mode transfer is the default state whereas most files transferred are binary compressed archives of some form or another. SFTP fixes all of these while introducing all sorts of useful features of its own (random access being a good example); but the _ability_ to do text- mode transfers is not a failing of FTP. -- Simon Tatham "Every person has a thinking part that wonders what the part that isn't thinking isn't thinking about." From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sat May 11 10:30:55 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00916 for ; Sat, 11 May 2002 10:30:55 -0400 (EDT) Received: (qmail 25930 invoked by uid 605); 11 May 2002 14:31:01 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25920 invoked from network); 11 May 2002 14:31:00 -0000 Received: from watsun.cc.columbia.edu (128.59.39.2) by mail.netbsd.org with SMTP; 11 May 2002 14:31:00 -0000 Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id KAA23346; Sat, 11 May 2002 10:30:57 -0400 (EDT) Date: Sat, 11 May 2002 10:30:57 EDT From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: Simon Tatham Cc: ietf-ssh@netbsd.org Subject: Re: A text transfer mode is needed for the SSH File Transfer Protocol In-Reply-To: Your message of Sat, 11 May 2002 11:44:36 +0100 Message-ID: Sender: ietf-ssh-owner@netbsd.org Precedence: list > True. But the _ability_ to transfer files in text mode is not one of > them. Among FTP's problems are the use of multiple network > connections in today's NAT-and-firewall-heavy world, true > the absence of > secure authentication, Secure authentication is supported in the protocol. There just is a huge pre-existing installed base that does not support it. > the difficulty of automating complex client > scripts because servers aren't required to give back directory > information in a standardised way, MLST. But again the large pre-existing installed base is the bigger problem here. > and the fact that text-mode > transfer is the default state whereas most files transferred are > binary compressed archives of some form or another. That is just a protocol state machine starting point. There is no requirement that this be the default for end user client applications. > SFTP fixes all > of these while introducing all sorts of useful features of its own > (random access being a good example); The ability to perform random access for playing audio/video streams was added to FTP as an extension. > but the _ability_ to do text- > mode transfers is not a failing of FTP. Thank you. The Kermit Project as part of RFC 2839 "Internet Kermit Service" describes the strengths and weaknesses of FTP in great detail as well as describing many of the additional functionalities that real world users require in a file transfer protocol in a world consisting of heterogenous operating systems and the lack of a universally deployed character-set. ftp://ftp.isi.edu/in-notes/rfc2839.txt and our FTP client implementation in the Kermit Scripting language demonstrates that whatever FTP's limitations, it is possible to develop extremely sophisticated automated processes. http://www.kermit-project.org/ftpclient.html The real problem with FTP in my eyes is not the protocol but the implementations. Any protocol that has been around for 20+ years is going to be widely deployed. Widely deployed protocols tend to have extremely large numbers of poor implementations. This is for two reasons: . the protocol is selected as one of the first projects inexperienced programmers choose to implement. the programmers have little context to use when reading the protocol specifications. In a protocol that is described by a large number of documents that have been edited/extended over a long period of time this results in severe misunderstandings of the proper way to implement the protocol. Hence, incompatibilities are introduced and even uglier (undocumented) hacks get introduced to work around the most common incompatibilities. . the protocol becomes a "required" protocol to be implemented in any and all operating systems. This operating system vendor does not consider themselves to be in the XYZ Protocol business. Therefore, they put a junior programmer on the project and do not provide the necessary research and testing resources. This is as true for Microsoft and IBM as it is for much smaller vendors. The end result is that we have 20+ years of implementations that are technically in violation of the documented protocol specifications. I can promise you that in ten years people are going to be making exactly the same complaints about SSH and SFTP. I have basicly decided to stay out of these discussions because although I do strongly believe that there needs to be a standardized means for transfering files as an SSH Subsystem that handles more than binary data streams I am not convinced that SFTP has to be that method. From my perspective in working with real world users in academia, government, military, health care, postal services, retail, banking, ... and dealing with their needs to automate the transfering of files around the world over all combinations of communication networks and devices I can tell you that there is still a large need for a transport independent protocol that: . transfers binary, text, and record based formats . can handle file systems with multiple data streams per file . can handle arbitrary attribute data . can be automated . provides in-band character set handling . provides atomic file movement operations . supports recursive directory tree operations . is firewall/nat friendly How do I know this? Its simple. People still download large numbers of our Kermit software every day and we receive a consistent high number of support requests targetting these issues. Of course, nothing happens in the IETF unless the person who needs the feature and functionality does the work. Good protocols don't simply materialize out of thin air. Jeffrey Altman * Sr.Software Designer Kermit 95 1.1.21 available now!!! The Kermit Project @ Columbia University SSH plus Telnet, FTP and HTTP http://www.kermit-project.org/ secured with Kerberos, SRP, and kermit-support@columbia.edu OpenSSL. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun May 12 02:07:27 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA07967 for ; Sun, 12 May 2002 02:07:27 -0400 (EDT) Received: (qmail 11338 invoked by uid 605); 12 May 2002 06:07:34 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11215 invoked from network); 12 May 2002 06:07:32 -0000 Received: from cpe-203-45-59-246.vic.bigpond.net.au (HELO mothra.mindrot.org) (203.45.59.246) by mail.netbsd.org with SMTP; 12 May 2002 06:07:32 -0000 Received: from localhost (djm@localhost) by mothra.mindrot.org (8.11.6/8.11.6) with ESMTP id g4C688613968; Sun, 12 May 2002 16:08:09 +1000 X-Authentication-Warning: mothra.mindrot.org: djm owned process doing -bs Date: Sun, 12 May 2002 16:08:06 +1000 (EST) From: Damien Miller To: Wei Dai cc: "denis.bider@denisbider.com" , "ietf-ssh@netbsd.org" Subject: Re: solving the SFTP text mode issue In-Reply-To: <20020510130155.A9475@eskimo.com> Message-ID: X-Paranoia: just because you're paranoid doesn't mean they aren't out to get you MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Fri, 10 May 2002, Wei Dai wrote: > Here's another simple suggestion for your consideration. Define a new > pflags flag for SSH_FXP_OPEN: > > #define SSH_FXF_TEXT 0x00000040 > > It would have the following meaning: > > SSH_FXF_TEXT > File SHOULD be encoded as UTF-8 using either CR, LF, or CR/LF to > indicate line end, or converted to this encoding before transfer. > File access MUST be sequential. The server should return an error if this is not supported, rather than silently failing. -d From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun May 12 06:50:51 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA11765 for ; Sun, 12 May 2002 06:50:50 -0400 (EDT) Received: (qmail 15011 invoked by uid 605); 12 May 2002 10:50:58 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15002 invoked from network); 12 May 2002 10:50:55 -0000 Received: from enginettech.com (HELO mail.enginettech.com) (206.156.231.224) by mail.netbsd.org with SMTP; 12 May 2002 10:50:55 -0000 Received: from tortoise113 (24.240.6.246[24.240.6.246])by ENGINET-01(MailMax 3.073) with ESMTP id 1611960 for ; Sun, 12 May 2002 05:51:50 -0500 CDT Message-ID: <004b01c1f9a2$5722c840$0100a8c0@tortoise113> From: "Calvin Bebermeyer" To: References: <63D30D6E10CFD11190A90000F805FE86040AA378@lespaul.process.com> Subject: Re: solving the SFTP text mode issue Date: Sun, 12 May 2002 05:45:23 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit For what it is worth, SFTP is not an ftp implementation, thus the choice of "ftp" in the name was not really a good one. If someone were to port the SSH protocol to a mainframe, the everyday user that is really not interested in computer inner workings would see really strange text results on these transfers. regards, Calvin Bebermeyer calvinb@acm.org From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon May 13 10:49:30 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13731 for ; Mon, 13 May 2002 10:49:29 -0400 (EDT) Received: (qmail 17020 invoked by uid 605); 13 May 2002 14:49:36 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17010 invoked from network); 13 May 2002 14:49:35 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 13 May 2002 14:49:35 -0000 Received: from [127.0.0.1] (HELO mail) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 666769; Mon, 13 May 2002 08:49:34 -0600 Received: from chaos.vandyke.com ([192.168.0.77]) by mail (MailMonitor for SMTP v1.1.0 ) ; Mon, 13 May 2002 08:49:33 -0600 (Mountain Daylight Time) Message-ID: <042c01c1fa8c$7eb87db0$4d00a8c0@galb.vandyke.com> From: "Joseph Galbraith" To: , References: <001501c1f87d$8f7933d0$0301010a@idiomatic> Subject: Re: solving the SFTP text mode issue Date: Mon, 13 May 2002 08:42:46 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > > The solution proposed works extremely well in the > > fixed length record cases -- in fact, I would say > > it is ideal. It provides, fast, efficient, random > > record based access. > > The question is: is there a need for random access to record-based files? > > After some consideration, I think that the READ_RECORD/WRITE_RECORD proposal > is probably too enthusiastic. Implementing random access to files where > records are lines of text will be difficult on most platforms. Most > applications don't currently do random access in the first place, so it's > hard to imagine it being done much with records. > > But if we dismiss random access, than the only remaining advantage of the > readrecord/writerecord proposal is that it allows LF to be embedded in > lines. > > I think that Wei's proposal is the most balanced of all I've considered > today: > > - It does seem to support all kinds of text files reasonably well, including > record-based text files. The latter is true as long as individual records > don't contain LF characters, which I assume is reasonable to expect from a > text file. > > - It is simple to implement on Windows and Unix. It resembles the approach > taken by C/C++ standard libraries to solve the same problem. Translation > between CRLF and LF is simple. No convoluted algorithms to support random > access need to be implemented. In terms of solving the text transfer problem, Wei's proposal is sufficient I believe, although it does not provide for resuming a large text transfer if it is interupted. (Something our customers want to be able to do.) I'll talk more about Wei's solution in a response directly to it. I must say that the solution I proposed was not aimed at solving the text transfer problem, per say, but at solving the record file access problem that VMS folks have (and probably mainframe folks too.) It just happens that the text access problem is a subset of the record access problem. Now, if the random access thing bothers your too much, we might say something like: If the SSH_FILEXFER_ATTR_RECORD_ACCESS flag is not set, the file can not be opened for RECORD access. Any attempt to do so will result in a SSH_FX_INVALID_ACCESS_MODE error. If the SSH_FILEXFER_ATTR_RANDOM_ACCESS flag is not set, the offset and / or record number field is ignore in READ, READ_RECORD, WRITE, and WRITE_RECORD operations and the file is read / written in sequential order. Now, VMS (or any other operating system that natively supports random access record oriented files) can natively support this, and NT or unix, for example, Of course, on the other hand, I'm not really attached to this solution -- only proposing that it solves more of the proposed problem then other solutions proposed. Personally, if we want to solve just the text access solution, we have the server advertise what line delimiter it will use, and the MacOS and VMS folks who deal with different kinds on a per file basis can do conversions on the server side. I.e., the VMS server would convert a variable length counted file into \r\n delimited, and always advertise \r\n as its line delimiter. As I said before, we already implement this solution in our servers, and if other servers implemented it, it would solve 99% of our customers problems, which is a lot more than we currently have. And it doesn't really prevent implementors working under VMS from using the solution -- they just have to work harder. They have to do the server side translation work the rest of us are avoiding by not specifying the canonical line termination in the draft, but rather allowing the server to specify it's own cananical line termination. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon May 13 10:59:27 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14283 for ; Mon, 13 May 2002 10:59:27 -0400 (EDT) Received: (qmail 21028 invoked by uid 605); 13 May 2002 14:59:35 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21021 invoked from network); 13 May 2002 14:59:35 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 13 May 2002 14:59:35 -0000 Received: from [127.0.0.1] (HELO mail) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 666818; Mon, 13 May 2002 08:59:34 -0600 Received: from chaos.vandyke.com ([192.168.0.77]) by mail (MailMonitor for SMTP v1.1.0 ) ; Mon, 13 May 2002 08:59:34 -0600 (Mountain Daylight Time) Message-ID: <042d01c1fa8d$e4b0f6a0$4d00a8c0@galb.vandyke.com> From: "Joseph Galbraith" To: "Wei Dai" , Cc: References: <000701c1f857$91246810$0301010a@idiomatic> <000801c1f85a$e8bf97e0$0301010a@idiomatic> <20020510130155.A9475@eskimo.com> Subject: Re: UTF8 in SFTP (was: solving the SFTP text mode issue) Date: Mon, 13 May 2002 08:53:07 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > Here's another simple suggestion for your consideration. Define a new > pflags flag for SSH_FXP_OPEN: > > #define SSH_FXF_TEXT 0x00000040 > > It would have the following meaning: > > SSH_FXF_TEXT > File SHOULD be encoded as UTF-8 using either CR, LF, or CR/LF to > indicate line end, or converted to this encoding before transfer. > File access MUST be sequential. First, I don't think SHOULD is strong enough here. For this to be useful, it would need to be MUST. Probably this text should be included: If the server can not comply, it must respond with status SSH_FX_OP_UNSUPPORTED. I don't think I can determine the current encoding of an arbitrary text file in order to convert it's contents to UTF-8. (Some files will be encoded in unicode, and of course there is no problem with those.) I believe the unix folks have the same problem with file names -- which is why I've been having such a hard time getting them to swallow UFT-8 for file names. I actually think that for both cases, it may be necessary to make UTF-8 optional, determined by the server. I.e., the client MUST be able to read filenames and content encoded in UTF-8. The server MAY send filenames and/or content in UTF-8. If content/filenames are not encoded in UTF-8, there encoding is unspecified, and user intervention may be required to determine how to display / save the file. If the SSH_FXF_TEXT flag is set during open, and the server will send file content in UTF-8, it should respond with status code SSH_FX_OK_UTF8 (status code 9) instead of SSH_FX_OK. If the server will encode filenames in UTF-8, it should include the following extension data in it's VERSION packet (if and only if the clients INIT packet specified a version >= 3.) "filename-utf8" # extension name "" # no extension data - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue May 14 03:21:25 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA06144 for ; Tue, 14 May 2002 03:21:25 -0400 (EDT) Received: (qmail 2740 invoked by uid 605); 14 May 2002 07:21:34 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2732 invoked from network); 14 May 2002 07:21:33 -0000 Received: from mail2.nrw.net (194.245.103.15) by mail.netbsd.org with SMTP; 14 May 2002 07:21:33 -0000 Received: (qmail 15063 invoked from network); 14 May 2002 07:21:09 -0000 Received: from unknown (HELO fileserver.ITinhaus.de) (194.176.6.50) by mail2.nrw.net with SMTP; 14 May 2002 07:21:09 -0000 Received: by FILESERVER with Internet Mail Service (5.5.2650.21) id ; Tue, 14 May 2002 09:18:25 +0200 Message-ID: <81F901A447CCD31182B900508B7160EC0BB250@FILESERVER> From: Benedikt Niehues To: "'info@linWare.de'" Subject: Newsletter LinWare, Mai 2002 Date: Tue, 14 May 2002 09:18:06 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA06144 Sehr geehrte Damen und Herren, Nach dem erfolgreichen Start von LinThin im vergangenen Jahr wurde auch LinWare auf der Cebit mit großer Begeisterung aufgenommen. LinWare "macht einen PC zum Thin Client": geringe Betriebskosten eines Thin Clients auf beliebiger PC - Hardware. Eine Demoversion erhalten Sie bei autorisierten Vertriebspartnern (http://www.linware.de/partner.html). Mit freundlichen Grüßen aus Aachen, Benedikt Niehues SojusIT http://www.linware.de Themen heute: + LINWARE: Nutzen Sie die Vorteile eines Thin Client auf Ihrem PC + LINTHIN 1.5: Program-Neigbourhood auf dem PC + THIN CLIENT MARKT: 35% Wachstum im Jahr 2002 -------------------------------------------------------------- LINWARE: Nutzen Sie die Vorteile eines Thin Client auf Ihrem PC http://www.linware.de/produkte_linware.html Wenn Sie die Vorteile von Thin Clients nutzen und dabei PC Hardware verwenden möchten, ist LinWare die Lösung. Es entstehen keine zusätzliche Kosten für ein Windows - Betriebsystem. Mit LinWare können Sie auf Windows 2000, Citrix- und Unix Server und Hostsysteme zugreifen. Beim Umstieg auf einen LinThin Thin Client werden die erworbenen LinWare-Lizenzen angerechnet. LINTHIN 1.5: Program-Neigbourhood auf dem PC http://www.linware.de/produkte_linthin.html Die Vorteile von Program-Neighbourhood weiß jeder Administrator zu schätzen. In Verbindung mit dem kostenfreien NFuse von Citrix erhält jeder LinThin - Benutzer Zugriff auf das Program-Neighbourhood. Dann müssen keine Anwendungen mehr lokal konfiguriert werden und die lokale Benutzerverwaltung entfällt. Bei LinThin kann die Änderung der Anwendungskonfiguration für hunderte von Benutzern auf einen Knopfdruck erfolgen, ohne das ein einziger Thin Client konfiguriert werden muss. THIN CLIENT MARKT: 35% Wachstum im Jahr 2002 http://www.gartner.com/DisplayDocument?id=350667 Nach einen Bericht der Gartner Group gehört der Thin Client Markt auch dieses Jahr wieder zu den Märkten mit den höchsten Zuwachszahlen. Bis zu 35 % Zuwachs erwarten die Analysten für dieses Jahr, begründet durch die hohen Einsparpotentiale. Den vollständigen Bericht erhalten Sie über die Homepage der Gartner Group (http://www.gartner.com) NEWSLETTER bestellen / abmelden Wenn Sie jemanden kennen, der diesen Newsletter auch erhalten sollte, schicken Sie bitte eine Antwortmail mit dem Betreff: ADD [emailadresse] Wenn Sie zukünftig keine weiteren Nachrichten von uns erhalten möchten, schicken Sie bitte eine Antwortmail mit dem Betreff: REMOVE From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue May 14 11:00:33 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22356 for ; Tue, 14 May 2002 11:00:32 -0400 (EDT) Received: (qmail 24872 invoked by uid 605); 14 May 2002 15:00:40 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24865 invoked from network); 14 May 2002 15:00:39 -0000 Received: from lespaul.process.com (192.42.95.27) by mail.netbsd.org with SMTP; 14 May 2002 15:00:39 -0000 Received: by lespaul.process.com with Internet Mail Service (5.5.2653.19) id ; Tue, 14 May 2002 11:02:26 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE86040AA37B@lespaul.process.com> From: Richard Whalen To: "'Joseph Galbraith'" , Wei Dai , denis.bider@denisbider.com Cc: ietf-ssh@netbsd.org Subject: RE: UTF8 in SFTP (was: solving the SFTP text mode issue) Date: Tue, 14 May 2002 11:02:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ietf-ssh-owner@netbsd.org Precedence: list I believe that a text transfer mode is sufficient to meet our customers' needs. Users view SCP & SFTP as replacements for FTP and hence expect to be able to transfer text files as well as binary files. Though FTP defines a record transfer mode it is seldom used, so I don't think that the development of the SSH File Transfer Protocol should be encumbered with the work that would need to be done if a record transfer mechanism were to be added at this time. The text transfer mechanism in the SSH File Transfer Protocol should define a single method of encoding the line end to remove any ambiguity. Systems that encode line breaks differently from the specified method would be responsible for scanning the data and performing the necessary substitution. One additional thing to note: When a file is transferred in Text mode, the size information reported for a file must be considered to be an estimate as computing the exact size may consume too many resources or use too much time to process the command in a timely manner. The only way to determine that all of the text from the file has been retrieved is through the receipt of end of file status when there is a request for data. ---------------------- Richard Whalen Process Software > -----Original Message----- > From: Joseph Galbraith [mailto:galb-list@vandyke.com] > Sent: Monday, May 13, 2002 10:53 AM > To: Wei Dai; denis.bider@denisbider.com > Cc: ietf-ssh@netbsd.org > Subject: Re: UTF8 in SFTP (was: solving the SFTP text mode issue) > > > > Here's another simple suggestion for your consideration. > Define a new > > pflags flag for SSH_FXP_OPEN: > > > > #define SSH_FXF_TEXT 0x00000040 > > > > It would have the following meaning: > > > > SSH_FXF_TEXT > > File SHOULD be encoded as UTF-8 using either CR, LF, > or CR/LF to > > indicate line end, or converted to this encoding > before transfer. > > File access MUST be sequential. > > First, I don't think SHOULD is strong enough here. > For this to be useful, it would need to be MUST. > Probably this text should be included: > > If the server can not comply, it must respond > with status SSH_FX_OP_UNSUPPORTED. > > I don't think I can determine the current encoding > of an arbitrary text file in order to convert > it's contents to UTF-8. (Some files will be > encoded in unicode, and of course there is no > problem with those.) > > I believe the unix folks have the same problem > with file names -- which is why I've been having > such a hard time getting them to swallow UFT-8 > for file names. > > I actually think that for both cases, it may be > necessary to make UTF-8 optional, determined > by the server. > > I.e., the client MUST be able to read filenames and content > encoded in UTF-8. The server MAY send filenames and/or > content in UTF-8. If content/filenames are not encoded in UTF-8, > there encoding is unspecified, and user intervention may > be required to determine how to display / save the file. > > If the SSH_FXF_TEXT flag is set during open, and the server > will send file content in UTF-8, it should respond with > status code SSH_FX_OK_UTF8 (status code 9) instead of > SSH_FX_OK. > > If the server will encode filenames in UTF-8, it should > include the following extension data in it's VERSION > packet (if and only if the clients INIT packet specified > a version >= 3.) > > "filename-utf8" # extension name > "" # no extension data > > - Joseph > > From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue May 14 16:00:04 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA03627 for ; Tue, 14 May 2002 16:00:03 -0400 (EDT) Received: (qmail 14032 invoked by uid 605); 14 May 2002 20:00:12 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14025 invoked from network); 14 May 2002 20:00:11 -0000 Received: from mx1.eskimo.com (204.122.16.48) by mail.netbsd.org with SMTP; 14 May 2002 20:00:11 -0000 Received: from eskimo.com (root@eskimo.com [204.122.16.13]) by mx1.eskimo.com (8.9.1a/8.8.8) with ESMTP id NAA13549; Tue, 14 May 2002 13:00:05 -0700 Received: (from weidai@localhost) by eskimo.com (8.9.1a/8.9.1) id MAA12685; Tue, 14 May 2002 12:54:15 -0700 (PDT) Date: Tue, 14 May 2002 12:54:15 -0700 From: Wei Dai To: Richard Whalen Cc: "'Joseph Galbraith'" , denis.bider@denisbider.com, ietf-ssh@netbsd.org Subject: Re: UTF8 in SFTP (was: solving the SFTP text mode issue) Message-ID: <20020514125413.A5615@eskimo.com> References: <63D30D6E10CFD11190A90000F805FE86040AA37B@lespaul.process.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <63D30D6E10CFD11190A90000F805FE86040AA37B@lespaul.process.com>; from Whalenr@process.com on Tue, May 14, 2002 at 11:02:23AM -0400 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, May 14, 2002 at 11:02:23AM -0400, Richard Whalen wrote: > The text transfer mechanism in the SSH File Transfer Protocol should define > a single method of encoding the line end to remove any ambiguity. Systems > that encode line breaks differently from the specified method would be > responsible for scanning the data and performing the necessary substitution. Ok, I now realize there is no point in allowing either CR, LF, or CR LF, so let's just specify LF. > One additional thing to note: When a file is transferred in Text mode, the > size information reported for a file must be considered to be an estimate as > computing the exact size may consume too many resources or use too much time > to process the command in a timely manner. The only way to determine that > all of the text from the file has been retrieved is through the receipt of > end of file status when there is a request for data. That seems reasonable. Joseph Galbraith wrote: > > If the SSH_FXF_TEXT flag is set during open, and the server > > will send file content in UTF-8, it should respond with > > status code SSH_FX_OK_UTF8 (status code 9) instead of > > SSH_FX_OK. Instead of the above, how about a seperate flag SSH_FXF_UTF8, and status code SSH_FX_UTF8_NOT_SUPPORTED. It seems likely that a client sometimes will not be able to determine how to convert a file it wants to upload into UTF-8 either. SSH_FXF_TEXT would then mean only using LF for line end. > > If the server will encode filenames in UTF-8, it should > > include the following extension data in it's VERSION > > packet (if and only if the clients INIT packet specified > > a version >= 3.) > > > > "filename-utf8" # extension name > > "" # no extension data Why shouldn't this extension apply to both sides symmetrically? We can say that if both sides support this extension, all filenames will be in UTF-8, otherwise their native encodings are used. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue May 14 16:24:06 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA04872 for ; Tue, 14 May 2002 16:24:06 -0400 (EDT) Received: (qmail 28693 invoked by uid 605); 14 May 2002 20:24:16 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28686 invoked from network); 14 May 2002 20:24:15 -0000 Received: from carnelian.propagation.net (209.164.120.1) by mail.netbsd.org with SMTP; 14 May 2002 20:24:15 -0000 Received: from CELLO (localhost [127.0.0.1]) by carnelian.propagation.net (8.8.5/8.8.5) with SMTP id PAA16116; Tue, 14 May 2002 15:23:39 -0500 From: "Howard Chu" To: "Wei Dai" , "Richard Whalen" Cc: "'Joseph Galbraith'" , , Subject: RE: UTF8 in SFTP (was: solving the SFTP text mode issue) Date: Tue, 14 May 2002 13:23:48 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20020514125413.A5615@eskimo.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > -----Original Message----- > From: ietf-ssh-owner@netbsd.org [mailto:ietf-ssh-owner@netbsd.org]On > Behalf Of Wei Dai > On Tue, May 14, 2002 at 11:02:23AM -0400, Richard Whalen wrote: > > The text transfer mechanism in the SSH File Transfer Protocol > should define > > a single method of encoding the line end to remove any > ambiguity. Systems > > that encode line breaks differently from the specified method would be > > responsible for scanning the data and performing the necessary > substitution. > > Ok, I now realize there is no point in allowing either CR, LF, or CR LF, > so let's just specify LF. One complication to watch out for - some systems actually treat CR and LF according to their original definition. You will find text files that use CRs by themselves to achieve overstrike, and LFs by themselves to insert whitespace, etc., in addition to CR/LF "line terminator" sequences. There's a good reason why all the existing RFCs that deal with text transmission specify CR/LF as the line break sequence; if you use just a single CR or LF as suggested here, it is impossible to canonicalize a file without losing formatting (of individual CR or LFs). I'm still at a loss as to why SSH FTP wasn't simply FTP wrapped in SSH. FTP has already been designed, what is with all this re-inventing the wheel business. How are you going to accomodate record-oriented file transfers, records with line numbers, and other structured file transfers? As much as I like Unix and its simple bytestream file model, there's still a place for record-oriented files in this world... -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue May 14 16:29:23 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA05204 for ; Tue, 14 May 2002 16:29:22 -0400 (EDT) Received: (qmail 3737 invoked by uid 605); 14 May 2002 20:29:32 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3730 invoked from network); 14 May 2002 20:29:31 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 14 May 2002 20:29:31 -0000 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA13949; Tue, 14 May 2002 14:29:17 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA26153; Tue, 14 May 2002 16:28:45 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g4EKPiW5019306; Tue, 14 May 2002 16:25:44 -0400 (EDT) Message-Id: <200205142025.g4EKPiW5019306@thunk.east.sun.com> From: Bill Sommerfeld To: "Howard Chu" cc: "Wei Dai" , "Richard Whalen" , "'Joseph Galbraith'" , denis.bider@denisbider.com, ietf-ssh@netbsd.org Subject: Re: UTF8 in SFTP (was: solving the SFTP text mode issue) In-Reply-To: Your message of "Tue, 14 May 2002 13:23:48 PDT." Reply-to: sommerfeld@east.sun.com Date: Tue, 14 May 2002 16:25:44 -0400 Sender: ietf-ssh-owner@netbsd.org Precedence: list > I'm still at a loss as to why SSH FTP wasn't simply FTP wrapped in > SSH. for the record, the working group chair (me) is *still* at a loss to understand why there seems to be so much of a desire to reinvent the wheel here. I'd personally welcome a simple document explaining how to run the ftp protocol over an ssh connection. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue May 14 16:50:15 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA06295 for ; Tue, 14 May 2002 16:50:15 -0400 (EDT) Received: (qmail 19938 invoked by uid 605); 14 May 2002 20:50:24 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19931 invoked from network); 14 May 2002 20:50:23 -0000 Received: from mx1.eskimo.com (204.122.16.48) by mail.netbsd.org with SMTP; 14 May 2002 20:50:23 -0000 Received: from eskimo.com (weidai@eskimo.com [204.122.16.13]) by mx1.eskimo.com (8.9.1a/8.8.8) with ESMTP id NAA16455; Tue, 14 May 2002 13:50:22 -0700 Received: (from weidai@localhost) by eskimo.com (8.9.1a/8.9.1) id NAA15997; Tue, 14 May 2002 13:50:22 -0700 (PDT) Date: Tue, 14 May 2002 13:50:22 -0700 From: Wei Dai To: Bill Sommerfeld Cc: Howard Chu , Richard Whalen , "'Joseph Galbraith'" , denis.bider@denisbider.com, ietf-ssh@netbsd.org Subject: Re: UTF8 in SFTP (was: solving the SFTP text mode issue) Message-ID: <20020514135022.B5615@eskimo.com> References: <200205142025.g4EKPiW5019306@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200205142025.g4EKPiW5019306@thunk.east.sun.com>; from sommerfeld@east.sun.com on Tue, May 14, 2002 at 04:25:44PM -0400 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, May 14, 2002 at 04:25:44PM -0400, Bill Sommerfeld wrote: > > I'm still at a loss as to why SSH FTP wasn't simply FTP wrapped in > > SSH. > > for the record, the working group chair (me) is *still* at a loss to > understand why there seems to be so much of a desire to reinvent the > wheel here. I can think of a few reasons: 1. SFTP is very easy to understand and implement, once you've implemented SSH. 2. FTP's seperate control and data channels are an annoyance in the context of SSH. 3. Historically FTP implementations have been vulnerable to various attacks. SFTP implementations have not been. 4. SFTP server typically runs under the user's account instead of root. 5. SFTP can be used as a basic network file system, again lightweight and secure compared to existing solutions. Unless people foresee more problems beyond the current one (i.e. text transfer mode) with SFTP, why not finish it up? From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue May 14 17:18:02 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07305 for ; Tue, 14 May 2002 17:18:01 -0400 (EDT) Received: (qmail 13566 invoked by uid 605); 14 May 2002 21:18:11 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13559 invoked from network); 14 May 2002 21:18:10 -0000 Received: from raptor.psccos.com (207.225.29.51) by mail.netbsd.org with SMTP; 14 May 2002 21:18:10 -0000 Received: from ntbsod.process.com ([207.225.29.50]) by RAPTOR.PSCCOS.COM (PMDF V6.1 #36649) with ESMTPA id <01KHQ0QQL96U8ZDYKG@RAPTOR.PSCCOS.COM> for ietf-ssh@netbsd.org; Tue, 14 May 2002 15:18:07 -0700 (MST) Date: Tue, 14 May 2002 15:17:45 -0600 From: "Dan O'Reilly" Subject: Re: UTF8 in SFTP (was: solving the SFTP text mode issue) In-reply-to: <20020514135022.B5615@eskimo.com> X-Sender: oreilly@raptor.psccos.com To: Wei Dai Cc: Bill Sommerfeld , Howard Chu , Richard Whalen , "'Joseph Galbraith'" , denis.bider@denisbider.com, ietf-ssh@netbsd.org Message-id: <5.1.0.14.2.20020514151514.03627d70@raptor.psccos.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Content-type: text/plain; format=flowed; charset=us-ascii References: <"from sommerfeld"@east.sun.com> <200205142025.g4EKPiW5019306@thunk.east.sun.com> Sender: ietf-ssh-owner@netbsd.org Precedence: list At 02:50 PM 5/14/2002, Wei Dai wrote: >On Tue, May 14, 2002 at 04:25:44PM -0400, Bill Sommerfeld wrote: > > > I'm still at a loss as to why SSH FTP wasn't simply FTP wrapped in > > > SSH. > > > > for the record, the working group chair (me) is *still* at a loss to > > understand why there seems to be so much of a desire to reinvent the > > wheel here. > >I can think of a few reasons: > >1. SFTP is very easy to understand and implement, once you've implemented >SSH. >2. FTP's seperate control and data channels are an annoyance in the >context of SSH. >3. Historically FTP implementations have been vulnerable >to various attacks. SFTP implementations have not been. >4. SFTP server typically runs under the user's account instead of root. >5. SFTP can be used as a basic network file system, again lightweight and >secure compared to existing solutions. > >Unless people foresee more problems beyond the current one (i.e. text >transfer mode) with SFTP, why not finish it up? I agree. The issue here is, as I see it, one that regardless of the original intent of what SFTP was supposed to be, the fact of the matter is, customers in the real world are using it in a uniform way: as a secure replacement for ftp. And that's the bottom line. Once it's in production, it's DARNED hard to make somebody change. No, it doesn't have to do everything ftp does; but on the other hand, given what real-world users are using it for, it's inevitable that it gets finished with the stuff we've been discussing. I think Wei put it very well. ------ +-------------------------------+---------------------------------------+ | Dan O'Reilly | | | Principal Engineer | "Why should I care about posterity? | | Process Software | What's posterity ever done for me?" | | http://www.process.com | -- Groucho Marx | +-------------------------------+---------------------------------------+ From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sat May 18 05:49:46 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA07067 for ; Sat, 18 May 2002 05:49:46 -0400 (EDT) Received: (qmail 16428 invoked by uid 605); 18 May 2002 09:49:57 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16420 invoked from network); 18 May 2002 09:49:54 -0000 Received: from unknown (HELO aol.com) (195.219.110.3) by mail.netbsd.org with SMTP; 18 May 2002 09:49:54 -0000 Received: from n7.groups.huyahoo.com ([81.54.222.27]) by f64.law4.hottestmale.com with SMTP; Sat, 18 May 0102 10:58:07 +0100 Received: from unknown (HELO mailout2-eri1.midmouth.com) (80.208.224.224) by symail.kustanai.co.kr with smtp; 18 May 0102 11:48:42 -0300 Received: from [100.235.221.175] by anther.webhostingtotalk.com with asmtp; 18 May 0102 08:39:17 +0100 Reply-To: Message-ID: <026d07a43a7c$8321d1d1$5cc82bc8@qorphx> From: To: dan@netbsd.org Subject: good idea! Date: Sat, 18 May 0102 16:49:13 -0700 MiME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00C2_54A66B4C.D5833A42" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 Importance: Normal Sender: ietf-ssh-owner@netbsd.org Precedence: list ------=_NextPart_000_00C2_54A66B4C.D5833A42 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 aGkNCg0Kd2hhdCBhIGdvb2QgaWRlYSB0byBtYWtlIGEgbGlzdCBvZiB0aGUg YmVzdCBmcmVlIHBvcm4gc2l0ZXMgb2YgdGhlIHdlYiENCmFuZCB5b3UgYXJl IHN1cmUgdG8gZmluZCB3aGF0IHlvdSBsaWtlOiByZWFsIGFtYXRldXJzLCBm ZXRpc2hpc20sIGdheSwgYmxhY2tzLi4uDQp5b3UgbXVzdCB2aXNpdCB0aGlz IGZyZWUgd2ViIHNpdGU6ICh5ZXMgcmVhbGx5IGZyZWUhISkNCg0KaHR0cDov L3VrLnNleC1hbm51YWlyZS5jb20NCg0KRGFuDQoxMDY5QVpqVTAtOTMyRWdY TDM4MjhzSHNOMC0wMzd0c0dPOTExN25aZ0ozLTYzMkRVV1k3NjU3VHpnejct Nzg0TW9tZjc5MDB2Wmw3MA== ------=_NextPart_000_00C2_54A66B4C.D5833A42-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun May 19 17:26:14 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21820 for ; Sun, 19 May 2002 17:26:13 -0400 (EDT) Received: (qmail 18941 invoked by uid 605); 19 May 2002 21:26:21 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18932 invoked from network); 19 May 2002 21:26:20 -0000 Received: from carnelian.propagation.net (209.164.120.1) by mail.netbsd.org with SMTP; 19 May 2002 21:26:20 -0000 Received: from CELLO (localhost [127.0.0.1]) by carnelian.propagation.net (8.8.5/8.8.5) with SMTP id QAA15485; Sun, 19 May 2002 16:26:10 -0500 From: "Howard Chu" To: "Wei Dai" Cc: Subject: RE: UTF8 in SFTP (was: solving the SFTP text mode issue) Date: Sun, 19 May 2002 14:26:13 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20020514135022.B5615@eskimo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > -----Original Message----- > From: ietf-ssh-owner@netbsd.org [mailto:ietf-ssh-owner@netbsd.org]On > Behalf Of Wei Dai > On Tue, May 14, 2002 at 04:25:44PM -0400, Bill Sommerfeld wrote: > > > I'm still at a loss as to why SSH FTP wasn't simply FTP wrapped in > > > SSH. > > > > for the record, the working group chair (me) is *still* at a loss to > > understand why there seems to be so much of a desire to reinvent the > > wheel here. > > I can think of a few reasons: > > 1. SFTP is very easy to understand and implement, once you've implemented > SSH. The implication here is that FTP is not. This is a pretty odd statement; FTP has been in use for so long, the volume of expertise with it surely exceeds the volume of expertise in SSH/SFTP by several orders of magnitude. It's a long-ago solved problem. There's nothing new to understand. Even if SFTP is easy to understand, it's just creating work where none was needed. It's also obvious, by the length of these discussions, that it is not well thought out enough to address many desired usage scenarios. > 2. FTP's seperate control and data channels are an annoyance in the > context of SSH. SSH itself is a multi-channel protocol. I don't see the problem in mapping FTP PORT commands to SSH channels. > 3. Historically FTP implementations have been vulnerable > to various attacks. SFTP implementations have not been. This is like saying "historically libcurses has been insecure compared to libdes." And just because an implementation is broken is no reason to discard the protocol definition. > 4. SFTP server typically runs under the user's account instead of root. This is an implementation detail, not a protocol feature. > 5. SFTP can be used as a basic network file system, again lightweight and > secure compared to existing solutions. FTP has been used in this manner for many years. Again, it is not unique to the protocol definition. > > Unless people foresee more problems beyond the current one (i.e. text > transfer mode) with SFTP, why not finish it up? If all you want is to come to consensus on how to finalize one last detail of the current implementation, fine, do that as an informational RFC. I don't believe this spec merits Standard status. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon May 20 04:53:16 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA00661 for ; Mon, 20 May 2002 04:53:16 -0400 (EDT) Received: (qmail 14692 invoked by uid 605); 20 May 2002 08:53:24 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14685 invoked from network); 20 May 2002 08:53:22 -0000 Received: from ixion.tartarus.org (195.149.39.210) by mail.netbsd.org with SMTP; 20 May 2002 08:53:22 -0000 Received: from simon by ixion.tartarus.org with local (Exim 3.12 #1 (Debian)) id 179iue-0007vY-00; Mon, 20 May 2002 09:53:04 +0100 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@netbsd.org In-Reply-To: Subject: Re: UTF8 in SFTP (was: solving the SFTP text mode issue) Message-Id: Date: Mon, 20 May 2002 09:53:04 +0100 Sender: ietf-ssh-owner@netbsd.org Precedence: list Howard Chu wrote: > SSH itself is a multi-channel protocol. I don't see the problem in > mapping FTP PORT commands to SSH channels. Mapping them how? By changing their syntax so that they show SSH channel numbers rather than IP addresses and ports, or by having the client somehow translate them _into_ IP addresses and ports, or what? A technique that is already practised is to forward an FTP control channel over SSH, and to edit the PORT commands as they go down the wire so that the FTP client ends up conducting a multi-connection FTP dialogue with the SSH client, and the SSH server conducts a different one with the FTP server. This works, but it's hardly what I'd call elegant. Particularly since, after you've gone to the effort of setting up SSH identity keys and arranging one-touch authentication, the last thing you want is to have to type your password into an FTP client every time you want to transfer a file! An alternative would be to have a specialist FTP client integrated with an SSH server; so that it would send a PASV command and then ask the SSH server to open a fresh channel to the IP and port number specified by the FTP server. This would work (modulo the above authentication inconvenience) but suddenly no existing FTP client is competent to do this - and what was the point of keeping FTP unmodified if not to be able to use the large array of existing clients? I really don't see why people are still trying to tell us FTP is perfectly sufficient. SFTP allows plausible automated clients, is able to run over an already-authenticated SSH connection, and is readily extensible by a well-defined means. Why, merely because FTP has solved one or two problems that SFTP as yet hasn't, are people exhorting us to go back to FTP which fails to solve all those _other_ problems? I just don't see it. -- Simon Tatham "Imagine what the world would be like if there were no hypothetical situations..." From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon May 20 14:58:44 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA00629 for ; Mon, 20 May 2002 14:58:40 -0400 (EDT) Received: (qmail 23973 invoked by uid 605); 20 May 2002 18:58:48 -0000 Delivered-To: ietf-ssh@netbsd.org Message-ID: <20020520185848.23972.qmail@mail.netbsd.org> Received: (qmail 23964 invoked from network); 20 May 2002 18:58:43 -0000 Received: from acb0d008.ipt.aol.com (HELO arcor.de) (172.176.208.8) by mail.netbsd.org with SMTP; 20 May 2002 18:58:43 -0000 From: "phoengeist38259@arcor.de" To: Subject: Entschuldigen Sie bitte die Störung! Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Sat, 11 May 2002 23:05:36 +0200 Reply-To: "phoengeist38259@arcor.de" Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit Entschuldigen Sie bitte die Störung! Mir ist etwas zu Ohren gekommen. Eine relativ aussergewöhnliche Gerüchteküche, aus der man mir ein schwerverdauliches Süppchen vorgesetzt hat, ist der Grund meiner Mail. Unappetitlich ist gar kein Ausdruck! Ist es möglich auf funktechnischem Wege(in welchen Frequenzbereichen?) jemanden zu beeinflussen oder zu manipulieren? Oder sogar zu schikanieren und terrorisieren? Unter dem Motto:"Einen am Sender?Nich ganz alleine? Kleine Mannim Ohr?Falsche Wellenlänge?Bohnen in den Ohren? Auf den Zahn gefühlt(Amalgam)?Mal unverbindlich reinhören? Der Pullacher Wanzentanz? Ist das Spinnerei?Das geht doch gar nicht,oder? Und wenn wie sieht das ethisch moralisch aus? Zur technischen Seite der Sache gibt es zwar Berichte und Webseiten: Totalitaer,de - Die Waffe gegen die Kritik http://www.raum-und-zeit.com/Aktuell/Brummton.htm http://www.fosar-bludorf.com/Tempelhof/ http://jya.com/haarp.htm http://www.zeitenschrift.at/magazin/zs_24_15/1_mikrowaffen.htm http://www.bse-plus.de/d/doc/lbrief/lbmincontr.htm http://home.nexgo.de/kraven/bigb/big3.html http://w3.nrl.navy.mil/projects/haarp/index.html http://cryptome.org/ http://www.raven1.net/ravindex.htm http://www.calweb.com/~welsh/ http://www.cahe.org/ http://www.parascope.com/ds/mkultra0.htm http://www.trufax.org/menu/mind.html http://www.trufax.org/menu/elect.html http://mindcontrolforum.com/ http://www.trufax.org/menu/elect.html usw. usw. usw. ,aber,das kann doch nicht sein,das soetwas gemacht wird,oder? Eine Menschenrechtsverletzung sonder gleichen!?! Ist es möglich,durch Präparation,der Ohren und im Zusammenspiel mit eventuell vorhandenem Zahnersatz? Mit relativ einfacher Funktechnik?? In diesem Land?Hier und heute??? Unter welchen Motiven? Wo ist eigentlich die Abteilung 5 des BND und des Verfassungsschutzes? Kann es sein,daß es Leute gibt,die dem BND/Verfassungsschutz,auf funktechnischem Wege permanent einen Situationsbericht abliefern,ohne es selbst zu merken,im Kindesalter machbar gemacht?? Werden durch solche inoffiziellen Mitarbeiter,beim BND und Verfassungsschutz,nach Stasimanier, Informationen von und über,rein theoretisch, jeden Bundesbürger,gesammelt? Gibt es dann noch ein Recht auf Privatsphere? Wer kontrolliert eigentlich den BND,MAD und Verfassungsschutz auf Unterwanderung??? In der Mail geht es mir eigentlich um die Frage,ob es kriminellen Elementen, aus dem Motiv der Bereicherung,oder Gruppierungen aus ideologischen Motiven, möglich ist ,sich Wissen und Technik anzueignen,die zu anderen Zeiten, aus anderen Motiven(Westfernsehen?),entwickelt wurde. Und stellt der technische Wissensstand, der der Allgemeinheit bekannt ist wirklich das Ende der Fahnenstange dar? Ist es denn nicht kriminellen Elementen genauso möglich, ich sage das jetzt mal verharmlost und verniedlichend, einzelne Personen oder Gruppen mit relativ einfachen Mitteln, aus welchen Motiven auch immer, auszuspionieren? Und stellt diese "Ausspioniererei" nicht einen erheblichen Eingriff in die Privatsphäre dar? Ist es möglich einzelne Personen oder Gruppen, eine Akzeptans einer gewissen Öffentlichkeit(suggeriert?), die z.B. mit Hilfe von Internetseiten,wie zum Beispiel dem "Pranger"geschaffen werden könnte, mal vorausgestzt,zu terroriesieren und oder zu schikanieren, und das in aller (suggerierten)Öffentlichkeit?Haben die Leute die da am Pranger, oder auf irgendeiner anderen Seite verunglimpft,oder gar Verleumdet werden, eigentlich eine Chance zur Gegenöffentlichkeit?Ist das nicht Rufmord? Vor einigen Jahren bin ich per Zufall auf die Seite "Der Pranger" gestoßen, damals lief das noch nicht unter dem Deckmantel der Partnervermittlung. Können sich einzelne Personen,oder Interessengemeinschaften, aus reinem Selbstzweck,solcher Seiten bedienen, um unter dem Deckmantel einer fragwürdigen Zivilkourage, durch anzetteln irgendwelcher Hetzkampagnen,eigene, ganz persöhnliche Interessen durchsetzen? Können solche Seiten zur Koordination von kriminellen machenschaften dienen? Die Frage,ist es Möglichkeit oder Unmöglichkeit,technisch und gesellschaftlich, einzelne Personen,oder auch Gruppierungen,aus einer kriminellen/ideologischen Energei heraus,zu manipulieren oder zu beeinflussen,terrorisieren oder zu schickanieren,und zwar gezielt. Zielgruppenmanipulation durch Massenmedien sind alltägliche Manipulation, der mansich,mehr oder weniger,entziehen kann. Wird das Recht auf Privatsphäre,schleichend,tiefenpsychologisch, durch Sendungen,wie,zum Beispiel "Big brother",untergraben? Sollte bei einem der Angemailten ein gewisser Wissensstand zum Thema vorhanden sein, wäre ich über Hinweise zum Thema froh. Auf der Suche nach Antworten auf meine Fragen maile ich verschiedene Adressen aus dem Internet an, und hoffe aufkonstruktive Antworten und Kritiken. Über einen Besuch auf der Seite würde ich mich freuen. Sollten Sie von mir mehrfach angeschrieben worden sein,so bitte ich Sie,mir dies zu entschuldigen, das war nicht beabsichtigt. Der Grund für meine Anonymität ist die Tatsache, daß bei derlei Fragenstellerei, verständlicherweise,schnell der Ruf nach der Psychatrie laut wird. Was auch Methode hat(ist). Sollten Sie die Mail als Belästigung empfinden, möchte ich mich hiermit dafür entschuldigen! Big brother is watching you? Excuse please the disturbance! Me something came to ears. A relatively unusual rumor kitchen, from which one put forward to me a heavydigestible soup, is the reason of my Mail. Unappetizing is no printout! Is it possible on radio Wege(in for which frequency ranges?) to influence or manipulate someone? Terrorize or to even chicane and? Under the Motto:"Einen at the Sender?Nich quite alone? Small Mannim Ohr?Fal Wellenlaenge?Bohnen in the ears? On the tooth clean-hear gefuehlt(Amalgam)?Mal witthout obligation? The Pullacher bug wanzentanz? Isn't the Spinnerei?Das goes nevertheless at all, or? And if as looks ethicalally morally? For the technical page of the thing there is to report and web page: Totalitaer,de - Die Waffe gegen die Kritik http://www.raum-und-zeit.com/Aktuell/Brummton.htm http://www.fosar-bludorf.com/Tempelhof/ http://jya.com/haarp.htm http://www.zeitenschrift.at/magazin/zs_24_15/1_mikrowaffen.htm http://www.bse-plus.de/d/doc/lbrief/lbmincontr.htm http://home.nexgo.de/kraven/bigb/big3.html http://w3.nrl.navy.mil/projects/haarp/index.html http://cryptome.org/ http://www.raven1.net/ravindex.htm http://www.calweb.com/~welsh/ http://www.cahe.org/ http://www.parascope.com/ds/mkultra0.htm http://www.trufax.org/menu/mind.html http://www.trufax.org/menu/elect.html http://mindcontrolforum.com/ http://www.trufax.org/menu/elect.html usw. usw. usw. but, that cannot be nevertheless, which is made soetwas, or? A violation of human rights resemble special!?! Is it possible, by preparation, the ears and in interaction with possibly available artificial dentures? With relatively simple radio engineering?? In this Land?Hier and today??? Under which motives? Where is the department actually 5 of the BND and the protection of the constitution? Can it be that there are people, which deliver the Federal Intelligence Service/protection of the constitution, on radio way permanently a situation report, without noticing it, in the infancy feasiblly made? By such unofficial coworkers, with the BND and protection of the constitution, after Stasimanier, is information collected of and over,purely theoretically, each Federal citizen? Is there then still another right to Privatsphere? Who actually checks the BND, WAD and protection of the constitution for infiltration??? Into the Mail actually concerns it to me the question whether it criminal items, from which motive of enriching, or groupings from ideological motives is possible, to acquire itself knowledge and technique which were developed at other times, from other Motiven(Westfernsehen?).And does the technical knowledge status place, to that the public admits is really the end of the flag bar? Is it not to criminal items just as possible, I legend that now times played down and does nice-end, individual persons or groups with relatively simple means, to spy from whatever motives always? And doesn't this " Ausspioniererei " represent a substantial intervention into the privatsphaere? It is possible individual persons or groups, one acceptance to of a certain Oeffentlichkeit(suggeriert?), e.g. by Internet pages, how for example the " Pranger"geschaffen could become, times vorausgestzt, to terroriesieren and or chicane, and in everything (the people suggerierten)Oeffentlichkeit?Haben there at the Pranger, or on any other page to be reviled, or slandered, actually a chance to the Gegenoeffentlichkeit?Ist that not character assassination? Some years ago I am by coincidence the page " the Pranger " encountered, at that time ran not yet under the cover of the partner switching.Itself can individual persons, or communities of interests, from pure self purpose, such pages to serve, over under the cover of a doubtful Zivilkourage, through plot any rushing campaigns, own, quite persoehnliche interests to intersperse? Can such pages serve for the co-ordination of criminal machinations? The question, is it possibility or impossibility, technically and socially, individual persons, or also groupings of manipulating or of influencing from an criminal/ideological Energei, terrorizes or to schickanieren, directed.Target group manipulation by mass media are everyday manipulation, from which, more or less, can extract itself. Does the right to privatsphaere, creeping, by transmissions become deep psychological, how, for example " Big undermine brother"? If the Angemailten should be available a certain knowledge status to the topic with one, I would be glad over notes to the topic On the search for responses to my questions maile I different addresses from the Internet on, and hope up-constructional responses and criticisms.Over an attendance on the page wuerde I are pleased.If you should have been written down by me several times, then please I you to excuse me this that was not intended. The reason for my anonymity is the fact that with such Fragenstellerei, understandably, fast after the call the Psychatrie loud becomes. Which also method hat(ist). If you should feel the Mail as annoyance, I would like to apologize hereby for it! Big is watching you? Veuillez excuser le dérangement! Moi quelque chose concernant des oreilles est venu. Une cuisine de bruit relativement inhabituelle, dont on m'a placé un Sueppchen schwerverdauliches devant, est la raison de mes Mail.Aucune expression n'est peu appétissante! Il est possible sur un Wege(in funktechnischem pour quelles réponses fréquentielles?) quelqu'un influencer ou manipuler? Ou même schikanieren et terroriser? Sous le Motto:"Einen au Sender?Nich tout à fait seulement? Petits Mannim Ohr?Falsche Wellenlaenge?Bohnen dans les oreilles? Sur la dent gefuehlt(Amalgam)?Mal non contraignant reinhoeren? Le Pullacher Wanzentanz? Le Spinnerei?Das n'est-il quand même pas du tout va, ou? Et si comme cela paraît éthiquement moralement? Au côté technique de la chose, il y a certes des rapports et des Webseiten: Totalitaer,de - Die Waffe gegen die Kritik http://www.raum-und-zeit.com/Aktuell/Brummton.htm http://www.fosar-bludorf.com/Tempelhof/ http://jya.com/haarp.htm http://www.zeitenschrift.at/magazin/zs_24_15/1_mikrowaffen.htm http://www.bse-plus.de/d/doc/lbrief/lbmincontr.htm http://home.nexgo.de/kraven/bigb/big3.html http://w3.nrl.navy.mil/projects/haarp/index.html http://cryptome.org/ http://www.raven1.net/ravindex.htm http://www.calweb.com/~welsh/ http://www.cahe.org/ http://www.parascope.com/ds/mkultra0.htm http://www.trufax.org/menu/mind.html http://www.trufax.org/menu/elect.html http://mindcontrolforum.com/ http://www.trufax.org/menu/elect.html usw. usw. usw. toutefois qui ne peut quand même pas être qui on fait soetwas, ou? Une violation des droits de l'homme séparer ressembler!?! Il est possible, par la préparation, des oreilles et dans l'effet avec la prothèse dentaire éventuellement existante? Avec la technique de radio relativement simple?? Dans ce Land?Hier et aujourd'hui Sous quels motifs? Où le département est-il en réalité 5 du BND et de la protection d'constitution? peut il être qu'il y a les personnes qui livrent en permanence le BND/Verfassungsschutz, de manière funktechnischem un rapport de situation, sans le remarquer le -même , dans l'enfance rendu possible?? Par de tels collaborateurs officieux, avec le BND et la protection d'constitution, après manière, des informations sont-elles rassemblées et plus de, purement théoriquement, chaque citoyen allemand? Il y a alors encore un droit à des Privatsphere? Qui contrôle en réalité le BND, mad et protection d'constitution sur une infiltration??? Il s'agit en réalité dans le Mail me la question de savoir si lui éléments criminels, dont le motif de l'enrichissement, ou de groupements des motifs idéologiques, possible de s'acquérir le savoir et la technique qui à d'autres temps, est autre MotivenEt place-t-il le savoir technique dont le public vraiment la fin la barre de drapeau a connaissance ? Il n'est pas donc exactement la même chose possible pour des éléments criminels, moi cela maintenant fois verharmlost et minimisant une légende, personnes ou groupes particuliers avec des moyens relativement simples, de quels motifs aussi toujours, auszuspionieren?(Westfernsehen?), a été développé. Et ce "Ausspioniererei" ne représente-t-il pas une intervention considérable dans la vie privée? Il est possible personnes ou groupes particuliers, pour certain Oeffentlichkeit(suggeriert?), celui p. ex. à l'aide des côtés Internet, comme par exemple "le Pranger"geschaffen pourrait, fois vorausgestzt schikanieren terroriesieren et ou , et qui toute (suggerierten)Oeffentlichkeit?Haben les personnes ceux là, ou d'un autre côté verunglimpft, ou on ne pas calomnie, en réalité une chance au Gegenoeffentlichkeit?Ist qui meurtre d'appel? Il y a quelques années, je ne suis pas encore par hasard sur le côté "celui" poussé, fonctionnais alors cela sous la couche de pont de l'entremise partenaire. Des personnes particulières, ou des communautés d'intérêts le peuventelles, d'un autobut pur, de tels côtés servent, sous la couche de pont d'un Zivilkourage douteux, tracent plus de des campagnes de précipitation, propres intérêts tout à fait persoehnliche entremêlent? De tels côtés peuvent-ils servir à la coordination des manoeuvres criminelles? Question, est lui possibilité ou impossibilité de manipuler ou d'influencer techniquement et socialement, particulière personnes, ou aussi groupements, criminelle/ponctuel idéologique Energei dehors, , terroriser ou schickanieren, et ce.Une manipulation de groupe cible par des masse-médias être la manipulation quotidienne qui peut extraire mansich, plus ou moins. Le droit à la vie privée est-il miné, ramment, tiefenpsychologisch, par des envois, comme, par exemple "des Big brother"? Avec un les Angemailten si un certain savoir devait exister sur le thème, je serais heureux sur des indications sur le thème.Sur la recherche des réponses à mes questions je différentes adresses maile d'Internet dessus, et espère réponses et critiques aufkonstruktive. Sur une visite du côté http://hometown.aol.de/reinerhohn38259/homepage/index.html> je me réjouirais. Si vous deviez avoir été écrit à différentes reprises par moi, je vous demande de m'excuser cela qui n'était pas envisagé. La raison de mon anonymat est le fait qu'avec telle des Fragenstellerei, l'appel devient ce qui est bien compréhensible, rapidement bruyant après le Psychatrie. Ce que la méthode a également (ist). Si vous deviez ressentir les Mail comme un ennui, je voudrais m'excuser par ceci pour cela! Big brother is watching you? From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon May 20 23:57:08 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA05745 for ; Mon, 20 May 2002 23:57:07 -0400 (EDT) Received: (qmail 24505 invoked by uid 605); 21 May 2002 03:57:22 -0000 Delivered-To: ietf-ssh@netbsd.org Message-ID: <20020521035722.24503.qmail@mail.netbsd.org> Cc: recipient list not shown: ; Received: (qmail 24487 invoked from network); 21 May 2002 03:57:17 -0000 Received: from hh1120001.direcpc.com (HELO dpc000) (206.71.120.1) by mail.netbsd.org with SMTP; 21 May 2002 03:57:17 -0000 From: Gerta Reply-To: forex@forex.com Subject: FREE FOREX BOOK Date: Mon, 20 May 2002 20:50:51 -0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="6cb8739d-6c32-11d6-89c2-00a0c9279fdc" Sender: ietf-ssh-owner@netbsd.org Precedence: list This is a multi-part message in MIME format --6cb8739d-6c32-11d6-89c2-00a0c9279fdc Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable FREE FOREX BOOK http://www.royalforex.com/content.asp?id=3D32 MICRO Accounts www.royalforex.com --6cb8739d-6c32-11d6-89c2-00a0c9279fdc-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue May 21 00:11:14 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA06569 for ; Tue, 21 May 2002 00:11:13 -0400 (EDT) Received: (qmail 668 invoked by uid 605); 21 May 2002 04:11:29 -0000 Delivered-To: ietf-ssh@netbsd.org Message-ID: <20020521041129.666.qmail@mail.netbsd.org> Cc: recipient list not shown: ; Received: (qmail 635 invoked from network); 21 May 2002 04:11:14 -0000 Received: from hh1120001.direcpc.com (HELO dpc000) (206.71.120.1) by mail.netbsd.org with SMTP; 21 May 2002 04:11:14 -0000 From: Gerta Reply-To: forex@forex.com Subject: FREE FOREX BOOK Date: Mon, 20 May 2002 21:04:50 -0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="f42e929e-6c34-11d6-89c2-00a0c9279fdc" Sender: ietf-ssh-owner@netbsd.org Precedence: list This is a multi-part message in MIME format --f42e929e-6c34-11d6-89c2-00a0c9279fdc Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable FREE FOREX BOOK http://www.royalforex.com/content.asp?id=3D32 MICRO Accounts www.royalforex.com --f42e929e-6c34-11d6-89c2-00a0c9279fdc-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue May 21 00:31:55 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA07736 for ; Tue, 21 May 2002 00:31:54 -0400 (EDT) Received: (qmail 9491 invoked by uid 605); 21 May 2002 04:32:08 -0000 Delivered-To: ietf-ssh@netbsd.org Message-ID: <20020521043208.9489.qmail@mail.netbsd.org> Cc: recipient list not shown: ; Received: (qmail 9477 invoked from network); 21 May 2002 04:32:04 -0000 Received: from hh1120001.direcpc.com (HELO dpc000) (206.71.120.1) by mail.netbsd.org with SMTP; 21 May 2002 04:32:04 -0000 From: Gerta Reply-To: forex@forex.com Subject: FREE FOREX BOOK Date: Mon, 20 May 2002 21:25:38 -0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="60bb5a37-6c37-11d6-89c2-00a0c9279fdc" Sender: ietf-ssh-owner@netbsd.org Precedence: list This is a multi-part message in MIME format --60bb5a37-6c37-11d6-89c2-00a0c9279fdc Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable FREE FOREX BOOK http://www.royalforex.com/content.asp?id=3D32 MICRO Accounts www.royalforex.com --60bb5a37-6c37-11d6-89c2-00a0c9279fdc-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed May 29 20:56:17 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA09307 for ; Wed, 29 May 2002 20:56:16 -0400 (EDT) Received: (qmail 5407 invoked by uid 605); 30 May 2002 00:56:38 -0000 Delivered-To: ietf-ssh@netbsd.org Message-ID: <20020530005638.5406.qmail@mail.netbsd.org> Received: (qmail 5396 invoked from network); 30 May 2002 00:56:28 -0000 Received: from unknown (HELO maktoob.com) (217.78.74.104) by mail.netbsd.org with SMTP; 30 May 2002 00:56:28 -0000 From: "GEN.HAMA SALAMA" To: Subject: BUSINESS RELATIONSHIP PROPOSAL Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Thu, 30 May 2002 01:06:35 +0200 Reply-To: "GEN.HAMA SALAMA" Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit BUSINESS RELATIONSHIP PROPOSAL Dear Sir, I received encouraging information about you, hence I decided to contact you. I am Gen. Hama Salama, Military Commander with POLISARIO(Political Front for the Liberation of Western Sahara) and a member of council of the National Secretariat of Western Sahara(Saharawi Democratic Republic). See web site: www.arso.org or www.arso.org/secr.nate99.htm to confirm about me and also know more about Western Sahara. Prior to my promotion to this command, I was the second in command to the former military boss. He was killed in battle in early January. Some private , religious and corporate organizations who recognize us assist/aid us always in the war prosecution. Before the death of my former boss, we were given some funds(US$55m) to procures ammunitions. My boss deposited it with a private security company in Europe. It was only I and him that are aware of thiscash deposit. I now want to claim this funds and I have all the relating documents needed to collect the deposit including the Certificate of Deposit with which the Cash was deposited as Precious stones and The Deposit Agreement. I therefore want you to team up with me to collect the funds in Europe as I require a foreigner to perfect the operation. Let me know your terms. I will provide you with all the necessary documentation needed and there are no risks involved. It is a simple and straight transaction but must bekept highly confidential. Upon the receipt of your positive response, further details and the method of operation will be communicated to you. Therefore if you are interested, please do reach me via an immediate reply mail. I will want everything about this transaction to be treated in strictest confidence even if you are notinterested.I await your response. Yours Gen Hama Salama Military CommanderWestern Sahara