Subject: Re: [lemonade] WGLC NOTIFY

From: Eric Burger <[email-masked]>
Date: Fri, 16 May 2008 08:16:58 -0400

DUDES!!!

I still have not received ANY last call comments.  Please at least  
give us some +1's.

On Apr 22, 2008, at 5:35 PM, Eric Burger wrote:

> OK, I may have been joking: there were absolutely NO last call  
> comments.
>
> If NOTIFY is so beautiful that you couldn't even hit +1, go ahead,  
> feel
> good, and +1 me.
>
> Thanks.
>
>
> On 4/22/08 5:10 PM, "Eric Burger" <[email-masked]> wrote:
>
>> WGLC is closed.
>>
>>
>> On 3/31/08 10:01 AM, "Eric Burger" <[email-masked]> wrote:
>>
>>> IMAP NOTIFY is ready for Work Group Last Call.
>>>
>>> There has already been one comment that Alexey said he will put in  
>>> the
>>> final version.  Anything else anyone wants to see?
>>>
>>> <http://www.ietf.org/internet-drafts/draft-ietf-lemonade-imap-notify-05 
>>> .
>>> txt>
>>>
>>> WGLC closes 11 April 2008.
>>>
>>> Notice:  This email message, together with any attachments, may  
>>> contain
>>> information  of  BEA Systems,  Inc.,  its subsidiaries  and   
>>> affiliated
>>> entities,  that may be confidential,  proprietary,  copyrighted   
>>> and/or
>>> legally privileged, and is intended solely for the use of the  
>>> individual or
>>> entity named in this message. If you are not the intended  
>>> recipient, and have
>>> received this message in error, please immediately return this by  
>>> email and
>>> then delete it.
>>> _______________________________________________
>>> lemonade mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/lemonade
>>> Supplemental Web Site:
>>> http://www.standardstrack.com/ietf/lemonade
>>
>>
>> Notice:  This email message, together with any attachments, may  
>> contain
>> information  of  BEA Systems,  Inc.,  its subsidiaries  and   
>> affiliated
>> entities,  that may be confidential,  proprietary,  copyrighted   
>> and/or
>> legally privileged, and is intended solely for the use of the  
>> individual or
>> entity named in this message. If you are not the intended  
>> recipient, and have
>> received this message in error, please immediately return this by  
>> email and
>> then delete it.
>> _______________________________________________
>> lemonade mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/lemonade
>> Supplemental Web Site:
>> http://www.standardstrack.com/ietf/lemonade
>
>
> Notice:  This email message, together with any attachments, may  
> contain information  of  BEA Systems,  Inc.,  its subsidiaries  and   
> affiliated entities,  that may be confidential,  proprietary,   
> copyrighted  and/or legally privileged, and is intended solely for  
> the use of the individual or entity named in this message. If you  
> are not the intended recipient, and have received this message in  
> error, please immediately return this by email and then delete it.
> _______________________________________________
> lemonade mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lemonade
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/lemonade

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

---

From: Timo Sirainen <[email-masked]>
Date: Fri, 16 May 2008 18:22:46 +0300

(Resend, accidentally used Reply instead of Reply-to-all for first send)

I was too busy to give comments on time, but here are some now anyway:

> If FlagChange event is specified, MessageNew and MessageExpunge MUST
> also be specified by the client.

I assume this is because otherwise it's difficult for server. So  
shouldn't this be "If FlagChange or AnnotationChange event is .." to  
make it easier also for servers supporting annotations? Or are  
annotations handled somehow differently from flags? (I haven't  
implemented annotations or read the spec for a while)

Kind of a conflict:

> If either AnnotationChange or FlagChange are included and the server  
> also supports CONDSTORE [RFC4551] and/or QRESYNC [QRESYNC]  
> extension, the STATUS response MUST contain UIDVALIDITY and  
> HIGHESTMODSEQ.

vs.

> If the change happens in another mailbox, then the response depends  
> on whether CONDSTORE [RFC4551] and/or QRESYNC [QRESYNC] is being  
> used. If so, the server sends a STATUS (HIGHESTMODSEQ) response.

So is UIDVALIDITY required to be sent or not?

> Note that for different event types different <event-group>s can  
> apply to the same mailbox. .. SubscriptionChange event will also be  
> reported for INBOX due to the second <event-group>.
> C: a notify set (mailboxes INBOX (Messagenew messageExpunge))  
> (personal (SubscriptionChange))

Is SubscriptionChange somehow more special than other events then,  
because the next example shows:

> In this example, the client asks for FlagChange events for all  
> personal mailboxes except the selected mailbox:
> C: a notify set (selected (Messagenew (uid flags) messageExpunge))  
> (personal (MessageNew FlagChange MessageExpunge))

I suppose the intent is to separate message-events, mailbox-events and  
user-events into their own overridable groups? If so, I think it  
should say that.

Also I find FlagChange for non-selected mailboxes to be a bit  
pointless currently. A FlagModseqChange would better describe what it  
currently sends to clients. But maybe using different names for  
selected and non-selected event groups would be a bit too complex.  
Anyway the point is that I think this should work well in future when  
it's integrated with STATUS-COUNTERS so that a client can ask for all  
flag changes on selected mailbox and also have server reply with flag  
counters on non-selected mailboxes.
_______________________________________________
lemonade mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 19 May 2008 11:42:53 +0400

> (Resend, accidentally used Reply instead of Reply-to-all for first send)
Hi Timo,
Thank you for your review.
> I assume this is because otherwise it's difficult for server.
Yes. Peter Coates has requested this.
> So shouldn't this be "If FlagChange or AnnotationChange event is .." to  
Agreed.
> So is UIDVALIDITY required to be sent or not?
It is required, as without UIDVALIDITY HIGHESTMODSEQ is meaningless.
I will fix the document.
> because the next example shows:
No, it is not. I just wanted to include in one example an event that was 
not a message specific event.
> user-events into their own overridable groups?
Can you clarify what is your definition of "overridable"?
> If so, I think it  
> pointless currently.
Yes.
> A FlagModseqChange would better describe what it  
Exactly.
> counters on non-selected mailboxes.
Yes.

---

From: Timo Sirainen <[email-masked]>
Date: Mon, 19 May 2008 13:01:44 +0300

> Can you clarify what is your definition of "overridable"?

Being able to drop an event. If you look at the examples and their
descriptions:

> SubscriptionChange event
> will also be reported for INBOX due to the second <event-group>.
> 

This means the result is a union of "mailboxes INBOX" events and
"personal" events, because they both match INBOX.

The next example however shows:

>         C: a notify set (selected (Messagenew (uid flags)
>            messageExpunge)) (personal (MessageNew FlagChange
>            MessageExpunge))

Using the previous logic I would have thought that the result is again a
union of "selected" and "personal" events, resulting flag changes being
returned again. Unless "selected" is treated specially? So given two
more simplified examples:

a notify set (selected (MessageNew MessageExpunge)) (personal
(SubscriptionChange))

b notify set (selected (MessageNew MessageExpunge)) (personal
(MessageNew MessageExpunge FlagChange))

If a) returns SubscriptionChange, does b) return FlagChanges or not, and
using what logic?

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 22 May 2008 23:56:48 +0400

Timo Sirainen wrote:
> Being able to drop an event.
Sorry, what do you mean by "drop an event"?
> If you look at the examples and their
> descriptions:
>   
>> SubscriptionChange event
Correct.
> returned again. Unless "selected" is treated specially?
"Selected" is indeed treated specially, as per the following text in
section 3.1:

The NOTIFY SET command can request notifications of changes to the
selected mailbox, whatever it may be at the time the notifications are
being generated. This is done by specifying the SELECTED mailbox
selector (see Section 6.1) in the NOTIFY SET command. The client can
also request notifications on other mailboxes by name or by a limited
mailbox pattern match. The notifications returned for the currently
selected mailbox will be those specified by the SELECTED mailbox
specifier, even if the selected mailbox also appears by name in the command.

So, according to this text:
> So given two more simplified examples:
>
This would result in MessageNew and MessageExpunge events for the
currently selected mailbox (whether it is a personal one or not) and
subscription change notifications for all personal mailboxes except for
the currently selected one (if it is a personal mailbox).

Hmm, this raises an interesting question: is the "except for the
currently selected" part in the last sentence is what we actually want?
Should "Selected"only apply to message level events?
> (MessageNew MessageExpunge FlagChange))
This would result in MessageNew and MessageExpunge events for the
currently selected mailbox (whether it is a personal one or not) and
MessageNew+MessageExpunge+FlagChange notifications for all personal
mailboxes except for the currently selected one (if it is a personal
mailbox).

---

From: Timo Sirainen <[email-masked]>
Date: Sun, 25 May 2008 22:55:39 +0300

> "Selected" is indeed treated specially, as per the following text in

OK, I guess this answers my question. It would be helpful if the

>            messageExpunge)) (personal (MessageNew FlagChange

to something like:

In the next example the client asks for FlagChange events for all
personal mailboxes except the selected mailbox. This is different from
the previous example, because SELECTED overrides all other event
definitions.

> Should "Selected"only apply to message level events?

I think that would be better.

One more thing I thought of:

> If IDLE (as well as this extension) is supported, while processing
>     IDLE the server MUST send the same events as instructed by the
>     client using the NOTIFY command.

Does this mean EXPUNGEs must not be sent if MessageExpunge isn't
included in NOTIFY SET? That would make it impossible to create clients
that use MSNs and want to be immediately notified of EXPUNGEs (while
IDLEing).
_______________________________________________
lemonade mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 27 May 2008 10:33:25 +0400

Timo Sirainen wrote:
> included in NOTIFY SET?
Correct.
> That would make it impossible to create clients
Correct. The client can either chose not to use NOTIFY at all (in which 
case it will get expunges with MSNs), or it can chose to specify both 
MessageNew & MessageExpunge (they are tied together as per section 5), 
in which case it will get back UIDs.

It is possible that some servers that support IDLE don't send 
MessageExpunge events while idling, but I haven't seen any such server. 
We could mandate that all servers advertising the NOTIFY capability send 
MessageExpunge during IDLE if NOTIFY wasn't issued on the connection?!

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 27 May 2008 11:13:36 +0400

> the previous example, because SELECTED overrides all other event
I've changed this in my copy.
> I think that would be better.
I think this change would need wider support from the WG, that is why 
I've changed the subject of this message.

Speaking personally, I am in favor of this change, because behaviour of 
SELECTED might be a bit surprising.

I would like to hear what other people think about this, in particular I 
would like to hear opinions from Peter Coates and Arnt.

---

From: Timo Sirainen <[email-masked]>
Date: Tue, 27 May 2008 13:30:14 +0300

> in which case it will get back UIDs.

"get back UIDs"? Do you mean VANISHED? Doesn't that depend on the  
server if it or EXPUNGE is sent?

What happens if NOTIFY SET is used, but SELECTED isn't specified? I  
can't seem to find this from the draft. I'm guessing it'll use the  
defaults? Or does it use the first other matching rule?

Anyway I think this is too restrictive if using NOTIFY basically  
requires the client to drop using MSNs. Some use cases for clients  
which want to keep using MSNs and IDLE:

1. Client just wants to use NOTIFY to see changes in other mailboxes,  
so it specifies NOTIFY SET (personal (messagenew messageexpunge)).

2. Client wants to use NOTIFY to ignore annotation changes, so it uses  
NOTIFY SET (selected (FlagChange)). EXISTS and EXPUNGEs are still sent  
in command replies, but not during IDLE?

3. Client wants to get pushed information about new messages' contents  
(MessageNew (uid ..)), but it still wants to keep using MSNs. Since  
MessageNew and MessageExpunge must specified together, this is  
impossible.

Is there even any other reason for client to even run IDLE unless it  
wants to keep using MSNs + see EXPUNGEs immediately? I think IDLE  
could be specified as sending EXPUNGEs immediately regardless of  
whether MessagExpunge has been specified.

3. is also problematic. Is it really necessary to give MessageExpunge  
if MessageNew is given? The (well-behaving) servers already have to  
handle the case when a message is expunged and a new message arrives  
during FETCH/STORE/SEARCH command. The client is notified about the  
new message but not about the expunge.

> MessageExpunge during IDLE if NOTIFY wasn't issued on the connection?!

I don't think that really matters since well-behaving servers already  
do that. I'm more concerned that well-behaving servers aren't allowed  
to do that when NOTIFY is used..
_______________________________________________
lemonade mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade