First of all, please add a Changelog.
However, all content specified in the notify action SHOULD be
included. It is RECOMMENDED that a timestamp be included in the
notification.
Do we really need SHOULD and RECOMMENDED? If a method can not implement
the above for technical reasons, of course that qualifies as reason to
violate the SHOULD. But isn't it silly to set a strong default, knowing
it will be violated?
I recommend that each method MUST define if specified content is not
included in the notification and if it includes a timestamp. Do we
define anywhere that this timestamp should be as close to the delivery
as possible?
If there are errors sending the notification, the Sieve interpreter
SHOULD ignore the notification and not retry indefinitely.
[[Barry 4: Does this really belong here? Shouldn't we push the
question of error recovery to the individual methods?]]
I think defining the default behaviour is useful, but again I question
the "SHOULD". How about "should" and saying that each method MUST define
how error recovery works?
The entirety of the string SHOULD be sent but
implementations MAY shorten the message for technical or aesthetic
reasons.
If aesthetic reasons suffice, then why a SHOULD? This repeats the
paragraph at top, but weakens it.
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.
No timestamp here?
The implementation of a notification method MAY modify the final
notification text -- for example, truncating it if it exceeds a
length limit, or modifying characters that can not be represented in
the target character set. Allowed modifications should be documented
in a standards-track or informational document.
I suggest that allowed modifications MUST or at least SHOULD be
documented.
Usage: valid_notif_method <notification-uris: string-list>
Of course that is real easy to implement, but it is also real ugly.
There is nothing I know of else in Sieve that checks certain options
of actions for validity. I still suggest a generic extension for
exception handling.
Example: if valid_notif_method ["mailto:";,
"http://gw.example.net/notify?test";] {
stop;
}
I miss a reference to the mailto and http schemes, if you use them,
but you raise an interesting point concerning mailto here:
What does an URI without recipient do? Looking at the guideline of not
causing an error by sending notifications, I suggest: If no recipient
is specified in the URI, no notification is being sent. I will make a
note to define this in the mailto method description.
The notify action is potentially very dangerous. The path the
notification takes through the network may not be secure.
It is worse: *The path the notification takes through or out of
the network may not be secure.* It is the nature of notifications
that they may leave the network to get to the user, whereas the
above implies the risk is just the network.
I notice ":id" and "denotify" are gone. Good! There is still no
":from", though, and the change of ":priority" to ":importance" is
only discussed, but not made. Why?
Since we broke compatibility with the original draft, I repeat my
point of view to remove ":method" and change its argument to an
argument of "notify", as in:
notify "mailto:0123456789(_at_)sms(_dot_)example(_dot_)net";
instead of
notify :method "mailto:0123456789(_at_)sms(_dot_)example(_dot_)net";
Sorry for the amount of comments. I am real glad you pushed out a
new version, because it makes my work way easier.
Michael