Post Office Protocol Version 3 (POP3) Support for UTF-8
draft-ietf-eai-rfc5721bis-08
Yes
(Barry Leiba)
No Objection
(Benoît Claise)
(Brian Haberman)
(Gonzalo Camarillo)
(Martin Stiemerling)
(Robert Sparks)
(Ron Bonica)
(Stewart Bryant)
(Wesley Eddy)
Note: This ballot was opened for revision 07 and is now closed.
Barry Leiba Former IESG member
Yes
Yes
(for -07)
Unknown
Pete Resnick Former IESG member
Yes
Yes
(2012-09-21 for -07)
Unknown
In section 3.1: The character encoding format of maildrops may not be UTF-8 or ASCII. That sentence is wrong. Please correct.
Adrian Farrel Former IESG member
No Objection
No Objection
(2012-09-27 for -07)
Unknown
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.
Benoît Claise Former IESG member
No Objection
No Objection
(for -07)
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
(for -07)
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
(for -07)
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -07)
Unknown
Ralph Droms Former IESG member
No Objection
No Objection
(2012-09-27 for -07)
Unknown
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.
Robert Sparks Former IESG member
No Objection
No Objection
(for -07)
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
(for -07)
Unknown
Russ Housley Former IESG member
No Objection
No Objection
(2012-09-23 for -07)
Unknown
The abstract should mention that this document obsoletes RFC 5721.
Sean Turner Former IESG member
No Objection
No Objection
(2012-09-25 for -07)
Unknown
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.
Stephen Farrell Former IESG member
No Objection
No Objection
(2012-09-25 for -07)
Unknown
(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.
Stewart Bryant Former IESG member
No Objection
No Objection
(for -07)
Unknown
Wesley Eddy Former IESG member
No Objection
No Objection
(for -07)
Unknown