On Dec 17 2004, Keith Moore wrote:
it depends on what you mean by transferable. surely a mail client
could use IMAP to move a message+annotations from one server to another
(as long as both source and destination servers supported that
feature), or from one folder to another.
That's certainly easy to do. But what bothers me with this is the prospect
of having message (meta) data which can't be accessed for a variety of
reasons. Perhaps the following is too simplistic or abstract:
Currently the RFC 2822 format is flexible enough that a message can be
considered a self-contained object. This is a very powerful property
because messages can be moved around the world in many ways, not just
the mail system.
They can be moved by protocols such as SMTP, IMAP, POP3, they can be
cut and pasted into applications, they can be imported/exported to and
from servers, they can be stored or archived in mbox or maildir
format in any filesystem. All of this is possible because a message is
only a stream of bytes with some structure, and programs need not fully
understand the structure to be able to do some useful things.
Enter annotations, which would be meta information about a message,
accessible via particular protocol extensions. Such information, if
not embedded into the message, would be lost by the kinds of operations
mentioned above. So the annotations would be second class information,
stuck inside a given server, and only extracted with some effort.
Perhaps that's what annotations ought to be? The last paragraph above
is nearly beginning to look like a definition.
OTOH, it's not at all clear that annotations should be forwarded along
with a forwarded message. certainly there are cases where this is not
appropriate.
As I said above, I like the self-containedness of RFC 2822
messages. It's well documented, both simple (if the MIME structure is
ignored) and complex. Separate annotations would break this, unless
annotations were considered value-less to most other software, as
there would be some extra effort required to access them. But who's to
say what has value in the long term?
Conversely, having annotations travel with the message (i.e. embedded
somehow in the RFC 2822 format) will certainly encourage third party
use of such information in the long run. So it will tend to add
cruft.
I don't know what I think of these options yet. I guess one way to think
of the question is this: if annotations exist as part of the message,
then they do not impose new requirements on the existing transport
infrastructure. While if annotations are intrinsically separate from
the message, then the transport infrastructure must be aware of them,
e.g IMAP needs an extension to access them, POP3 will need another
extension, etc.
--
Laird Breyer.