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

From: Alexandros Vellis <[email-masked]>
Date: Tue, 07 Feb 2006 15:11:44 +0200

[Cc: ing notifications list]

On Tue, 2006-02-07 at 12:05 +0100, Michael Haardt 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?

So, just as IMAP4 Capability responds with a set such as AUTH=DIGEST-MD5
AUTH=ANONYMOUS or THREAD=ORDEREDSUBJECT THREAD=REFERENCES, a Sieve
server could respond with "notify notifymethod=mailto
notifymethod=xmpp", or something similar.

For a client implementation that has no idea what is suppored on the
server, this would be ideal. It will also save my client implementation
from an extra configuration option. :)

> 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:[email-masked]";

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 "[email-masked]"

draft-ietf-sieve-notify-xmpp on the other hand uses the :method for the
entire destination:

 notify :method "xmpp:[email-masked]"

How about a 'target' option, or as you suggest, no option at all, and a
general plan to use existing URLs defined in other documents.

For instance:

* mailto URI: 
:target "mailto:[email-masked]?subject=Mail%20Notification"

*XMPP URI according to draft-saintandre-xmpp-iri
:target "xmpp:[email-masked]"

* SMS URI according to
http://www.ietf.org/internet-drafts/draft-wilde-sms-uri-10.txt :
:target "sms:+41796431851;pid=smtp:[email-masked]"

* tel: URI according to RFC3966. Could probably leave a preconfigured,
implementation-specific voice mail message:
:target "tel:+306999999999"

And so on.

-- 
Alexandros Vellis
[email-masked]

_______________________________________________
Notifications mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/notifications

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 08 Feb 2006 18:42:37 +0000

>notifymethod=xmpp", or something similar.
If you are talking about ManageSieve protocol 
(draft-martin-managesieve), then draft-ietf-sieve-notify-02.txt already 
has text describing relevant capability.

---

From: Michael Haardt <[email-masked]>
Date: Tue, 7 Feb 2006 14:36:01 +0100

> 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.

>  notify :method "mailto" :options "[email-masked]"

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

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 09 Feb 2006 11:02:06 +0000

Mark E. Mallett wrote:

>BTW I also agree that the ":method" tag is superflous and would prefer
>to see the method as a positional argument.  An empty string could indicate
>the site-default method, or one could even use "default:" .
>
Ok, we will do that in the next revision.

>
>BTW what happened to the ":attributes" thing?  Did this get shot down?
>
No, Barry and I didn't have time to add it back :-).