Last Call Review of draft-ietf-appsawg-multimailbox-search-01
review-ietf-appsawg-multimailbox-search-01-opsdir-lc-winter-2014-07-21-00

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