Subject: [EAI] EDITORIAL: draft-ietf-eai-utf8headers-07.txt

From: Alexey Melnikov <[email-masked]>
Date: Wed, 19 Sep 2007 23:20:20 +0100

Hi,

I fully support publication of this document. Some editorial comments/suggestions are below:

Abstract

   Full internationalization of electronic mail requires not only the
   capability to transmit non-ASCII content, to encode selected

..., but also a capability to encode selected

   information in specific header fields, and to use non-ASCII
   characters in envelope addresses.  It also requires being able to
   express those addresses and information based on them in mail header
   fields.  This document specifies an experimental variant of Internet
   mail that permits the use of Unicode encoded in UTF-8, rather than
   ASCII, as the base form for Internet email header field bodies.  This
   form is permitted in transmission only if authorized by an SMTP
   extension, as specified in an associated specification.

1.2.  Relation to other standards

   Allowing of use a content-transfer-encoding on subtypes of messages
   is not limited to transmissions, which are authorized by the SMTP
   extension specified in [EAI-SMTP-extension].

I am not sure what this sentence is trying to say. Is it saying something like the following:

   Transmissions of subtypes of the "message" MIME type containing content-transfer-encoding
   are authorized by the SMTP extension specified in [EAI-SMTP-extension].

?

4.2.  Changes on MIME headers

Changes *to* MIME headers

 [...]

   To be able to use UTF-8 characters in MIME header field paramerer

typo: parameter

   values, the syntax of <value> , as defined in [RFC2045], is extended
   as

4.3.  Syntax extensions to RFC 2822

 [...]

   To able to use UTF-8 on Content-Description header field on

To be able to use UTF-8 in Content-Description header field defined in

   [RFC2045], following syntax is used

I think "the" is missing before "following".

   <utext> syntax is extended on next chapter to allow UTF-8 characters

*in* the next chapter

   on <unstructured> header fields.

*in*

4.4.  Change on addr-spec syntax

   Internationalized email addresses are represented in UTF-8.  Thus,
   all header fields containing <mailbox>es are updated to permit UTF-8
   as well as an additional, optional all-ascii alternate address.

all-ASCII *alternative* address

   Below list a few possible <mailbox> representation as example.

Replace the whole sentence with "A few possible <mailbox> examples are listed below".

4.5.  Trace field syntax

 [...]

   The "Return-Path" header provides the email return address in the
   mail delivery.  Thus, it MUST able 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 fied integrity, because it is

typo: field

   added at the last MTA.

   <item-value> on "Received:" syntax is augmented to allow UTF-8 email

*in* "Received:" header field syntax

   address on "For" clause. <angle-addr> is augmented to include UTF-8

address *in* "For" clause.

   email address on previous chapter.  To allow UTF-8 email address also

email address *in the* previous chapter.

   on syntax corresponding of <addr-spec> on original syntax, <utf8-

*in* syntax ...

   addr-spec> is added to <item-value>.

4.6.  message/global

   Internationalized messages, also called UTF8SMTP messages, must only
   be transmitted as authorized by [EAI-SMTP-extension] or within a non-
   SMTP environment which supports these messages.  A message is a
   "message/global message", if

The previous version said "A message is a UTF8SMTP message". I think the old text is more correct.
(A message is message/global if it it has "message/global" MIME type)

   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.

   The second type, used for content return, is message/global which is
   similar to message/rfc822, except it contains a message with UTF-8
   headers.

I would change this sentence to read (This document only defines one MIME type):

   message/global is similar to message/rfc822, except that it contains a message with UTF-8
   headers.

10.2.  Informative References

 [...]

   [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part One: Format of Internet Message
              Bodies", RFC 2045, November 1996.

This reference is normative, so it should be moved to section 10.1

   [RFC3501]  Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
              4rev1", RFC 3501, March 2003.

This reference is no longer used, it should be deleted.

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

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 20 Sep 2007 14:10:29 +0100

>    are authorized by the SMTP extension specified in  
I think it is trying to say that some message types are now allowed to use  
encodings other than 7bit, 8bit and binary (i.e. Q-P and Base64), but I do  
not see where EAI-SMTP-extension] comes into it. Agreed it needs  
clarification.

> (A message is message/global if it it has "message/global" MIME type)

Yes, see my own editorial comments on this bit. I think s/UTF8SMTP  
message/global message/ throughout the documents will accord well with our  
decision to use message/global as the MIME type for them. But to speak of  
"message/global messages" seems an overkill.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5