Subject: [EAI] Comments on draft-ietf-eai-rfc5335bis-02

From: SM <[email-masked]>
Date: Sat, 02 Oct 2010 08:16:44 -0700

Hello,

I read draft-ietf-eai-rfc5335bis-02 and I have a few comments.

In the Abstract Section:

   "This specification Updates"

That should be "updates".

In Section 1.2:

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

As the intended status of the document is Standards Track, the 
"participate in the experiment" is no longer applicable.  I suggest 
removing that sentence and adding:

   This document also updates RFC5322

at the end of the first paragraph of that section.

In Section 4:

   "To permit UTF-8 characters in field values, the header definition in
    [RFC5322] must be extended to support the new format."

I suggest the following to avoid the "must".

    To permit UTF-8 characters in field values, the header definition in
    [RFC5322] is extended to support the new format.

In Section 4.4:

    "DISPLAY_NAME" <ASCII@ASCII>
      ; traditional mailbox format

I suggest labelling that "standard mailbox format"

In Section 4.5:

    "For" fields containing internationalized addresses are allowed, by
    use of the new uFor syntax.

I suggest a rewrite:

   The uFor syntax has been added to allow the use of internationalized
   addresses in "For" fields.

  'The "Return-Path" header field provides the email return address in
   the mail delivery.'

I suggest:

   The "Return-path" designates the address to which messages indicating
   non-delivery or other mail system failures are to be sent.

In Section 4.6:

   "Internationalized messages must only be transmitted as authorized by
    [I-D.yao-eai-rfc5336bis] or within a non-SMTP environment which
    supports these messages."

I suggest using "MUST".

   "The type message/global is similar to message/rfc822, except that it
    contains a message that can contain UTF-8 characters in the headers
    of the message or body parts."

I suggest:

   The type message/global is similar to message/rfc822, except that it
   specifies that a message can contain UTF-8 characters in the headers
   of the message or body parts.

  '(Note that a system compliant with MIME that doesn't recognize
    message/global would treat it as "application/octet-stream" as
    described in Section 5.2.4 of [RFC2046].'

I suggest:

    (Note that a system compliant with MIME that doesn't recognize
    message/global MUST treat it as "application/octet-stream" as
    described in Section 5.2.4 of [RFC2046].

Regards,
-sm

---

From: Joseph Yee <[email-masked]>
Date: Mon, 4 Oct 2010 15:50:27 -0400

> That should be "updates".

+1

> As the intended status of the document is Standards Track, the "participate
> in the experiment" is no longer applicable.  I suggest removing that
> sentence and adding:
>

<individual>
Maybe mention the Experimental Draft? So that the whole thing says:

"This document also updates [RFC5322] and MIME[RFC2045], and obsolete
the Experimental Internationalized Email Header [RFC5335]."

Since the beginning of this doc already mention the obsolete of
RFC5335, I like SM's suggestions too.

</individual>

>   [RFC5322] is extended to support the new format.

<individual>
I think both are fine, personally like the suggested text more.
</individual>

> I suggest labelling that "standard mailbox format"

<chair>
concern: If we label this "standard", will users confuse as this is
the only format?  This part is showing examples, and the one below is
an UTF8 example, didn't use any word "standard" nor "new",
"extended".....

If we changed it the first one to standard, I think we should change
the second one's comment.
</chair>

>  addresses in "For" fields.

<chair>
The suggested text reads better.
</chair>

>  non-delivery or other mail system failures are to be sent.

<individual>
"Return-Path" is not for error case only right?

How about:
The "Return-Path" whose primary purpose is to designate ..... (follow
the rest of suggestion)

</individual>

>   supports these messages."

+1

>  of the message or body parts.

<chair>
Recommend to use the suggested text.
</chair>

>   described in Section 5.2.4 of [RFC2046].

<chair>
Agreed.  The source used 'must'.
</chair>

Thanks for the suggestions
Joseph

>
> Regards,
> -sm
>
> _______________________________________________
> IMA mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ima
>

---

From: SM <[email-masked]>
Date: Sun, 17 Oct 2010 10:01:14 -0700

Hi Joseph,
>the Experimental Internationalized Email Header [RFC5335]."

I suggest using:

   This document also updates [RFC5322] and MIME[RFC2045], and obsoletes
   [RFC5335].

I avoided using the title of RFC 5335 as it may be 
misunderstood.  It's fine with me if you use your version of the text.

>the second one's comment.

This is up to the WG Chair to decide.

>"Return-Path" is not for error case only right?

It is also used for for delivery status messages and other automatic responses.

>The "Return-Path" whose primary purpose is to designate ..... (follow

That's fine with me.

In the IANA Considerations Section:

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

That should be Section 4.6.  I don't know why the reference was to 
Section 4.4 in RFC 5335.

Regards,
-sm

---

From: John C Klensin <[email-masked]>
Date: Thu, 21 Oct 2010 12:44:17 -0400

> <chair>
> concern: If we label this "standard", will users confuse as
> this is the only format?  This part is showing examples, and
> the one below is an UTF8 example, didn't use any word
> "standard" nor "new", "extended".....

Personal opinion:
 
FWIW, for exactly that reason, I think "traditional" (or some
equivalent) is preferable here.  Once this document is adopted,
the new format will be "standard" too.
 
>...

best.
   john