Simplified POP and IMAP Downgrading for Internationalized Email
RFC 6858

Note: This ballot was opened for revision 07 and is now closed.

Barry Leiba Yes

(Pete Resnick) Yes

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

Comment (2012-09-24)
No email
send info
The most often cited originator of rule 12 was William of Ocam (b1285) though scollars who know more about these things than I think that it does back much further. I am most interested in the nature of the help that William was able to provide the Apps Area on this work.

(Gonzalo Camarillo) No Objection

(Benoît Claise) (was Discuss) No Objection

Comment (2012-11-12)
No email
send info
While the writeup mentions:

      Consequently the base IMAP and POP3
      documents are no longer dependent on particular downgrading
      choices and that two methods presented are, to a considerable
      extent, just examples.

I believe that the two methods should be Informational, as opposed to Standards Track.

However, I now see the following sentence, which was essential to me:
    While this document specifies a well designed mechanism, it is only
   an interim solution while clients are being upgraded
   [I-D.ietf-eai-rfc5721bis] [I-D.ietf-eai-5738bis].

So I'll clear my DISCUSS.

Regards, Benoit

(Ralph Droms) No Objection

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

Comment (2012-09-26)
No email
send info
It is petty of me and you may ignore this Comment at your discretion,

   This document specifies a method for IMAP and POP servers to serve
   internationalized messages to conventional clients.

1. Those would be "email clients" or "IMAP or POP clients" I guess
2. What is convention these days?

" email clients that do not include internationalization support"
be better?


Section 1 para 1



Section 5

   Some POP or IMAP clients, such as Fetchmail, download messages and
   delete the version on the server.  This may lead to permanent loss of
   information when the only remaining version of a message is the
   synthetic message.

This seems to suggest that the mechanisms described in this document 
might not always be what the user wants the server to do (i.e., they
would prefer the message was hidden on the conventional MUA and found by
the internationalized MUA, rather than downgraded for the conventional
MUA and deleted from the server).

That seems to suggest that the behavior of the server must be 
configurable per account with the default to hide.

(Stephen Farrell) No Objection

Comment (2012-09-25)
No email
send info

- The reference on page 2 to 5738 should presumably be to

- Examples would be good here, and as with the other downgrade
approach, it'd be nice if there were a PDF version that showed
actual non-ASCII.

(Brian Haberman) No Objection

(Russ Housley) (was Discuss) No Objection

(Robert Sparks) No Objection

Comment (2012-09-27)
No email
send info
(Same comment made on -downgrade):

Consider reinforcing in the security considerations section that the actions
described by this document do not include removing any signatures from the
original message - discouraging a server implementation from trying to be
'helpful' by removing a signature they know will fail.

(Martin Stiemerling) No Objection

(Sean Turner) No Objection