Hi Nigel,
First of all, thank you for the comments!
Abstract:
This draft describes an extension to the Sieve mail filtering
language that allows users to give specific preferences for
- notification of Sieve actions.
+ notification of mail delivery.
Sieve notify can also be used to notify about Sieve actions executed for
a message, so the original text is better in this respect.
The document as written is not quite clear how this has to be done, though.
That sounds like the extension allows you to be notified about an action,
rather than a message. I thought the significant event was the delivery of
mail rather than a sieve action. Similar comments apply to Introduction
section.
This document does not dictate the notification method used.
Examples of possible notification methods are Zephyr and Jabber. The
- method shall be site-defined.
+ available methods shall be site-defined.
Done.
Which makes me wonder if each desired "method" should really be available via a
require command?
I am not sure that this is needed.
Remember, notifications are ignored if method is not recognized.
One thought I have is to have separate documents describing how
different notification schemas should be handled, e.g. a separate
document for SMS, another one for XMPP, etc.
3.1 Notify Action
In
addition, if the notification method does not provide a timestamp,
one SHOULD be appended to the notification.
Why bother with this? While I agree it might be a sensible idea, I was
surprised to see it as a SHOULD, I guess it's not a MUST though :o/
I can even lowercase SHOULD here.
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
This makes it sound like there are hard and fast rules between user status
notifications and the setting of the priority parameter, yet the discussion is
very brief and doesn't elaborate to rigorously define all those rules. I also
feel uneasy about adding syntax that permits only 3 levels of priority. I
think we should either drop the parameter, or extend it to allow an almost
arbitrary number and style of priority statuses, even if we only define 3 for
now. I'm thinking of the Priority/X-Priority/X-MSMail-Priority mess in mail
headers. I'd suggest a string which could be used with the relational draft to
do numeric comparisons if desired.
Let me think about this one for a bit.
If the message parameter is absent, a default message
containing the value of the From header field and the value of the
Subject header field will be used.
Could this be specific to the notification mechanism in use?
Yes!
And can it just be left to be implementation specific?
I think so.
The original draft was prescribing the exact syntax. While I was trying
to construct an XMPP example I've realized that Subject is not a part of
XMPP payload, it is a separate XML element. So I've made the text more
generic.
I also want to allow for Sieve notify to be usable without variables.
The use of "will be" instead of SHOULD/MUST makes this sentence pretty
ignorable anyway. As it stands it doesn't seem to want me to include as much of the
message body as I can, which is clearly a nice feature.
<<Open issue: the previous version of this draft has defined the two
variables that can't be currently represented:
$text$ - the first text/* part
$text[n]$ - the first n bytes of the first text/* part
>>
I'd like to drop both of these, and wait for other extensions used with
VARIABLES to allow the behaviour.
Yes, this will need an extension to variables.
The syntax of the above doesn't sit well with VARIABLES.
Right, I've just kept the original syntax as defined in Tim Martin's draft.
- The denotify action can be used to cancel a previous notification.
+ The denotify action can be used to cancel previous notifications.
Done.
5. Security Consideration
Is there additional risk of mail loops when using this extension?
Yes, if you use mailto: URI schema. Or any other notification method
that can be getawayed to mail.
But this is not an issue specific to Sieve notify.
Alexey