Date: Tue, 23 May 2017 09:35:52 +0100
From: Jon Fairbairn
<jon(_dot_)fairbairn(_at_)cl(_dot_)cam(_dot_)ac(_dot_)uk>
Message-ID: <wfd1b0km1j.fsf@calligramme.charmers>
| One of the first things I learnt was that
| using in-band data as a separator is a bad idea,
Like most generalizations, that is sometimes true, but sometimes not.
| so mmdf was obviously a more sensible format than mbox.
Which doesn't follow at all, as MMDF is also using in-band data as
a separator, just a different one.
I never really used MMDF format, so I am not sure of its details, but
as I understand it, the only real issue with mbox format is that the
conversion isn't invertible, that is, in that format, a line that used
to start "From" is stored as ">From" (which exact lines that happens to
depends upon implementation to some extent, but that doesn't matter),
whereas an input like that started ">From" is also stored as ">From".
When it comes time to extract the message, there's no way to invert that
addition of the '>' as there's no way to determine whether the '>' was
one that was added for this purpose or not.
If the mbox encoding format had been properly designed, rather than just
a "we need some way to fix the problem that a line starting 'From' in
a message acts like a separator" (which was a real issue/bug in early
implementations of it) this issue wouldn't arise.
There was one attempt to use (essentially, though as I recall, not quite
implemented that way) out of band data for mail collection files - that
is, adding a header and length field (much like tar format, or cpio, etc,
but much simpler) but which was a spectacular failure, and hated much more
than '>From' (which is mostly an annoyance, though it does screw integrity
checking). It failed as the messages were still text files, and people
like to edit text files - an in-band separator mechanism isn't affected
by that, but a length field of some kind, which is what an out of band
mechanism requires usually, is, and mangled e-mail archives were far too
frequent with that mechanism.
kre
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers