Subject: [lemonade] NOTIFY and CONTEXT

From: Peter Coates <[email-masked]>
Date: Sun, 15 Jul 2007 17:36:18 -0700

It seems to me that there is an unhealthy lack of orthogonally between the
NOTIFY and CONTEXT drafts.  Both have ways by which a client can  request
notification of updates of messages meeting a search program.

The CONTEXT draft is reasonably consistent and concise: persistent searches
or sorts last until reset or until the currently select mailbox is closed.

The NOTIFY draft, on the other hand is rather less self consistent.  You can
specify a search criteria for several notification types, duplicating
substantially some of the functionality of CONTEXT.  And for NewMessage you
can specify both search criteria and fetch-att.  The interaction between
this and CONTEXT is not specified.  The logic of what notifications are sent
to the client when a mailbox with complicated notifications specified is
clear enough, but a bit surprising requiring some odd manipulation of when
message match criteria are used.

Lemonade as a whole is pretty heavy on the server, making it more likely
that multi server solutions will be adopted.  Shared folders become a bit of
an issue in multi server deployments.  One solution is to direct the initial
connection to the server that hosts the user's mailbox and to proxy request
for shared folders to the hosting machine.  To implement NOTIFY in such an
environment is challenging.

The functionality offered by NOTIFY (tell me immediately if an update of
interest happens, and send me a synopsis of new messages of interest), and
CONTEXT (server, please help me maintain search and sort lists) can be
maintained with the following changes to both NOTIFY and CONTEXT.

(1)                get rid of the message-search-criteria from NOTIFY.  With
CONTEXT this looses no functionality except when associated with the
fetch-atts on NewMessage

(2)                get rid of the fetch-atts on NewMessage in NOTIFY.  This
looses some important functionality that can be replaced by

(3)                add optional fetch-atts on the UPDATE option in search in
the CONTEXT SPEC.

Thus a client can, with a combination of CONTEXT and NOTIFY

(a)    keep a number of search/sort lists up to date

(b)   have the server push important attributes of new messages as they are
added to these search/sort lists

(c)    NOTIFY becomes a more manageable draft with far less conditional
baggage, and far less overlap with CONTEXT.  These search programs are then
only ever specified in SEARCH and SORT programs

Is there something I'm missing here?  This pair of changes massively
simplified the implementation of NOTIFY, scarcely complicates CONTEXT, makes
the commands much closer to orthogonal, and makes NOTIFY MUCH easier to
implement of multi server deployments.

Peter

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