Subject: [lemonade] Notify

From: Timo Sirainen <[email-masked]>
Date: Wed, 19 Mar 2008 14:59:14 +0200

A couple of typos first:

2. "Without the NOTIFY command defined in this document, and IMAP
server" -> ", an IMAP server"

5.9. "Even if NOTIFY succeeds, it is still possible to loose access to
the" -> "lose access"

> Until the NOTIFY command is used for the first time, the server only
> sends notifications while a command is being processed, and notifies
> the client about these events on the selected mailbox: (see section 5
> for definitions): MessageNew, MessageExpunge, FlagChange. It does not
> notify the client about any events on other mailboxes.

I don't think any of this is necessarily true with a RFC 3501-compliant
IMAP server. A server can send almost whatever untagged replies whenever
it wants. This paragraph sounds like such a server wouldn't be allowed
to do that if it wants to support NOTIFY.

> 3.  The NOTIFY Command
..
> If either AnnotationChange or
>    FlagChange are included, the STATUS response MUST contain UIDVALIDITY
>    and HIGHESTMODSEQ. 

Doesn't say anything about what to do if CONDSTORE is not supported.

>    [[Open Issue: Filip Navara requested for STATUS (UNSEEN) to be sent
>    for MessageRead. Arnt considers that unsound, since it involves
>    processing all messages in a mailbox after an event affecting only
> one message, and since it's not reliable anyway.]]

How about server MAY send UNSEEN? I think clients are probably
interested in it anyway (don't they all show the number of unseen
messages in mailbox list?), so if the server doesn't give it they'll
just explicitly ask for it, wasting everyone's time and resources.

> Note that if a client requests MessageExpunge, the meaning of a MSN
>    can change at any time, so the client cannot use MSNs in commands
>    anymore.  For example, such a client cannot use FETCH, but it has to
>    use UID FETCH. The meaning of '*' can also change when messages are
>    added or expunged. A client wishing to keep using MSNs MUST NOT
>    request the MessageExpunge event.

How about also: If a server receives a command with MSN while
MessageExpunge is enabled, it MUST return with a tagged BAD reply.
Avoids accidental random problems.

>    And a deleted mailbox:
>        S: * LIST (\NonExistent) "/" "INBOX.DeletedMailbox" 

Looks weird. Should it have been INBOX/DeletedMailbox? Examples
before/after it don't have INBOX prefix at all.

> Clients are advised to limit the number of mailboxes used with
> NOTIFY. Particularly, if a client asks for events for all accessible
> mailboxes, the server may swamp the client with updates about shared
> mailboxes. 

Good advise, but is it even possible to request updates for all
accessible mailboxes? Wildcards aren't allowed, so I don't see any easy
accidental way for a client to do that.

> If the name refers to a mailbox which the client can LIST (e.g. it
> has the 'l' right from [RFC4314]), but misses another right
> required for processing of the specified event(s), then the server
> MUST respond with an untagged extended LIST response containing the
> \NoAccess name attribute.  [[Alexey: Note, the newly defined
> \NoAccess doesn't mean that the client doesn't have any rights
> other than 'l'. The \NoAccess is only meaningful in the context of
> the specified NOTIFY command.]]

\NoAccess sounds like an unnecessary extra complication. What would a
client do if it receives such reply? How often would this LIST reply
have to be sent? Only once or after each status change? How does it
combine with e.g. a subscription change?
_______________________________________________
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: Sat, 22 Mar 2008 21:24:00 +0000

Hi Timo,
Thanks for your comments. Some comments below.

>5.9. "Even if NOTIFY succeeds, it is still possible to loose access to
Both fixed, thanks.

>it wants.
Right.
How about changing the beginning of this sentence to read:

Until the NOTIFY command is used for the first time, the server compliant
with this document only sends notifications while a command is being processed, and notifies
the client about these events on the selected mailbox:

This also need to be changed to address your following comment:

>This paragraph sounds like such a server wouldn't be allowed
Hmm, it can be read this way. The text is trying to do 2 things: it 
describes typical server behavior and dictates which events must be 
generated by the server. The former is informative and should be aligned 
with RFC 3501. The latter is normative. Do you object to restricting 
which events are returned before NOTIFY is issued? While this largely 
defines common server behavior, I would like to have some consistency 
across servers.

>Doesn't say anything about what to do if CONDSTORE is not supported.
Fixed. I've added "and the server also supports CONDSTORE and/or QRESYNC 
extension".

>How about server MAY send UNSEEN?
>
I like that.

>I think clients are probably
>messages in mailbox list?),
>
Indeed, this is why I've added an open issue on this earlier.

>so if the server doesn't give it they'll
Personally, that would be fine with me. But I need to hear other speak 
up in favor of this change before doing it.

>Looks weird. Should it have been INBOX/DeletedMailbox?
>
Yes, or "/" should be changed to "."

>Examples before/after it don't have INBOX prefix at all.
>  
>
"Personal" or "subtree" are close enough to requesting all mailboxes, so 
this is still a problem.

>client do if it receives such reply?
>
The client can see that it can't watch for the requested events on 
certain mailboxes.
It might chose to abort NOTIFY.

>How often would this LIST reply have to be sent?
>
When executing the NOTIFY command and when relevant ACL change on all 
affected mailboxes.

>Only once or after each status change?
>
I think it should be sent after ACL change that affects the requested 
events. I will clarify this in the document.

>How does it combine with e.g. a subscription change?  
>
\NoAccess and \Subscribe can be combined. For example \NoAccess can be 
returned as the result of missing "r" right when MessageNew was 
requested by the client. If you think this is unclear, please suggest 
some text or at least point to paragraphs that need to be updated.

---

From: Timo Sirainen <[email-masked]>
Date: Tue, 25 Mar 2008 09:15:04 +0200

> defines common server behavior, I would like to have some consistency 

Many clients now send STATUS commands for all/most mailboxes every n
minutes and most of them probably won't be using NOTIFY anytime soon.
I'd like to send them STATUS replies automatically to have them update
the "unseen" counts in mailbox list immediately when new mails come. (Of
course most clients probably will ignore unsolicited STATUS replies, but
at the very least I'm going to patch the client I'm using to support
it. :)

So I'd rather have NOTIFY extension have effect only after the NOTIFY
command has been given.

> Fixed. I've added "and the server also supports CONDSTORE and/or QRESYNC 

So is FlagChange supported at all for non-selected mailboxes if
CONDSTORE/QRESYNC isn't supported?

Although just sending UIDVALIDITY+HIGHESTMODSEQ doesn't seem all that
useful. What else can the client do with just that information except to
select the mailbox to see what flag exactly changed? Could
STATUS-COUNTERS be combined with this somehow?

> Indeed, this is why I've added an open issue on this earlier.

I think it would be cleaner if there were SeenFlagChange and
RecentFlagChange events for non-selected mailboxes so UNSEEN and RECENT
STATUS counts could clearly be returned, but of course that makes it
worse for selected mailboxes.

> some text or at least point to paragraphs that need to be updated.

I'll think about this later.
_______________________________________________
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, 25 Mar 2008 11:50:26 +0000

>So I'd rather have NOTIFY extension have effect only after the NOTIFY
Ok, I will try to reword the text to be entirely informative.

>CONDSTORE/QRESYNC isn't supported?
Supported: yes (as in "the server needs to parse it").
Does it return any information? No, unless UNSEEN is also returned. Or 
unless another IMAP extension updates NOTIFY to list other STATUS items 
and/or other IMAP responses.

>select the mailbox to see what flag exactly changed?
>
That is the only thing the client can do.

>Could STATUS-COUNTERS be combined with this somehow?
>
I can work on STATUS-COUNTERS update, but (speaking as an individual WG 
contributor) I object to adding it to NOTIFY at this point. I want 
NOTIFY to get published. IMHO, working on STATUS-COUNTERS will delay it 
by at least 6 months.

>worse for selected mailboxes.
I need to see other opinions from the WG on this.

---

From: Timo Sirainen <[email-masked]>
Date: Tue, 25 Mar 2008 17:00:36 +0200

> NOTIFY to get published. IMHO, working on STATUS-COUNTERS will delay it 

I didn't mean that NOTIFY would require it, but maybe FlagChange could
be replaced so that STATUS-COUNTERS will be able to extend it in future.
So maybe something like:

SelectedFlagChange: Show all flag changes on selected mailboxes.

NonselectedFlagChange(\Seen \Recent): Send STATUS UNSEEN and RECENT
updates on non-selected mailboxes.

NonselectedFlagChange(\Flagged $hello $world): A future STATUS-COUNTERS
extension.