IMAP Extension for Referencing the Last SEARCH Result
draft-melnikov-imap-search-res-07
Yes
(Chris Newman)
No Objection
(Cullen Jennings)
(Dan Romascanu)
(Jon Peterson)
(Lars Eggert)
(Lisa Dusseault)
(Magnus Westerlund)
(Mark Townsley)
(Ron Bonica)
(Ross Callon)
(Russ Housley)
(Tim Polk)
Note: This ballot was opened for revision 07 and is now closed.
Chris Newman Former IESG member
Yes
Yes
()
Unknown
Cullen Jennings Former IESG member
No Objection
No Objection
()
Unknown
Dan Romascanu Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(2008-02-21)
Unknown
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 IESG member
No Objection
No Objection
()
Unknown
Lars Eggert Former IESG member
No Objection
No Objection
()
Unknown
Lisa Dusseault Former IESG member
No Objection
No Objection
()
Unknown
Magnus Westerlund Former IESG member
No Objection
No Objection
()
Unknown
Mark Townsley Former IESG member
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Ross Callon Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
(was Discuss, No Objection, Discuss, No Objection, Discuss)
No Objection
No Objection
()
Unknown
Tim Polk Former IESG member
No Objection
No Objection
(2008-02-05)
Unknown
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...