[Email-SIG] Problem Report for email.Utils.decode_rfc2231

[Mark Sapiro]

Barry Warsaw wrote:
>
>The way I read the RFC however, I don't think the patch is quite  
>right.  Specifically, you can mix encoded and non-encoded segments in  
>an extended parameter, like so:
>
>filename*0*="This is%20encoded"
>filename*1="This is%20not encoded"
>
>I believe this should end up with a 'filename' parameter with a value:
>
>This is encodedThis is%20not encoded
>
>Further, if any segment ends in a * then the charset and language  
>information must appear at the front of the string, but this is  
>decoded after segments are %-decoded and all the segments are  
>concatenated together. (The RFC appears to be a bit ambiguous here,  
>but this is the only interpretation that makes sense to me.)


I agree with the above. I considered that there could be mixed encoded
and non-encoded segments, but I was focused only on not trying to
split the charset and language info when it wasn't there, so my patch
is over-zealous and will decode non-encoded segments in the mixed case.

I'll take a detailed look at your patch tomorrow I hope and let you
know what I think.

-- 
Mark Sapiro <msapiro at value.net>       The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan