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

From: [email-masked]
Date: Mon, 06 Feb 2006 15:50:01 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF.

	Title		: Sieve Extension: Notifications
	Author(s)	: A. Melnikov, et al.
	Filename	: draft-ietf-sieve-notify-02.txt
	Pages		: 17
	Date		: 2006-2-6
	
Users go to great lengths to be notified as quickly as possible that
   they have received new mail.  Most of these methods involve polling
   to check for new messages periodically.  A push method handled by the
   final delivery agent gives users quicker notifications and saves
   server resources.  This document does not specify the notification
   method but is expected that using existing instant messaging
   infrastructure such as Zephyr, Jabber, or SMS messages will be
   popular.  This draft describes an extension to the Sieve mail
   filtering language that allows users to give specific rules for how
   and when notifications should be sent.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-notify-02.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sieve-notify-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sieve-notify-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Michael Haardt <[email-masked]>
Date: Tue, 7 Feb 2006 12:05:13 +0100

First of all, please add a Changelog.

   However, all content specified in the notify action SHOULD be
   included.  It is RECOMMENDED that a timestamp be included in the
   notification.

Do we really need SHOULD and RECOMMENDED? If a method can not implement
the above for technical reasons, of course that qualifies as reason to
violate the SHOULD.  But isn't it silly to set a strong default, knowing
it will be violated?

I recommend that each method MUST define if specified content is not
included in the notification and if it includes a timestamp.  Do we
define anywhere that this timestamp should be as close to the delivery
as possible?

   If there are errors sending the notification, the Sieve interpreter
   SHOULD ignore the notification and not retry indefinitely.
   [[Barry 4: Does this really belong here?  Shouldn't we push the
   question of error recovery to the individual methods?]]

I think defining the default behaviour is useful, but again I question
the "SHOULD".  How about "should" and saying that each method MUST define
how error recovery works?

                  The entirety of the string SHOULD be sent but
   implementations MAY shorten the message for technical or aesthetic
   reasons.

If aesthetic reasons suffice, then why a SHOULD? This repeats the
paragraph at top, but weakens it.

             If the message parameter is absent, a default message
   containing the value of the From header field and the value of the
   Subject header field will be used.

No timestamp here?

   The implementation of a notification method MAY modify the final
   notification text -- for example, truncating it if it exceeds a
   length limit, or modifying characters that can not be represented in
   the target character set.  Allowed modifications should be documented
   in a standards-track or informational document.

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.

   Example:  if valid_notif_method ["mailto:",
                     "http://gw.example.net/notify?test"] {
                 stop;
             }

I miss a reference to the mailto and http schemes, if you use them,
but you raise an interesting point concerning mailto here:

What does an URI without recipient do? Looking at the guideline of not
causing an error by sending notifications, I suggest: If no recipient
is specified in the URI, no notification is being sent.  I will make a
note to define this in the mailto method description.

   The notify action is potentially very dangerous.  The path the
   notification takes through the network may not be secure.

It is worse: *The path the notification takes through or out of
the network may not be secure.*  It is the nature of notifications
that they may leave the network to get to the user, whereas the
above implies the risk is just the network.

I notice ":id" and "denotify" are gone.  Good! There is still no
":from", though, and the change of ":priority" to ":importance" is
only discussed, but not made.  Why?

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]";

instead of

  notify :method "mailto:[email-masked]";

Sorry for the amount of comments.  I am real glad you pushed out a
new version, because it makes my work way easier.

Michael

---

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

[Cc: ing notifications list]

> of actions for validity.  I still suggest a generic extension for

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

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

---

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: 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: "Mark E. Mallett" <[email-masked]>
Date: Wed, 8 Feb 2006 14:53:39 -0500

[I'm not on the notify list, dunno if this group-reply will cause an error]

> see a need for _some_ generic solution and that's all I can think of

Yes it would be nice to have a way of testing capabilities that didn't
introduce a new verb for each capability to be tested.  One naive
thought is to have a side-effect of "require" set a variable within a
"require" namespace, but I don't really like that: it would only be
available if variables were present, and it would also not address the
problem of using a method that is specified by a variable.

Another would be to introduce some new style of "require" ("xrequire")
that:
  - accepted only a single string (not a string-list);
  - could have a side-effect that could be tested;
  - could be used anywhere, even after other non-require commands;
  - could require notify methods, a la the way that comparators are required;
  - enabled the capability if the require is satisfied, but
  - did not cause the script to fail if the 'require' wasn't satisfied.

   if xrequire "refuse" {
      do one thing...;
   } else {
      do another thing;
   }

The form of the "notify-" capability could be specified to include either
just a method name (in which case only the availability of the method would
be tested) or a complete URI (in which case the availability of the method
AND the syntax of the URI could be tested):

   if xrequire "mailto:[email-masked]" {
      notify "mailto:[email-masked]";
   }

I don't know how reasonable any of this is, I'm just scattering some
thoughts.  Although this is more the way I've felt that require should
have been made to operate anyway, perhaps with a :fail option:

   xrequire :fail "refuse";

Yet another approach would be to add a :nofail option to "require" and
have another command to test the results of "require"s later.

   require :nofail "refuse";

   if available "refuse" { ... }

but again, that doesn't address the use of variable methods.

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

-mm-

BTW what happened to the ":attributes" thing?  Did this get shot down?

---

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

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