Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-imap-notify-06.txt

From: Alexey Melnikov <[email-masked]>
Date: Sat, 26 Jul 2008 19:49:14 +0100

Timo Sirainen wrote:

>> <<Open Issue: should there be a way to require the server to return  
>> UNSEEN?>>
>
> My suggestion would be MessageNew-like parameters, maybe:

This seems sensible and at least one of my co-editor doesn't object to this.

With my server implementor hat on I would like to slightly change the 
meaning:

>   - FlagChange : Track all changes, don't return UNSEEN

I would say: track all changes, MAY return UNSEEN

>  - FlagChange (\Seen \*) : Track all changes, return UNSEEN

"track all changes, MUST return UNSEEN"

>  - FlagChange (\Seen) : Track only \Seen changes, return UNSEEN

"track \Seen changes, but MAY return all changes (so that it is easier 
for servers to implement)

> This would also allow in future:
>
>  - FlagChange ($keyword1 $keyword2)

Right.

> 2) Perhaps the ABNF should be changed so that filter-mailboxes- 
> selected can only contain message-events?

We could do this, I suppose. It might be easier to have this restriction 
in prose.

> And related to that: Is the  NONE events useful elsewhere than for 
> SELECTED/SELECTED-DELAYED?

Yes, just to make sure that the server doesn't send any non message 
related events by default.

> I  don't think so?

> So maybe the ABNF could be like:

> event-group = event-group-selected / event-group-other
>
> event-group-selected = "(" filter-mailboxes-selected SP 
> message-events  ")"
>
> message-events = ( "(" message-event *(SP message-event) ")" ) / "NONE"
>
> events = ( "(" event *(SP event) ")" )
>     ;; NONE dropped

_______________________________________________
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: Sat, 26 Jul 2008 22:39:43 +0300

On Jul 26, 2008, at 9:49 PM, Alexey Melnikov wrote:

> With my server implementor hat on I would like to slightly change  
> the meaning:
>
> "track \Seen changes, but MAY return all changes (so that it is  
> easier for servers to implement)

Why is it easier to implement? Anyway I don't mind these changes.