I quite strongly agree with Iljitsch on this one.
Having a well-defined format that can be used for files
is very helpful. The biggest advantage would be that it
makes it easier to switch MUAs.
At 07:37 04/02/26 -0500, Bruce Lilly wrote:
I don't think that's practical:
1. platform differences affecting file sizes,
The format could come in single-message and multiple-message (like
current mbox) variants. The later should just be a concatenation
of the former, or otherwise a very trivial transform.
And in general, file sizes shouldn't be that much of a
ability to control access,
ability to lock portions of a file for update, etc.,
sharing a format doesn't necessarily mean having access
at the same time. Being able to do that may lead to
very interesting new applications, but it's not that
not to mention
record-oriented systems (e.g. Bitnet),
On the way out, not worth caring about too much
(as Iljitsch said, nobody should be forced to use
differences in line endings,
bit- and byte-ordering, etc. ad infinitum
That's an issue anyway.
2. metadata used by different applications (e.g. IMAP requires, and POP
supports a UID per message)
Well, the new format should be designed so that these can be
added, and where possible shared.
IETF doesn't generally define storage formats, rather formats used for
network transfer. One might devise a format for sending a collection
of messages, and it might look like multipart/digest...
The IETF doesn't generally do this, but when there are good reasons, why not?
Or designing the message format so that it can be trivially used for
file storage (currently SMTP uses a . to terminate DATA, and mbox
uses From to start a message; just removing this difference would
bring us a long way; the problem is essentially the same).
Applications running across a network can access mailboxes via
established network protocols for accessing or transferring messages
and mailboxes, such as POP and IMAP.
There are many other things to email, such as procmail,...