Comment 5 for bug 505078

On Sat, 2010-01-09 at 08:47 +0000, Martin Pool wrote:
> The root cause of this is that the subunit protocol and implementation
> requires the file contain plan carriage returns in some places, and
> crlf
> in others. If you lose the linefeeds, you get this error.
>
> In a sense this is user error: I copied the text from a terminal which
> lost the linefeeds. However requiring this seems to make things
> unnecessarily difficult for something that's meant to be a human-
> readable interchange format.

So, the following:
3\r\n
0\r\n
0\r\n

(a single chunk consisting of '0\r\n') if copied and pasted will fail to
parse even with a more relaxed parse because it would become:
3\n
0\n
0\n

Now, I appreciate that many attachments will not contain \r and so not
fail in this way - but tabs are also lost by some terminals.

Sadly, the tensions:
 - relatively easy for humans to read
 - binary attachment safe

have caused simple copy and paste to stop being as robust. Now, I've
documented the multipart stuff as experimental, to permit it to be
changed if needed. We could uuencode the contents of the attachments,
but that would make them considerably less human inspectable IMO.

-Rob