[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.