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.
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.
If that's the correct reading of the
draft, then I think it needs to be made clearer that the "notify" verb
merely enables notifications, and the notifications are triggered by
other actions. I'm still not sure I have interpreted it correctly.
I hope not.
Also it's not clear if a single notification (one per :id, presumably)
is sent that summarizes all actions that have been taken, or if one
notification must be sent per action (per :id).
Notifications should contains what the action says they should contain.
Automatic addition of information about other actions is IMO entirely
inappropriate, and even if was appropriate I don't see how it could be done
usefully. (Tnink about the internationalization issues.)
Nor is it clear (to me)
whether "denotify" cancels any queued-up notifications, or whether it
merely disarms the trigger (and queued-up notifications as a result of
already-executed actions are still sent). And what happens if you've
executed two "notify" statements with different ":id"s -- does each
subsequent action then get two notifications? That seems reasonable but
probably should be stated.
My personal view is that denotify should be yanked from the specification. I
see no more reason for it than I see for having defileinto or deredirect. (The
last one has an especially nice name, doesn't it?)
However, if there is a consensus to retain denotify (it isn't all that
difficult to implement, just silly), it should be able to cancel either a
specific pending notification (by id), a group of notifications (by id list) or
all notifications.
Ned