Hello, I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the operational area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I believe this draft is ready. I have one question below where I'd appreciate a short answer (marked ??? ) which is probably only due to my own insufficient knowledge of the innards of IMAP. The draft defines a new extension to the IMAP protocol. A new command can be sent by the client. The command is meant to be triggered manually by a human who searches for content in a number of mailboxes he has access to (as opposed to IMAP without this extension, where he could only search in one single mailbox at a time). IMAP servers advertise the corresponding extension, so clients know whether it is at their disposal for use or not. There are workarounds for a client if it is not (multiple searches in one mailbox each). The deployment of the extension can be done safely in a step-up manner; there are no backward-compatibility issues. The security considerations section mentions workload considerations and reminds of the necessity of access control and computation time limitations. ??? When an ESEARCH hits those configured limits, e.g. maximum permitted computation time on the query has been exceeded, can this be communicated to the client, or is that a "silent" failure? Also, does the ESEARCH then yield partial results, or none at all? As a user, I would appreciate notice that my search results are incomplete - either in terms of "only N out of M mailboxes searched" or "stopped after 1000 hits to your search terms". Assuming I have the necessary access rights to the mailboxes in question, there is no security leakage in telling me (otherwise, fully agree to the "insufficient access" distinguishing in the Security Considerations). None of the return values "OK" "NO" and "BAD" seems to capture the condition above clearly (NO is close, but could also mean things like charset mismatch, so it's not very clear as a response). But maybe there is some standard IMAP signalling for things like that elsewhere in the protocol. Then apologies for my question. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Attachment: 0x8A39DC66.asc Description: application/pgp-keys Attachment: signature.asc Description: OpenPGP digital signature