IMAP Extension for Referencing the Last SEARCH Result
RFC 5182
Yes
No Objection
Note: This ballot was opened for revision 07 and is now closed.
Lars Eggert No Objection
(Chris Newman; former steering group member) Yes
(Cullen Jennings; former steering group member) No Objection
(Dan Romascanu; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
Christian Vogt's review: This document specifies an IMAP extension that calls for servers to store search results in a way referable by clients in subsequent requests. The document is ready for publication once the issues described below has been addressed. The document clearly motivates the proposed IMAP extension, specifies it in an understandable manner, and accompanies this with a rich set of examples. Two issues need to be addressed, however: - Overall: For how long should a server store a given search result? The current document does not talk about state expiry. State expiry is important to address, however, given the large amount of memory that is potentially needed to hold a search result. I would specifically suggest to let the state expiry interval be determined by the server. This enables the server to discard search results earlier when memory availability is low. Reduction in state expiry intervals may also be used as a defense against DoS (and hence should mentioned in the security considerations). - Section 2.1, 3rd paragraph: What is the format in which lists are stored? This paragraph may refer to a data type from the IMAP specification to be more specific.
(Jon Peterson; former steering group member) No Objection
(Lisa Dusseault; former steering group member) No Objection
(Magnus Westerlund; former steering group member) No Objection
(Mark Townsley; former steering group member) No Objection
(Ron Bonica; former steering group member) No Objection
(Ross Callon; former steering group member) No Objection
(Russ Housley; former steering group member) (was Discuss, No Objection, Discuss, No Objection, Discuss) No Objection
(Tim Polk; former steering group member) No Objection
Does the implementation note in section 2.1 mean that implementors are required to convert a message sequence to a UID sequence, and vice versa? If this is mandatory to implement, perhaps a statement in the normative text would be worth adding...