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