Post Office Protocol Version 3 (POP3) Support for UTF-8
RFC 6856

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

Barry Leiba Yes

(Pete Resnick) Yes

Comment (2012-09-21 for -07)
No email
send info
In section 3.1:

   The character encoding format of maildrops may not be UTF-8 or ASCII.

That sentence is wrong. Please correct.

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

(Ralph Droms) No Objection

Comment (2012-09-27 for -07)
No email
send info
Barry tells me the working group considered and rejected marking this
document as "updates RFC 2449".  I'd like the working group to
reconsider that decision, considering this text from the IANA
considerations:

   Section 2 and 3 of this specification update two capabilities ("UTF8"
   and "LANG") to the POP3 capability registry [RFC2449].

   Section 5 of this specification also adds one new response code
   ("UTF8") to the POP3 response codes registry [RFC2449].


It seems to me anyone implementing POP3 from scratch or updating an
existing implementation should read this document as part of that
implementation.

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

Comment (2012-09-27 for -07)
No email
send info
Please ask the RFC editor to remove section 8 before publication.

---

When a new document obsoletes an old one, it is really nice to include
a short section stating the changes. I think it is unfortunate that this
document doesn't include such a section.

(Stephen Farrell) No Objection

Comment (2012-09-25 for -07)
No email
send info
(Sorry, ignore the previous mail, I attached the wrong comment
to the wrong document.)

I checked the diff with 5721 but its not that useful since there
are a lot of changes. Apologies in advance if I comment on
something that's unchanged from there and feel free to ignore
such comments.

- 2.1: Why mustn't clients issue the STLS command after UTF8?  I
don't get that.

(Brian Haberman) No Objection

(Russ Housley) No Objection

Comment (2012-09-23 for -07)
No email
send info
  The abstract should mention that this document obsoletes RFC 5721.

(Robert Sparks) No Objection

(Martin Stiemerling) No Objection

(Sean Turner) No Objection

Comment (2012-09-25 for -07)
No email
send info
Along the same lines as Stephen's suggestion in response to Chris:

s7: A bit more precise ?:

OLD:

  A mechanism to protect the
   integrity of the session, such as Transport Layer Security (TLS)
   [RFC2595] can be used to defeat such attacks.

NEW:

   A mechanism to protect the integrity of the session can be used
   to defeat such attacks, e.g., issuing the STLS [RFC2595] command
   before issuing the LANG command.