Re: MML 'encoding' tag value ignored...

[Daniel Pittman <daniel@rimspace.net>]

On 28 Feb 2001, Toby Speight wrote:
> 0> In article <87d7c3o54j.fsf@inanna.rimspace.net>,
> 0> Daniel Pittman <URL:mailto:daniel@rimspace.net> ("Daniel") wrote:
> 
> Daniel> In trying to work out why a PDF file was being corrupted when
> Daniel> sent from Gnus to several Win32 mailers, I found two things.
> Daniel>
> Daniel> Firstly, Gnus was selecting quoted-printable encoding for the
> Daniel> PDF file.  This was then incorrectly decoded by both Outlook
> Daniel> and Eudora on the Win32 machine, resulting in a corrupt PDF
> Daniel> file.
> Daniel>
> Daniel> Specifically, LF => CRLF conversion was happening on the Win32
> Daniel> machine.  Now, I don't know the QP spec well, so I can't tell
> Daniel> if this is correct behaviour for the Win32 machines.
> 
> I think the fix for this is to quote LF and CR in non-text parts:
> 
> <LF>     ->  =0A=<CR><LF>
> <CR>     ->  =0D=<CR><LF>
> <CR><LF> ->  =0D=0A=<CR><LF>

Well, if it were possible to ship PDF files as QP without Win32
exploding, that would be great...

> Daniel> If it is, though, I think that 'application/.*' MIME entities
> Daniel> should be encoded with base64 exclusively, to avoid this sort
> Daniel> of problem.
> 
> I thought you could Configure that somehow?
> 
> [/me RTFMs]
> 
> `mm-content-transfer-encoding-defaults' is what you're looking for,
> though it's not defcustom in 5.8.3.

Well, no. `mm-content-transfer-encoding-defaults' now features
`("application/.*" base64)' for me, but that's not the point.

The point is that the MML tag specified an encoding. Explicitly. Because
I put it there.

This, according to the documentation, should override whatever is in
`mm-content-transfer-encoding-defaults' because I, as the user, wanted
something different in this case.

Heck, the code in the MIME composing is even written in an attempt to
make this possible, I think.[1] It's just not _used_ in the code.


Seriously, though, what would you expect this MML tag to encode the
content as?

<#part type="some/type" encoding="base64">

I know that /I/ expected base64, regardless of what the *default*
encoding of MIME objects of "some/type" was. Because I told Gnus what I
wanted.

        Daniel


Footnotes: 
[1]  I didn't quite follow through what was implemented but there is
     *definitely* support in `mm-encode-buffer' for specifying an
     explicit encoding.

-- 
Estne Tibi Forte Magna Feles Fulva Et Planissima?