Werner writes:
I'd say don't deprecate anything, the 'u' is merely a flag that the
message is for sure utf-8 encoded. It's up to the MUA[1] to create
and display a message correctly, that flag might be helpful. Maybe a
"If it is definitely known that the message is utf-8 encoded, the 'u'
flag SHOULD be used."
I'm concerned that it's going to be hard to clearly specify when 't'
should be used and when 'u' should be, and likewise how to distinguish
the handling of 't' from 'u'. Should 't' prompt the recipient to try
to guess what character set it is, i.e. prompt the user to choose
a charset? That's going to make things inconvenient for all the old
't' encrypted files around.
And what about the problem with 'u' causing CRLF's to be left in files
when decrypted by legacy versions? That would suggest that in at
least some cases (like plain ASCII text) it would be better to use 't'.
This is true even though plain ASCII is legal UTF-8 and so the rule you
suggest would suggest to use 'u'.
It's not that this is a bad idea, it's just that it's hard to codify
the unfortunately messy situation that we are in now.
Hal