Subject: Re: [EAI] I-D ACTION:draft-ietf-eai-rfc5335bis-02.txt

From: Julien ÉLIE <[email-masked]>
Date: Thu, 2 Sep 2010 21:29:51 +0200

Hi all,

> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
> Title : Internationalized Email Headers
> Author(s) : A. Yang, S. Steele
> Filename : draft-ietf-eai-rfc5335bis-02.txt

A few remarks:
-- before Last Call :-)

* Abstract
   This document specifies an variant of Internet mail

=> "a variant" I think.

   This specification Updates section 6.4 of [RFC2045]

=> "updates" in lowercase, "Section" in upercase.

* Section 1.1
   This document specifies an variant of Internet mail

=> "a variant" I think.

* Sections 1.2 and 4.2
   blanket ban on applying a content-transfer-encoding to all subtypes
   of message/.

=> I do not find it satisfying to read "message/." at the end of
   a sentence.  I believe it should be quoted.  RFC 2045 uses
   quotes for "message/rfc822".
   Anyway, it is just a remark, and it should be homogenized
   according to the current trend for that.

* Section 1.2
   This document also updates [RFC5322] and MIME ([RFC2045]), and people
   who participate in the experiment have to swich to this document.

=> "switch"?

   Message/global (see
   Section 4.6) permits use of a content-transfer-encoding.

=> I also do not find it satisfying to have an uppercase initial letter
   for "Message/global"!
   I believe quotes and a lowercase letter would be fine at the beginning
   of the sentence.

* Section 2
   text (such as in the Subject: field) to be encoded (as required by

=> Wouldn't "Subject:" with quotes be better?  It is the way it is
   written in RFC 5322.

   change described in the associated document
   [I-D.ietf-eai-frmwrk-4952bis] and [I-D.yao-eai-rfc5336bis]

=> "documents" in plural?

* Section 3
   Unless otherwise noted, all terms used here are defined in [RFC5321],
   [RFC5322], [I-D.ietf-eai-frmwrk-4952bis],or [I-D.yao-eai-rfc5336bis].

=> Missing space.

* Section 4.1
                       %xE1-EC 2(UTF8-tail) /
                       %xF4 %x80-8F 2( UTF8-tail )

=> It should be homogenized:  with spaces or without spaces.

* Section 4.3
   FWS     =  <see [RFC5322], folding white space>
   CFWS    =  <see [RFC5322], folding white space>

=> why "folding white space" for both of them, and not "Section 3.2.2"
   or its title?

   timezone in the Date: headers are still expressed in ASCII.  And

=> Same as before.  Quotes for "Date:"?

* Section 4.5
   "For" fields containing internationalized addresses are allowed, by
   use of the new uFor syntax.  UTF-8 information may be needed in
   Received fields.

=> If not "Received:" fields (with a colon), the wording should be
   "Received header fields".

   The "Return-Path" header field provides the email return address in

=> Same thing.

   email address in the "For" field. <angle-addr> is augmented to
   include UTF-8 email address.

=> Missing space (it should be doubled after the final dot).

* Section  4.6
   o  it contains UTF-8 header values as specified in this document, or
   o  it contains UTF-8 values in the headers fields of body parts.

=> Hmm...  Is it clear regarding RFC terminology?
Isn't it "UTF-8 values in header field bodies" for the first and
I-don't-know-how-to-name-it (for "For" if I understand well?)
for the second?

   different properties.  Systems unaware of international headers
   Email clients which forward messages with international headers as

=> "internationalized"?

Regards,

-- 
Julien ÉLIE

« Tout est dans tout, et réciproquement. » (Pierre Dac)

---

From: "Ernie Dainow" <[email-masked]>
Date: Wed, 8 Sep 2010 11:31:38 -0400

Comment 1.
I think it is a nice improvement to have common ABNF across these documents
now. This principle should be carried forward, where appropriate, in the
rest of the EAI documents.

Whenever ABNF uses terms from another document, a reference should be cited
to make it easy for the reader to locate dependent definitions. This has
generally been done (sometimes the section is left out) but should be
checked again. I came across the following section where there is no
reference. Section 4.4 of rfc5335bis-02 uses elements such as uAddr-Spec
that are defined in rfc5336bis-02.

Comment 2.
The following are not defined anywhere. They should be added to
rfc5335bis-02.
uDomain 
uDot-String
sub-uDomain

Comment 3.
It is generally easier to read ABNF if any elements that are used have
already been defined. This allows the reader to scan backwards for elements
they don't recognize. If the BNF uses forward references, then after
scanning backwards and not finding the term, the reader then has to scan
forward.

The following rule definitions all contain forward references. The
readability of these documents could be improved by simply moving these
definitions so that they occur after the elements they rely upon.

rfc5336bis-02

      uTime-stamp-line = "Received:" FWS uStamp <CRLF>
          ; Replaces Time-stamp-line in Section 4.4 of RFC 5321

      uStamp = From-domain By-domain uOpt-info ";"  FWS date-time
          ; Replaces Stamp in Section 4.4 of RFC 5321

rfc5335bis-02

   comment =   "(" *([FWS] uCcontent) [FWS] ")"

   word    =   uAtom / uQuoted-String

   uQcontent      = uQtext / uQuoted-Pair

   uQuoted-String = [CFWS]
                        DQUOTE *([FWS] uQcontent) [FWS] DQUOTE
                        [CFWS]

   uDot-Atom =     [CFWS] uDot-Atom-text [CFWS]

   mailbox            =  name-addr / addr-spec / uAddr-Spec

   angle-addr         =/ [CFWS] "<" uAddr-Spec">" [CFWS] /
                     obs-angle-addr

-Ernie

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 5419 (20100902) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

---

From: "Ernie Dainow" <[email-masked]>
Date: Wed, 8 Sep 2010 12:11:47 -0400

Comment 1.
In Section 3.2, the following statement is made:

   This document applies only when an UTF8SMTPbis-aware client is trying
   to send an internationalized message to a server which requires the
   UTF8SMTPbis extensions to handle it.

In Section 3.4, the following statement seems to be out of scope.

   An "internationalized message" as defined in the appendix of this
   specification MUST NOT be sent to an SMTP server that does not
   support UTF8SMTPbis. Such a message should be rejected by a server
   if it lacks the support of UTF8SMTPbis.

What is the context for the following? 

   When messages are rejected because the RCPT command requires an ASCII
   address,

Since our scope is only UTF8SMTPbis servers, when would the server ever
reject a non-ASCII address? 

If this whole section is meant to cover the following case, it needs to be
more fully explained that we are talking about the SMTP server in the
middle.

UTF8SMTPbis client --> UTF8SMTPbis server --> legacy SMTP server
              <------------------- reject

Comment 2.
In Section 3.6.4.2, the phrase "and some clients might crash" does not seem
to be appropriate in a standards document. It is unnecessary and should just
be removed.

   If the SMTP client does not support the UTF8SMTPbis extension, but
   receives a UTF-8 string in a reply, it may not be able to properly
   report the reply to the user, and some clients might crash.
   Internationalized messages in replies are only allowed in the
   commands under the situations described above.  Under any other
   circumstances, UTF-8 text MUST NOT appear in the reply.

-Ernie

http://www.eset.com