On Mon, Jan 10, 2022 at 06:08:12PM -0600, Derek Martin wrote:
On Sat, Jan 08, 2022 at 02:46:48PM -0800, Kevin J. McCarthy wrote:I'm thinking about enabling $rfc2047_parameters by default, and would like to hear any counter-arguments against this.I believe the original argument against was that doing so violates the RFCs, and therefore potentially obscures a header that actually wanted that text to appear in the header in conformance with the spec.
I guess it's theoretically possible someone would want an attachment named that way, but it doesn't sound likely. :-/
However--and my memory on this is as vague as ever--wasn't there an update to the RFCs that expressly allowed it in headers for which it wasn't previously allowed?
If anyone else has a pointer please let me know, but I'll try to take a look.
One certainly might raise the question of why it was originally excluded from the spec... There was probably a reason, but I don't know it.
I think it's because 2231 both provides encoding and allows the parameters to be split across multiple lines and reassembled. The intro to the rfc also discusses the reason language information was added.
-- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
