With apologies for the delayed submission of this due to the holidays...



I have been selected as the Applications Area Review Team reviewer for this draft (for background on apps-review, please see http://www.apps.ietf.org/content/applications-area-review-team).

Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft.



Document: draft-ietf-eai-rfc5335bis-07

Title: Internationalized Email Headers

Reviewer: Murray S, Kucherawy

Review Date: 2010-12-23

IETF Last Call Date: unknown

IESG Telechat Date: unknown

Summary: This draft is not ready for publication as a Proposed Standard and should be revised before publication.



Major issues:


Sections 1.2 and 4.2 of this specification "removes the blanket ban on applying a content-transfer-encoding to all subtypes of message/ and instead..."  This is in reference to RFC2045 Section 6.4.  I re-read RFC2045 Section 6.4 and I don't have the same interpretation.  It says:



   "In particular, it is EXPRESSLY FORBIDDEN to use any
   encodings other than "7bit", "8bit", or "binary" with any composite
   media type, i.e. one that recursively includes other Content-Type
   fields.  Currently the only composite media types are "multipart" and
   "message".  All encodings that are desired for bodies of type
   multipart or message must be done at the innermost level, by encoding
   the actual body that needs to be encoded."

It seems to me that there is not an outright ban, but a restriction on which particular encodings can be used.  It also seems to me that "8bit" and "binary" encodings are sufficiently unrestrictive that they could contain any conceivable encoding, including UTF-8, especially "binary".  Thus, a binary-encoded message/global MIME object is legal and doesn't require any alteration to RFC2045, and therefore I don't understand the need for this section of this draft.

Section 5.2.4 of RFC2046 specifies that future "message" subtypes are expected to be "7bit" only, and anything else should register some other top-level media type.  Why was that not followed here?

Having exchanged email now with one of the WG chairs, I realize there may be more background or operational experience with EAI than I have that explains the above concerns.  However, future readers of this specification will likely also lack that context.  Therefore, I recommend that either Section 1.2 of this draft be extended with such discussion and background, or an appendix be included to contain such.  The last paragraph of Section 4.2 does do a little of this, but I'm at a loss to see the point being made here.  Perhaps an example would help.  If one of the other documents EAI is advancing contains such material, please add a reference to it here.



The Security Considerations section should discuss the problem of having UTF-8 aware transport (i.e. MTAs) coupled with UTF-8 unaware user agents (e.g. readers) as well as filters and the like.  The author talks about needing bigger buffers, but I think that's far less interesting than the possible semantic implications.  I consider this a major issue, and so I would expect this discussion to be non-trivial in size, and include some admonishment about not upgrading a delivery MTA to support UTF-8 message headers until the entire infrastructure it serves has already been verified to handle it.  This might be discussed in one of the other EAI documents already; if it is, this one should contain a reference to that.



On a related note, Security Considerations should also talk about abuse mechanisms.  If, for example, there are lots of ways of using UTF-8 to represent something equivalent or similar to a particular displayed character or group of characters (all the variants of "e" in French, using accents, for example), then filtering systems can be bypassed by using one of the variants to avoid detection while still reaching the end user with largely the same original effect.  This too might be discussed elsewhere in general, in which case a reference to that discussion can be left here.

Minor issues:



Section 2 explains that some people want to be able to use non-ASCII characters as part of header fields, though it also points out that RFC2047 already presents a mechanism to do so in a 7-bit-clean manner.  Section 4.3 then lays out the ABNF required to update RFC5322 such that just about any field can contain UTF-8 data.  Since this is a pretty big deal, it would be helpful to have some data about why the RFC2047 encoding mechanism that has been in widespread use since 1996 is not sufficient or appropriate, other than what's presented here which basically states that people don't want to use that encoding scheme for some reason, perhaps personal preference.


Section 4.6, which contains the registration for "message/global", says "(Note that a system compliant with MIME that doesn't recognize message/global SHOULD treat it as "application/octet-stream" as described in Section 5.2.4 of [RFC2046].)"  As another reviewer points out, and I concur, it's dangerous to copy normative language from one document to another, rather than simply referencing it, as it encourages divergent requirements.  Another instance of this appears in Section 5.



Nits:



In the Abstract and in Section 1.1, the phrase "specifies a variant of Internet mail" seems to portray a much wider scope than what's being presented.  Suggest "specifies a modified version of the Internet message format".



Section 3: "A plain ASCII string is full compatible..."  I believe the authors wanted "fully" here.



Section 4: The title "Changes on..." should be "Changes to..."



Section 4.1: The final paragraph is a little too conversational in its use of language, such as starting a sentence with "Actually, ..." and another with "And ..."  This is inconsistent with the rest of the document and should be avoided.

Section 4.2 and 4.4: The titles "Changes on..." should be "Changes to..."



Section 4.5: "It described in" should be "It is described in"



Section 4.6: "or within a non-SMTP environment which supports these messages."  Change "which" to "that".



Section 4.6: The Security Considerations of "See Section 5" should also say "of [this document]" or such.



Section 4.6: "Email clients which forward messages..." and "This is a structured media type which embeds..."  Change "which" to "that" in both cases.



Section 5: "...characters MUST be no more 998 octets, excluding..." Change "no more 998" to "no more than 998".