Subject: [lemonade] FW: notify and context

From: Peter Coates <[email-masked]>
Date: Mon, 26 Nov 2007 16:22:20 -0800

I have looked into implementing the notify draft as it stands, and am
impressed by the complexity implied by the little bit of syntax:
message-event   = ( "MessageNew" SP
                            "(" fetch-att *(SP fetch-att) ")"
                          SP message-match-criteria )

I am also not convinced by the usefulness of the complexity, although I have
to accept the value of the service being offered to clients. I am
unconvinced that the requirements are met in a useful way with this command.

The intent is that a client can register its interests, and sit back being
fed the information it wants as it arrives.  Thus if it is only interested
in messages meeting a specific set of criteria in particular mailboxes, it
says so and gets headers or whatnot for just those messages.

What actually happens is that the search program specified and the fetch
program specified are only used if the mail box in question is selected.
Otherwise, if a new message arrives, the client is told about it, end of
story.  The implication of this is that if a client is interested in
messages from multiple folders, it will have to select those folders from
time to time to see it the new mail is "interesting". 

With the way notify is currently drafted, this switch will cause any search
and fetch programs specified in previous notify commands to come into play,
which is all very nice for the client, if rather nasty to implement in the
server.  But all that pain in the server is not actually adequate for the
client.  If a message or two have arrived since the mailbox was last
selected, the client needs to know whether they match the search criteria.
This requires it either to fetch the necessary bits of the message and
evaluate the search itself (and lemonade assumes we are dealing with devices
that are a bit limited in their ability to do that) or they need to issue a
search command (or a few search commands) to catch up with these messages
that arrived in the mailbox before it was selected.  That is to say, even
with these search commands being in the notify command the client still has
to issue the equivalent search command as part of its synchronizing with a
newly selected mailbox.

Now we already have another mechanism for specifying persistent searches
(and sorts!) in the selected mailbox, and that is EASEARCH.  If a persistent
search were in effect as well as a notify, then all the various searches and
sorts would have to be evaluated, so the client would expect both ESEARCH
and FETCH responses when interesting new messages arrive in the selected
mailbox.

So  NOTIFY (a) is not adequate to allow a stored search to "synch up" a
"view" for a client as a mail box is selected, (b) overlaps somewhat in
functionality with CONTEXT, and (c) is difficult to implement.  It also
fails the "keep separate functions separate" guidelines as it is mixing
notifications of events, searching, and fetching.

(other than that I like it)

I propose that the search and fetch programs be removed from NOTIFY.

This leaves an even bigger gap in the functionality that mobile clients
want.  This gan can be closed by adding an optional fetch program to the
UPDATE phrase in ESEARCH, changing the definition of modifier-update from
modifier-update     = "UPDATE"

to
modifier-update     = "UPDATE"
 [ SP "(" fetch-att *(SP fetch-att) ")"]

This allows a client, when selecting a mailbox to issue the command

View1 uid search (update (body.peek[header.fields (from to subject)]) all)
from "myboss" modseq 11374

This allows a client to fetch the uids of any interesting messages that
arrived or were changed after the last known modseq so they can be fetched
if needed, and sets up the automatic search/fetch for any new messages.  We
even have the technology to do this in a sort, possibly even more important
for mobile clients, although in that case the modseq option in the search
program becomes a bit less useful.

An argument that can be put against this proposal is that it muddies the
search command with fetch things.  That is true.  But it enables us to
disentangle both search and fetch from notify, and (at no real cost to the
client) significantly reduces the complexity of the context that the server
is expected to carry as a result of the notify command.

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