Re: FTP to HISTORIC? RE: [BEHAVE] Can we have on NAT66 discussion?
Not sure how wide this net is being cast but there has also been draft-ietf-secsh-scp-sftp-ssh-uri draft-ietf-secsh-filexfer-extensions draft-ietf-secsh-filexfer Tom Petch - Original Message - From: SM [EMAIL PROTECTED] To: Hallam-Baker, Phillip [EMAIL PROTECTED] Cc: Behave WG [EMAIL PROTECTED]; ietf@ietf.org Sent: Friday, November 14, 2008 6:51 PM Subject: Re: FTP to HISTORIC? RE: [BEHAVE] Can we have on NAT66 discussion? At 08:43 14-11-2008, Hallam-Baker, Phillip wrote: I propose that we either move FTP to historic or start a revision effort if there is sufficient interest in continuing it as a separate protocol from HTTP. There are a few I-D about FTP that have been submitted: FTP Extension Registry http://www.ietf.org/internet-drafts/draft-klensin-ftp-registry-00.txt FTP Extension for Internationalized Text http://www.ietf.org/internet-drafts/draft-klensin-ftp-typeu-00.txt Streamlined FTP Command Extensions http://www.ietf.org/internet-drafts/draft-peterson-streamlined-ftp-command-exten sions-06.txt FTP EXTENSION ALLOWING IP FORWARDING (NATs) http://www.ietf.org/internet-drafts/draft-rosenau-ftp-single-port-05.txt There were some discussion about one of the above I-Ds in Dublin. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: FTP to HISTORIC? RE: [BEHAVE] Can we have on NAT66 discussion?
On 14 nov 2008, at 17:43, Hallam-Baker, Phillip wrote: The Internet has two protocols that account for 95% of user interactions, email and Web. Pointing out that one of those protocols involves an IP address change en-route might be a single data point but it is a significant one. Also note that the same is true of IRC, Jabber and other 'chat' type protocols. There are very many things that I do less than 95% of the time that are very important to me. If you want to change the architecture such that IP addresses may change in transit under certain conditions, I'm willing to have that discussion, but I would rather not start from the assumption that the two most braindead protocols that we use on the internet are shining examples of how things should work. Note though that IM has a number of functionalities, and several of them operate peer-to-peer (file transfer, audio/video chat). In fact the only application protocol I am aware of that is built on the assumption that the IP address remains constant end to end would be FTP which is an antique design. Passive mode fixes this. What I really want is a standards based protocol that keeps two object stores in synchronization transparently and in real time. And I want that protocol to be sufficiently simple and free of unnecessary UI interaction that it can be embedded in a digital camera, WiFi picture frame or the like so that once a device is attached, updates are pushed transparently. To quote a former AD of some notoriety: anyone with a keyboard and time on their hands can write an internet draft. So go for it. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
FTP to HISTORIC? RE: [BEHAVE] Can we have on NAT66 discussion?
The Internet has two protocols that account for 95% of user interactions, email and Web. Pointing out that one of those protocols involves an IP address change en-route might be a single data point but it is a significant one. Also note that the same is true of IRC, Jabber and other 'chat' type protocols. In fact the only application protocol I am aware of that is built on the assumption that the IP address remains constant end to end would be FTP which is an antique design. I propose that we either move FTP to historic or start a revision effort if there is sufficient interest in continuing it as a separate protocol from HTTP. FTP does not work through NAT, does not support encryption or confidentiality in a satisfactory manner and exchanges passwords en-clair. That is not a protocol that should be allowed to be the gating factor for Internet architecture discussions. HISTORIC does not imply obsolete, or that people must stop using it, merely that it is a protocol that does not meet contemporary standards acceptance criteria and there is insufficient interest in producing a revision. There is certainly a set of file management type interactions that is handled better by FTP than HTTP. But neither protocol can be said to handle these interactions particularly well. For example, I have a bunch of digital photos on my home machine that I would like to be able to synchronize to a machine at a different location for backup security. It is somewhat easier to write scripts that upload the data via FTP, but not by much. What I really want is a standards based protocol that keeps two object stores in synchronization transparently and in real time. And I want that protocol to be sufficiently simple and free of unnecessary UI interaction that it can be embedded in a digital camera, WiFi picture frame or the like so that once a device is attached, updates are pushed transparently. This pretty much suggests to me that tweaking FTP to meet modern protocol expectations is probably not worth the effort. Better to declare it Historic and let others propose a replacement if there is a genuine need. From: Keith Moore [mailto:[EMAIL PROTECTED] Sent: Thu 11/13/2008 6:03 PM To: Hallam-Baker, Phillip Cc: Mark Townsley; Eric Klein; Routing Research Group Mailing List; Behave WG; [EMAIL PROTECTED]; ietf@ietf.org Subject: Re: [BEHAVE] Can we have on NAT66 discussion? Hallam-Baker, Phillip wrote: It is called the principle of encapsulation. The most successful Internet protocols do not involve connections to hosts today. SMTP is a connection to a service and has been for two decades. HTTP is not quite so agile but would be had we had SRV at the time. In SMTP the IP address does not remain constant end to end and never did. You're extrapolating a long way from a small sample size. Simply asserting that there will still be some need to talk to a host or an interface without giving instances is hardly a compelling argument. More proof by unsupported assertion seems to me. It's what you have to do to diagnose problems in deeply layered systems. You have to be able to strip away the layers that aren't working until you find one that does. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: FTP to HISTORIC? RE: [BEHAVE] Can we have on NAT66 discussion?
Hallam-Baker, Phillip wrote: The Internet has two protocols that account for 95% of user interactions, email and Web. Pointing out that one of those protocols involves an IP address change en-route might be a single data point but it is a significant one. it's a fallacy that you can measure the value of a protocol by looking at the percentage of transactions, bandwidth, etc. it uses. In fact the only application protocol I am aware of that is built on the assumption that the IP address remains constant end to end would be FTP which is an antique design. that's because you don't know much about protocols. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: FTP to HISTORIC? RE: [BEHAVE] Can we have on NAT66 discussion?
At 08:43 14-11-2008, Hallam-Baker, Phillip wrote: I propose that we either move FTP to historic or start a revision effort if there is sufficient interest in continuing it as a separate protocol from HTTP. There are a few I-D about FTP that have been submitted: FTP Extension Registry http://www.ietf.org/internet-drafts/draft-klensin-ftp-registry-00.txt FTP Extension for Internationalized Text http://www.ietf.org/internet-drafts/draft-klensin-ftp-typeu-00.txt Streamlined FTP Command Extensions http://www.ietf.org/internet-drafts/draft-peterson-streamlined-ftp-command-extensions-06.txt FTP EXTENSION ALLOWING IP FORWARDING (NATs) http://www.ietf.org/internet-drafts/draft-rosenau-ftp-single-port-05.txt There were some discussion about one of the above I-Ds in Dublin. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
