IMAP4 Multimailbox SEARCH Extension
RFC 7377
Yes
No Objection
Recuse
Note: This ballot was opened for revision 02 and is now closed.
(Pete Resnick; former steering group member) Yes
(Adrian Farrel; former steering group member) No Objection
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...
(Alissa Cooper; former steering group member) No Objection
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.
(Brian Haberman; former steering group member) No Objection
Thanks for including the RFC 6982 section!
(Jari Arkko; former steering group member) No Objection
(Joel Jaeggli; former steering group member) No Objection
(Kathleen Moriarty; former steering group member) (was Discuss) No Objection
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.
(Martin Stiemerling; former steering group member) No Objection
(Richard Barnes; former steering group member) No Objection
(Spencer Dawkins; former steering group member) No Objection
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)?
(Stephen Farrell; former steering group member) No Objection
(Ted Lemon; former steering group member) No Objection
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. :)
(Barry Leiba; former steering group member) Recuse