Subject: Re: [EAI] draft-ietf-eai-smtpext-02.txt (draft-ietf-eai-utf8headers-02.txt )

From: "Yao Jiankang" <[email-masked]>
Date: Mon, 30 Oct 2006 17:38:24 +0800

----- Original Message ----- 
From: "Kari Hurtta" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, October 26, 2006 9:21 PM
Subject: [EAI] draft-ietf-eai-smtpext-02.txt (draft-ietf-eai-utf8headers-02.txt )

> 
> draft-ietf-eai-smtpext-02.txt:
> 
> |  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.
> 
> So model is following:
> 
>   Indication for internationalized email is
>      Header-Type: UTF8
> 
>   header field on mail DATA.
> 
> let's compare this to model of 8-bit MIME email model:
> 
>   Indication for 8-bit (MIME)  emila is
>      BODY=BITMIME
> 
>   parameter on MAIL -command
> 
>   However there is also
>      Content-Transfer-Encoding: 8bit
> 
>   header field on mail DATA,  but 8BITMIME extension did
>   not select that for indication.
> 
> 
> 
> So perhaps it make sense to compare what are differences
> on these two situations?
> 
> Question is: 
> 
>   Why 8BITMIME needed BODY=BITMIME parameter for MAIL -command
>   when same information is available on email header
>   fields ?
> 
>   Why UTF8SMTP does not need parameter for MAIL -command,
>   but instead is relying email header field about that.

On my view, one reason is that we do not want too many parameters on MAIL-commands.
Too many parameters may  impose addtional burdens on SMTP   processors.
So few parameters are prefered by SMTP. So UTF8SMTP does design to have  few parameters for MAIL -command

YAO Jiankang
CNNIC

> 
> 
> 
> I do not say that there is something wrong,
> but I ask reasoning of selections.

see above.

> 
> / Kari Hurtta
> 
> 
> _______________________________________________
> IMA mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ima

_______________________________________________
IMA mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ima

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 30 Oct 2006 22:00:05 -0000

> On my view, one reason is that we do not want too many parameters on  

In my view, the difference is that, if 8BITMIME wants to be sure that the  
message is already 7bit-safe, then if has to examine the whole body  
(including all the multiparts) looking for a CTE: 8bit. So instead it  
requires a BODY=8BITMIME parameter, and if that is absent it can omit the  
search.

In the case of UTF8SMTP, we shall arrange things so that if any deeply  
buried multipart has some UTF8SMTP-sensitive stuff in it, then all the  
parent multiparts, and in particular the top-level headers, will have  
Header-Type: UTF8.

So the MTA needs only to examine the top-level headers, and if it detects  
no such header there, it need look no further.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

---

From: Kari Hurtta <[email-masked]>
Date: 31 Oct 2006 07:42:43 +0200

"Charles Lindsey" <[email-masked]> writes:

> In my view, the difference is that, if 8BITMIME wants to be sure that
> the  message is already 7bit-safe, then if has to examine the whole
> body  (including all the multiparts) looking for a CTE: 8bit. So
> instead it  requires a BODY=8BITMIME parameter, and if that is absent
> it can omit the  search.

No.  If one of subparts of multipart have
        content-transfer-encoding: 8bit

then it means that here must be also
        content-transfer-encoding: 8bit
on multipart itself.

You image that difference. 
 
If there is 8bit data on somewhere on mail body and 
top level content-transfer-encoding do not say it, 
then it is protocol violation.

RFC 2045:

|   The proper Content-Transfer-Encoding label must always be used.
|   Labelling unencoded data containing 8bit characters as "7bit" is not
|   allowed, nor is labelling unencoded non-line-oriented data as
|   anything other than "binary" allowed.

> So the MTA needs only to examine the top-level headers, and if it
> detects  no such header there, it need look no further.
> 
> -- 

/ Kari Hurtta

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 31 Oct 2006 12:12:13 +0100

>         content-transfer-encoding: 8bit

ACK, the part is contained in something, that must be
8bit, and recursively the complete compound multipart/*
or message/* must be 8bit.

Frank

P.S.:  Sorry for the 9"9"7 vs. 977 confusion elsewhere