FTP to HISTORIC? RE: [BEHAVE] Can we have on NAT66 discussion?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Title: 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:moore@xxxxxxxxxxxxxxxxxxxx]
Sent: Thu 11/13/2008 6:03 PM
To: Hallam-Baker, Phillip
Cc: Mark Townsley; Eric Klein; Routing Research Group Mailing List; Behave WG; v6ops@xxxxxxxx; ietf@xxxxxxxx
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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]