Whoops, I just realized that there could be a problem with the
recursive RFC-XXXX format method.
If I send a uuencoded, compressed tar file using the recursive method,
and the receiver does not have one of those new UAs, he/she will first
have to uudecode the body, then invoke a binary editor to remove the
header from the result, then uncompress, then remove another header,
and so on. I don't think it's reasonable to expect the poor user to
have a binary editor, nor can we expect the user to be able to edit
out the header perfectly.
So we should stick to non-recursive methods, e.g.:
Body-Type: uuencode, compress, tar
Of course, we can adopt the recursive method so that there is an
incentive for users to upgrade to a better UA, but I think it would
cause too much of a hassle. The receiver would have to either (a) take
the trouble to edit out the headers, or (b) ask the sender to re-send
in a better format, which would be a hassle for the sender. Or (c) get
a new UA, but that may take some time.