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

Re: Distros

> Have you ever actually implemented the protocol?

Yes. I have. My current assignment is implementing RFC 2228 (aka FTPS or "FTP 
over SSL" - not to be confused with SFTP (which is like-FTP over SSH).

>  It's a crufty,
> error-prone protocol that is positively hostile to firewalls.  The
> only "protocol" that is worse that I am aware of is rsh/rlogin.

I disagree. It's not error-prone at all. In fact, the protocol goes to great
lengths to require transfer integrity, and the command protocol is based on 
Telnet. The whole thing is based on TCP/IP, so that adds another layer against
your "error-prone" claim. I don't understand how something that is hard for 
firewalls makes a protocol "error prone". Is rsh/rlogin "worse" because it's 
error-prone or hostile to firewalls? I think you're making value statements 
like '"old" equates to "bad"' and are disappointed that FTP doesn't meet your 
newly imposed feature requirements after the fact of its creation.

That said, I do agree that many FTP *implementations* are often incomplete, or 
worse, incorrect. In addition folks have bolted on various "enhancements" with 
varying success at adoption - each with their own set of incomplete or 
incorrect implementations. Not much different than other standards - IP,
HTML, ECMAScript, 802.11b, XSLT, HTTP, RPC, etc. - in that respect. So is FTP
error prone? No. Is implementing an FTP server/clients? Yes, by observation.

See: http://mcarpenter.free.fr/Dev/sftp.php3 and

> FTP should have been abandoned years ago.

Well, it won't happen until rsync gets an RFC if that's how you feel about it.

I don't think that HTTP will be RFC'd into a better replacement, since it
actually does a worse job of file transfer than FTP does. And I've never
seen an RFC for SFTP, although it has been in IETF draft form for some time.


From http://www.ietf.org/ID.html ...
Internet-Drafts are not an archival document series. These documents should not 
be cited or quoted in any formal document. Unrevised documents placed in the 
Internet-Drafts directories have a maximum life of six months. After that time, 
they must be updated, or they will be deleted. After a document becomes an RFC, 
it will be replaced in the Internet-Drafts Directories with an announcement to 
that effect.

As for rsync ... well, it's up to Tridge.

> Honestly though, I only see two realistic options for transfering
> large files.  (Maybe three, depending on how you count.)  One is
> rsync, which is useful for all the things FTP used to be useful for,

So when did FTP stop being useful to transfer files just because rsync
showed up?

BTW, if you say "compression", you should read the FTP spec (RFC 959) again.
However, I previously mentioned meny implementors don't implement all of
RFC 959, in particular, the compressed mode (MODE C).

I'm not saying FTP is the best thing since sliced bread. I'm saying your
statement that FTP is "old and crufty" because it is, well, "old and crufty"
is quite circular in nature and isn't the objective criticism or opinion 
you hold it out to be. You are enamored with the "shiny new toy" of rsync,

I'm not saying there's nothing wrong with FTP. Two connections is quite
smart. Synchronizing them isn't easy. Passing IP addresses and ports
over a connection makes FXP transfers easy, but traversing firewalls and
NAT is a real PITA.

I'm not saying rsync sucks. I think it's a much improved proposal over
FTP. But Tridge needs to get off his duff, form a working group and get
it into an RFC for the standards track.

Until that happens, you'll never see widespread government or corporate 
adoption of rsync, since there's no public standards body that's accepted it.

Don't confuse popularity with standardization. That's why we have Microsoft.

BTW, As Ford-Hutchinson (URL above) can attest, FTP-over-SSL (RFC 2228) is 
in just as sad a state of affairs as FTP (RFC 959).



To unsubscribe, send email to majordomo@luci.org with
"unsubscribe luci-discuss" in the body.