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

From: Alexey Melnikov <[email-masked]>
Date: Wed, 01 Sep 2010 10:37:17 +0100

The IESG wrote:

>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
>  
>
A minor clarification about IETF process:

Chairs asked me if this document should be Proposed Standard or 
Informational. I decided to initiate the IETF Last Call as if it is 
going to Proposed. The document might end up being Informational based 
on IESG review, but the document status change from Proposed Standard to 
Informational can be done during IESG review and no additional Last Call 
would be needed.

---

From: Tony Hansen <[email-masked]>
Date: Wed, 01 Sep 2010 10:39:20 -0400

I reviewed this document and support it being published.

     Tony Hansen

On 8/31/2010 6:54 PM, The IESG wrote:
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2010-09-14. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-eai-frmwrk-4952bis/
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-eai-frmwrk-4952bis/
>
>
> No IPR declarations were found that appear related to this I-D.
> _______________________________________________
> IMA mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ima
>

---

From: Julien ÉLIE <[email-masked]>
Date: Wed, 1 Sep 2010 21:15:43 +0200

Hi all,

>  <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)

---

From: Barry Leiba <[email-masked]>
Date: Fri, 3 Sep 2010 10:46:41 -0400

> I reviewed this document and support it being published.

For the record: so have I, and so do I.

Barry

---

From: "Jiankang YAO" <[email-masked]>
Date: Mon, 6 Sep 2010 09:49:14 +0800

----- Original Message ----- 
From: "Barry Leiba" <[email-masked]>
To: <[email-masked]>
Sent: Friday, September 03, 2010 10:46 PM
Subject: Re: [EAI] Last Call: <draft-ietf-eai-frmwrk-4952bis-07.txt> (Overview and Framework for Internationalized Email) to Proposed Standard

> For the record: so have I, and so do I.

me too

Jiankang Yao

---

From: Sean Shen 沈烁 <[email-masked]>
Date: Mon, 6 Sep 2010 09:55:13 +0800

+1

Sean

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jiankang YAO
Sent: Monday, September 06, 2010 9:49 AM
To: [email-masked]; [email-masked]
Subject: Re: [EAI] Last Call: <draft-ietf-eai-frmwrk-4952bis-07.txt>
(Overview and Framework for Internationalized Email) to Proposed Standard

----- Original Message ----- 
From: "Barry Leiba" <[email-masked]>
To: <[email-masked]>
Sent: Friday, September 03, 2010 10:46 PM
Subject: Re: [EAI] Last Call: <draft-ietf-eai-frmwrk-4952bis-07.txt>
(Overview and Framework for Internationalized Email) to Proposed Standard

me too

Jiankang Yao

---

From: "Ernie Dainow" <[email-masked]>
Date: Wed, 8 Sep 2010 11:45:42 -0400

Comment 1.
In section 4.2, I find it difficult to relate the following statement to
what is actually stated in RFC2045.

   [RFC2045]
   prohibits applying a content-transfer-encoding to all subtypes of
   message/.  This specification relaxes the rule -- it allows newly
   defined MIME types to permit content-transfer-encoding

Section 6.4 of RFC2045 says

   If a Content-Transfer-Encoding header field appears as part of a
   message header, it applies to the entire body of that message.  If a
   Content-Transfer-Encoding header field appears as part of an entity's
   headers, it applies only to the body of that entity.

These seem to be saying different things. Perhaps rfc5335bis-02 can be
reworded to correspond more clearly to 2045, or illustrated with an example.

Comment 2.
In section 4.2, there are two problems with the statement

   In the case where a message
   containing a message/global is downgraded from 8-bit to 7-bit as
   described in [RFC1652]

RFC1652 is about "MIME messages". If this is equivalent to "message/global"
and is just a difference in terminology, say so. Otherwise the relationship
between MIME messages and message/global needs to be defined.

Second, RFC1652 does not describe downgrading, it says

   The specifics of the
   transformation from 8bit MIME to 7bit MIME are not described by this
   RFC

Comment 3.
Section 4.5. states

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

It is not easy to find the context of "For" fields. This needs a reference
to RFC5336bis, section 3.6.3.

-Ernie

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 5419 (20100902) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 10 Sep 2010 19:46:03 +0100

> a paragraph about Netnews gatewaying?

It might be reasonable to mention that EAI could be adapted to Netnews (I  
believe it would fit quite nicely), but that would be merely an aside,  
pointing out that it was "Future Work".

Indeed, an EAI extension SHOULD be written for Netnews, but this group, as  
currently chartered, is not the place to do it. Maybe some future WG, or  
maybe even an individual submission.

> use an i18n mail address in a From:, Sender: or Approved: header field

I don't really see a problem there.
> posted (by gatewing) to an i18n newsgroup.)

And obviously UTF-8 newsgroups names would be a principal feature of any  
future EAI-extended Netnews.

-- 
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

---

From: Julien ÉLIE <[email-masked]>
Date: Fri, 10 Sep 2010 22:24:04 +0200

Hi Charles,

> It might be reasonable to mention that EAI could be adapted to Netnews (I  believe it would fit quite nicely), but that would be 
> merely an aside,  pointing out that it was "Future Work".

Yep, it was my point.  Something like what is for instance done for URIs:

  11.1.  Impact on URIs and IRIs

    The mailto: schema [RFC2368] and discussed in the Internationalized
    Resource Identifier (IRI) specification [RFC3987] may need to be
    modified when this work is completed and standardized.

It is a section with only three lines.  I thought something similar
could have been added for Netnews.

> I don't really see a problem there.

No problem indeed.  I mentioned it because I had just read the draft
and it was totally fresh in my mind.  I just mentioned it after reading
Section 11.3:

  11.3.  Encoded Words, Signed Messages, and Downgrading

    For example, message parts that are cryptographically signed, using
    e.g., S/MIME [RFC3851] or Pretty Good Privacy (PGP) [RFC3156], cannot
    be upgraded from the RFC 2047 form to normal UTF-8 characters without
    breaking the signature.  Similarly, message parts that are encrypted
    may contain, when decrypted, header fields that use the RFC 2047
    encoding; such messages cannot be 'fully' upgraded without access to
    cryptographic keys.

The same issue affects downgrading a PGP-signed Approved: header field
in Netnews.  I meant that when I wrote my comment.
Sorry for not having said it more clearly.  I understand it is not obvious
at all when rereading what I wrote without any context.

-- 
Julien ÉLIE

« Ne crains pas d'avancer lentement, crains seulement de t'arrêter. »
  (proverbe chinois)

---

From: "Martin J. Dürst" <[email-masked]>
Date: Fri, 17 Sep 2010 15:53:42 +0900

> modified when this work is completed and standardized.

This just cought my eyes. First, the sentence is difficult to read. It 
seems to contain a parenthetical expression without clear boundaries. 
Was the intended meaning something such as:

The mailto: schema (see [RFC2368]; also discussed in the 
Internationalized Resource Identifier (IRI) specification [RFC3987]) may 
need to be modified when this work is completed and standardized.

Second, an update to RFC 2368 has been approved by the IESG (see 
https://datatracker.ietf.org/doc/draft-duerst-mailto-bis/). I guess it's 
that document that should be referenced. (maybe the RFC editor will fix 
that automatically?)

Third, I note that there is no talk anymore (at least not explicitly) 
about creating a new URI/IRI scheme. Not creating a new scheme is 
probably the right thing to do now that the fallback syntax in email 
addresses has been dropped.

Forth, draft-duerst-mailto-bis is already written with some foresight, 
saying:

        Percent-encoding of non-ASCII octets in the <local-part> of an
        <addr-spec> is reserved for the internationalization of the
        <local-part>.  Non-ASCII characters MUST first be encoded
        according to UTF-8 [STD63], and then each octet of the
        corresponding UTF-8 sequence MUST be percent-encoded to be
        represented as URI characters.  Any other percent-encoding of
        non-ASCII characters is prohibited.  When a <local-part>
        containing non-ASCII characters will be used to compose a
        message, the <local-part> MUST be transformed to conform to
        whatever encoding may be defined in a future specification for
        the internationalization of email addresses.

This means that implementers can use it for EAI addresses without any 
problems (not only is it clearly spelled out how to put non-ASCII 
characters in the LHS into a mailto: URI; it also so happens that the 
encoding used in EAI and in the percent-encoding in a mailto: URI is the 
same, UTF-8. (But note that the encoding used in an IRI doesn't have to 
be UTF-8; it's just the encoding used in the carrier of the IRI (e.g. 
email message or Web page or whatever).)

Of course I'm very much ready to produce another new version of 
draft-duerst-mailto-bis once the current one becomes an RFC, but the 
changes necessary for EAI might be limited to a few tweaks to the above 
paragraph, replacing 'reserved' with a pointer to the relevant EAI 
document(s).

Regards,    Martin.

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]

---

From: Joseph Yee <[email-masked]>
Date: Sun, 19 Sep 2010 22:47:21 -0400

On 2010-09-17, at 2:53 AM, Martin J. Dürst wrote:

> This just cought my eyes. First, the sentence is difficult to read. It seems to contain a parenthetical expression without clear boundaries. Was the intended meaning something such as:
> 
> The mailto: schema (see [RFC2368]; also discussed in the Internationalized Resource Identifier (IRI) specification [RFC3987]) may need to be modified when this work is completed and standardized.
> 
> Second, an update to RFC 2368 has been approved by the IESG (see https://datatracker.ietf.org/doc/draft-duerst-mailto-bis/). I guess it's that document that should be referenced. (maybe the RFC editor will fix that automatically?)
> 
> Third, I note that there is no talk anymore (at least not explicitly) about creating a new URI/IRI scheme. Not creating a new scheme is probably the right thing to do now that the fallback syntax in email addresses has been dropped.
> 
> Forth, draft-duerst-mailto-bis is already written with some foresight, saying:
> 
> This means that implementers can use it for EAI addresses without any problems (not only is it clearly spelled out how to put non-ASCII characters in the LHS into a mailto: URI; it also so happens that the encoding used in EAI and in the percent-encoding in a mailto: URI is the same, UTF-8. (But note that the encoding used in an IRI doesn't have to be UTF-8; it's just the encoding used in the carrier of the IRI (e.g. email message or Web page or whatever).)
> 
> Of course I'm very much ready to produce another new version of draft-duerst-mailto-bis once the current one becomes an RFC, but the changes necessary for EAI might be limited to a few tweaks to the above paragraph, replacing 'reserved' with a pointer to the relevant EAI document(s).
> 
> Regards,    Martin.
> 

Martin,

We have a deliverable for maito, properly a good place to capture the change.

* Mailto (Proposed Standard, updating draft-duerst-mailto-bis
to reflect internationalized addresses)

Best,
Joseph

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 20 Sep 2010 13:47:08 +0900

> to reflect internationalized addresses)

Hello Joseph,

Yes, the charter captures this  just fine. I was commenting on the text 
in the frmwrk document.

Regards,   Martin.