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