Subject: [MORG] MORG notes from IETF 77

From: Randall Gellens <[email-masked]>
Date: Thu, 25 Mar 2010 18:58:12 -0700

These are tentative and merged from Murray's and my notes.
Please review and send corrections to the chairs.

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

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 extended LIST (like children).

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

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.

--

Randall Gellens

Opinions are personal;    facts are
suspect;    I speak for myself only

-------------- Randomly selected tag: ---------------

One never sits in hotel lobby chairs, my dear.  One never knows whom

has been sitting in them before one.

--unknown

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 26 Mar 2010 09:35:32 +0100

On 03/26/2010 02:58 AM, Randall Gellens wrote:
>     * 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
>         * Timo says Dovecot already has implemented most of INTHREAD for
>           internal purposes

That counts as demand to me. Expect a draft after easter, and I'll check 
that my code matches the draft too.

Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 26 Mar 2010 09:55:50 +0100

I didn't stay awake for this. I sleep better these days, but not so well 
that I'll disturb my sleep cycle voluntarily.

On 03/26/2010 02:58 AM, Randall Gellens wrote:
>     * Multi-mailbox search:
>
>         * Discussion about IN clause being a regular search condition
>         * Discussion on using message sequence numbers as criteria. (Use
>           case: search a single non-SELECTed mailbox.) Sense of room

That relieves me. I really didn't want to be non-compliant.

>         * Discussion about interaction of special-use flags and
>         * Open issues:
>             * Everyone should review this, but pay attention to the
>               issues listed in Section 3.

Will review again over easter.

>             * Security Considerations needs work. Barry asks for input
>               on list for what should go here.

What I ran into was interactions with access control. I found it was 
simplest to just restrict the search to the accessible mailboxes and be 
silent about the possible existence of others.

>             * Interactions with CONTEXT that seems complex. Barry asks
>               for people to review and send thoughts to this.

Caveat: I don't implement CONTEXT. I did review it, and decided to defer 
implementation until someone for it (saying "we use client x and want to 
y", not "maybe someone will find it useful").

The interactions are complex, but nothing record-breaking. Database 
people have equivalent facilities, and the DBMSes manage.

>             * Are there problems with implementing CONTEXT, NOTIFY, and
>               multi-mailbox search? Alexey says his head hurts thinking
>               about it.

So would mine do if I wanted to implement it all without able help ;)

>             * Suggestion to add EXCLUDE clause. Barry says this could be

What's the use-case for this?

Arnt

---

From: Daniel Keen <[email-masked]>
Date: Fri, 26 Mar 2010 08:30:19 -0700

One more thing that I brought up briefly but was more of a nit:

          Servers MAY allow the creation of a special-use mailbox even if one
             so designated already exists, having the effect of moving
the special
             use from the old mailbox to the new one.

I think that combined with the "can't have the same special-use
metadata existent more than once" we should make this more explicit,
such as (and should probably be written better):

Servers MAY allow the creation of a special use mailbox even if one so
designated already exists.  Servers MUST remove the special use from
the old mailbox and onto the new one.

D

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 27 Mar 2010 22:11:12 +0000

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:
>     * 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 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."
>           extension for searching using metadata, and this would
>           extend multi-mailbox search.
>         * Open issues:
>
>             * 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.
>
>
>         * 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".