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?
Because that's what past experience with similar schemes indicates will happen.
And even if not, then you know exactly where to
point your finger.
Which sometimes works and other times only serves to get your finger bitten
off. Being right isn't always sufficient. For this reason it is much, much
better to eliminate as many potential casues for interop failure as possible.
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?
For all the reason I have previously given.
- 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.
This I agree with. Encoding isn't always necessary or even appropriate.
Ned