Logged In: YES 
user_id=113859

I did not write that "no filetype has parameters" 
and I know how to operate Roundup's detectors. 
Thanks for the lecture. 
 
My first post was about that roundup need to record 
and then set the charset parameter for text/plain file 
attachment on all occasions. This does not seem to be done 
yet. Sending out an 8bit attachment without that parameter 
calls for trouble. I did not look up if latin-1 or utf-8 
should be assumed in this case, but anyway, it is quite 
likely to be wrong.  
 
You have not answered my question wether your patch will 
fix the scenario for the bug that I have described, btw. 
Can I include that you agree that the charset parameter 
should be saved and that this is not the case currently? 
Then we only disagree if this should be done by default 
or not. I say: Yes, it is a serious bug as roundup is 
unusable in environments where e.g. latin-1 and utf-8 based 
texts are used. Umlauts break frequently and users 
rightfully think that this is the software. 
 
My second post was about where to save the parameter. 
Just because in emails this is saved in a body part header 
file as string in a parameter, roundup does not need to do 
this. From your answer I conclude that you like method a) 
best and do not care about the style of code when the  
string is parsed. Also you want places within Roundup (not 
within RFC anything) to break if they have made the 
assumption that "type/subtype" is what they get as string?