RFC - e-mail in tough environments

[Sergey Matveev]

Greetings,

On Thu, Dec 10, 2009 at 03:48:18PM +0000, Peter Lewis wrote:

> Absolutely, as you quite rightly say, 30 or so years ago. But nowadays the terminal is _one way_ of reading email. There are now others, and in my very humble opinion, cultural conventions should always be able to be updated to move with the way people actually use things.

But, you are using email system that is 30 or so years old. All email
message format (RFC822 AFAIR), SMTP, POP3/IMAP, mbox/Maildir, MIME,
Base64/Quoted-Printable -- nearly everything of this is for old 30-40
years old systems. You are using it -- you can not change any rules,
protocols, formats and specifications. If you will -- you will get the
very different system, of course that can work quite good with unlimited
lines.

> This is of course valid, though the client could detect the size of the terminal and wrap accordingly, no (assuming there was also an option to disable it)?

Why not to do it reversely? If no postprocessing to 72-formated message
is applied -- it will be ideally shown on all terminals. If you have got
Web-interface, cellphone or netbook -- you can switch some kind of
postprocessing on to trim all newlines and do whatever you want. Why
should increadible amount of an old-style email writers switch to
something? Why not just to format your message 72-chars per line and
everyone will be happy? :-)

> This is probably the best argument, i.e. if what is being sent is code, a patch or something which isn't natural language where line breaks have other meanings... but couldn't (shouldn't?) these go in attachments anyway?

Why should we change email to look like Web? It is very different
fully undependent systems.

-- 
Happy hacking, Sergey Matveev                   () ASCII Ribbon Campaign
FSF Associate member #5968 | FSFE Fellow #1390  /\ Keep it simple!