Re: Proceedings for IMAPEXT meeting at IETF 63

[Alexey Melnikov <[e-mail]>]

Lisa Dusseault wrote:

> Here are the notes and the slides from the IMAPEXT meeting last week.
>
> Notes:
> http://ietf.webdav.org/imapext/notes/IETF63-imapext-notes.txt

Some editorial/clarifying comments for the notes below:

> There's a suggestion to extend the grammar such that we can later include
> "max 100" blah, but the change makes the grammar much more complex.

I was talking about LIST paged results, i.e. the client ask "return me 
the first 100 mailboxes", later on it can ask "return the next 100", etc.

> Dave as
> client developer was in favour, Arnt was against until there are two good
> reasons. Alexey mentioned IMAPABNF, I didn't really get the point.

I think I've mentioned that it might be better if extended LIST ABNF is 
moved to IMAPABNF draft. For example, ACL2 might use extended LIST 
responses, without the need to require the servers to implement 
LIST-EXTENDED. But this is a separate issue to allowing option 
parameters in LIST.

I've also said that I would hate to do an extension to LIST extension.

> Food for
> thought, he said. Tony Hansen cautioned against painting ourselves into
> a corner.
>  
> Barry doesn't feel that he has guidance yet, just incidental opinions. 
> Arnt
> emphasizes that give two good reasons, etc. Chris proposes erring on the
> side of complexity, since we've had to many too-limited list 
> extensions in
> the past.

I think we had a weak consensus that extended LIST should allow for 
options. Chris' argument was very convincing, at least for me.

> Interaction of REMOTE and RECURSIVEMATCH. Alexey: Would it be reasonable
> to return all mailboxes that might have remote children? Tricky 
> discussion
> ensues - is it a no-op or not?

The question is what should the server that doesn't support any remote 
mailboxes do.
REMOTE is not "return only remote mailboxes", it is "return all local + 
remote mailboxes". So REMOTE RECURSIVE might be a bit counter intuitive, 
because it doesn't answer the question "all mailboxes with remote children".

> Scribe is not alone being puzzled. Document
> needs clarification. Dave will provide some text.
>  
> Currently, the CHILDINFO works like this: If the parent matches the
> pattern and the child the other requirement,

"the child doesn't match the pattern, but matches the selection criteria."

> the parent with CHILDINFO
> is returned. Is that what clients need? Phillip explains RECURSIVEMATCH:
> Clients want to find something, and doesn't want to use LIST *.
>  
> Barry shows parent-child relationships on a way he eventually explains.
> Revision will ensue, and will be reviewed by people who don't get it. New
> revision Aug 19, then probably WGLC.
>  
> ANNOTATE: Brief agreement that we don't need another WGLC. We'll push 
> it on.
>  
> IMAP ABNF:
>  
>  - purpose: use of common syntax for all extension elements
>    (refactoring)
>  - which extended commands should be listed (suggestion to add CREATE
>    and maybe ESEARCH response)
>  - discussion about wording requirements on future documents
>  
> Alexey has noted similar but different ABNF in several extensions, and
> wants that to be the same. Much silence in room. Arnt spoke in favour,
> saying we now have the experience to write such a document. Lisa
> suggests it's suitable individual submission and can be discussed on
> the list.

I've also clarified that consistent syntax doesn't change any existing 
extension, it just make grammar more permissive in certain cases. This 
should only affect future extensions.

>
> Alexey suggests adding ESEARCH to IMAP ABNF. Noone seems to understand
> the implications.

There are several extensions to SEARCH that need to be compatible with 
each others:
1). "IMAP extension for referencing the last SEARCH result" 
(draft-melnikov-imap-search-res-02.txt)
2). "IMAP4 extension to SEARCH command for controlling what kind of 
information is returned" (draft-melnikov-imap-search-ret-01.txt)

Also, CONDSTORE extends SEARCH response, in the future it probably 
should also use ESEARCH response as well.

>  
> Hairsplitting over draft names. It's good to name things clearly enough
> that grep can find it. It's also good to mention thing on lemonade, since
> a small group of people are paying attention there.
>  
> COMPARATOR and stuff: comparator is lost, can WG adopt? (Script edits
> that now.) Adoption carries. Phillip, Barry will review. Tony too. No
> rename is required. Arnt will submit with the right bullet, including
> Dave's comments.
>  
> Tony likes comparator, thinks it's close.
>  
> Lisa asks about who implements Annotate. Arnt, Dave, who else?
>  
> Annotatemore and annotate: Depend on each other? Dave says amore has

typo: annotatemore

> been deployed, annotate not. 

[...]