[issue1693546] email.Message set_param rfc2231 encoding incorrect

R. David Murray added the comment: No, I was wrong. This would only be an issue when a parameter's value is changed, and at that point we should be producing correctly (un)quoted values no matter what the original quoting of the individual value was. So I've applied the patch in r87479. ---

[issue1693546] email.Message set_param rfc2231 encoding incorrect

R. David Murray added the comment: I take it back. Previously quotes didn't get added if they weren't already there. So my simpleminded fix may not be the best choice. -- ___ Python tracker __

[issue1693546] email.Message set_param rfc2231 encoding incorrect

R. David Murray added the comment: Reading the RFC again, I think you are right. The quoted vs unquoted sounds like it refers to the *n vs the [*n]* forms, and the latter doesn't use quoted strings but % encoding. I'm attaching a patch that adds some tests and fixes this. It's a visible be

[issue1693546] email.Message set_param rfc2231 encoding incorrect

Changes by Mark Lawrence : -- versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6, Python 3.0 ___ Python tracker ___ ___ Pytho

[issue1693546] email.Message set_param rfc2231 encoding incorrect

Changes by Barry A. Warsaw : -- assignee: barry -> r.david.murray status: pending -> open ___ Python tracker ___ ___ Python-bugs-lis

[issue1693546] email.Message set_param rfc2231 encoding incorrect

R. David Murray added the comment: Hmm. The RFC text says: Note that quotes around parameter values are part of the value syntax; they are NOT part of the value itself. Furthermore, it is explicitly permitted to have a mixture of quoted and unquoted continuation fields. So this l

[issue1693546] email.Message set_param rfc2231 encoding incorrect

Changes by Daniel Diniz : -- assignee: -> barry nosy: +barry stage: -> test needed type: -> behavior versions: +Python 2.6, Python 3.0 ___ Python tracker ___ ___