Subject: [EAI] Disposition of comments, Last Call on EAI documents

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 10 Jun 2008 00:15:34 +0200

Based on the list of comments prepared by my co-chair, I have verified 
against the latest drafts the following dispositions.

I have called out those comments that have not resulted in changes in the 
drafts; I believe all others have been adequately addressed:

draft-ietf-eai-dsn-06:
  No comments requiring addressing.

draft-ietf-eai-smtpext-12:
  Comment from Frank ellermann on -11: Addressed.

  Comments from Miguel Garcia (gen-ART reviewer) on -11:
    A number of comments, all addressed in -12.

draft-ietf-eai-utf8headers-11:
  Comment from Spencer Dawkins (gen-ART reviewer) on -09:
    Most comments were addressed in -11. Some of them were
    replied to on the mailing list.
    Comment 7: the WG has  made a deliberate decision for
      message/global, and this will not be changed.
    Comment 8: Seems clear enough. Not changed.
    Comment 9: Mac typecode specific, probably clear to those
      who know about Mac UTIs.

  Comments from Frank Ellermann on -09 and -10:
     All addressed, except the comment about "message-id" vs
     "msg-id", and one NOTE IN DRAFT that has not been removed;
     the last one can be fixed with the RFC Editor.

To the best of my judgment, these documents are ready for IESG processing.

                  Harald Alvestrand, document shepherd

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

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 9 Jun 2008 21:05:54 -0700

As soon as Chris puts the others on the IESG agenda (Chris ping me  
when you do) I can put DSN on the agenda.

Lisa

On Jun 9, 2008, at 3:15 PM, Harald Tveit Alvestrand wrote:

> Based on the list of comments prepared by my co-chair, I have  
> verified against the latest drafts the following dispositions.
>
> I have called out those comments that have not resulted in changes  
> in the drafts; I believe all others have been adequately addressed:
>
> draft-ietf-eai-dsn-06:

---

From: SM <[email-masked]>
Date: Tue, 10 Jun 2008 08:44:34 -0700

> > draft-ietf-eai-utf8headers-11:

I sent some comments on the above draft to the author.  I didn't get 
any feedback on them. There were minor language nits.

In Section 2:

   "Issues about how to handle messages that contain UTF-8
    header fields but are proposed to be delivered to systems that have
    not been upgraded to support this capability are discussed elsewhere,
    particularly in [I-D.ietf-eai-downgrade]."

I suggest a rewording:

    Issues such as how to handle messages containing UTF-8 header fields that
    have to be delivered to systems that have not been upgraded to support
    this capability are discussed in [I-D.ietf-eai-downgrade].

In Section 4:

   "To permit UTF-8 characters in field values, the header definition in
    [RFC2822] must be extended to support new format. The following ABNF
    is defined to substitute those definition in [RFC2822]."

You used field bodies in the previous paragraph.  You could use 
"field bodies" instead of "field values" in that sentence.  You are 
extending the header definition in this draft.  There's no need for 
the "must be".  I suggest:

   To permit UTF-8 characters in field bodies, the header definition in
   [RFC2822] is extended to support the new format. The definition in [RFC2822]
   is substituted with the following ABNF.

  "Those syntax rules not referred to in this section remain as the
   original definition in [RFC2822]."

   The syntax rules not covered in this section remain as defined
   in [RFC2822].

In Section 4.5:

   "UTF-8 information in needed in Received
    fields and such information is therefore allowed, to preserve the
    integrity of those fields."

I suggest:

   UTF-8 information may be needed in Received fields.  Such information
   is therefore allowed to preserve the integrity of those fields.

   "The "Return-Path" header provides the email return address in the
    mail delivery.  Thus, it is augmented to carry UTF8 addresses (see
    the revised syntax of <angle-addr> in Section 4.4 of this document).
    This will not break the rule of trace field integrity, because it is
    added at the last MTA."

I copied the first sentence from RFC 2821:

    The "Return-Path" line preserves the information in the <reverse-
    path> from the MAIL command.  It is augmented to carry UTF8 addresses
    (see the revised syntax of <angle-addr> in Section 4.4 of this document).
    This does break the rule of trace field integrity as the "Return-Path" is
    added when the delivery SMTP server makes the "final delivery".

   "<item-value> on "Received:" syntax is augmented to allow UTF-8 email
    address on "For" clause. <angle-addr> is augmented to include UTF-8
    email address on previous chapter.  To allow UTF-8 email address also
    on syntax corresponding of <addr-spec> on original syntax, <utf8-
    addr-spec> is added to <item-value>."

I suggest:

    The <item-value> in the "Received:" syntax is augmented to allow a UTF-8
    email address in the "For" clause. <angle-addr> is augmented to
    include UTF-8 email address on previous chapter.  To allow a UTF-8 email
    address also in the syntax corresponding of <addr-spec> of the original
    syntax, <utf8-addr-spec> is added to <item-value>.

I left in "on previous chapter" as I am not sure what you meant to 
say.  Could you please explain to me what you are referring to 
there?  Did you mean section or paragraph?

In Section 4.6:

   "Systems unaware of international headers"

Shouldn't that be internationalized email headers?

Regards,
-sm