Subject: [apps-discuss] Ted Lemon's No Objection on draft-ietf-appsawg-multimailbox-search-03: (with COMMENT)

From: "Ted Lemon" <[email-masked]>
Date: Thu, 07 Aug 2014 06:27:41 -0700

Ted Lemon has entered the following ballot position for
draft-ietf-appsawg-multimailbox-search-03: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-appsawg-multimailbox-search/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

   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. :)

---

From: Barry Leiba <[email-masked]>
Date: Thu, 7 Aug 2014 09:49:36 -0400

> use.

Right; forgive me for erroneously saying "widespread" in that
paragraph (which, by the way, at Adrian's suggestion will no longer be
removed at publication).

> and eagerly await explanation as to why I am wrong about this. :)

Indeed, it was debated for, quite literally, many minutes before being
settled on.

This *was* reviewed by the primary implementors of email servers, and
I'm confident that they think what's there is reasonable protocol
("MAY return 'BAD').  Perhaps it would be better to reverse its sense:
rather than saying that the server MAY consider it a protocol error to
include duplicates, say that it's a protocol error but the server MAY
accept and process it anyway.

The point, though, is that actual clients do not have a need for
mixing the non-specific mailbox specifiers ("selected", "personal",
"inboxes", "subscribed", and "subtree").  An ESEARCH that searches,
say, "subscribed" and "subtree" at the same time is just not going to
happen.  And because the "mailboxes" specifier takes only an explicit
list of mailboxes, with no wildcard matching, there's really no
problem for clients to make sure there's no overlap.

It's possible that a client might want to search << mailboxes "f1"
subscribed >>, where f1 is subscribed, but, again, that's the sort of
think a properly written client should be able to sort out (it ought
to know which mailboxes are subscribed).

The most likely user interface for this is a mailbox list with
check-boxes, which, by its nature, will de-dup things.

I suspect that a change from "BAD" to "NO" would be acceptable, but we
(the IMAP community) really don't see what's there as a problem for
implementations (&deity knows, there are enough other traps in
implementing IMAP, and this isn't one of them).

Barry

---

From: Ted Lemon <[email-masked]>
Date: Thu, 7 Aug 2014 10:05:12 -0400

> to know which mailboxes are subscribed).

This is in fact the scenario I was considering.   If the WG thought about this and doesn't care, I don't care.