Re: Updated Sieve notification draft

["Mark E. Mallett" <[e-mail]>]

On Fri, Sep 30, 2005 at 08:05:05AM -0700, Ned Freed wrote:
> > On Mon, Sep 26, 2005 at 03:26:46PM +0100, Alexey Melnikov wrote:
> > > Hi folks,
> > > I took a stab at updating draft-martin-sieve-notify-01.txt, which should
> > > be published soon as draft-ietf-sieve-notify-00.txt. The document is
> > > attached.
> 
> > Hi-
> 
> > On my first read through, I had the idea that it was defining an action
> > "notify" that would itself generate a notification, deferred until the
> > end of the script's execution (otherwise the "denotify" made no sense).
> 
> That's exactly what the extension does, or at least should do.
> 
> > After reading this thread and having another go or two at the document,
> > I now get the idea that "notify" merely enables notifications to be sent
> > when *other* actions are taken.
> 
> I cannot believe this was the intent, but it is it needs to be changed ASAP.

My problem is that I couldn't really tell which was the intent.  My
first read was prejudiced by what I expected notify to do, which is that
of an action that had an immediate effect of sending a notice.  But
there are some parts that read as though the intent is to enable
notifications when other actions occur.  e.g.:

    This is an extension to the Sieve language defined by [SIEVE] for
    providing instant notifications of sieve actions that have been
    preformed.

    However, all content specified in the notify action, including Sieve
    actions taken on the message, SHOULD be included.

    If errors occurred in another action they SHOULD be reported in the
    notification.

The kicker being:

    Notifications MUST be sent in all cases, unless a reject action is
    also executed. Users may wish to be notified of a message being
    discarded, for example.   <<The reject action is given an exception
    because implementations may wish to restrict users from seeing the
    contents of a rejected message. However, notifications MAY be
    modified to not include any data from the original rejected message.>>

That paragraph is perplexing, in several ways, if notify simply sends
its own message, but not so much with the other interpretation.


> There is absolutely no reason to make notify actions have special and
> unusual dependencies on other actions. This sort of thing would add all
> sorts of strange interaction semantics to the sieve language that it doesn't
> need and which will make our job of describing action behavior moving
> forward vastly more difficult. It will also make it harder to write
> scripts that function properly, debug scripts, and just about everything
> else.

I don't think that a summary notification of actions taken would have
these dire consequences, any more than logging each action does, or any
more than delaying actions until after script execution does.  (Not that
I'm in favor of having notify work that way, either.)  But I do think
the intent is unclear, and some wording needs to be changed to better
reflect whichever was meant.

mm