Re: [EAI] Last Call: <draft-ietf-eai-frmwrk-4952bis-07.txt> (Overview and Framework for Internationalized Email) to Proposed Standard

[Julien ÉLIE <[e-mail]>]

Hi all,

> The IESG has received a request from the Email Address
> Internationalization WG (eai) to consider the following document:
> - 'Overview and Framework for Internationalized Email'
>  <draft-ietf-eai-frmwrk-4952bis-07.txt> as a Proposed Standard

Thanks for the document, which I find to be very interesting.

Here are a few editorial remarks, as I read it:

* I read in the Abstract, in Section 1 and in Section 15 that
"This document is an update of RFC 4952".  Shouldn't it be better
to say that this document obsoletes RFC 4952?  (especially in the
Abstract)


* I do not fint it easy to read lists of RFC references.  For instance:

   A prior
   version of this specification, RFC 4952 [RFC4952], also provided an
   introduction to a series of experimental protocols [RFC5335]
   [RFC5336] [RFC5337] [RFC5504] [RFC5721] [RFC5738] [RFC5825].

Shouldn't commas be added between these references?

   This document, and others that comprise the collection described
   above, assume a reasonable familiarity with the basic Internet
   electronic mail specifications and terminology [RFC5321][RFC5322] and
   the MIME [RFC2045] and 8BITMIME [RFC1652] ones as well.  While not
   strictly required to implement this specification, a general
   familiarity with the terminology and functions of IDNA
   [RFC5890][RFC5891] [RFC5892][RFC5893] [RFC5894] are also assumed.

Aren't a few spaces missing between the references?  (+ commas)


* Section 6
   that turned out to not be the case

Isn't "that turned out not to be the case" better?


* Section 7.2
   For
   transition purposes and compatibility with legacy systems, this can
   done by extending the traditional MIME encoding models for non-ASCII
   characters in headers [RFC2045] [RFC2231].

I think "be" is missing at the end of the second line.


* I read in Section 8 "Submission server" with an uppercase letter, but
"submission server" in Sections 8.1 and 9 with a lowercase letter.
Shouldn't it be homogenized?


* Section 11.3
   While extensions to both
   POP3 [RFC1939] and IMAP [RFC3501] have been defined that include
   automatic upgrading of messages that carry non-ASCII information in
   encoded form -- including RFC 2047 decoding -- of messages by the
   POP3 [RFC5721bis-POP3] or IMAP [RFC5738bis-IMAP] server,

I think "have defined" is the right wording at the second line, isn't it?


* Section 14
   Expecting and most or all
   such transformations prior to final delivery be done by systems that
   are presumed to be under the administrative control of the sending
   user ameliorates the potential problem somewhat as compared to what
   it would be if the relationships were changed in transit.

Isn't it "Expecting that most or all [...]"?
I otherwise do not understand the meaning of the sentence.  Not easy
to understand at first reading by the way :-)


* In section 11 about additional issues, would it be worthwhile adding
a paragraph about Netnews gatewaying?
With a reference to Section 3.10.2 of RFC 5537, where it is for instance
written:

   News articles prepared by gateways MUST be valid news proto-articles
   (see Section 3.4.1).  This often requires the gateway to synthesize a
   conforming article from non-conforming input.  The gateway MUST then
   pass the article to an injecting agent, not directly to a relaying
   agent.

      NOTE: Message identifiers play a central role in the prevention of
      duplicates, and their correct use by gateways will do much to
      prevent loops.  Netnews does, however, require that message
      identifiers be unique, and therefore message identifiers from
      other media may not be suitable for use without modification.  A
      balance must be struck by the gateway between preserving
      information used to prevent loops and generating unique message
      identifiers.

   An incoming gateway MUST add a Sender header field to the news
   article it forms by containing the <mailbox> of the administrator of
   the gateway.  Problems with the gateway may be reported to this
   <mailbox>.  The <display-name> portion of this <mailbox> SHOULD
   indicate that the entity responsible for injection of the message is
   a gateway.  If the original message already had a Sender header
   field, it SHOULD be renamed to Original-Sender so that its contents
   can be preserved.

Addresses in Netnews are still derived from RFC 5322 (according to
Section 3.1.2 of RFC 5536) and only allow ASCII characters.
And other header fields are expected to be MIME-encoded.  No direct UTF-8.

News articles can also be PGP-signed (for control articles, moderated
newsgroups, de-spamming bots, etc.) so it is still not advisable to
use an i18n mail address in a From:, Sender: or Approved: header field
for instance...

(I hope that one day we will have UTF-8 newsgroup names and that
we will be able to send mails to an i18n email address that will be
posted (by gatewing) to an i18n newsgroup.)


Have a nice week,

-- 
Julien ÉLIE

« It's documented in The Book, somewhere... » (Larry Wall)