In <621AC392-F0C2-11D8-928C-000393DB5366(_at_)cs(_dot_)utk(_dot_)edu> Keith
Moore <moore(_at_)cs(_dot_)utk(_dot_)edu> writes:
- my preference is to not have parameters describing format variants at
all, as they're highly unlikely to be used correctly and even less
likely to be generated correctly. if you must have parameters, make
them optional.
I agree that the parameters should be optional (the sender might not know,
or he might have constructed the mbox by concatenating a bunch of other
mboxen of varied and dubious provenance).
But it is too pessimistic to predict that they will not be used/generated
correctly. Why ever not? And even if not, then you know exactly where to
point your finger.
But the common case will be where the sender is transmitting his own
inbox, or some folder from his own machine, which will have been generated
previously by his own MDA or MUA; so it will be in a consistent and known
format. So why on earth not let him describe that format in a parameter if
he knows it?
- recommend base64 encoding as a default for transport of mbox files
over email, since the encoder typically has no idea about the message
contents and whether they might contain binary data.
No. In the common case where the 'blobs' are in fact RFC 2822 + MIME
messages, they will already contain their own CTEs. And if they
occasionally contain raw binary, then the sender (who knows where he got
them from) is in the best position to decide whether an overall base64 is
necessary.
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk Snail: 5 Clerewood Ave,
CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5