[EAI] Re: HDR=UTF8SMTP (Re: draft-hurtta-eai-messagestore-00.txt)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[EAI] Re: HDR=UTF8SMTP (Re: draft-hurtta-eai-messagestore-00.txt)
Frank Ellermann <nobody at xyzzy.claranet.de> writes
in gmane.ietf.ima:
> For what you have as HDR=UTF8SMTP a client would always
> use BODY=8BITMIME. This includes cases where the DATA
> doesn't contain a single non-ASCII, but the MAIL FROM
> (ending up as Return-Path) or a RCTP TO (ending up as
> a from-clause or some X-EnvelopeSender header field at
> least in theory) is an address with <UTF8-non-ASCII>.
>
> That's quite a lot of parameters, ALT-ADDRESS, HDR, and
> BODY. If we're sure that HDR=UTF8SMTP _always_ implies
> BODY=8BITMIME we can define a new BODY=UTF8SMTP joining
> these parameters.
I asked that earlier. Problem is then that BODY=BINARYMIME
does not fit to picture.
Answer was that UTF8SMTP does not forbid BODY=BINARYMIME.
Therefore BODY=UTF8SMTP does not fly.
/ Kari Hurtta
draft-ietf-eai-smtpext-04.txt:
| The UTF8SMTP
| extension MAY be used with the BODY=8BITMIME parameter if that is
| appropriate given the body content or, if the server advertises it
| and it is appropriate, with the BODY=BINARYMIME parameter specified
| in [RFC3030].
|
| Assuming that the server advertises UTF8SMTP and 8BITMIME, and at
| least one non-ASCII address, with or without ALT-ADDRESS, the precise
| interpretation of these parameters on the MAIL command is:
|
| 1. Headers are in UTF-8, body parts are in ASCII.
| 2. Headers are in UTF-8, some or all body parts contain 8-bit line-
| oriented data.
| 3. Headers are in UTF-8, some or all body parts contain binary data
| without restriction as to line lengths or delimiters.
_______________________________________________
IMA mailing list
IMA at ietf.org
https://www1.ietf.org/mailman/listinfo/ima
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.