IMAP4 Multimailbox SEARCH Extension
draft-ietf-appsawg-multimailbox-search-04

I have no objection to the publication of this document, but please consider my one suggestion below. (Also a homily for the delectation of future generations.)

---

In section 1

   This extension was previously published as experimental.  There is
   now implementation experience, giving confidence in the protocol, so
   this document puts the extension on the Standards Track, with some
   minor updates that were informed by the implementation experience.
   [[RFC Editor: Please remove this paragraph at publication.]]

To the contrary, I think you should retain this paragraph and use it to
record how/why this document obsoletes 6327 with the inclusion of a
forward-pointer to section 8.

---

I appreciate your use of RFC 6982 (because I get commission), but the
information you included is not overwhelming or very detailed. Nothing 
to be done at this stage, but next time...

Section 2:

"A server that supports this extension includes "MULTISEARCH" in its IMAP capability string."

This jumped out at me as I would have expected a statement like this to be a normative requirement, rather than a statement of fact.

Thanks for including the RFC 6982 section!

Thanks for discussing my concerns around logging.  I'm okay with that being left as an implementation choice (not mentioned in the draft), but do think it would be helpful to have it for testing access controls as well as detection of unapproved access attempts.

One question, at most a nit.

 In the Abstract

   This
   extension also uses MAILBOX and TAG fields in ESEARCH responses,
                       ^^^^^^^     ^^^
   allowing a client to pipeline the searches if it chooses.  This
   document updates RFC 4466 and obsoletes RFC 6237.

but in 1.  Introduction

   o  The MAILBOX, UIDVALIDITY, and TAG fields in the responses allow a
          ^^^^^^^  ^^^^^^^^^^^      ^^^
      client to distinguish which responses go with which search (and
      which mailbox).  A client can safely pipeline these search
      commands without danger of confusion.  The addition of the MAILBOX
      and UIDVALIDITY fields updates the search-correlator item defined
      in [RFC4466].

I'm only pattern matching, but should these lists of fields match? 

Or am I not understanding (which is likely)?

   This extension was previously published as experimental.  There is
   now implementation experience, giving confidence in the protocol, so
   this document puts the extension on the Standards Track, with some
   minor updates that were informed by the implementation experience.
   [[RFC Editor: Please remove this paragraph at publication.]]

The list of implementations is apparently one, which is not in widespread use.   I mention this not to argue against reclassification.   But:

   The client SHOULD NOT provide source options that resolve to
   including the same mailbox more than once.  A server can, of course,
   remove the duplicates before processing, but the server MAY return
   "BAD" to an ESEARCH command with duplicate source mailboxes.

This sounds a little tenuous to me, and I wonder if it's not the result of some implementors making an engineering decision and then deciding to mention it in the RFC as advice.   ISTM that it's actually not unreasonable to expect two mail box terms to identify an overlapping set of mailboxes, and in such a case it would be very desirable for the server to eliminate the duplicate rather than rejecting the command: that is, it is easier for the server to know that such a duplication exists than for the client to know, and therefore requiring the client to prevent this error is more onerous than requiring the server to prevent the error.   ISTM that the right advice here is "the server should notice and eliminate duplicates when searching, and MUST NOT return BAD."   However I assume there was vigorous discussion on the working group mailing list that reached the conclusion presented in the current text, and eagerly await explanation as to why I am wrong about this. :)