Subject: [EAI] AD review of draft-ietf-eai-rfc5335bis-03 .txt

From: Alexey Melnikov <[email-masked]>
Date: Sat, 27 Nov 2010 12:59:48 +0000

Hi,
Below is my review of draft-ietf-eai-rfc5335bis-03.txt. This is in 
addition to the ABNF issues I reported in a separate email. I might have 
a couple of extra issues, but I need to think them over first.

2.  Background and History

   Use of this SMTP extension helps prevent the introduction of such
   messages into message stores that might misinterpret, improperly
   display, or mangle such messages.  It should be noted that using an
   ESMTP extension does not prevent transferring email messages with
   UTF-8 header fields to other systems that use the email format for
   messages and that may not be upgraded, such as unextended POP and
   IMAP servers.  Changes to these protocols to handle UTF-8 header
   fields are addressed in [RFC5721bis] and [RFC5738bis].  [[Note in
   Draft: RFC5721bis and RFC5738bis did not yet posted.]]

Please delete the note, as it is no longer accurate.

4.1.  UTF-8 Syntax and Normalization

   See [RFC5198] for a discussion of normalization; the use of
   normalization form NFC is RECOMMENDED.

I think NFC needs a Normative reference.

4.3.  Syntax Extensions to RFC 5322

   description   = "Content-Description:" unstructured CRLF

   The <utext> syntax is extended above to allow UTF-8 in all
   <unstructured> header fields.

The problem with this is that <unstructured> is not referencing <text>.
RFC 5322 defines:

   unstructured    =   (*([FWS] VCHAR) *WSP) / obs-unstruct

So should this document also extend <unstructured> to allow UTF-8?

   Note, however, this does not remove any constraint on the character
   set of protocol elements; for instance, all the allowed values for
   timezone in the "Date:" headers are still expressed in ASCII.  And
   also, none of this revised syntax changes what is allowed in a
   <message-id>, which will still remain in pure ASCII.

In the last sentence I've noticed that one of the revisions of this draft
changed <msg-id> to <message-id> (as compared to RFC 5335). I believe this
is incorrect, because <msg-id> is an ABNF production used in many other 
places,
such as in In-reply-to and References header fields. So please undo the 
change.

Also, "Date:" headers --> "Date:" header fields.

4.4.  Change on addr-spec Syntax

   Let-dig      =  <See Section 4.1.3 of RFC 5321>

This should be pointing to Section 4.1.2 of RFC 5321.

4.5.  Trace Field Syntax

   The uFor ( described in [I-D.ietf-eai-rfc5336bis] Section 3.6.3 ))
   has been added to allow the use of internationalized addresses in
   "For" fields. by use of the new uFor syntax.

Extra dot before "by".

5.  Security Considerations

   If a user has a non-ASCII mailbox address and an ASCII mailbox
   address, a digital certificate that identifies that user may have
   both addresses in the identity.  Having multiple email addresses as
   identities in a single certificate is already supported in PKIX
   (Public Key Infrastructure for X.509 Certificates) and OpenPGP.

This needs Informative references to PKIX and OpenPGP RFC.

   In this specification, a user could provide an ASCII alternative
   address for a non-ASCII address.  However, it is possible these two
   addresses go to different mailboxes, or even different people.  This
   configuration may be based on a user's personal choice or on
   administration policy.  We recognize that if ASCII and non-ASCII
   email is delivered to two different destinations, based on MTA
   capability, this may violate the principle of least astonishment, but
   this is not a "protocol problem".

I think this paragraph is no longer relevant and needs to be deleted.

6.  IANA Considerations

   IANA has registered the message/global MIME type using the
   registration form contained in Section 4.4.

This should be a bit clearer that IANA needs to update the current 
registration
to point to this document.

 [RFC1652]

This reference doesn't seem to be Normative.

Best Regards,
Alexey

-- 
IETF Application Area Director, <http://www.ietf.org/iesg/members.html>
Internet Messaging Team Lead, <http://www.isode.com>
JID: same as my email address

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 27 Nov 2010 13:12:24 +0000

uQuoted-Pair   = ("\" uText) / obs-qp

I think this is too permissive (although obs-qp allows for control 
characters
already). RFC 5322 says:

 text            =   %d1-9 /            ; Characters excluding CR
                     %d11 /             ;  and LF
                     %d12 /
                     %d14-127

 quoted-pair     =   ("\" (VCHAR / WSP)) / obs-qp

And the ABNF document defines:

 VCHAR          =  %x21-7E
                   ; visible (printing) characters

 WSP            =  SP / HTAB
                   ; white space

So I think something like the following would be more appropriate:

   uQuoted-Pair   = ("\" (VCHAR / WSP / UTF8-xtra-char )) / obs-qp

But that would mean that a single \ can escape a sequence of octets. Is 
that Ok?

---

From: John C Klensin <[email-masked]>
Date: Sat, 27 Nov 2010 15:34:23 -0500

--On Saturday, November 27, 2010 1:12 PM +0000 Alexey Melnikov
<[email-masked]> wrote:

> I think this is too permissive (although obs-qp allows for
> control characters
> already). RFC 5322 says:
> 
> But that would mean that a single \ can escape a sequence of
> octets. Is that Ok?

My recollection is that the WG's decisions the first time around
was to drastically reduce the number of permitted "weird"
characters, i.e., if one decides to move into UTF-8 address
land, one gives up the control characters (both C0 and C1) the
embedded spaces in addresses, and most of the need to escape or
quote anything.  What would be prohibited would include anything
the 5321 or 5322 mark as obsolete.   I don't remember any
discussion this time around that would reverse that rule so, if
my recollection is correct, then this ought to be drastically
limited.

Remember that mixing essentially unrestricted Unicode with,
e.g., control characters can cause what is technically known as
"a big mess", so part of the question, IMO, is whether one can
find strong justification for permitting all of those things.

Obviously need the opinions of others about this.

   john