Re: [lemonade] WGLC NOTIFY

[Alexey Melnikov <[e-mail]>]

Hi Timo,

Timo Sirainen wrote:

> On May 27, 2008, at 9:33 AM, Alexey Melnikov wrote:
>
>> Timo Sirainen wrote:
>>
>>> 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?
>>
>> Correct.
>>
>>> That would make it impossible to create clients
>>> that use MSNs and want to be immediately notified of EXPUNGEs (while
>>> IDLEing).
>>
>> 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.
>
This statement was incorrect (and I think your statement on which I 
commented is also incorrect). When MessageExpunge is requested, the 
server will either send EXPUNGE (with message numbers) or VANISHED (with 
UIDs). VANISHED is only sent if QRESYNC was also enabled.

Having said that, if the client specifies MessageExpunge and QRESYNC was 
not enabled, it will get MSNs immediately.

> "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?

Good question. I think this needs to be clarified.

> Anyway I think this is too restrictive if using NOTIFY basically 
> requires the client to drop using MSNs.

After rereading some portions of draft-ietf-lemonade-imap-notify, I 
would like to correct this: a client using NOTIFY can't use MSNs in 
commands it is issuing. However it will still be using MSNs to process 
server responses.

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

I assume the client still wants to immediately see changes in the 
current mailbox? In this case it should also include (selected 
(MessageNew MessageExpunge)) and things should work as before.

> 2. Client wants to use NOTIFY to ignore annotation changes, so it uses 
> NOTIFY SET (selected (FlagChange)).

FlagChange is tied to MessageNew and MessageExpunge, so this should 
really be "NOTIFY SET (selected (FlagChange MessageNew MessageExpunge))"

> EXISTS and EXPUNGEs are still sent in command replies, but not during 
> IDLE?

They will be sent in IDLE as well, as per my previous comment.

> 3. Client wants to get pushed information about new messages' contents 
> (MessageNew (uid ..)), but it still wants to keep using MSNs.

Can you elaborate on this use case?
Your MessageNew already contains "uid", so clearly the client is already 
capable of using UIDs anyway.

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

I would rather not special case IDLE, so that we can keep server logic 
consistent.
In light of my corrected statement above, can you double check that 
there is any issue?

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

True.
The reason why we have MessageExpunge and MessageNew tied together is 
because representative of a certain company kept moaning that he can't 
implement them separately. The WG couldn't find any use cases where this 
would make a difference for a client.

>> 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?!
>
> 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
[e-mail]
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade