Re: Updated Sieve notification draft
"Mark E. Mallett" <mem@mv.mv.com> Thu, 29 September 2005 22:39 UTC
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8TMdtI7084780; Thu, 29 Sep 2005 15:39:55 -0700 (PDT) (envelope-from owner-ietf-mta-filters@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8TMdtGC084779; Thu, 29 Sep 2005 15:39:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id j8TMdr5U084773 for <ietf-mta-filters@imc.org>; Thu, 29 Sep 2005 15:39:53 -0700 (PDT) (envelope-from mem@mv.mv.com)
Received: (qmail 67435 invoked by uid 101); 29 Sep 2005 18:39:53 -0400
From: "Mark E. Mallett" <mem@mv.mv.com>
Date: Thu, 29 Sep 2005 18:39:53 -0400
To: Alexey Melnikov <alexey.melnikov@isode.com>
Cc: MTA filtering mailing list <ietf-mta-filters@imc.org>
Subject: Re: Updated Sieve notification draft
Message-ID: <20050929223953.GE51878@osmium.mv.net>
References: <43380526.4070001@isode.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <43380526.4070001@isode.com>
User-Agent: Mutt/1.4.2.1i
Sender: owner-ietf-mta-filters@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe>
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). 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. 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. 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). 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. It may just be me, of course, but I think some of this could be a lot clearer. As for a few specific comments (pared down a little): > 1. Introduction > > This is an extension to the Sieve language defined by [SIEVE] for > providing instant notifications of sieve actions that have been > preformed. It defines the new action "notify". That definition suggests that executing the "notify" action will cause a notification. > 1.0 > > Sieve interpreters for which notifications are impractical or is not > possible SHOULD ignore this extension. What does this mean... are you recommending that interpreters implement the extension as no-ops, so that the "require" will work but the actual notify statements will not? I mean, this seems to be recommending something other than the usual thing of having the "require" fail to operate if the capability is not available. If all this means is "have the 'require' fail if the capability isn't available" -- doesn't that go without saying? > 3.1. Notify action > ... If an URI schema is > specified that the implementation does not support, the notification > MUST be ignored. An implementation treats this as a warning > condition and execution of the sieve script MUST continue. I find "must be ignored" and "treat as a warning condition" to be contradictory.. Perhaps the intent is "must not be treated as a fatal error, may result in a warning, but the script must continue" > Some notification methods allow users to specify their > state of activity (for example "busy" or "away from keyboard"). If > the notification method provides this information it SHOULD be used > to selectively send notifications. If, for example, the user marks > herself as "busy", an implementation SHOULD NOT send a notification > for a new mailing list message with a priority of :low, however the > user should be notified of a high priority action. If the > notification method allows users to filter messages based upon > certain parameters in the message, users should be able to filter > based upon priority. If the notification method does not support > priority, then this parameter MUST be ignored. Is any of this in scope? That stuff sounds to me more like details of the way the specific notification platform operates than how the Sieve implementation should operate. It would be pretty hairy for the Sieve implementation to figure out what user to query, even assuming the notification system directs the message to a particular user, let alone how to find out what the user's state is. Then again, I may be misunderstanding. > 3.2. Denotify Action > > Usage: denotify [MATCH-TYPE string] [<":low" / ":normal" / ":high">] I don't care for the fact that "match-type" takes an argument; this is different from every other context for "match-type." I would much prefer ":id" with an argument to specify the id(s) to affect, as it's already defined with "notify," and revert "match-type" the way it is everywhere else. For that matter, rather than two verbs "notify" and "denotify" I'd rather see just one verb, with modifiers to toggle the notification on or off and/or to cancel. e.g.: notify :cancel # to cancel any pent-up notifications notify :off # to disable notifications for future actions notify :on # to [re]enable a notification > 4. Interaction with Other Sieve Actions > > 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. Might users not want to be notified of a 'reject' action too? Why not let them have that control? The :off/:on/:cancel thing would facilitate that. > The notify action is compatible with itself. Meaning? With apologies for any extra denseness, mm
- Updated Sieve notification draft Alexey Melnikov
- Re: Updated Sieve notification draft Nigel Swinson
- Re: Updated Sieve notification draft Alexey Melnikov
- Re: Updated Sieve notification draft Kjetil Torgrim Homme
- Re: Updated Sieve notification draft Alexey Melnikov
- Re: Updated Sieve notification draft Michael Haardt
- Re: Updated Sieve notification draft Michael Haardt
- Re: Updated Sieve notification draft Michael Haardt
- Re: Updated Sieve notification draft Michael Haardt
- Re: Updated Sieve notification draft Michael Haardt
- Re: Updated Sieve notification draft Ned Freed
- Re: Updated Sieve notification draft Mark E. Mallett
- Re: Updated Sieve notification draft Ned Freed
- Re: Updated Sieve notification draft Nigel Swinson
- Re: Updated Sieve notification draft Kjetil Torgrim Homme
- Re: Updated Sieve notification draft Ned Freed
- Re: Updated Sieve notification draft Mark E. Mallett
- Re: Updated Sieve notification draft Michael Haardt
- Re: Updated Sieve notification draft Alexey Melnikov
- Re: Updated Sieve notification draft Michael Haardt
- Re: Updated Sieve notification draft Alexey Melnikov
- Re: Updated Sieve notification draft Alexey Melnikov
- Re: Updated Sieve notification draft Alexey Melnikov
- Re: Updated Sieve notification draft Michael Haardt
- Re: Updated Sieve notification draft Michael Haardt
- Re: Updated Sieve notification draft Michael Haardt
- Re: Updated Sieve notification draft Alexey Melnikov
- Re: Updated Sieve notification draft Alexey Melnikov
- Re: Updated Sieve notification draft Michael Haardt
- Re: Updated Sieve notification draft Ned Freed
- Re: Updated Sieve notification draft Alexey Melnikov
- Re: Updated Sieve notification draft Alexey Melnikov
- Re: Updated Sieve notification draft Michael Haardt
- Re: Updated Sieve notification draft Alexey Melnikov
- Re: Updated Sieve notification draft Michael Haardt
- Re: Updated Sieve notification draft Ned Freed