- 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 such distinctions are only rarely recognzied by existing
mbox-reading software - and are of even less consequence to humans.
having more knobs introduces the potential for those knobs to be set
incorrectly. this can cause more interop problems than not having the
knobs in the first place.
- 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.
I said "reccommend...as a default" not "require". If the sending MUA wants
to scan the entire message to determine whether q-p or 8bit or 7bit is more
appropriate, it is free to do so.
Keith