[Top] [All Lists]

Re: Sieve Vacation and draft-moore-auto-email-response-04

2003-10-31 18:10:02

ned(_dot_)freed(_at_)mrochek(_dot_)com wrote:
>> Ned Freed writes:
>> > Is there any reason it can't be both?
>> Not particularly - I just like protocols that make up their mind. Call
>> it OSI/ISO-induced paranoia.
> Personally, I'm more afraid of introducing silly states. What does it
> mean when the switch is set to "non-mime" and there are encoded words
> present. Or vice versa.

I agree; I think this is likely the right thing to do.  I intend to
write this up.  However I'm concerned about two things.

First, what is an editor client supposed to do when it encounters an
encoded-word string?  Obviously it could present =?ISO-8859-1?....?= and
invite the user to edit it by hand.  Perhaps that's the appropriate
thing, but I'm worried how such things could be misinterpreted.  This is
at least consistent with some of the other things we've done, and I
think it's the right way to go, though.

I suppose the obvious thing to do would be to let the user edit the charset field separately from the content of the field. But this
gets very complex very quickly -- there are lots and lots of charsets
and what do you do when they pick a charset that doesn't support all
the characters that were specified?
Simply allowing access to the raw encoded words in the editor is probably
what's going to happen in any case.

I also suspect that some regions expect UTF-8 input in this context to
be in a more favored charset on outbound.  I think permitting implicit
transcoding (or at least not forbidding it) is appropriate.