IMAP4 Access Control List (ACL) Extension
RFC 4314
Yes
(Scott Hollenbeck)
No Objection
(Bill Fenner)
(Brian Carpenter)
(David Kessens)
(Mark Townsley)
(Russ Housley)
(Ted Hardie)
Note: This ballot was opened for revision 08 and is now closed.
Scott Hollenbeck Former IESG member
Yes
Yes
()
Unknown
Bill Fenner Former IESG member
No Objection
No Objection
()
Unknown
Brian Carpenter Former IESG member
No Objection
No Objection
()
Unknown
David Kessens Former IESG member
No Objection
No Objection
()
Unknown
Jon Peterson Former IESG member
(was No Record, No Objection)
No Objection
No Objection
(2005-06-22)
Unknown
While this entire document concerns access and permissions, it seems to lack any text describing the protocol security requirements of a protocol that sets such permissions. Section 4 details what rights one must possess in order to modify ACLs, but I don't really see any text that describes the related threats concerning impersonation, replays, eavesdropping and so on in ACL creation. I have no doubt that mechanisms to address such threats exist in core IMAP (like SASL and STARTTLS), but it would be nice if this document explained why implementers should bother to use them.
Mark Townsley Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Sam Hartman Former IESG member
(was Discuss)
No Objection
No Objection
(2005-06-21)
Unknown
This document says that identifiers used as usernames for the login and authenticate commands are reserved to correspond to those users. However the authenticate command doesn't really take a username. I'm not sure what the right way of saying this in IMAP is, but in SASL it would be the authorization identity. But basically the text should be clarified to make it consistent with how authenticate actually works.
Ted Hardie Former IESG member
No Objection
No Objection
()
Unknown