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

[SM <sm at resistor.net>]

At 21:05 09-06-2008:
> > 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 

_______________________________________________
IMA mailing list
IMA at ietf.org
https://www.ietf.org/mailman/listinfo/ima