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

Alexandros Vellis <avel@noc.uoa.gr> Tue, 07 February 2006 13:11 UTC

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k17DBepl039674; Tue, 7 Feb 2006 05:11:40 -0800 (PST) (envelope-from owner-ietf-mta-filters@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k17DBeAA039673; Tue, 7 Feb 2006 05:11:40 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f
Received: from msa.uoa.gr (msa.uoa.gr [195.134.100.72]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k17DBcj5039649 for <ietf-mta-filters@imc.org>; Tue, 7 Feb 2006 05:11:39 -0800 (PST) (envelope-from avel@noc.uoa.gr)
Received: by MSA with id 9644AC95A9E61D4102AD9E9BEE1C59A2E65DD1C1
Received: from null.noc.uoa.gr (null.noc.uoa.gr [195.134.100.40]) (authenticated bits=0) by msa.uoa.gr (8.12.11/8.12.11) with ESMTP id k17DBBmS002855 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 7 Feb 2006 15:11:12 +0200 (EET)
Subject: Re: I-D ACTION:draft-ietf-sieve-notify-02.txt
From: Alexandros Vellis <avel@noc.uoa.gr>
To: ietf-mta-filters@imc.org
Cc: notifications@ietf.org
In-Reply-To: <20060207110513.GA10924@nostromo.freenet-ag.de>
References: <E1F6DJB-0001Ck-JY@newodin.ietf.org> <20060207110513.GA10924@nostromo.freenet-ag.de>
Content-Type: text/plain
Organization: National & Kapodistrian University of Athens
Date: Tue, 07 Feb 2006 15:11:44 +0200
Message-Id: <1139317905.5030.19.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.4.1
Content-Transfer-Encoding: 7bit
X-UoAMSAId: 9644AC95A9E61D4102AD9E9BEE1C59A2E65DD1C1
Sender: owner-ietf-mta-filters@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe>

[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:0123456789@sms.example.net";

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"

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

 notify :method "xmpp:romeo@example.com"

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:foo@example.org?subject=Mail%20Notification"

*XMPP URI according to draft-saintandre-xmpp-iri
:target "xmpp:romeo@example.com"

* SMS URI according to
http://www.ietf.org/internet-drafts/draft-wilde-sms-uri-10.txt :
:target "sms:+41796431851;pid=smtp:erik.wilde@dret.net"

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

And so on.

-- 
Alexandros Vellis
avel@noc.uoa.gr