Subject: [EAI] I-D Action: draft-ietf-eai-rfc5335bis-11.txt

From: [email-masked]
Date: Sun, 10 Jul 2011 19:21:48 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email Address Internationalization Working Group of the IETF.

	Title           : Internationalized Email Headers
	Author(s)       : Abel Yang
                          Shawn Steele
                          Ned Freed
	Filename        : draft-ietf-eai-rfc5335bis-11.txt
	Pages           : 13
	Date            : 2011-07-10

   Internet mail was originally limited to 7-bit ASCII.  MIME added
   support for the use of 8-bit character sets in body parts, and also
   defined an encoded-word construct so other character sets could be
   used in certain header field values.  But full internationalization
   of electronic mail requires additional enhancements to allow the use
   of Unicode, including characters outside the ASCII repertoire, in
   mail addresses as well as direct use of Unicode in header fields like
   From:, To:, and Subject:, without requiring the use of complex
   encoded-word constructs.  This document specifies an enhancement to
   the Internet Message Format that allows use of Unicode in mail
   addresses and most header field content.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-eai-rfc5335bis-11.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-eai-rfc5335bis-11.txt

---

From: Chris Newman <[email-masked]>
Date: Mon, 25 Jul 2011 10:34:39 -0400

> 	Filename        : draft-ietf-eai-rfc5335bis-11.txt

I did a detailed review of this document, and found two issues I consider 
substantial:

1. End of Section 3.2. I suggest adding a statement at least discouraging 
use of RFC 2047 encoding. Perhaps go so far as to say that submission 
servers MAY convert RFC 2047 encoding to UTF-8 when the UTF8SMTPbis 
parameter is used. Perhaps also say that clients including the UTF8SMTPbis 
parameter SHOULD NOT use RFC 2047 encoding in the headers.

2. A discussion of the impact to RFC 5322 section 2.1.1 (line length 
limits) is needed. Specifically, the hard 998 character limit becomes a 998 
octet limit for 5335bis. However, the conservative 78 character soft-limit 
should remain based on characters, even if those characters are multi-octet 
UTF-8. This could also go at the end of section 3.2.

Editorial issues:

Section 2

I find the first paragraph useless and suggest removing it.

Section 4, paragraph 2

I suggest replacing all but the last sentence with a reference to UTF-8 
[RFC3629] security considerations which basically all apply and include 
this issue.

Otherwise I think this document is in good shape and ready for 
standardization.

		- Chris

---

From: [email-masked]
Date: Mon, 25 Jul 2011 17:00:56 -0700 (PDT)

> parameter SHOULD NOT use RFC 2047 encoding in the headers.

I agree this needs to be in there but I think it belongs in a separate section,
not at the end of the one about the ABNF changes. How about:

<section title="Use of MIME Encoded-words">

<t>
The MIME encoded-words facility <xref target="RFC2047"/> provides the ability
to place non-ASCII text, but only in a subset of the places allowed by this
extension. Additionally, encoded-words are substantially more complex since
they allow the use of arbitrary charsets. Accordingly, encoded-words SHOULD NOT
be used when generating header fields for messages employing this extension.
Agents MAY, when incorporating material from another message, convert
encoded-word use to direct use of UTF-8.
</t>

<t>
Note that care must be taken when decoding encoded-words because the results
after replacing an encoded-word with its decoded equivalent in UTF-8 may be
syntactically invalid. Processors that elect to decode encoded-words MUST NOT
generate syntactically invalid fields.
</t>

</section>

> UTF-8. This could also go at the end of section 3.2.

I have to say I regard it as an error that RFC 5322 talks about characters and
not octets. But then again, if memory serves,  this whole discussion is only
present in the document because of a rubbish comment from the IESG eons ago.

Anyway, this also really calls for another (short) section. How about:

<section title="Effects on Line Length Limits">

<t>
Section 2.1.1 of <xref target="RFC5322"/> limits lines to 998 characters
and recommends that the lines be restricted to only 78 characters. This
specification changes the former limit to 988 octets. (Note that in ASCII
octets and characters are effectively the same but this is not true in UTF-8.)
The 78 character limit remains defined in terms of characters, not octets,
since
it is intended to address display width issues, not line length issues.
</t>

</section>

> I find the first paragraph useless and suggest removing it.

I agree but I'm reluctant to remove it without some additional feedback.
Comments from others as to whether this paragraph:

   A plain ASCII string is fully compatible with [RFC5321] and
   [RFC5322].  In this document, non-ASCII strings are UTF-8 strings if
   they are in header field values which contain at least one <UTF8-non-
   ascii> (see Section 3.1).

should be removed?

> [RFC3629] security considerations which basically all apply and include

Agreed and done.

> Otherwise I think this document is in good shape and ready for

Thanks for the review; these suggestions were very helpful.

I'll post an updated draft in a bit if no further comments are received.

				Ned

---

From: John C Klensin <[email-masked]>
Date: Tue, 26 Jul 2011 04:45:57 -0400

--On Monday, 25 July, 2011 17:00 -0700 [email-masked] wrote:

>...

I think this is about the best we can do despite the fact that
it will lead to shorter lines than the "78" was intended to
permit.  The problem is that, in Unicode-speak, combining
characters are really characters.   In a different world, we
might be talking about 78 "character positions", but attempting
to introduce that term always causes a world of woe.

>    ascii> (see Section 3.1).

No strong opinion.   We should talk about the relationship
between 3536bis (recently approved by the IESG) and the EAI
documents during the meeting.

   john

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 26 Jul 2011 18:25:50 +0900

Hello John, others,

On 2011/07/26 17:45, John C Klensin wrote:
> I think this is about the best we can do

I agree.

> despite the fact that
> permit.

Not so fast, not so fast. This is internationalization, it can't be that 
easy :-).

It may also lead to longer lines. CJK Ideographs, Kana, and Hangul 
usually take two 'display cells'.

Regards,   Martin.

> The problem is that, in Unicode-speak, combining
> _______________________________________________
> IMA mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ima
>

---

From: John C Klensin <[email-masked]>
Date: Tue, 26 Jul 2011 05:37:46 -0400

--On Tuesday, 26 July, 2011 18:25 +0900 "\"Martin J. Dürst\""
<[email-masked]> wrote:

> Not so fast, not so fast. This is internationalization, it
> can't be that easy :-).
> 
> It may also lead to longer lines. CJK Ideographs, Kana, and
> Hangul usually take two 'display cells'.

Depends entirely on the typestyles, rendering machinery, and
counting mechanism used.   This of course proves your "can't be
that easy" point and my point about worlds of woe :-(

    john

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 26 Jul 2011 07:12:54 -0400

On 7/25/2011 8:00 PM, [email-masked] wrote:
>> should remain based on characters,
...
> it is intended to address display width issues, not line length issues.

I'll ask a "due diligence" question:

    Are we certain that this long-standing 78-character limit has not produced 
hard buffering limits in software that really make it an installed base of 
78-octets?

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net