RFC - e-mail in tough environments

Peter Lewis prlewis at fsfe.org
Thu Dec 10 15:48:18 UTC 2009


Hi Sergey,

On Thursday 10 Dec 2009 13:37:14 Sergey Matveev wrote:
> On Thu, Dec 10, 2009 at 01:15:24PM +0000, Peter Lewis wrote:
> 
> > >     - *Line break of e-mails* Should be around 72 characters. Nobody
> > >       will kill you if it is 70 or 74 or even 76. But a lot of people
> > >       will get angry if you do not have a line break at all.
> > 
> > Can I ask what the reason behind this is?
> 
> That is because of email systems was created when most users have
> standart terminals without any GUI. The standart terminal's workspace
> size is 80x25 (24?) characters. No more, no less. It is standart.

(and from below)
> If you are using system that is 30 (40?) years old -- you should know
> it's rules. Even RFCs will tell you about 80/72 characters issues.

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.

> Modern email clients like Mutt, Gnus, Mailx, Pine, etc of course use
> terminal too. And it is really VERY ugly to read messages with lines
> longer that 80 characters. 72 is some kind of "protective"-layer between
> text itself and standart terminal's width of 80 characters. You know --
> line numbers in Vi(m), line borders of email client, maybe too long
> words and so on.

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)?

> If it will use dynamic wrapping, then noone can guarantee you that you
> read EXACTLY what I send you. In HTML you have to use <pre>-tag for
> what, all email always was used oriented (repeating again) on terminals
> and so on, that is why it should not do anything with body (more or
> less).

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?

Pete.



More information about the Discussion mailing list