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

From: [email-masked]
Date: Mon, 26 Jun 2006 18:50:01 -0400

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-03.txt
	Pages		: 15
	Date		: 2006-6-26
	
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-03.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-03.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-03.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: Wed, 28 Jun 2006 12:30:54 +0200

Hello,

I am just changing my code to implement -03 and have a few issues:

Section 3.1:

  [":options" 1*(string-list / number)]

Honestly, I think that's overkill.  An arbitrary amount of string lists
and numbers, but it must not be empty? I expected a single string list
and I am surprised to see it was considered not to be enough.

This has the implication that the ":method" tag is going to stay forever,
whereas I expected -03 to remove it, making the method string the last
argument.  Correct?

Section 3.2:

   An implementation MAY enforce other
   semantic restrictions on URIs -- for example an SMS URI can only
   contain phone numbers in a particular geographical region.  Violation
   of such semantic restrictions MUST be treated as an error.
   [[Barry 1: "MUST" seems silly here, since the whole sentence is a
   "MAY".]]

How about wording it differently?

   An implementation MAY enforce other
   semantic restrictions on URIs -- for example an SMS URI can only
   contain phone numbers in a particular geographical region.
   A violation of such semantic restrictions MUST be treated as an error
   and not cause notifications to be ignored.

If that is not what was meant, then I guess we should word it differently
for sure. :)

Section 3.5:

   [[Alexey 1: Should we keep using "high", "normal" and "low" instead?
   Numbers are easier to compare with comparators.]]

Since we talk about an input parameter to "notify", how about allowing
words as well as numbers? Expressions using variables might generate
numbers, whereas users probably prefer words.

   [[Barry 3.5: Why do we call this "priority", and then explain it as
   "importance"?  Shouldn't we just call it "importance"?]]

YES. In fact I thought it was decided to change that in -03.

Section 3.6:

   If the message parameter is absent, a default message
   containing the value of the From header field [[Alexey 3: Align with
   usage of :from]] and the value of the Subject header field will be
   used.  Note that the notification method (the ":method" tag) may
   affect how this information is formatted.

Is that a suggestion, a MAY, SHOULD or MUST? Sites should be free to
send other default messages and I vote for:

   If the message parameter is absent, a site-specific default message
   will be used.  It is suggested that it contains the value of the
   "From" header field and the value of the "Subject" header field.

Michael