Re: [MORG] MORG notes from IETF 77

[Alexey Melnikov <[e-mail]>]

Randall Gellens wrote:
> These are tentative and merged from Murray's and my notes.  Please 
> review and send corrections to the chairs.
This looks fine, some editorial corrections (mostly minor) below:
> The chairs thank Murray for taking notes.
>
>     * Barry is now co-chair
>     * Status in List now published (RFC 5819)
>     * Sort Display is ready for IETF Last Call
>
Actually it is ready for IESG review.
>
>     * Collations un-dropped if Ned and his colleague produce a new
>       version of the document.
>
>
>     * Special-use mailboxes:
>
>         * Barry to remove text allowing multiple mailboxes to have the
>           same tag.
>
>         * Discussion on how to add a special-use tag to an existing
>           mailbox.
>         * Proposal: leave CREATE option, don't add any non-METADATA
>           way to add special-use tag, define METADATA way (registry)
>           to add or change special use tags (if you support METADATA,
>           we will give a reserved item for this function).  No
>           objection in room; adopted.
>         * Discussion if client needs to request that special use-tags
>           be returned, or if they can always be returned.  Conclusion
>           that this is OK for unextended LIST (like IMAP CHILDREN).
>
I've uppercased METADATA/CHILDREN above to be clearer that we are 
talking about IMAP extensions.
>
>         * There is a problem discovering mailboxes which have
>           special-use tags, especially if they are not in the base
>           tree.  Barry suggests a SELECT option
>
to the LIST command
>
>         * so a client can select all mailboxes with special-use
>           flags.  Something like LIST (SPECIAL-USE) "" * that lists
>           only them.
>
>
>     * Multi-mailbox search:
>
>         * Discussion about IN clause being a regular search condition
>           instead of a modifier at the start.  No agreement to do this.
>         * Discussion on using message sequence numbers as criteria. 
>           (Use case: search a single non-SELECTed mailbox.)  Sense of
>           room that this does not makes sense and could be difficult
>           for some servers.  While there may be some use cases, these
>           are not considered valuable enough to outweigh server issues.
>
I would add: "Agreement that that a multimailbox search with message 
numbers should result in a BAD tagged response."
>
>         * Discussion about interaction of special-use flags and
>           multi-mailbox search.  Barry suggests a new draft with an
>           extension for searching using metadata, and this would
>           extend multi-mailbox search.
>         * Open issues:
>
>             * Everyone should review this, but pay attention to the
>               issues listed in Section 3.
>             * Security Considerations needs work.  Barry asks for
>               input on list for what should go here.
>             * Interactions with CONTEXT that seems complex.  Barry
>               asks for people to review and send thoughts to this.
>             * Are there problems with implementing CONTEXT, NOTIFY,
>               and multi-mailbox search?  Alexey says his head hurts
>               thinking about it.
>             * Suggestion to add EXCLUDE clause.  Barry says this could
>               be done with metadata, perhaps.
>
>
>     * Address Search: stalled; Arnt says he'll do it if there is real
>       demand.
>
>
>     * In Thread: stalled; Arnt says he'll do it if there is real demand.
>
>         * Dan Keen says he wants it and would help with draft.  Alexey
>           says he'll implement as well.
>         * Timo says Dovecot already has implemented most of INTHREAD
>           for internal purposes
>
>
>     * Discussion on a new SORT extension for top x non-deleted messages.
>
>         * ESEARCH PARTIAL
>         * CONTEXT has PARTIAL paging
>
>
>     * Discussion on a command where clients could announce the
>       extensions they want, e.g., REQUEST, so that the server
>       developer (such as Google) can focus extension effort on those
>       that have a lot of demand.
>     * Chris suggests using Client ID.
>
as in "ID IMAP extension".