ietf
[Top] [All Lists]

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

2008-11-14 11:43:36
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(_at_)network-heretics(_dot_)com]
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(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
<Prev in Thread] Current Thread [Next in Thread>