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

[Ken Hornstein]

>`*8bit' wouldn't look to the future.  How about `field:value' as I don't
>think it can be mistaken for any of the existing syntax?  It could also
>occur more than once if future needs arise.  `cte:8bit'.

I'm not sure I follow that it wouldn't look to the future.  I was really
thinking of "*" as being the start character to indicate the CTE.  So
you could have *8bit, *q-p, *base64, whatever.  I don't see many (any)
new CTE's being defined, but note that it's not a case of just copying it
into the MIME draft, like every other header; it needs to be interpreted
by mhbuild to perform the necessary encoding.

Also, I'd rather avoid anything that could look like a filename, and
"cte:" is unlikely but closer to a possible filename than "*".  Also:
easier to parse.

>In general, it would be nice if nmh chose the `best', allowing me to
>override it.  I'd favour 8bit if the text doesn't violate it, then
>quoted-printable, then, if that was too noisy or bloated, base64.  This
>would avoid me having to observe nmh complain 8bit wasn't possible and
>manually downgrade to QP.

Well, what's "best"? :-)  My thinking is this:

- We'd switch to a default of 8bit for text/* parts.
- You could override that default on the mhbuild command line (and of
  course via .mh_profile)
- Whatever you put in the mhbuild directive would override the default.

--Ken