Re: [Nmh-workers] Understanding nmh (aka. What's the goal) [ really non-ASCII message bodies ]

[Jon Steinhart]

> >The existing code takes a non-ASCII message body and sends it as an 
> >attachment
> >of type application/octet-stream.
> >
> >Your patch changes this behavior so that it is sent as type text/plain with 
> >the
> >appropriately chosen character set.
> 
> You know .... I'm all for backwards compatibility and everything, but
> I'm wondering ... did the previous behavior actually make sense?  Can
> people argue that it was desirable or correct?  Or was the previous
> behavior actually wrong, and this is really fixing a long-standing
> bug?  Because if we decide that the previous behavior is a bug, then
> I don't think an explicit enable option for this chance makes sense; I'd
> prefer that the new behavior be the default.
> 
> (I am personally on the fence regarding whether or not the previous
> behavior is a bug).
> 
> --Ken

Don't disagree with you.  The current behavior was the best idea that I had
at the time and nobody has said anything about it until recently.  I don't
mind it changing, but I don't want to all of a sudden get complaints from
people who were counting on this behavior.  Maybe that number is 0, but I
have no way of knowing.  I don't care that much, so if you think compability
isn't an issue here that's fine with me.

If the defalt behavior was to change I would add a "binary" flag to
make_mime_composition_file_entry() so that the body didn't have to be
scanned for non-ASCII characters twice.

Jon