[lemonade] List of open issues for IMAP NOTIFY

[Alexey Melnikov <[e-mail]>]

Below is the list of major open issues with the document. There are some 
other minor editorial questions which are not worth discussing at this 
point.

1). Peter Coates has indicated that his implementation can't report 
ExpungeMessage without NewMessage or vice versa. I've suggested that we 
should probably combine NewMessage and ExpungeMessage into a single 
event. So far I can't think of any disadvantage of this: for example if 
the client would like to know about expunges (so it can handle VANISHED 
reported at any time), then it is not a big deal to handle (or ignore) 
notifications about new messages as well. If the client can't handle 
expunges, then it wouldn't request either. If you can think of a use 
case when a client would only want NewMessage, but can't handle 
ExpungeMessage, please let me know.

Another way of handling this issue would be to allow the server to 
announce that certain event types are bundled together. I am not sure if 
the extra complexity on clients is worth it.

2). Whether BODY FETCH data item in the NOTIFY command (and the like) 
should automatically set the \Seen flag on newly delivered/appended 
messages if  it is specified in the NewMessage event.
The issue needs to be addressed. I prefer to have the same behavior as 
in FETCH (for consistency), but I don't have a strong opinion on this. 
Opinions?

3). Peter Coates has suggested that only the SELECTED mailbox matching 
criteria should apply to the currently selected mailbox.
Currently the draft suggests that any mailbox matching criteria can 
apply to the currently selected mailbox.

Speaking as an individual participant in the WG: as this is marginally 
easier to implement for servers, I am now leaning toward accepting 
Peter's proposal. Any objections?

4). Peter Coates has suggested removal of ADD/SET keyword in the NOTIFY 
command, or restrict NOTIFY command to a single event-group.

Speaking as an individual participant in the WG: I think we want to 
allow for at least 2 event groups (one for the currently selected 
mailbox and one for all other mailboxes). But I can also see use cases 
for different events on shared mailboxes, etc. If we have 2, a rule of 
good design suggests that we should allow for any number.

Now, regarding SET versa ADD. If we allow for multiple event groups 
above, this means that one need to store them in a server as a list 
anyway. So restricting NOTIFY to a single event group is not going to 
make NOTIFY easier to implement for servers.
I also see some arguments about ADD (e.g. now monitor this new mailbox).

So speaking as an individual, I would like to keep multiple event groups 
and SET/ADD as is.
If you disagree, please speak up *now*.

_______________________________________________
lemonade mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade