> >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 _______________________________________________ Nmh-workers mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/nmh-workers
