Subject: [EAI] utf8headers document update

From: "Jeff Yeh" <[email-masked]>
Date: Tue, 24 Oct 2006 14:14:22 +0800

I made a mistake on timezone diffent, and didn't make the cut-off date.
Here is the updated I-D for discussion. 
http://www.twnic.net.tw/jeff/draft-ietf-eai-utf8headers-02.txt
Thank you.

Jeff Yeh
-TWNIC

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

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 24 Oct 2006 12:02:51 +0200

> http://www.twnic.net.tw/jeff/draft-ietf-eai-utf8headers-02.txt

See also http://tinyurl.com/y65mjb for a diff created by rfcdiff

Frank

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 25 Oct 2006 00:36:24 +0200

> http://www.twnic.net.tw/jeff/draft-ietf-eai-utf8headers-02.txt

| Intended status: Informational

That should be "experimental"

| have a mechanism (such as self-label) or some indicator to identify

s/as/as a/ (?)  or s/such as/as/ (?)

| To be able to do so, sending MUA MUST insert a new header field to

s/sending/a sending/

- The new header specified as "Header-Type", and elements of the
- header is the header type of i18n email.  The i18n header field
- syntax specified as below:
+ The new header field "Header-Type" is specified below for this
+ purpose:

| "ASCII" indicates that it is in the format defined by RFC 2822 (and is
| the default when this header field is absent); and "Downgraded"
| indicates the same as "ASCII", but also that it was earlier downgraded
| from "UTF8SMTP".

Maybe add:
? Headers of type "ASCII" and "Downgraded" are compatible with the
? MIME content-type text/rfc822 as used in a multipart/report, see
? [RFC3462].

The important point is of course, that header type "UTF8" is _not_
compatible with RFC 3462.

| Thus, when a i18n email is generated.

How about "Ditto" or "Likewise, when i18n email is generated"

| o  The "UTF8SMTP" header field MUST be inserted by the originating
|     MUA.

s/UTF8SMTP/Header-Type/  This MUST affects only type UTF8, or what's
the idea here ?  If a legacy MUA submits a message/rfc822 (= ASCII)
at an UTF8-MSA, then that legacy MUA won't add Header-Type: ASCII.

The MSA could add Header-Type: ASCII in this case.  That's somewhere
between MAY and MUST for the MSA, not the MUA.

- o  Whenever the email is downgraded, the content-code of the
-    "UTF8SMTP" MUST change to "Downgraded", the detail of downgrade
-     process will be described in [EAI-downgrading].
+ o  Whenever the email is downgraded, the content-code "UTF8" MUST
+    be changed to "Downgraded" as specified in [EAI-downgrading].

- SMTP client can send header fields in UTF-8 format, if the UTF8SMTP
- extension advertised by SMTP server or as permitted by other
- transport mechanisms.
+ An SMTP client can send header fields in UTF-8 format, if the
+ UTF8SMTP extension is advertised by the SMTP server.

Other mechanisms (news, uucp, etc.) shouldn't talk with SMTP clients.

| the rules in RFC 2822 for header names are not changed.

s/header names/header field names/

| the header definition in RFC 2822 must extended to support new format.

s/must extended/is extended here/  s/new/the new/

| That following ABNF is defined to substitute those definition

s/That/The/

| For those syntax rules not referred in this section remains as the

Incomplete sentence, please delete it, of course anything else in 2822
stays as is.

- The use of UTF8 characters are defined as following.
+ The use of UTF8 characters is defined as follows:

- UTF8-4          =   %xF0 %x90-BF 2(UTF8-tail) /
-                     %xF1-F7 3(UTF8-tail)
+ UTF8-4          =   %xF0 %x90-BF 2(UTF8-tail) /
+                     %xF1-F3 3(UTF8-tail) /
+                     %xF4 %x80-8F 2(UTF8-tail)

| These are taken from FRC 3629,

s/FRC/RFC/  Where did you find F1-F7 ?

- However, it will also lead <mesg-id> to allow UTF8 characters, which
- is not allowed due to the limitation describe in Section 6.4.
+ However, this would also affect the <msg-id>, which isn't desirable,
+ and also not allowed for the reasons outlined in Section 6.4.

- In this specification, internationalized email address will be
- presented in UTF-8.  Thus, all header fields involving <mailbox>es
+ All header fields involving <mailbox>es

Readers should have got the idea at this point in the spec. :-)

- In that case, MTA may bounce the message with reply code 550
+ In that case, the MTA may reject the message with reply code 550

The server rejects, the client can then create a DSN to the envelope
sender address (3462) or reverse path (821) if necessary.

- The downgrade process involve with a new ALT-ADDRESS parameter.
- When downgrade occurs, the ALT-ADDRESS will be used for mail
- delivery instead of the internationalized email address, the
- detail is described in [EAI-downgrading].
+ A downgrade process would require a new <alt-address>, for the
+ details see [EAI-downgrading].

- ; message will bounce if UTF8SMTP extension is not supported
+ ; the message has to be rejected if UTF8SMTP is unavailable

|  Internationalized domain names in Received fields must be transmitted
|  in punycode form.

s/punycode form./an ASCII Compatible Encoding (ACE), see RFC 3490./

- subsequent downgrading would force violating rules in RFC 2821
- prohibiting altering existing Received fields.
+ subsequent downgrading would violate an RFC 2821 prohibition.

-  With these two restrictions, there should be no need for
-  UTF-8 information in Received fields and such information is
-  prohibited to preserve the integrity of those fields.  More
-  generally, UTF-8 information of any sort MUST NOT appear in Received
-  fields, even in comments within those fields.
+ Unencoded UTF-8 information of any sort MUST NOT appear in
+ Received fields.

- it is possible these two address go to different mailbox,
+ it is possible that these two addresses go to different mailboxes,

| This might not be a protocol problem,

It is a protocol problem.  It needs fresh MUSTard in an "I18N-submit"
memo (or here), RFC 4409 does not cover such situations in 6.1 / 8.1.
It could undermine many anti-spam efforts on the side of the sender.

I skipped chapter 7 in this review.

Frank

---

From: Yangwoo Ko <[email-masked]>
Date: Wed, 25 Oct 2006 13:56:05 +0900

At the end of section 1.1, the document says;

 > This form is permitted in transmission, if authorized
 > by the SMTP extension specified in [EAI-SMTP-extension] or by other
 > transport mechanisms capable of processing it.

It is nice to see that [utf8headers] doc is capable of supporting
not only EAI's [smtp-ext] but also many other transport mechanisms.

However, we have discussed the [utf8headers] doc in the context of
[smtp-ext] doc. For example most of considerations focus on what
should happen when UTF8SMTP-compliant SMTP client meets UTF8SMTP
compliant/non-compliant SMTP server.

Since I don't have any idea on what "other transport mechanisms" are
and how they work, I am not convinced whether the decision to extend
the [utf8headers] doc to support other mechanisms is safe.

I guess that these (some of) "other transport mechanisms" do not
support UTF8 headers as of today. Then they also need to be upgraded
to support UTF8 headers. During the upgrade process, newly generated
docs may refer to [utf8headers]. I think this is safer approach.

I will be happy if somebody convinces me that "other transport
mechanisms" can exploit [utf8headers] without any problem. :-)

Regards

---

From: "Charles Lindsey" <[email-masked]>
Date: Sat, 28 Oct 2006 16:06:03 +0100

> the [utf8headers] doc to support other mechanisms is safe.

Essentially, any transport mechanism that is 8bit (or even better, binary)  
clean is in principle able to transport UTF8SMTP messages. So FTP, UUCP,  
NNTP are in principle possible. Even carrier pigeons will work :-) . I  
don't know about X.400.

I think the point is that we need to separate the document format (RFC  
2822, and now utf8hdrs) from the transport mechanism. RFC 2822 can already  
be used with _any_ transport mechanism that will transport messages safely  
- it is not wedded to RFFC 2821. The same should apply to utf8hdrs.

In both cases, it is up to the user (or rather his MUA) to choose a  
transport mechanism that is safe. For SMTP, it is easy because it is all  
laid out in RFC 2821 and smtpext. If he (or his implementor) wants to use  
any other mechanism, then it is up to him to look at whatever  
specification exists for that mechanism, and see whether it is suitable.

We should, however, point out that extra care may be needed at gateways  
between diffferent transport mechanisms. This will usually involving  
looking to see whether there is a Header-Type header present before  
deciding whether the gatewaying is safe.

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