Re: [Nmh-workers] Syntax for choosing content transfer encoding

[Ken Hornstein]

>"*8bit", etc., is fine.

Ok, great.

>I assume the most likely use would be to specify 8bit, q-p,
>or base64 when mhbuild wouldn't pick one of those on its
>own?

Well, there have been a couple of times when the default used by mhbuild
is wrong (and by "wrong" I mean, "not what I wanted").  I'd prefer 8bit
for text content, for example, but I could see wanting to pick q-p for
some text parts depending on who I'm sending to.  Also, I've occasionally
had to deal with "application/x-patch" parts and those are by default
encoded with base64; I'd rather do 7bit or 8bit.

>If I tried to use 7bit or 8bit for something that
>needs to be encoded, would it just ignore that?  If
>so, maybe "?8bit" to convey that it's more of a suggestion
>than a selection?

Well, I think that if you specify "7bit" for something that has octets >127,
that's an error.  Same goes for the other rules (embedded CR).  That suggests
to me that since the line end character on Unix is just a bare LF, mhbuild
should reject encoding drafts with 7bit or 8bit if they contain a CR.  So
in short, the "normal" mode is to take the automatic rules, but if you
override them the content has to be valid.  And there will be a mhbuild
switch to select the default encoding for text parts.

I see one wrinkle; you aren't supposed to have a composite MIME type of
7bit if one of the enclosed parts is 8bit.  I'll have to dig into the
code to see how hard that will be (perhaps the right answer is to
make a C-T-E for all multiparts be 8bit).

--Ken