Subject: [lemonade] notify

From: Peter Coates <[email-masked]>
Date: Thu, 20 Dec 2007 12:49:00 -0800

I have a problem with the quotachange notification.  I have quota, and I
even have notifications about quota.  But quota for me can be by user, by
mailbox, by subtree, by messagetype.  It is hard (and possibly meaningless)
to implement notification on quotachange by mailboxname or subtree.  This
needs rethinking.

Also, the point of having notifications add was to keep (and augment) the
functionality for clients while simplifying the syntax of the command.  If
notifications are add, then the command only need deal with one event-group.

It is likely that some servers will have a greater or lesser ability to
implement all the functionality of this command.  They may or may not be
able to support all the event types.  This suggests tome that either the
capability advertised for this indicate what is actually available, or the
error reporting on this command be spelt out allowing the server to indicate
what it couldn't do.

Peter

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

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 20 Dec 2007 16:09:57 -0500

Hi Peter,

--On December 20, 2007 12:49:00 PM -0800 Peter Coates 
<[email-masked]> wrote:

> mailbox, by subtree, by messagetype.  It is hard (and possibly
> meaningless) to implement notification on quotachange by mailboxname or
> subtree.  This needs rethinking.
>
>
>
> functionality for clients while simplifying the syntax of the command.
> If notifications are add, then the command only need deal with one
> event-group.
>
>
>
> capability advertised for this indicate what is actually available, or
> the error reporting on this command be spelt out allowing the server to
> indicate what it couldn’t do.

There was discussion at the meeting on removing a number of non-essential 
event types from the base spec.

My belief is that quota and acl changes should definitely go.

Note that many servers already support over quota messages via the existing 
[ALERT] mechanism. Those you can receive during IDLE already, if I am not 
mistaken.

-- 
Cyrus Daboo

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 24 Dec 2007 00:10:07 +0300

Peter Coates wrote:

> I have a problem with the quotachange notification. I have quota, and 
> I even have notifications about quota. But quota for me can be by 
> user, by mailbox, by subtree, by messagetype. It is hard (and possibly 
> meaningless) to implement notification on quotachange by mailboxname 
> or subtree. This needs rethinking.

You are right.
As IMAP QUOTA is not a part of Lemonade Profile Bis, I will be taking
quota events out of the document.

> Also, the point of having notifications add was to keep (and augment) 
> the functionality for clients while simplifying the syntax of the 
> command. If notifications are add, then the command only need deal 
> with one event-group.
>
Considering that one can implement storing of event-groups as a linked
list, I don't think this change would simplify anything. Besides, I
think it is important to keep syntax consistent between NOTIFY SET and
NOTIFY ADD.

> It is likely that some servers will have a greater or lesser ability 
> to implement all the functionality of this command. They may or may 
> not be able to support all the event types. This suggests to me that 
> either the capability advertised for this indicate what is actually 
> available, or the error reporting on this command be spelt out 
> allowing the server to indicate what it couldn’t do.

I've already added the latter (a new BADEVENT response code). But I
think the document should also define which events from the document are
mandatory.

---

From: Peter Coates <[email-masked]>
Date: Mon, 24 Dec 2007 17:16:35 -0700

I'm glad quota is out.  Now the single event group thing.  The object of my
suggestion here is to minimize complexity for the server while maximizing
functionality available.  I see no gain whatsoever is having more than one
event group on the command.  Clients can as easily issue several notify
commands each specifying a single event group as they can one command
specifying several.  Similarly though, it is as easy for the server to
handle one as many... as long as we do not worry about error handling.  IMAP
commands are supposed to be atomic, all succeed or all fail.  I suppose that
there is little difference between allowing one mailboxes or a set of them
and a set of subtrees.  But reporting  the cause of a failure just starts
getting more difficult the more things you allow at once.

I don't suppose for a moment I'm going to get traction on this, so I think
I'll stop.  But I will continue to think that this shows a continued lack of
attention to error recovery, error recovery, and error handling in IMAP.

Peter

-----Original Message-----
From: Alexey Melnikov [mailto:[email-masked]] 
Sent: December 23, 2007 14:10
To: Peter Coates
Cc: [email-masked]
Subject: Re: [lemonade] notify

You are right.

> allowing the server to indicate what it couldn't do.