[Top] [All Lists]

Re: [Notifications] Re: I-D ACTION:draft-ietf-sieve-notify-02.txt

2006-02-07 06:56:39

On Tue, Feb 07, 2006 at 03:11:44PM +0200, Alexandros Vellis wrote:
I suggest that allowed modifications MUST or at least SHOULD be

   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.

I don't know about generic exception handling, but wouldn't it make more
sense, in this particular case, that the available notifications are
present in the capabilities of the Sieve server?

I am not sure if you talk about managesieve or a new capability test,
but anyway:

If the method consists of variables, you can not test the method when
installing a script.  Although I think "if you write code that shoots
in your foot, then suffer", I must admit that a script really shouldn't
cause an error just because of a notification, and simply ignoring all
notification errors is awkward, too.

So we do need some way to deal with errors, both semantic and runtime
errors.  The "valid_notif_method" addresses semantic errors and we
decided that "notify" should never cause runtime errors.

In a way, notifications are remotely similar to "fileinto + redirect".
We have no facility to check a redirect address, and I am not asking
for valid_redirect_recipient, although it would be easy to implement.
I am asking for a generic way to solve the problem.

try {
  notify "sms:NaN";
catch {

Yes, that's a can of worms and possibly not a good idea at all, but I
see a need for _some_ generic solution and that's all I can think of
right now.

Good idea. I think that the current plan is a bit awkward. The Cyrus
implementation uses the :options field to define the email address:

 notify :method "mailto" :options "foo(_at_)example(_dot_)org"

Well, the notify draft changed a lot (IMHO, for the better) and
was probably never widely employed.  I don't expect agreement upon
implementations a few days after the latest draft. :-)