Re: [Extra] Design of a new Sieve action to process iMIP messages

[Alexey Melnikov <[e-mail]>]

Hi Ken,

On 22/09/2021 13:27, Ken Murchison wrote:
>
> All,
>
> We (Fastmail) are in the process of designing and implementing a new 
> Sieve action which will process iMIP messages and add/update resources 
> on a CalDAV calendar.  The main issue that I'm facing is that a user 
> may want to have additional actions be executed depending on whether 
> the 'processimip' action [un]successfully updates the calendar (E.g., 
> add flags to and/or fileinto the email message into different 
> mailbox).  Neither RFC 5528 nor any extension that I'm aware of 
> defines a mechanism for determining whether an action was successful.  
> Failure of some actions, such as fileinto cause script execution to 
> stop. Failure of others such as vacation/notify are usually ignored.
>
> I have come up with 3 ways to solve this issue for the new 
> 'processimip' action, in order of preference:
>
>  1. Have 'processimip' set a variable with a return code/status.  This
>     variable can then be checked with a 'string' test.  There is
>     precedent for an action setting a variable with the 'extracttext'
>     action.
>  2. Make 'processimip' a test rather than an action.  This would be
>     the first test that I'm aware of with side-effects (other than
>     setting match variables).
>  3. Add optional :flags and :mailbox (and :mailboxid, :specialuse)
>     args to 'processimip' which are only used if the action is
>     successful and are used to execute an implicit 'fileinto'.  This
>     is very ugly IMHO.  I'd prefer that an explicit 'fileinto' action
>     be used.
>
> What do others think?  Any different/better design ideas?
>
Your list of preferences seems reasonable. #2 is not ideal, even though 
it is otherwise compelling. #1 ties you to implementing another 
extension, even if it is an important one.

Can you tell me more about failure cases and maybe it would be possible 
to extract some logic into a separate test?

Best Regards,

Alexey