IMAP4 Extension to SEARCH Command for Controlling What Kind of Information Is Returned
RFC 4731
Yes
No Objection
Note: This ballot was opened for revision 03 and is now closed.
Lars Eggert No Objection
(Lisa Dusseault; former steering group member) Yes
(Sam Hartman; former steering group member) Yes
(Ted Hardie; former steering group member) Yes
(Brian Carpenter; former steering group member) No Objection
Gen-ART reviewer Avri Doria said: This document is only understandable when taken with several other documents. The form of reference it uses relies on strong familiarity with the normative references. This may be fine given the specialized audience but it was a difficult draft to read. The IANA considerations seem sparse as it does not explcitly list the parameters for which values are needed. BC says: X-DRAFT-I02-ESEARCH < < fix before publication > > What fix is needed? Is IANA requested to provide a different value? 5. Security Considerations In general case IMAP SEARCH/UID SEARCH command can be CPU and/or IO intensive, so some sites/implementations even disable it entirely. This is quite unfortunate, as SEARCH command is one of the best examples demonstrating IMAP advantage over POP3. The ALL and COUNT return options don't change how SEARCH is working internally, they only change how information about found messages is returned. MIN and MAX SEARCH result options described in this document can lighten load on IMAP servers, which chose to optimize SEARCHes containing only one or both of them. What on earth has that to do with security?
(Cullen Jennings; former steering group member) No Objection
(David Kessens; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Jon Peterson; former steering group member) No Objection
(Mark Townsley; former steering group member) No Objection
(Ross Callon; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection