Subject: RE: [lemonade] IMAP-SIEVE: Per-Client Sieve Script

From: Randall Gellens <[email-masked]>
Date: Tue, 16 Oct 2007 15:06:11 -0700

Sorry for the delay in responding.

At 11:27 AM +0300 9/3/07, <[email-masked]> wrote:

>  But I see no text saying that the message MUST NOT be expunged until all
>  scripts have finished.

If the text goes forward, a statement to this effect can be added, 
just to make it very clear.

>  Ok, so let' take this a step further.
>  There is a new mail arriving, and we have scripts A, B and C from
>  clients A, B and C respectively. The new mail triggers both A and B
>  scripts.
>  The result of script A is to delete the email. The result of script B is
>  to move (copy+delete, right?) the email to a different mailbox. The
>  result of script C is to notify about new mail. So,  A copy of the email
>  is placed into another mailbox and finally the mail is deleted and C is
>  notified. The deposit of the new mail to the other mailbox (the copy
>  action of script B) triggers at least script A (since it was script B
>  making the change, I assume that it will not trigger itself to avoid
>  loops) and C. The result of script C is to notify about new mail. The
>  result of script A is to delete the email (same result as before).
>  Script A triggers script B and C. B does nothing, C is notified again.
>  Problems:
>   -  the email that B wanted to move somewhere else is deleted
>   - C receives four notifications when "nothing" really happened (a new
>  mail arrived, copied, but deleted both). This can be optimized though.
>   - If C wanted a copy of the mail (justl like B), script A would have
>  deleted it.
>   - What if scripts A and B moved (copy+delete) the email between two
>  different mailboxes continuously (infinite loop)?

The existing language in the draft (for a single script) makes it 
clear that actions that are the result of a script do not cause the 
script to execute.  In proposing text to permit multiple scripts, I 
attempted to carry this forward.  I think this is one way to simplify 
multiple script handling: actions taken by any script are applied 
after the scripts execute and do not trigger scripts.

>  There is nothing wrong with the text - I just got the feeling that
>  something is missing. I can't tell what, but something does not feel
>  right. Perhaps after we went through a few use cases, we can come up
>  with a solid proposal.

The text I proposed was very minimal, I admit.  I wanted to show that 
it was possible to extend the draft to cover multiple scripts, and 
that doing so could be constrained to minimize the complexity.  If 
the concept has acceptance in the group, further restrictions and 
details can be added to remove ambiguity.

>   >thinking that any identifier for the device could be used, but even a
>>random number with a reasonable range would suffice.
>
>  I guess a client could figure out the allocated random IDs by doing a
>  simple query to the server - so it could figure out a unique random ID
>  for itself if needed.

The per-client component is up to the client, and I suggested that 
any identifier for the device could be used, or that a random value 
could also be used.  I didn't mean that a random value must be used, 
only that a client could choose to use a random value or incorporate 
a random value.  I think an identifier for the device, if available, 
is better.  An example of a device identifier might be an ESN, if 
available.  Maybe even a MIN?

>  Could we add <random> then (with a requirement saying that it must be
>  unique within the scope of the client-id; could be any number of hexa
>  digits, case insensitive? 0-9, a-f, A-F)?
>  So the whole ID would look like: <client-id>.<random-id>.<script-id>
>
>  A requirement might be also needed to store the <random id> in a safe
>  place. Some clients overwrite/delete user data when the
>  OS/client/firmware is updated. If the random id is lost, there will be
>  no way to identify which client owned the script and it wil be hanging
>  there for an eternity.

I'm not sure a random component is needed.  I was only suggesting 
that, in the absence of a better identifier, one could be used.

>
>  Could this ID be re-used? Well, at least the <client-id>.<random-id>
>  part of it - for example, to store client-specific preferences on the
>  server?

We should explore this when we do client-specific preferences that 
are stored on the server.

At 10:03 AM -0400 9/4/07, Cyrus Daboo wrote:

>  I think as Zoltan's examples show this is getting way too 
> complicated. Having multiple "competing" scripts being executed 
> like this is a recipe for disaster. Lets drop this aspect of the 
> spec and see whether the rest will actually get implemented and be 
> interoperable first. Then, if there really is demand, we can 
> consider per-client scripts as an extension.

I think this can be done without allowing it to get too complicated, 
and I would agree that we shouldn't do this if it can't be done 
fairly simply.  The key is to enough constraints to keep it simple, 
while still useful.  But if we choose not to do so, and if we think 
that we might want to revisit this, then we need to look carefully at 
the draft to make sure that it isn't doing anything that would get in 
the way of such an extension.

At 9:35 AM -0400 9/5/07, Cyrus Daboo wrote:

>  I question whether there is a need to do it this way at all. I 
> think an adequate solution for most cases is to allow manual 
> triggering of scripts by clients. That way clients can apply their 
> own scripts when they actually interact with the server.

I'm not sure manual execution of a script really addresses the 
usefulness or solves a problem.

>  The whole business of allowing clients to upload their own scripts 
> which get automatically handled and considered "private" to each 
> client is awkward. For example, what happens if a user stops using 
> a client? How does the script for that client get disabled? Does 
> there have to be some sort of script management UI in every client 
> so users can manage other client's scripts use etc?

What I proposed is that old script age out and get reaped by the 
server.  (This was in the proposed new section called "Automatic 
Deletion of Old Scripts".)  That way there is no need for a script 
management UI.

At 1:22 PM -0700 9/5/07, Ned Freed wrote:

>  However, delivery time processing is a better defined problem (it is, after
>  all, the place Sieve was deisned to operate) and there are some simplifying
>  assumptions having to do with ranking of multiple sieves that I 
> don't think are
>  possible in the context of IMAP. I therefore support dropping this for now.

Per-client (and per-device) scripts might be better at delivery time 
rather than as part of IMAP.  I'm not sure.

At 12:01 PM +0300 9/6/07, <[email-masked]> wrote:

>  My worry here is that we might release a genie from the bottle.
>  I mean if Lemonade bis was released/deployed as is (with a single 
> script setup), we might not be able to change that in the future - 
> well, at least not easily and quickly because we are going to have 
> to provide backwards compatibility until the old services are phase 
> out.
>  Would it be possible to build in some sort of safeguard so that we 
> can change this later on without making it incompatible with 
> existing Lemonade deployment? Some sort of future-proof-ish 
> solution?

That's a matter of carefully reading the draft to see if a future 
extension along these lines would cause problems.  If we miss 
something, then we'll have to deal with it when we try and extend it.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
In politics stupididty is not a handicap.
      --Napoleon

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