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.
The two major changes are:
1). updated the document to reference Sieve variables. Some notification
variables line "$text$" can't be mapped directly, but I will send a
separate message on this.
2). changed the document to use notification URIs, e.g. "sms:+123456789"
I remember there was a discussion few months ago about defining a
separate SMS notification mechanism. I just want to let people know that
the update I've made doesn't prevent any other documents in this area.
Just treat it as an input for discussion.
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.
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.
Which makes me wonder if each desired "method" should really be available via a
require command?
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/
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.
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? And can it just
be left to be implementation specific? 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. The syntax of the above doesn't sit well
with VARIABLES.
- The denotify action can be used to cancel a previous notification.
+ The denotify action can be used to cancel previous notifications.
5. Security Consideration
Is there additional risk of mail loops when using this extension?
Cheers
Nigel