New Mail RFCs Released

Anonymvs Cowardvs writes "Well, it looks like after their 20-year reign, RFCs 821 (SMTP) and 822 (mail message format) are history. The replacements, RFCs 2821 and 2822 are available now (2822 was just released). Apparently they reserved the numbers, no cosmic coincidence here."(Read on for more.)

"It's weird. Both 821 and 822 looooong predate my time on the Internet, and you sort of get used to them being as if written in stone. Doesn't look like the changes were too radical -- mostly just catching them up to current practice -- but that's a lot of text that I haven't got through yet and there's surely some gotchas in there. Does your mail client or server (or netnews client, since they use the message format) comply?

And this is the first time that Jon Postel's name has seemed conspicuously absent to me..."

Comments

Re:Why the wasted time and energy?

[Zeinfeld]

Not sure what you're smoking, but FTP is considerably more efficient for data transfer than HTTP. (Just try timing downloads of something like, say GNOME using both FTP and HTTP - you'l find that FTP will almost always win...)

FTP requires two separate connections for a data transfer, HTTP requires only one. Packet for packet there is no circumstance in which FTP does not require more packets than HTTP.

There are many inefficient HTTP servers arround, mainly those that try to do intelligent processing of some sort on the content. Also HTTP servers are usually designed to handle lots of requests for small chunks of data rather than infrequent requests for big blocks at a time. Equally comparing a GUI based HTTP client against a line mode based FTP client is ridiculous. Use a good line mode HTTP client and it is much faster than FTP.

Protocol efficiency has nothing to do with implementation efficiency. HTTP is the more efficient protocol.

There are many 'protocol jocks' who think they could have done better. Many are full of it. I don't know anyone seriously suggesting FTP as a design exemplar who has actually coded it (as I have BTW).

BEEP and HTTP-NG address a set of problems that simply do not exist in the FTP world. There is no reason to multiplex sessions onto a single conection for file transfer. The processing overhead of HTTP ASCII headers is common to most IETF protocols and is negligible.

FTP is intentionally designed the way it is so that it would force the TCP stacks to mature much faster than they would have otherwise...

Opening and closing TCP connections has a dramatic negative impact on performance. Each time a TCP connection is opened the van Jackobssen slow start begins from scratch. That is the limiting factor for transfer. Ever wondered why when transferring files on a broadband conection the transfer speed continues to accellerate for 10 to 15 seconds?

I don't think the story is true by the way. It was simply a joke told round the IETF.

/.ed

[sllort]

since we just /.ed the RFC editor site to hell, have a mirror of both

sigh.

Be conservative in what you send and liberal in what you receieve.