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

From: <[email-masked]>
Date: Sun, 19 Sep 2010 15:30:50 -0400

Joseph,

The proposed changes for [1], [2] and [3] are ok with me.  Specifically for [3], I agree that prohibition of backspace characters is the better approach (I had read the draft as implying that such a prohibition was not feasible).

The discussion on [4] has missed the point, as [4] is not specifically about NFKC.  Here's a suggested change that would respond to [4], although the draft is ok with me if this is not done (Unicode normalization is problem area where interoperability issues are possible no matter how much guidance is supplied, so this is a judgment call about the amount of guidance to supply):

OLD
   o  It may be wise to support other forms of the same local-part
      string, either as aliases or by normalization of strings reaching
      the delivery server, in the event that the sender does not send
      the strings in normalized form.

NEW
   o  It may be wise to support other forms of the same local-part
      string, either as aliases or by normalization of strings reaching
      the delivery server, in the event that the sender does not send
      the strings in normalized form or that the recipient's local-part
	string is not in normalized form.

I apologize for the delayed response.

Thanks,
--David

Responses inline.  Thanks

On 2010-09-10, at 8:19 PM, <david.black at emc.com> <david.black at emc.com> wrote:

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

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

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 adding a discussion of making the backspace character an exception to the prohibition of Unicode C0 controls for transition purposes.

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

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

> 
> 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
> david.black at emc.com        Mobile: +1 (978) 394-7754
> ----------------------------------------------------
>

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: John C Klensin <[email-masked]>
Date: Sun, 19 Sep 2010 21:30:20 -0400

--On Sunday, September 19, 2010 15:30 -0400 [email-masked]
wrote:

> Joseph,
> 
> The proposed changes for [1], [2] and [3] are ok with me.
> Specifically for [3], I agree that prohibition of backspace
> characters is the better approach (I had read the draft as
> implying that such a prohibition was not feasible).

Sorry.  I hope the new text is clear, but there is an absolute
prohibition on C0 controls (including, but not limited to
backspace) in 2821 which was reaffirmed in 5321.  All EAI is
doing is _not_ overriding that prohibition.

> The discussion on [4] has missed the point, as [4] is not
> specifically about NFKC.

I/we responded to the use of NFKC in your report because
application of some types of compatibility normalization is a
particularly problematic case.  If you (or anyone else copied)
don't understand the issue there, I'm happy to explain, but I
don't think it properly belongs in this document.   But, more
generally and more or less as you put it, Unicode normalization
is indeed a problem area ... no matter how much guidance is
supplied.

Your report also appeared to us to call for installing all of
the alternate representations of a string as aliases.  That is
pretty much a non-starter due to multiplicative explosion and
the issue discussed below.

>  Here's a suggested change that would
> respond to [4], although the draft is ok with me if this is
> not done (Unicode normalization is problem area where
> interoperability issues are possible no matter how much
> guidance is supplied, so this is a judgment call about the
> amount of guidance to supply):
> 
> OLD
>    o  It may be wise to support other forms of the same
> local-part       string, either as aliases or by normalization
> of strings reaching       the delivery server, in the event
> that the sender does not send       the strings in normalized
> form.
> 
> NEW
>    o  It may be wise to support other forms of the same
> local-part       string, either as aliases or by normalization
> of strings reaching       the delivery server, in the event
> that the sender does not send       the strings in normalized
> form or that the recipient's local-part 	string is not in
> normalized form.

Well, frankly, if someone tries to keep a local-part string only
in unnormalized form (at least NFC/NFD) they are basically nuts
_unless_ their goal is to make the address hard to access for
filtering purposes (there are traditions of deliberately making
addresses deliberately obscure and hard to access that which go
back to the time when email was still being transported over
FTP).  

I consequently can live this change as harmless.  I am not
convinced that it is a good idea.  There are two reasons:

	-- we've historically (in pre-EAI email specs) been
	reluctant to give too-specific advice about the
	formation of address local parts, just because local
	needs differ.  That situation is one of the reasons why
	there are strong prohibitions about anything other than
	the final delivery server trying to parse and reorganize
	or rewrite addresses in RFC 5321 and its predecessors.
	Even the "no control characters" mandate in 2821 was
	controversial for that reason: there are just too many
	edge cases and specific local needs.  There may be
	reasons today to start changing our minds about that
	strategy and give more advice (and a few of the
	historical reasons for not doing so have receded into
	obscurity), but this document is perhaps not the right
	place to start making that change:  EAI is very much
	about a pure extension to traditional Internet email,
	not a back door for introducing new policies or concepts
	that are not strictly required for i18n purposes.
	
	-- The WG Charter contains a benchmark for an
	Informational document described as "Advice for
	non-ASCII & ASCII addresses".  We don't know what is
	going to be in that document yet and I anticipate some
	difficulty getting consensus on any but the weakest of
	recommendations (I hope I'm wrong).  Especially because
	there is no EAI I-D on the subject yet, if we make a
	specific recommendation in 4952bis --even one as
	seemingly innocuous as "make sure one of the aliases is
	in normalized form"-- there is some small possibility of
	its being inconsistent with whatever recommendations
	will appear in that more focused document, presumably
	requiring re-opening this one.  I think we would need to
	take a more specific recommendation than the existing
	one back to the WG for signoff.  While the risk is
	small, the advantages of the difference between the
	deliberately somewhat vague text that now appears in the
	document and your suggestion don't seem to me to justify
	either the added risk or the added time and effort.

YMMD, of course, and, if the IESG were to insist on your
suggested textual change,  I assume the WG would agree to make
it.

Incidentally,  your "nits" list slipped through the cracks for
-08, largely because we were concentrating on the more
substantive issues.   They have been addressed in my working
copy of the I-D; I can post that more or less immediately if the

>> last paragraph in Section 7.1.

Those citations were omitted deliberately as the result of an
ongoing discussion with the RFC Editor about how often to repeat
citations.  In addition, since we do not expect this document to
be held for the IMAP and POP ones, the citation would need to
point to a not-particularly-useful "work in progress" reference.
So I/we thought it better to send the user who needed to know
back to Section 5, where those specs are put into context.  This
is, of course, easily changed if the IESG or RFC Editor disagree.

Incidentally, in checking the Section 5 text, I noticed that we
had a citation to the base POP3 protocol but not one for the
base IMAP protocol.  That has also been fixed in the working
copy.

>...

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

This, and some of the others below, somehow slipped through the
cracks into -08.  While it is clearly the sort of thing that the
RFC Editor can handle, I've fixed it in my working copy of the
XML.

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

The document draws most of its text from RFC 4952, which is a
pre-November 2008 document.  So, yes, the disclaimer is needed.

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

Yes.  A discussion of LMTP was removed fairly late in the
process.  The definition has been removed from the working
version.  But, again, the RFC Editor is extremely good at
catching  this sort of thing.

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

It has been.  See above.

best,
   john

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 20 Sep 2010 12:29:27 +0100

John C Klensin wrote:
 [...]

>Alexey, Russ, or other IESG members wish.
>
Let's wait till Thursday evening.

---

From: John C Klensin <[email-masked]>
Date: Mon, 20 Sep 2010 09:39:12 -0400

--On Monday, September 20, 2010 12:29 +0100 Alexey Melnikov
<[email-masked]> wrote:

>> copy of the I-D; I can post that more or less immediately if
>> the Alexey, Russ, or other IESG members wish.
>> 

Ack.  Thanks.  It is ready to go, so just let me know when you
want it.

   john