On Mon, Sep 26, 2005 at 03:26:46PM +0100, Alexey Melnikov wrote:
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.
Thanks a lot! I appreciate this very much, because some functionality of
this kind is on my list of tasks. I am not sure if notify is really
what I ask for, reading the draft, but it may.
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.
Using URLs may well allow to unify all notification mechanisms. Sure
a "comsat" URL may look odd, but why a whole new extension for it?
Usage: notify [":method" string]
[":id" string]
[<":low" / ":normal" / ":high">]
[":message" string]
I miss a sender specification of some kind, like [":from" string], like
we have for vacation.
The format of the notification is implementation-defined. However,
all content specified in the notify action, including Sieve actions
taken on the message, SHOULD be included. If errors occurred in
another action they SHOULD be reported in the notification. In
addition, if the notification method does not provide a timestamp,
one SHOULD be appended to the notification. Implementations SHOULD
NOT include extraneous information.
I don't like that, because it means I have to delay sending notifications
until successful delivery of a message, like transferring it to the mail
store or forwarding it to another host. What if the user is over quota
or the remote host is down? That's not a successful delivery. Yet I would
like to get a notification that the mail was seen by the filter.
I guess what I do not like it that notify sounds like DSNs. To me,
it should be just some action. If I decide to send a notification and
then discard the message in order to process mail alarms, I don't need
to have notify tell me the message was discarded.
If the :method tag is not specified, the default
implementation defined notification method is used. The
possible values of this will be site-specific. 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.
As I wrote in another mail, people have a hard time to get phone numbers
right, like not including letters in them. I prefer to generate errors
if that happens. That way they see something is wrong instead of yelling
at the SMS provider.
May an implementation choose not to send any notification if no method is
given? I run a bunch of systems without a default notification mechanism.
If there are errors sending the notification, the Sieve interpreter
SHOULD ignore the notification and not retry indefinitely.
I agree on that. If the URL was syntactically correct, and perhaps even
semantically correct, faults are usually outside the scope of users.
Michael