2010/1/11 Robert Collins <email address hidden>:
> On Mon, 2010-01-11 at 04:48 +0000, Martin Pool wrote:
>>
>> You're already partly using mime here, so I think you might as well do
>> it the rest of the way, by specifying a content-encoding for the
>> attachments. They could be quoted-printable for things that are
>> mostly text (like tracebacks) but need to be sent byte-for-byte, plain
>> text for things like tracebacks, and base64 for tarballs.
>
> Do you mean transfer encodings perhaps? They already do specify a
> content encoding?
really? where?
they seem to only specify a content-type at the moment.
> 1. It indicates whether or not a binary-to-text encoding scheme has been used on top of the original encoding as specified within the Content-Type header, and
> 2. If such a binary-to-text encoding method has been used it states which one.
however, this doesn't mark boundaries between attachments.
2010/1/11 Robert Collins <email address hidden>:
> On Mon, 2010-01-11 at 04:48 +0000, Martin Pool wrote:
>>
>> You're already partly using mime here, so I think you might as well do
>> it the rest of the way, by specifying a content-encoding for the
>> attachments. They could be quoted-printable for things that are
>> mostly text (like tracebacks) but need to be sent byte-for-byte, plain
>> text for things like tracebacks, and base64 for tarballs.
>
> Do you mean transfer encodings perhaps? They already do specify a
> content encoding?
really? where?
they seem to only specify a content-type at the moment.
istm that what is wanted here is a content- transfer- encoding which en.wikipedia. org/wiki/ MIME#Content- Transfer- Encoding>
<http://
> 1. It indicates whether or not a binary-to-text encoding scheme has been used on top of the original encoding as specified within the Content-Type header, and
> 2. If such a binary-to-text encoding method has been used it states which one.
however, this doesn't mark boundaries between attachments.
-- launchpad. net/~mbp/>
Martin <http://