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

On Tue, Feb 07, 2006 at 03:11:44PM +0200, Alexandros Vellis wrote:
> > 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.
> 
> 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@example.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. :-)

Michael

_______________________________________________
Notifications mailing list
Notifications@ietf.org
https://www1.ietf.org/mailman/listinfo/notifications