Subject: [Gen-art] Gen-ART review of draft-ietf-eai-frmwrk-4952bis-07

From: <[email-masked]>
Date: Fri, 10 Sep 2010 20:19:32 -0400

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq . 

Please resolve these comments along with any other comments you may receive.

Summary:
This draft is on the right track, but has open issues, described in the review.

This draft describes a framework for international character support in mailbox names.  That easy-to-state requirement has a large scope of consequences, as it also requires:
	- international character support in message headers;
	- extensions to message delivery status and notification handling; and
	- i18n protocol extensions to SMTP, POP and IMAP.
Even so, the resulting email path coverage scope is not end-to-end, as important aspects of MUA behavior and interaction with users are out-of-scope (and I believe properly so).

The draft is well written, and does a good job of describing the overall framework of email transfer and the entities involved.  Unfortunately, that descriptive style carries over into the specification of the framework and interactions involved in international character support, and that descriptive (rather than prescriptive) style leads the open issues:

[1] The second sentence in the second paragraph of Section 7.2 begins with "That form SHOULD presumably use UTF-8".  I don't understand that, as "presumably" is not consistent with the RFC 2119 specification of "SHOULD".  The paragraph gets worse further on with a statement that something "can be done" to realize this "SHOULD presumably" requirement.  I cannot figure out what this paragraph is specifying or recommending; it should be rewritten.  As part of the rewrite, please carefully separate functionality that is acceptable in transition from functionality that is part of the longer term "target" and say something about how to go about retiring the transition functionality from use.

[2] The last paragraph of Section 8.1 has a similar problem - "In this context, one can easily imagine modifications" is a fine introduction to a fairy tale, but does not belong in a framework RFC, even an Informational one.  Again, I cannot figure out what is being recommended here - on its face, the language is entirely hypothetical, but I suspect that there's something that should be said about when the techniques in this paragraph should be used and for what purposes.  Please rewrite.

[3] Section 10.1 seems problematic.  The open issue is that the draft declines to say anything definitive about how to deal with existing ("running code" use of the backspace character).  I suggest adding a discussion of making the backspace character an exception to the prohibition of Unicode C0 controls for transition purposes.

[4] Also in Section 10.1, the second bullet under the principles assumes that the mailbox name is normalized, as that was recommended by the first bullet.  The other case should also be covered - if the mailbox name is not normalized, the draft should recommend that the normalized form of the mailbox name be an alias.  A non-obvious situation where this applies is to mailbox names that are not normalized wrt all applicable normalization forms, e.g., names that are in normal form with respect to NFC, but not with respect to NFKC.

The following item should also be dealt with, but does not rise to the level of an open issue:

[A] In Section 10.1, the warnings against unnormalized strings, use of spaces, punctuation, etc. seem weak, and would benefit from an example to make the point. Even though there's another draft referenced on MUA issues, the example I suggest involves a user sends a message to another user and expecting a reply.  In order for this example to work as intended, the first user's email address needs to survive the second user's MUA, which may normalize or fail to deal well with whitespace, punctuation, etc., independent of care taken in implementation of the first user's MUA.

-- Nits --

Please add citations of the i18n IMAP and POP specs to the last paragraph in Section 7.1.

idnits 2.12.05 found a lot to complain about, but only the following three items appear to deserve attention:

  == The 'Obsoletes: ' line in the draft header should list only the
     _numbers_ of the RFCs which will be obsoleted by this document (if
     approved); it should not include the word 'RFC' in the list.

  -- The document has a disclaimer for pre-RFC5378 work, but was first
     submitted on or after 10 November 2008.  Does it really need the
     disclaimer?

  == Unused Reference: 'RFC2033' is defined on line 1038, but no explicit
     reference was found in the text

I suspect that the disclaimer is needed courtesy of text taken from older documents, but that need should be double-checked.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: Joseph Yee <[email-masked]>
Date: Tue, 14 Sep 2010 11:10:44 -0400

HI,

Responses inline.  Thanks

> [1] The second sentence in the second paragraph of Section 7.2 begins with "That form SHOULD presumably use UTF-8".  I don't understand that, as "presumably" is not consistent with the RFC 2119 spe…

It was legacy from RFC 4952, which was deliberately more tentative then needs to be. 

Yes, the word "presumably" will be removed, and we also change 
"..non-ASCII characters in headers [RFC2045] [RFC2231]." 
to read 
""...non-ASCII characters in headers [RFC2045] [RFC2231], but even these should be based on UTF-8. rather than other encodings, if at all possible [IAB-idn-encoding]."

> [2] The last paragraph of Section 8.1 has a similar problem - "In this context, one can easily imagine modifications" is a fine introduction to a fairy tale, but does not belong in a framework RFC,…

This is what we intended for the flexibility and "fixes" needed for message submission server to deal with what MUAs may supply.  Also the behaviour of message submission server is out of framework scope.  We recommend to add a new paragraph (as new first paragraph in section 8.1) to explain the situation:

<t>The IETF has traditionally avoided specifying the precise
  behavior of MUAs to provide maximum flexibility in the
  associated user interfaces.  The 
  <xref target="RFC5321">SMTP standard</xref>, Section 6.4, 
  gives wide latitude to MUAs and Submission servers as to
  what might be supplied by the user as long as the result
  conforms with "on the wire" standards once it is injected
  into the public Internet.  In that tradition, the discussion
  in the remainder of this section is provided as general
  guidance rather than normative requirements.</t>

> [3] Section 10.1 seems problematic.  The open issue is that the draft declines to say anything definitive about how to deal with existing ("running code" use of the backspace character).  I suggest…

The technique of backspace character is not in practice at least in Unicode IMHO.  And this would create lots of issues on mail delivery and other areas.  Since EAI mail is new and allow UTF-8 only, I would recommend not to encourage this practice further.

> [4] Also in Section 10.1, the second bullet under the principles assumes that the mailbox name is normalized, as that was recommended by the first bullet.  The other case should also be covered - i…

NFKC could maps out some characters that could be part of a person's name.  

It is also hard, next to impossible, to generate all non normalized forms.  Given there will be new compatible equivalents when new version of Unicode introduced.

We could strength the text in section 10.1:

Old:

   The practice SHOULD be phased out as this extension becomes
   widely deployed but backward-compatibility considerations
   may require that it continue to be recognized.

New:

   Because RFC 5321 (and its predecessor, RFC 2821) prohibit
   the use of this character in ASCII mailbox names and it is
   even more problematic (for canonicalization and
   normalization reasons) in non-ASCII strings, backspace MUST
   NOT appear in UTF8MSTPbis mailbox names.

Thanks
Joseph

---

From: Russ Housley <[email-masked]>
Date: Sat, 18 Sep 2010 11:34:08 -0400

>    NOT appear in UTF8MSTPbis mailbox names.

s/UTF8MSTPbis/UTF8SMTPbis/

Russ