`*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
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers