Overview and Framework for Internationalized Email
draft-ietf-eai-frmwrk-4952bis-12

Thank you for this clear, well-written document. Several sentences struck me as difficult to parse...

1. In Section 8.1:

   It is likely that the most common cases in which a message that
   requires these extensions is sent to a system that does not will
   involve the combination of ASCII-only forward-pointing addresses with
   a non-ASCII backward-pointing one.

I suggest:

   Sometimes a message that requires these extensions is sent to a 
   system that does not support these extensions; tt is likely that the most 
   common cases will involve the combination of ASCII-only forward-pointing 
   addresses with a non-ASCII backward-pointing one.

2. In Section 10.1:

   While these
   are permitted by the protocols and servers are expected to support
   them and there are special cases where they can provide value, taking
   advantage of those features is almost always bad practice unless the
   intent is to create some form of security by obscurity.

I suggest:

   These formations are permitted by the protocols and servers are 
   expected to support them.  Although they can provide value in special 
   cases, taking advantage of them is almost always bad practice unless 
   the intent is to create some form of security by obscurity.

3. In Section 10.1:

   o  In general, it is wise to support addresses in Normalized form,
      using either Normalization Form NFC and, except in unusual
      circumstances, NFKC.

Is the intent to say that it is best to use NFC and to use NKFC only in unusual circumstances?

4. In Section 11.1:

   The mailto: schema [RFC2368] and discussed in the Internationalized
   Resource Identifier (IRI) specification [RFC3987] may need to be
   modified when this work is completed and standardized.

I suggest:

   The mailto: schema, defined in RFC 2368 [RFC2368] and discussed 
   in the Internationalized Resource Identifier (IRI) specification [RFC3987], 
   may need to be modified when this work is completed and standardized.

5. In Section 12:

   The key architectural difference between the
   experimental specifications and this newer set is that the earlier
   specifications supported in-transit downgrading including providing
   syntax and functions to support passing alternate, all-ASCII,
   addresses with the non-ASCII ones and special headers to indicate the
   downgraded status of messages.

Yes, "downgrading including providing" is impressive, but I suggest:

   The key architectural difference between the
   experimental specifications and this newer set is that the earlier
   specifications supported in-transit downgrading, which included the
   definition of syntax and functions to support passing alternate, all-ASCII,
   addresses with the non-ASCII ones as well as special headers to 
   indicate the downgraded status of messages.

6. In Section 14:

   Expecting and most or all
   such transformations prior to final delivery be done by systems that
   are presumed to be under the administrative control of the sending
   user ameliorates the potential problem somewhat as compared to what
   it would be if the relationships were changed in transit.

I suggest:

   This potential problem can be mitigated somewhat by enforcing the
   expectation that most or all such transformations will be performed 
   prior to final delivery by systems that are presumed to be under the 
   administrative control of the sending user (as opposed to being 
   performed in transit by entities that are not under the administrative
   control of the sending user).

Finally, a reference to RFC 5280 seems appropriate in Section 14 when 
mentioning PKIX.