Subject: WGLC for Sieve Notify has ended

From: Alexey Melnikov <[email-masked]>
Date: Tue, 16 Jan 2007 11:27:54 +0000

I will post the summary of all issues raised later this week.

I've only seen comments from Michael, Aaron and Dilyan. Has anybody else 
reviewed the document?

---

From: "Mark E. Mallett" <[email-masked]>
Date: Tue, 16 Jan 2007 12:19:00 -0500

> I've only seen comments from Michael, Aaron and Dilyan. Has anybody else 

Yes... but too late, I fear.

mm

---

From: "Mark E. Mallett" <[email-masked]>
Date: Tue, 16 Jan 2007 15:19:45 -0500

> Yes... but too late, I fear.

Sorry for being abrupt.  I just have some probably-inconsequential
comments.

>    Usage:  notify ":method" string
>            [":from" string]
>            [":importance" <"1" / "2" / "3">]
>            [":options" string-list]
>            [":message" string]

If I interpret the past discussion correctly, this may be getting
changed to remove ':method' and add a positional <method: string> .
I think that is a positive change, but I don't feel too strongly.

> 4.  Extract_text Action
> 
>    Usage:  extract_text [MODIFIER] [":first" number]
>            <varname: string>

I feel that this would be much better as a standalone extension, or at
least as part of an extension where it is more relevant (e.g. "mime").
It has broader use than for just notify; users might want it when notify
is not available; and it could be specified in a more general way.  I
also think that notify could easily proceed without it (though I don't
know all the history, so maybe I'm wrong).  Having it here has the same
feel as a legislative earmark.  This is the strongest I feel of the
remarks that I have here :)

There's also this:

>    The Extract_text action stores at most :first bytes of the first
>    text/* part in the variable identified by varname.  If the :first
>    parameter is not present, the whole content of the first text/* part
>    is stored.

Should something be said about the upper bound?  If nothing else, that
the "whole content" may not be stored because of the truncation that
happens when the variables limit is exceeded.  I also think it would
help to say that implementation limits may apply.  My implementation,
for example, caches in memory some minimum number of bytes of each mime
part, with any excess possibly being cached on disk.  I'd happily make
what's cached in memory available, but I might be disgruntled by having
to fetch more from disk cache.  (This would probably already exceed the
variables limit, but it's just an example of why an implementation might
want to have a limit.)

> 5.  Test valid_notif_method
> 
>    Usage:  valid_notif_method <notification-uris: string-list>

This has the feel of "creat()".  i.e., are we so short on space that
we can't have the 'y' ?

Guess that's it..

-mm-

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 17 Jan 2007 16:12:23 +0000

Ken Murchison wrote:

> Alexey Melnikov wrote:
>> I've only seen comments from Michael, Aaron and Dilyan. Has anybody 
>> else reviewed the document?
>
> I'm wondering if we shouldn't leverage the 'ihave' test from the 
> environment extension rather than creating the proposed 
> 'valid_notif_method' test.

I think you mean the "environment" test, not the "ihave".

valid_notif_method can validate the whole URI, not just the schema part 
of it.

---

From: Michael Haardt <[email-masked]>
Date: Wed, 17 Jan 2007 17:19:50 +0100

> 'valid_notif_method' test.

Does ihave address checking if a particular set of arguments to an
extension is valid, or just if the extension exists at all?

There was a discussion about all kinds of generic error handlers
and no consensus, but unfortunately nobody has valid reasons against
'valid_notif_method', so it looks like that's what we will get.

The test feels wrong to me, but that's hardly something to object a WGLC,
and even if we agree to some error handling approach, it is just ugly
to carry around, but not a problem really.

Michael

---

From: Ken Murchison <[email-masked]>
Date: Wed, 17 Jan 2007 10:49:37 -0500

-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 17 Jan 2007 18:12:59 +0100

Alexey Melnikov writes:
> valid_notif_method can validate the whole URI, not just the schema 
> part of it.

Shouldn't it then be named valid_notif_uri (or valid_notify_uri)?

Arnt

---

From: Lisa Dusseault <[email-masked]>
Date: Wed, 17 Jan 2007 09:55:01 -0800

I think we're going to need a bit more language in the sieve-notify  
draft about sending from authorized or unauthorized from addresses,  
as well as about sending to people who do not want to receive  
notifications, and throttling.  I'm not sure exactly what needs to be  
said, however.
	- Something about how implementations SHOULD restrict the from  
address to allow only appropriate mailboxes?  SHOULD restrict the  
from address so that other domains aren't caused to be spoofed?
	- If the recipient of a sieve notify mail doesn't want those  
notifications, what recourse do they have?  Servers SHOULD add a  
"cancel" link to each notify mail... ?
	- If the notification frequency is high, servers SHOULD throttle  
notifications (and if so what error to produce)? Disable the rule?

lisa

---

From: Dilyan Palauzov <[email-masked]>
Date: Thu, 18 Jan 2007 23:19:09 +0100

Hello,

   Reading Lisa's mail, a new problem arized in my head:

   For every generated notification, the system administrator shall be  
able to say how did it originate. Making "grep" on all scripts is not  
an option, since the user might have changed the script in the  
meantime, or two users might have identical scripts.

   Just imagine a user gets constantly notifications saying "you got  
an email at your example.com mailbox". But the user does not have an  
example.com mailbox, and moreover, he has not set up such a  
script-notification. Obviously this was made by another user and when  
the system administrator, on whose server the message was generated,  
is informed about it, s/he shall be able to track where the problem was.

   So I suggest to add something to section

   3.8.  Requirements on notification methods specifications

* It is RECOMMENDED that a notification includes means to  
identify/track its origin.

But this could be understood, that a notification shall say which  
server generated it, and not which user. Any ideas?

In sec 3.8. one more sentance could be included

* Where applicatiable, derived extensions shall support a subject: option.

   Greetings,
     Дилян

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 21 Jan 2007 12:38:06 +0000

>variables limit, but it's just an example of why an implementation might
I've added:

    In either case the actually stored data MAY be truncated to conform 
to implementation
    specific limit on variable length and/or on MIME body part length.

Is this sufficient?
Should we encourage implementations to have some kind of limit on body 
part length?

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 21 Jan 2007 14:22:55 +0000

> identify/track its origin.

I've extended your sentence. See my reply to a Lisa's message.

> server generated it, and not which user. Any ideas?

Replace "origin" with "sender"?

> * Where applicatiable, derived extensions shall support a subject: 

This is somewhat related to the discussion about :subject versa 
:message. I think we need to get consensus on the subject/message issue 
first.

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 21 Jan 2007 14:22:51 +0000

> from address so that other domains aren't caused to be spoofed?

Here is the text I've added (taken from the vacation draft and reworded):

    In order to minimize/prevent forgery of the author value,
    implementations MAY impose restrictions on what values can specified
    in a ":from" parameter; it is suggested that values which fail
    such a validity check simply be ignored rather than causing
    the notify action to fail.

Do you want to upgrade the MAY to SHOULD?

Also, if you feel that the two examples you gave above should be 
specifically mentioned, I can add them to the text.

> notifications, what recourse do they have?

I think this problem is already present in email.

> Servers SHOULD add a  "cancel" link to each notify mail... ?

How about the following text (I've reworded and extended Dilyan's proposal):

    Notifications SHOULD includes means to identify/track its origin, in 
order
    to allow a recipient to stop notifications or find out how to 
contact the sender.
    This requirement is to help tracking a misconfigured or abusive 
origin of
    notifications.

?

> notifications (and if so what error to produce)? Disable the rule?

Considering there is already some text about "not retrying notification 
indefinitely", I think it would be Ok to just drop notifications silently.
I also think that throttling should be a MAY. So how about the following 
text:

   If there are errors sending the notification, the Sieve interpreter
   SHOULD ignore the notification and not retry indefinitely.
   The Sieve interpreter MAY throttle notifications; if it does,
   a request to send a notification can be silently ignored.
   Documents describing notification methods SHOULD describe how
   retries, throttling, duplicate suppression (if any), etc. are
   to be handled by implementations.

?

---

From: Dilyan Palauzov <[email-masked]>
Date: Mon, 22 Jan 2007 15:28:26 +0100

Hello,

>   SHOULD ignore the notification and not retry indefinitely.

means that the notification service is unreliable: if an SMS is to be  
sentfrom the mail server to an sms gateway, and there is a temporary  
problem, the suggestion sais that it shall not be retired. But the  
user may rely on receiving the notifications.

   What about including expire: parameter and saying that the  
implementation shall not try after the message has expired (thus  
removing indefinetely)?

   Greetings,
     Дилян

> I also think that throttling should be a MAY. So how about the   
> following text:
>

----- End message from [email-masked] -----

---

From: Lisa Dusseault <[email-masked]>
Date: Fri, 26 Jan 2007 13:29:50 -0800

responses in-line...

On Jan 21, 2007, at 6:22 AM, Alexey Melnikov wrote:

> Lisa Dusseault wrote:
>
>> I think we're going to need a bit more language in the sieve- 
>> notify  draft about sending from authorized or unauthorized from  
>> addresses,  as well as about sending to people who do not want to  
>> receive  notifications, and throttling.  I'm not sure exactly what  
>> needs to be  said, however.
>>     - Something about how implementations SHOULD restrict the  
>> from  address to allow only appropriate mailboxes?  SHOULD  
>> restrict the  from address so that other domains aren't caused to  
>> be spoofed?
>

My individual opinion would be for a SHOULD but I'm not sure what  
other considerations hold.

> I think this problem is already present in email.

Yes, obviously.  But I wonder how often notifications will be sent  
from a system address for simplicity.   E.g. all notifications might  
come from "[email-masked]" for the IMAP server for  
example.com, regardless of whose SIEVE rule generated the  
notification.  Then it becomes harder for the recipient to filter  
which notifications they do and don't want, and a little different  
from ordinary email.

>    Notifications SHOULD includes means to identify/track its  
> origin, in order

Yes, and I think this addresses my above concern.

>
>>     - If the notification frequency is high, servers SHOULD  
>> throttle  notifications (and if so what error to produce)? Disable  
>> the rule?
>
> Considering there is already some text about "not retrying  
> notification indefinitely", I think it would be Ok to just drop  
> notifications silently.

Ok.

Lisa

---

From: Ned Freed <[email-masked]>
Date: Mon, 29 Jan 2007 09:51:25 -0800 (PST)

> means that the notification service is unreliable:

Not only are some notification services unreliable, some, including some SMS
variants, provide no way to determine if the notification was ever delivered.

> if an SMS is to be

If so the more fool they. I'm sorry, the issue of end users placing unwarranted
faith in inherently unreliable services is not a problem we should, or can, be
trying to solve here.

I will also point out that no amount of retrying will get a notification
through when the end device is switched off or otherwise unable to receive the
notification. In fact retrying too often will in quite a few cases cause
overall service reliability to drop precipitously.

> implementation shall not try after the message has expired (thus

Exactly what is an implementation supposed to do with such a parameter? Even in
the very restricted subcase of SMS, there are many possible implementation
approaches. For example, an obvious way for an email system to send a
notification to SMS is through an email gateway. This would presumably leverage
the existing queuing capabilites of the email system. The expire parameter
could in theory be respected by the email system, but once the notification is
passed through the gateway to SMS there may or may not be a way to pass the
parameter on to the other side. And if a receipt is requested (assuming the
email gateway even supports making such a request), the task of coordinating
that receipt to the original request goes far beyond anything most
implementations are likely to want to do.

As another example, suppose the sieve implementation is prepared to speak SMPP
to an SMSC. For some types of messages you can specify stuff like number of
retries or expiration date. But not for others, including what SMS calls
notifications. (I'm actually not entirely sure whether it makes sense for a
sieve notify to generate an SMS notification, but it certainly sounds
reasonable.) You can also ask for a delivery receipt, but now you're back to
the receipt correlation problem. (You can also poll using the SMS query
primitive, but this is frowned upon.)

The elephant in the corner in all this is the need for one or more additional
queues. System admins don't like queues - every one we require implementations
to have is another thing they have to continuously monitor, which in turn
increases operational costs. Further exacerbating the problem is when the queue
has a different format or interface than existing queues on the system,
requiring different/additional tools, training, etc. (This last is why
leveraging an existing email gateway to SMS, even one with limited
capabilities, may prove to be a lot more popular than people might initially
believe.)

And this is just SMS. There are all sorts of other ways to send notifications,
each with its own peculiarities.

The bottom line is that while I would have no problem with defining such a
parameter, we realistically cannot mandate that implementations actually
support it if we define it. And this will be true even if the underlying
notification service supports expiration dates, or retries, or whatever. And
saying MUST or SHALL isn't going to help: All it will do is force some
implementations into incomliance, which IMO is a bad thing.

				Ned

P.S. I should also mention that since our implementation has full a SMPP
implementation that leverages our existing queuing facilities we probably won't
have a problem implementing this, in the SMS case at least. But I suspect
we're an unusual case.

---

From: Ned Freed <[email-masked]>
Date: Mon, 29 Jan 2007 12:04:05 -0800 (PST)

> other considerations hold.

It seems to me that SHOULD has the right semantics here. Of course there are
plenty of other considerations, including situations where validity cannot be
accessed, notification mechanisms that either don't have the concept of an
author or which embody it as something other than an email address. But SHOULD
provides enough leeway that such cases can be dealt with without incompliance.

> which notifications they do and don't want, and a little different

Some time back we introduced the idea of an "owner email address" in our sieve
implementation to deal with this and related issues. However, there are also
cases where you cannot use such an address even if you have it: One such is
when the notification relates to a message arriving inside of a highly secure
environment. We have customers using notify in such cases to inform some
outside address that they need to check their secure mail, and one of the rules
is that the notification has to come from a generic address - not even the
recipient's address can be exposed. (My assumption is that sometimes the
address of a recipient conveys some information as to what the person does, and
revealing that is a no-no. Or maybe they's no real risk and they're being
paranoid. Whatever - rules is rules.)

> >    Notifications SHOULD includes means to identify/track its origin, in order
> >    to allow a recipient to stop notifications or find out how to contact the sender.
> >    This requirement is to help tracking a misconfigured or abusive origin of
> >    notifications.
> >
> > ?

> Yes, and I think this addresses my above concern.

This seems reasonable to me as well.

				Ned

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 29 Jan 2007 20:49:06 +0000

> provides enough leeway that such cases can be dealt with without 

Ok, I've changed MAY to SHOULD in my copy.

Date: Mon, 29 Jan 2007 20:49:06 +0000
From: Alexey Melnikov <[email-masked]>
To: Ned Freed <[email-masked]>
CC: Lisa Dusseault <[email-masked]>, [email-masked]
Subject: Re: WGLC for Sieve Notify has ended
Sender: [email-masked]

> provides enough leeway that such cases can be dealt with without 

Ok, I've changed MAY to SHOULD in my copy.

Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Date: Mon, 29 Jan 2007 12:04:05 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: WGLC for Sieve Notify has ended
To: Lisa Dusseault <[email-masked]>
Sender: [email-masked]

				Ned

Cc: Alexey Melnikov <[email-masked]>, Lisa Dusseault <[email-masked]>, [email-masked]
Date: Mon, 29 Jan 2007 09:51:25 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: retrying to send notifications
To: Dilyan Palauzov <[email-masked]>
Sender: [email-masked]

				Ned

X-Spam-Score-scoring_explanation: 
X-Spam-Score-spf_status: 
X-Spam-Score-Spamcatcher1: 2e98e97b3366143eb06f93b6e6389f1f
X-Spam-Score-Summary:  2,0,0,d403c76506bcdc09,cc0db37ab101e937,[email-masked],,RULES_HIT:152:355:379:539:540:541:542:543:567:599:601:945:967:973:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1513:1515:1516:1518:1521:1534:1537:1560:1587:1593:1594:1676:1711:1714:1730:1747:1766:1792:2073:2075:2078:2393:2525:2559:2563:2682:2685:2857:2859:2933:2937:2939:2942:2945:2947:2951:2954:3022:3027:3865:3866:3867:3869:3870:3872:3934:3936:3938:3941:5007,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:,MSBL:none,DNSBL:none
X-Spam-Score-rbl_summary: none
X-Spam-Score-Phishing_status: no
From: "Nigel Swinson" <[email-masked]>
To: "Dilyan Palauzov" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: the notify issues
Date: Mon, 29 Jan 2007 14:14:44 -0000
Sender: [email-masked]

> -- Does somebody know a standard, or part of it, to specify time  
> period, but not date? In this way the seconds can be replaced with  
> something easier to write.

See iCalendar:

http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-04#section-3.3.6

Nigel

X-Spam-Score-scoring_explanation: 
X-Spam-Score-spf_status: 
X-Spam-Score-Spamcatcher1: 32c7197bd748b7a45a4d9dbb8c597941
X-Spam-Score-Summary:  2,0,0,df2b949bc9de515b,0f86fb8d6d24f8a7,[email-masked],,RULES_HIT:355:379:481:539:540:541:542:543:567:599:601:945:946:973:980:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1513:1515:1516:1518:1521:1534:1542:1587:1593:1594:1711:1730:1747:1766:1792:2073:2075:2078:2196:2198:2199:2200:2379:2393:2559:2562:2693:2737:2828:3027:3355:3865:3866:3867:3868:3869:3870:3871:3872:3873:3874:4250:4605:5007,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:,MSBL:none,DNSBL:none
X-Spam-Score-rbl_summary: none
X-Spam-Score-Phishing_status: no
From: "Nigel Swinson" <[email-masked]>
To: "Alexey Melnikov" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Results of the Working Group Last Call on draft-ietf-sieve-notify-05.txt
Date: Mon, 29 Jan 2007 14:11:21 -0000
Sender: [email-masked]

> >> :subject versa :message. Aaron, Dilyan in favor of adding :subject. 
> >> Michael wants to keep using :message.
> >
> I need to poll people on this, as I don't hear a clear consensus on 
> this. Please pick one of the following:
> 
> 3). I don't care whether we have :message or :subject, but we should 
> have only one of them.

Option 3, or better still, make it a positional argument, ie the last argument.  :o)

> >> Issue #4:
> >>
> >> Dilyan suggested to add "expiration" parameter/option to the notify 
> >> action. While I see some utility in this option, I am reluctant to 
> >> extend the document so late in the game, unless there is strong 
> >> support from the WG. I would recommend to add this option in a 
> >> separate document. Opinions?
> >
> I've heard a couple of voices for this feature, but no rough consensus yet.
> 
> Hint for people who want this functionality: please provide some text 
> for inclusion into the document. This will improve your chances of 
> winning the argument ;-).

I'm not interested in this, it sounds like an unnecessary layer of complexity based on the premise that the transport is frequently unreliable.  It sounds to me like a feature more useful on the client that receives the notifications to filter (perhaps using sieve) out the "old" notifications and bin them.

> >> Issue #5:
> >>
> >> Ken (in a private message) has suggested to extend "body" test 
> >> instead of introducing a new "extract_text" test. Opinions?

I agree.

> >> Issue #6:
> >>
> >> Arnt wants to be able to do "send notification over XMPP, if can be 
> >> delivered immediately. Otherwise send it over SMS".
> >> This issue needs further discussion.
> >
> Aaron replied that he likes the idea. Anybody else?
> 
> Other alternative are:
> 1). Add a test to check if a notification method (specified as an URI) 
> can deliver the notification immediately.
> 
> Opinions?

I have a hesitant preference for a test to check the capabilites of a notification method.  Perhaps a set of variables in a namespace.

> =======
> + A new issues (# 8): the Sieve notify document needs to describe what 
> should happen if a parameter specified in two ways in the same notify 
> call: as a notify action parameter and as an URI parameter to the method 
> parameter, for example:
> 
>         notify :method "xmpp:[email-masked]?message;subject=SIEVE" 
> :message "You got mail";
> 
> (assume for a moment that the content of the :message gets translated 
> into the subject of the resulting notification)
> 
> Options suggested so far:
> 4). specify both the notify and the URI parameters is an error.

Option 4.  Preferably parse time error.

Nigel

Date: Sat, 27 Jan 2007 22:06:48 +0100
From: Dilyan Palauzov <[email-masked]>
To: [email-masked]
Subject: the notify issues
Sender: [email-masked]

Hello,

> Issue #3: :message vs :subject

I am for
4). notify should have both :message and :subject

> Issue #6
> "send notification over XMPP, if can be delivered immediately.  
> Otherwise send it over SMS"
I am in favour of:

   1). Add a test to check if a notification method (specified
   as an URI) can deliver the notification immediately.

   1)  Add a test to check if a notification method (specified
   as an URI) HAS delieverED the notification immediately.

Expanations: for sending an SMS, or mail it cannot be said if the  
message can be delivered immediately, as it depends on many things,  
and even if a notification can be delivered during the test, this does  
not mean that it is delivered delivered immediately at a later point,  
when the notification is send. On the other side, if an SMS of mail is  
send, an acknowledgement can be requested, that the notification is  
read/delivered. Naturally, this will mean that the interpreter has to  
stop for certain time, like 10s, and wait for the acknowledgement.

   2). Keep the existing syntax. A new "stackable" notification method
   can be specified that will perform the desired functionality.

I do not get what means "stackable notification".

> Issue #4, expire:
Let's add to
Section 3 Notify Action

*          [":expire" number]

* Section 3.7 Notify tag ":expire"
*
*   If there are errors sending the notification, the parameter of the  
:expire tag sets for how long in seconds shall it be retried to  
deliver the notification. If the  notification cannot be delivered  
within the time, it can be discarded. Missing ":expire" leaves up to  
the implementation to set up some reasonable defaults.
*  A value of 0 (zero) means that delivering the message shall not be retried.

And add an example to the current 3.7

-- Does somebody know a standard, or part of it, to specify time  
period, but not date? In this way the seconds can be replaced with  
something easier to write.

# Issue #8, having both content in both :method and :message --
I like:
3). the notify parameters override the corresponding URI parameters
Or
4). specify both the notify and the URI parameters is an error...
... if they lead to generation of different notification.

(it is not an error, if the :message and ?message define the same )

But 3 is more fault-tolerant.

And final suggestion:
    Notifications SHOULD includes means to identify/track its origin, in order
***Notifications SHOULD include  means to          track its origin, in order
    to allow a recipient to stop notifications or find out how to contact the
    sender. This requirement is to help tracking a misconfigured or abusive
    origin of notifications.

Greetings,
    Dilian

Date: Sat, 27 Jan 2007 17:24:24 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Re: Results of the Working Group Last Call on draft-ietf-sieve-notify-05.txt
Sender: [email-masked]

Alexey Melnikov wrote:

>> Issue #3:
>>
>> :subject versa :message. Aaron, Dilyan in favor of adding :subject. 
>> Michael wants to keep using :message.
>
I need to poll people on this, as I don't hear a clear consensus on 
this. Please pick one of the following:

1). keep the existing :message (it may or may not map to email Subject:, 
this is a separate issue at this point)
2). rename existing :message to :subject
3). I don't care whether we have :message or :subject, but we should 
have only one of them.
4). notify should have both :message and :subject

Let me know your opinion or if I've missed some choice.

>> Issue #4:
>>
>> Dilyan suggested to add "expiration" parameter/option to the notify 
>> action. While I see some utility in this option, I am reluctant to 
>> extend the document so late in the game, unless there is strong 
>> support from the WG. I would recommend to add this option in a 
>> separate document. Opinions?
>
I've heard a couple of voices for this feature, but no rough consensus yet.

Hint for people who want this functionality: please provide some text 
for inclusion into the document. This will improve your chances of 
winning the argument ;-).

>> Issue #5:
>>
>> Ken (in a private message) has suggested to extend "body" test 
>> instead of introducing a new "extract_text" test. Opinions?
>
In order to make some progress on this issue, here is how the updated 
body test can look like:

   "body" [COMPARATOR] [MATCH-TYPE] [BODY-TRANSFORM] [BODY-EXTRACT]
                <key-list: string-list>

where BODY-TRANSFORM is defined as (section 4 of 
draft-ietf-sieve-body-05.txt):

          ":raw"
        / ":content" <content-types: string-list>
        / ":text"

I've added BODY-EXTRACT:

    :extract_none /
    :extract_whole /
    :extract_first number

:extract_none is the default, i.e. if the variables extension is 
present, then the match variables ${1}, ${2}, ... are not set as a side 
effect of successful matching;
:extract_first will truncate the current body part after <number> bytes 
and will set the match variables.
:extract_whole will set the match variable, without performing any 
truncation.

>> Issue #6:
>>
>> Arnt wants to be able to do "send notification over XMPP, if can be 
>> delivered immediately. Otherwise send it over SMS".
>> This issue needs further discussion.
>
Aaron replied that he likes the idea. Anybody else?

Arnt has suggested that the notify action should take multiple :method 
parameters. As tagged parameters can't be specified multiple times in 
the same test (3028bis, section 2.6), this will mean changing the 
:method parameter to be a string list.

Other alternative are:
1). Add a test to check if a notification method (specified as an URI) 
can deliver the notification immediately.
 IMHO, I like this a bit better than Arnt's proposal, as it is easier to 
implement and the resulting script is going to be easier to read.
2). Keep the existing syntax. A new "stackable" notification method can 
be specified that will perform the desired functionality.

Opinions?
=======
+ A new issues (# 8): the Sieve notify document needs to describe what 
should happen if a parameter specified in two ways in the same notify 
call: as a notify action parameter and as an URI parameter to the method 
parameter, for example:

        notify :method "xmpp:[email-masked]?message;subject=SIEVE" 
:message "You got mail";

(assume for a moment that the content of the :message gets translated 
into the subject of the resulting notification)

Options suggested so far:
1). URI parameters are always ignored
2). URI parameters (if any) override the corresponding notify parameters
3). the notify parameters override the corresponding URI parameters
4). specify both the notify and the URI parameters is an error.

Opinions?

Cc: [email-masked]
From: Lisa Dusseault <[email-masked]>
Subject: Re: WGLC for Sieve Notify has ended
Date: Fri, 26 Jan 2007 13:29:50 -0800
To: Alexey Melnikov <[email-masked]>
Sender: [email-masked]

responses in-line...

Ok.

Lisa

Date: Mon, 22 Jan 2007 15:28:26 +0100
From: Dilyan Palauzov <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Lisa Dusseault <[email-masked]>, [email-masked]
Subject: retrying to send notifications
Sender: [email-masked]

Hello,

   Greetings,
     Дилян

----- End message from [email-masked] -----

Date: Sun, 21 Jan 2007 14:22:55 +0000
From: Alexey Melnikov <[email-masked]>
To: Dilyan Palauzov <[email-masked]>
CC: [email-masked]
Subject: Re: WGLC for Sieve Notify has ended
Sender: [email-masked]

Date: Sun, 21 Jan 2007 14:30:03 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Re: Results of the Working Group Last Call on draft-ietf-sieve-notify-05.txt
Sender: [email-masked]

Alexey Melnikov wrote:

> Alexey Melnikov wrote:
>
>> Issue #1:
>>
>> Make tagged "method" parameter positional. (Michael, Dylan are in 
>> favor of the change).
>
> Mark E. Mallett is also in favor of this change (doesn't feel strongly)

I've done this change now.

>> I would welcome additional opinions on this issue.
>>
>> Issue #2:
>>
>> Michael has suggested some changes to the requirement on timestamps. 
>> I will discuss this offline with Michael and Barry and will suggest 
>> some new text.
>
The updated text reads:
    Notifications SHOULD include timestamps, if the notification method 
allows
    for their transmission outside of the textual message. 
Implementation methods
    which can only transmit timestamps in the textual message MAY 
include them
    in the textual message.

 [...]

>> Issue #7:
>>
>> Lisa: controlling who can receive notifications and throttling.
>
I've sent some suggested text to the mailing list.

>> Have I listed all issues raised so far?
>
> Also, several people including Mark has suggested to rename 
> "valid_notif_method" to "valid_notify_method". Unless I hear 
> otherwise, I will do that in the next revision.

This change is done now.

Date: Sun, 21 Jan 2007 14:22:51 +0000
From: Alexey Melnikov <[email-masked]>
To: Lisa Dusseault <[email-masked]>
CC: [email-masked]
Subject: Re: WGLC for Sieve Notify has ended
Sender: [email-masked]

?

?

Date: Sun, 21 Jan 2007 12:38:06 +0000
From: Alexey Melnikov <[email-masked]>
To: "Mark E. Mallett" <[email-masked]>
CC: [email-masked]
Subject: Re: WGLC for Sieve Notify has ended
Sender: [email-masked]

I've added:

Is this sufficient?

Date: Thu, 18 Jan 2007 23:32:53 +0100
From: Dilyan Palauzov <[email-masked]>
To: [email-masked]
Subject: Re: sieve for spamfiltering and greylisting
Sender: [email-masked]

Hello,

> One idea worth considering is multiple Sieve engines, one running in  
> MTA and one running in delivery agent.
This was what I tried to explain all the time.

>>  My idea was not to call external applications, but to provide    
>> unified interface where different applications read the same sieve   
>>  script but interpret different parts of it.
>
> Can this be done using Ned's environment extension and/or Sieve include
> extension?

   No. The spam filter needs the user preferences in form of input and  
delivers probability as output. The environment extension might  
contain the results from the spam evaluation, but at the moment the  
script is supposed to be read either before or after spam filtering,  
thus being used either as input to the filter, or as output.
>
>> The aim is to minimize the  amount of interfaces a user needs to   
>> work with in order to configure  the way of the mail from the MTA   
>> to his mailbox.
>>
>>  There are several user's preferences in spamassassin (tool saying   
>>  for each may how high the probability is, that a specific mail is   
>>  spam). Such an example is the whitelisting. Another option is   
>> altering the scores per user, that matching specific test gives,   
>> thus modifying  the influence that a test has. rewrite_header    
>> (http://spamassassin.apache.org/full/3.1.x/doc/Mail_SpamAssassin_Conf.html#basic_message_tagging_options ) modifies the header of the message, in case it is spam. Of course this can be achieved by other means in   
>> sieve,
>
> Indeed. The editheader extension can be used for that.
>
>> but the latter fact is a sign that spamassassin and sieve do very   
>> similar things (conditionally rewriting headers) and therefore   
>> shall be configured from the same  place.
>
> I am not yet convinced that Sieve is the proper place for storing this
> information.
> One possibility is to store such information externally (in LDAP, ACAP
> or IMAP METADATA) and access it using a Sieve extension. I've written a
> Sieve extension for accessing IMAP METADATA values.

IMAP Metadata is not appropriate, since not every email address has  
assigned an imap mailbox. E.g. on my server I have 15000 mail aliases  
and I don't want to install for all the suers imap accounts in order  
to store the settings.

LDAP is an option, as well ACAP, but this is practiced at the moment:
   In order to configure the incoming mail, a user has to write a  
sieve script, then to setup the greylisting, then to sfjust  
spamassassin, and then one more spam filter. It would be better for  
the user if there was only one itnerface. Needless to say, first the  
anti-spam tools shall agree on common settings, but sieve is the only  
one of the mentioned 3 interfaces that provides standard means to  
upload the settings.

> Another possibility is to make spamassasin Sieve-aware. But maybe this
> is a wishful thinking :-).

It is not that impossible. Just a new module for reading preferences  
is needed and if there is a standard, I am sure the module will be  
written. (there is already managesieve in perl). I will contact, soon  
or late, different spam dev. teams and share later the common opinion.

   Greetings,
     Дилян

Date: Thu, 18 Jan 2007 23:19:09 +0100
From: Dilyan Palauzov <[email-masked]>
To: [email-masked]
Subject: Re: WGLC for Sieve Notify has ended
Sender: [email-masked]

   Hello,

   Greetings,
     Дилян

Date: Thu, 18 Jan 2007 21:42:54 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Re: Results of the Working Group Last Call on draft-ietf-sieve-notify-05.txt
Sender: [email-masked]

Alexey Melnikov wrote:

> Issue #1:
>
> Make tagged "method" parameter positional. (Michael, Dylan are in 
> favor of the change).

Mark E. Mallett is also in favor of this change (doesn't feel strongly)

> I would welcome additional opinions on this issue.
>
> Issue #2:
>
> Michael has suggested some changes to the requirement on timestamps. I 
> will discuss this offline with Michael and Barry and will suggest some 
> new text.
>
> Issue #3:
>
> :subject versa :message. Aaron, Dilyan in favor of adding :subject. 
> Michael wants to keep using :message.
>
> Issue #4:
>
> Dilyan suggested to add "expiration" parameter/option to the notify 
> action. While I see some utility in this option, I am reluctant to 
> extend the document so late in the game, unless there is strong 
> support from the WG. I would recommend to add this option in a 
> separate document. Opinions?
>
> Issue #5:
>
> Ken (in a private message) has suggested to extend "body" test instead 
> of introducing a new "extract_text" test. Opinions?

Somewhat related to this:
Mark (and I was thinking the same) has suggested to move "extract_text" 
to another document (e.g. MIME loops), as it has applicability beyond 
Sieve notify.

> Issue #6:
>
> Arnt wants to be able to do "send notification over XMPP, if can be 
> delivered immediately. Otherwise send it over SMS".
> This issue needs further discussion.
>
> Issue #7:
>
> Lisa: controlling who can receive notifications and throttling.
>
>
> Have I listed all issues raised so far?

Also, several people including Mark has suggested to rename 
"valid_notif_method" to "valid_notify_method". Unless I hear otherwise, 
I will do that in the next revision.

Date: Thu, 18 Jan 2007 20:40:00 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Results of the Working Group Last Call on draft-ietf-sieve-notify-05.txt
Sender: [email-masked]

Issue #1:

Make tagged "method" parameter positional. (Michael, Dylan are in favor 
of the change).
I would welcome additional opinions on this issue.

Issue #2:

Michael has suggested some changes to the requirement on timestamps. I 
will discuss this offline with Michael and Barry and will suggest some 
new text.

Issue #3:

:subject versa :message. Aaron, Dilyan in favor of adding :subject. 
Michael wants to keep using :message.

Issue #4:

Dilyan suggested to add "expiration" parameter/option to the notify 
action. While I see some utility in this option, I am reluctant to 
extend the document so late in the game, unless there is strong support 
from the WG. I would recommend to add this option in a separate 
document. Opinions?

Issue #5:

Ken (in a private message) has suggested to extend "body" test instead 
of introducing a new "extract_text" test. Opinions?

Issue #6:

Arnt wants to be able to do "send notification over XMPP, if can be 
delivered immediately. Otherwise send it over SMS".
This issue needs further discussion.

Issue #7:

Lisa: controlling who can receive notifications and throttling.

Have I listed all issues raised so far?

Date: Thu, 18 Jan 2007 19:45:54 +0000
From: Alexey Melnikov <[email-masked]>
To: Dilyan Palauzov <[email-masked]>
CC: [email-masked]
Subject: Re: subject: and method: / Re: Working Group Last Call on draft-ietf-sieve-notify-05.txt
Sender: [email-masked]

>     Hello,

Hi Dilyan,

>     To what I understood, the issue with method: and subject: was not 
> cleared yet. Let me share what I think:
>
> 'subject:" for me the purpose of sieve-notify is to define a general 
> framework for sending notifications, in the most general way a message 
> can be defined. It is true that some notify-gateways support subjects, 
> and others don't, but a subject is a property of a general message. 
> Look on the discussion as an object-oriented programmer: the base 
> class/interface is notify, derived by notify-voip-phone, notify-xmpp, 
> notify-mailto. Suppose notify-voip-phone puts a message in the voice 
> box of the user and displays text on the device's display (voip phones 
> do have ascii display).
>     If we want a common name in all derived classes, the name shall be 
> defined already in the interface. Then notify-xmpp can ignore this 
> tag, in the same way notify-voip-phone can ignore importance. But if 
> there is a subject: to be overwritten, then notify-display-phone is 
> supposed to use this keyword for the text to be displayed. If there is 
> no subject: , they could use display: and even if totally correct, it 
> is not very practical: the user will be then forced to learn the 
> different words used to replace "subject:", except having subject and 
> relying on the notify-extension to interpret it correctly (as will be 
> described in the sieve-notify.. how to use subject. I guess it is 
> already there, but have now now wish to check).
>     So I am in favour of having subject: in sieve-notify.

Maybe I didn't understand your comments correctly, but you haven't 
convinced me that we need both :message and :subject.
And I haven't heard a good argument for why :message is not acceptable, 
while :subject would be.

>     By the way, what do you think about adding an  "expire: date", in 
> order to allow the mechanism to delte the notification, if it is not 
> delivered within a certain time. E.g. I might like to get jabber 
> message when I get a mail, but when on holiday, I don't want 100 
> notifications once I am back. Instead the notification might wait 
> three days to be read and then be discarded.

I see some utility in this, but I would suggest that this be done as a 
separate extension to Sieve notify. If other people disagree, please 
speak up now!

>     "method:" If method: is a must to have, then it is redundant to 
> write "method:" when this can be avoided and I am in favour of 
> removing it. Now, the backward compatibility, there could be a 
> transitional clause, included or not in the final document, that if 
> "methond" is not mentioned, then the last string is considered to 
> describe the method; if it is mentioned, then what follows it is the 
> method. To what I understand from computer lang. grammars it is very 
> easy to define the method "so or so" and I do not imagine very-very 
> huge problems.

Ok, I count your voice for replacing :method with a positional argument.

Cc: [email-masked]
From: Lisa Dusseault <[email-masked]>
Subject: Re: WGLC for Sieve Notify has ended
Date: Wed, 17 Jan 2007 09:55:01 -0800
To: Alexey Melnikov <[email-masked]>
Sender: [email-masked]

lisa

> else reviewed the document?

Date: Wed, 17 Jan 2007 18:12:59 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: WGLC for Sieve Notify has ended
Cc: Alexey Melnikov <[email-masked]>, Ken Murchison <[email-masked]>
Sender: [email-masked]

Arnt

Date: Wed, 17 Jan 2007 17:19:50 +0100
To: [email-masked]
Subject: Re: WGLC for Sieve Notify has ended
From: Michael Haardt <[email-masked]>
Sender: [email-masked]

Michael

Date: Wed, 17 Jan 2007 16:12:23 +0000
From: Alexey Melnikov <[email-masked]>
To: Ken Murchison <[email-masked]>
CC: [email-masked]
Subject: Re: WGLC for Sieve Notify has ended
Sender: [email-masked]

Date: Wed, 17 Jan 2007 10:49:37 -0500
From: Ken Murchison <[email-masked]>
Organization: Carnegie Mellon University
To: [email-masked]
Subject: Re: WGLC for Sieve Notify has ended
Sender: [email-masked]

From: "Mark E. Mallett" <[email-masked]>
Date: Tue, 16 Jan 2007 15:19:45 -0500
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Subject: Re: WGLC for Sieve Notify has ended
Sender: [email-masked]

Guess that's it..

-mm-

From: "Mark E. Mallett" <[email-masked]>
Date: Tue, 16 Jan 2007 12:19:00 -0500
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Subject: Re: WGLC for Sieve Notify has ended
Sender: [email-masked]

mm

Date: Tue, 16 Jan 2007 16:28:59 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Updated milestones
Sender: [email-masked]

Hi folks,
Below is a proposal from chairs about updating our milestones (again):
  
Jan 2007    Submit 3028bis to IESG
Jan 2007    Submit editheader draft to IESG
Jan 2007     Submit body test draft to IESG
Feb 2007    Submit notification action draft to IESG
Mar 2007    WG last call for loop draft
Apr 2007    Submit loop draft to IESG
Apr 2007    Submit revised regex draft
May 2007    Submit refuse draft to IESG
Jun 2007    WG last call of regex draft
Aug 2007    Submit regex action draft to IESG
Aug 2007    3028bis interop report framework/matrix

Does this seem reasonable?

Date: Tue, 16 Jan 2007 11:27:54 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: WGLC for Sieve Notify has ended
Sender: [email-masked]

Date: Sun, 14 Jan 2007 09:35:53 +0000
From: Alexey Melnikov <[email-masked]>
To: Dilyan Palauzov <[email-masked]>
CC: [email-masked]
Subject: Re: sieve for spamfiltering and greylisting
Sender: [email-masked]

> Hello,

Hi Dilyan,

>   My idea was not to call external applications, but to provide  
> unified interface where different applications read the same sieve  
> script but interpret different parts of it.

Can this be done using Ned's environment extension and/or Sieve include 
extension?

> The aim is to minimize the  amount of interfaces a user needs to work 
> with in order to configure  the way of the mail from the MTA to his 
> mailbox.
>
>   There are several user's preferences in spamassassin (tool saying  
> for each may how high the probability is, that a specific mail is  
> spam). Such an example is the whitelisting. Another option is 
> altering  the scores per user, that matching specific test gives, thus 
> modifying  the influence that a test has. rewrite_header  
> (http://spamassassin.apache.org/full/3.1.x/doc/Mail_SpamAssassin_Conf.html#basic_message_tagging_options 
> ) modifies the header of the message, in case it is spam. Of course 
> this can be achieved by other means in sieve,

Indeed. The editheader extension can be used for that.

> but the latter fact is a sign that spamassassin and sieve do very 
> similar things (conditionally rewriting headers) and therefore shall 
> be configured from the same  place.

I am not yet convinced that Sieve is the proper place for storing this 
information.
One possibility is to store such information externally (in LDAP, ACAP 
or IMAP METADATA) and access it using a Sieve extension. I've written a 
Sieve extension for accessing IMAP METADATA values.

Another possibility is to make spamassasin Sieve-aware. But maybe this 
is a wishful thinking :-).

>   spam rewrite_header nanana, or rather spam rewrite_header subject  
> nanana is supposed to prefix the subject-header with +nanana+ in the  
> mails marked as spam.
>
>   Greetings,
>     Дилян

Date: Thu, 04 Jan 2007 15:56:02 +0100
To: [email-masked]
Subject: Re: subject: and method: / Re: Working Group Last Call on draft-ietf-sieve-notify-05.txt
From: Michael Haardt <[email-masked]>
Sender: [email-masked]

> > Ok, but the implementation specs (notify-xmpp and notify-mailto) each
> > specify different and strange default subjects in their respective media.
> > They even seem to suggest that the subject would be hardcoded in the
> > implementation.
>
> I'd say if the gateway supports subject+body, then the notification should be the subject, not the body.  A hardcoded subject sounds dreadful!

>From draft-ietf-sieve-notify-mailto-01:

   o  The "Subject:" field of the notification message contains the
      value defined by the :message notify tag, as described in
      [Notify].  If there is no :message tag, the subject is retained
      from the triggering message.  Note that Sieve [Variables] can be
      used to advantage here, as shown in the example in Section 3.

[...]

   o  If the mailto URI contains a "body" header, the value of that
      header is used as the body of the notification message.  If there
      is no "body" header, the body of the notification message is
      empty.

No fixed subject, and I can't remember that is was suggested to change
that.

Michael

X-Spam-Score-scoring_explanation: 
X-Spam-Score-spf_status: 
X-Spam-Score-Spamcatcher1: 2840ecd498a18647bdfc1c57d27f4e9f
X-Spam-Score-Summary:  2,0,0,a52e3ad2ff841928,17cb9f564c0fc456,[email-masked],,RULES_HIT:355:379:539:540:541:542:543:567:599:601:945:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1513:1515:1516:1518:1521:1534:1537:1567:1587:1593:1594:1711:1714:1730:1747:1766:1792:2073:2075:2078:2393:2559:2562:2828:3027:3865:3867:3868:3869:3870:3874:5007,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:,MSBL:none,DNSBL:none
X-Spam-Score-rbl_summary: none
X-Spam-Score-Phishing_status: no
From: "Nigel Swinson" <[email-masked]>
To: "Aaron Stone" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: subject: and method: / Re: Working Group Last Call on draft-ietf-sieve-notify-05.txt
Date: Thu, 4 Jan 2007 00:01:17 -0000
Sender: [email-masked]

> Ok, but the implementation specs (notify-xmpp and notify-mailto) each
> specify different and strange default subjects in their respective media.
> They even seem to suggest that the subject would be hardcoded in the
> implementation.

I'd say if the gateway supports subject+body, then the notification should be the subject, not the body.  A hardcoded subject sounds dreadful!

Nigel

Date: Wed, 3 Jan 2007 20:30:19 -0000
To: "Nigel Swinson" <[email-masked]>, "Aaron Stone" <[email-masked]>
Subject: Re: subject: and method: / Re: Working Group Last Call on draft-ietf-sieve-notify-05.txt
From: "Aaron Stone" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

On Wed, Jan 3, 2007, Nigel Swinson <[email-masked]> said:

>> Incidentally, "Read your hospital email now!" strikes me as the _subject_.
>> The message might be blank on a pager, or it might include some details if
>> it were an email. In a non-privacy-centric situation, perhaps a lot of
>> detail.
> 
> I think we run the risk of straying into message summaries that Ned warned
> about previously.  So why can't the notification be just "Read your hospital
> email now!" and have no two part subject/body, or in a non-privacy-centric
> situation use redirect(+keep?).

Ok, but the implementation specs (notify-xmpp and notify-mailto) each
specify different and strange default subjects in their respective media.
They even seem to suggest that the subject would be hardcoded in the
implementation.

Aaron

X-Spam-Score-scoring_explanation: 
X-Spam-Score-spf_status: 
X-Spam-Score-Spamcatcher1: 5e1332730d7713f67900a5e5ee7dd0eb
X-Spam-Score-Summary:  2,0,0,79ff669a7154f3e6,17cb9f564c0fc456,[email-masked],,RULES_HIT:355:379:539:540:541:542:543:567:599:601:973:980:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1513:1515:1516:1518:1521:1534:1541:1587:1593:1594:1711:1730:1747:1766:1792:2073:2075:2078:2194:2199:2393:2559:2562:2693:2828:2891:2892:3027:3352:3865:3866:3867:3868:3869:3870:3871:3872:3874:4362:4552:5007,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:,MSBL:none,DNSBL:none
X-Spam-Score-rbl_summary: none
X-Spam-Score-Phishing_status: no
From: "Nigel Swinson" <[email-masked]>
To: "Aaron Stone" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: subject: and method: / Re: Working Group Last Call on draft-ietf-sieve-notify-05.txt
Date: Wed, 3 Jan 2007 17:49:03 -0000
Sender: [email-masked]

> > What is the utility of using notify with email?  Why not just use redirect
> > (+keep?).
> 
> In many cases, the email and the email store will be secure, but the
> notification mechanism will not.
> 
> The use case I've thought of is a doctor's email, which will be be secured
> and is restricted by patient privacy laws, but the doctor's pager is an
> open broadcast. The notification to "Read your hospital email now!"
> contains no private information. A copy of the original message (or even
> its Received headers, hence the thorny issues with catching message loops)
> is private.

Thanks for that, it's helpful to think about :o)

> Incidentally, "Read your hospital email now!" strikes me as the _subject_.
> The message might be blank on a pager, or it might include some details if
> it were an email. In a non-privacy-centric situation, perhaps a lot of
> detail.

I think we run the risk of straying into message summaries that Ned warned about previously.  So why can't the notification be just "Read your hospital email now!" and have no two part subject/body, or in a non-privacy-centric situation use redirect(+keep?).

Nigel

Date: Wed, 3 Jan 2007 17:22:35 -0000
To: "Nigel Swinson" <[email-masked]>
Subject: Re: subject: and method: / Re: Working Group Last Call on draft-ietf-sieve-notify-05.txt
From: "Aaron Stone" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

On Wed, Jan 3, 2007, Nigel Swinson <[email-masked]> said:

> What is the utility of using notify with email?  Why not just use redirect
> (+keep?).

In many cases, the email and the email store will be secure, but the
notification mechanism will not.

The use case I've thought of is a doctor's email, which will be be secured
and is restricted by patient privacy laws, but the doctor's pager is an
open broadcast. The notification to "Read your hospital email now!"
contains no private information. A copy of the original message (or even
its Received headers, hence the thorny issues with catching message loops)
is private.

Incidentally, "Read your hospital email now!" strikes me as the _subject_.
The message might be blank on a pager, or it might include some details if
it were an email. In a non-privacy-centric situation, perhaps a lot of
detail.

Aaron

X-Spam-Score-scoring_explanation: 
X-Spam-Score-spf_status: 
X-Spam-Score-Spamcatcher1: 8f2fb5a3f76456a07e0c9c3f64b2318a
X-Spam-Score-Summary:  2,0,0,4b3bcde9424ab7d2,17cb9f564c0fc456,[email-masked],,RULES_HIT:355:379:539:540:541:542:543:567:599:601:973:980:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1513:1515:1516:1518:1521:1534:1540:1587:1593:1594:1711:1730:1747:1766:1792:2073:2075:2078:2194:2199:2393:2553:2559:2562:2828:3027:3352:3865:3866:3867:3868:3869:3870:3871:3872:3873:3874:5007,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:,MSBL:none,DNSBL:none
X-Spam-Score-rbl_summary: none
X-Spam-Score-Phishing_status: no
From: "Nigel Swinson" <[email-masked]>
To: "Michael Haardt" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: subject: and method: / Re: Working Group Last Call on draft-ietf-sieve-notify-05.txt
Date: Wed, 3 Jan 2007 16:28:47 -0000
Sender: [email-masked]

> > It is true that some notify-gateways support subjects, and others don't,
> > but a subject is a property of a general message.
> 
> IMHO: Messages in general - yes.  Notification messages - no.  

But then complex messages may also transport notifications.  Perhaps an alternative question is of all the available messaging channels, how many support a subject+body, and how many support just a body.  You probably then ought to weight the frequency of the messaging channel.  Carrier Pigeon isn't going to be as popular a choice as sms or email for notifications.  If there are several channels that support a subject, it is worth adding to the notify spec.

What is the utility of using notify with email?  Why not just use redirect (+keep?).

I'm currently marginally against adding :subject to the notify spec.

Nigel

Date: Wed, 03 Jan 2007 15:23:13 +0100
To: [email-masked]
Subject: Re: subject: and method: / Re: Working Group Last Call on draft-ietf-sieve-notify-05.txt
From: Michael Haardt <[email-masked]>
Sender: [email-masked]

Hello,

happy new year to everybody! I don't want to let this discussion just
stop without agreement.  So let's get results.

> It is true that some notify-gateways support subjects, and others don't,
> but a subject is a property of a general message.

IMHO: Messages in general - yes.  Notification messages - no.  A poll
should answer what the majority thinks:

----------------------------------------------------------------------
Do you consider general notification messages (in the context of the
notify extension) to have a property "subject"?

[ ] yes   [ ] no
----------------------------------------------------------------------

> If we want a common name in all derived classes, the name shall be
> defined already in the interface.

I agree to that.  Should the majority vote for subjects being proporties
of general notification messages, we absolutely should put ":subject" in
the framework.

> By the way, what do you think about adding an  "expire: date", in order
> to allow the mechanism to delte the notification, if it is not delivered
> within a certain time. E.g. I might like to get jabber message when I
> get a mail, but when on holiday, I don't want 100 notifications once I
> am back. Instead the notification might wait three days to be read and
> then be discarded.

I think if you want a rolling message store, the recipient store and its
associated delivery policy (e.g. a sieve filter:-) should care about that,
not the sender.

>	"method:" If method: is a must to have, then it is redundant to
> write "method:" when this can be avoided and I am in favour of removing
> it.

That makes two of us.  Compatibility is no problem at this point,
because the name of the extension changes anyway.

Michael