Plain text

Sarah Novotny is worried about the reliance of the Linux kernel development process on plain text email. Inevitably a lot of people are sniping at her¹, because 'it's easy to configure email clients to use plain text'. She is, however, right.

The reason that she is right is that 'plain text' now has two different meanings.

• The first, newer, meaning is now the most common one, which is that 'plain text' means that the you can only type text – there is no support for tables, boldface or anything else, and if you want to express those things you do so with markup like **bold** for instance. Very austere² versions of this may require 7-bit ASCII.
• The second, older, meaning is that the system will preserve exactly what is typed into it.

Email systems (mail user agents, or MUAs) are often easy to configure to use plain text in the first sense, but generally impossible to configure to use plain text in the second sense: they will, for instance, wrap lines because email transports (MTAs) have often often been fussy about line lengths. Responsible email systems will probably do this with the MIME quoted-printable encoding, to ensure that no lines longer than 76 characters go through the mail transport.

That means that what arrives in your mailbox is often not what was sent, in the sense of being the same sequence of octets, even if it is 'plain text'. Not only does the quoted-printable format have to deal with making sure lines are not too long, it also has to escape its own escape characters, which means that = signs get encoded, for instance. = does occasionally occur in code, I'm told.

It is kind of amusing that the people who are so vigorously declaiming that plain text is easy have forgotten – or, more likely, never knew – what 'plain text; once meant, and what it still means for Linux kernel development, which is the first definition.