headers
Barry Leiba | 1 Dec 2005 21:58
Picon
Favicon

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


>> Sure, I can do that -- but why not remove the whole paragraph?  There's
>> nothing in that paragraph that needs to be there, since the Sieve base
>> spec tells us what Sieve is, and this whole document is dependent on
>> that one.
>>  
>>
> That is fine as well.

OK... lacking any other comments, I'll submit this change, and when you
see -03 posted, please ask the ADs for a last call, yes?

Barry

--
Barry Leiba, Pervasive Computing Technology  (leiba <at> watson.ibm.com)
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam
Permalink | Reply | 0 comments |
headers
Internet-Drafts | 2 Dec 2005 21:50
Picon
Favicon

I-D ACTION:draft-ietf-sieve-3431bis-03.txt

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: Relational Tests
	Author(s)	: W. Segmuller, B. Leiba
	Filename	: draft-ietf-sieve-3431bis-03.txt
	Pages		: 14
	Date		: 2005-12-2
	
This document describes the RELATIONAL extension to the Sieve mail
   filtering language defined in RFC 3028.  This extension extends
   existing conditional tests in Sieve to allow relational operators.
   In addition to testing their content, it also allows for testing of
   the number of entities in header and envelope fields.

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

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org 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-3431bis-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Saint-Andre | 3 Dec 2005 00:44

values of notify ":priority" tag

In draft-ietf-sieve-notify-01 the possible values of the ":priority" tag 
are "1", "2", and "3". There is a note about perhaps retaining "high", 
"normal", and "low" instead. I wonder why we're not using "urgent", 
"normal", and "non-urgent" as specified in RFC 1327 and re-used in RFC 
2076 and RFC 3261 (the latter also adds "emergency" but I don't think 
we'd need that for email notifications).

Peter
Attachment (smime.p7s): application/x-pkcs7-signature, 3641 bytes
Permalink | Reply | 18 comments |
headers
Alexey Melnikov | 3 Dec 2005 15:52
Favicon

Re: values of notify ":priority" tag


Peter Saint-Andre wrote:

> In draft-ietf-sieve-notify-01 the possible values of the ":priority" 
> tag are "1", "2", and "3". There is a note about perhaps retaining 
> "high", "normal", and "low" instead. I wonder why we're not using 
> "urgent", "normal", and "non-urgent" as specified in RFC 1327 and 
> re-used in RFC 2076 and RFC 3261 (the latter also adds "emergency" but 
> I don't think we'd need that for email notifications).

Another question related to this: do we want to have 3 levels or 5 (like 
in X-Priority header)?
Permalink | Reply | 17 comments |
headers
Nigel Swinson | 5 Dec 2005 14:31
Favicon

Re: values of notify ":priority" tag


It feels like what was discussed in these threads has been forgotten:

http://www.imc.org/ietf-mta-filters/mail-archive/msg09483.html
http://www.imc.org/ietf-mta-filters/mail-archive/msg10008.html

Specifically:

"This makes it sound like there are hard and fast rules between user status notifications and the setting of
the priority parameter, yet the discussion is very brief and doesn't elaborate to rigorously define all
those rules.  I also feel uneasy about adding syntax that permits only 3 levels of priority.   I think we
should either drop the parameter, or extend it to allow an almost arbitrary number and style of priority
statuses, even if we only define 3 for now.  I'm thinking of the Priority/X-Priority/X-MSMail-Priority
mess in mail headers.  I'd suggest a string which could be used with the relational draft to do numeric
comparisons if desired."

However I don't recall us reaching any conclusions, as the discussion wandered towards the subject of
passing parameters to the notification mechanism.

Nigel

----- Original Message ----- 
From: "Alexey Melnikov" <alexey.melnikov <at> isode.com>
To: <ietf-mta-filters <at> imc.org>
Cc: "Peter Saint-Andre" <stpeter <at> jabber.org>
Sent: Saturday, December 03, 2005 2:52 PM
Subject: Re: values of notify ":priority" tag

> 
> Peter Saint-Andre wrote:
(Continue reading)

Permalink | Reply | 16 comments |
headers
Peter Saint-Andre | 5 Dec 2005 20:06

Re: values of notify ":priority" tag


On Mon, Dec 05, 2005 at 01:31:58PM -0000, Nigel Swinson wrote:
> It feels like what was discussed in these threads has been forgotten:
> 
> http://www.imc.org/ietf-mta-filters/mail-archive/msg09483.html
> http://www.imc.org/ietf-mta-filters/mail-archive/msg10008.html

Sorry, I wasn't here for that.

> Specifically:
> 
> "This makes it sound like there are hard and fast rules between user status notifications and the setting
of the priority parameter, yet the discussion is very brief and doesn't elaborate to rigorously define
all those rules.  I also feel uneasy about adding syntax that permits only 3 levels of priority.   I think we
should either drop the parameter, or extend it to allow an almost arbitrary number and style of priority
statuses, even if we only define 3 for now.  I'm thinking of the Priority/X-Priority/X-MSMail-Priority
mess in mail headers.  I'd suggest a string which could be used with the relational draft to do numeric
comparisons if desired."

What are the use cases for priorities other than those in RFC 1327?
Sure, infinite priority gradations sound appealing in theory, but what
will they really be used for?

Peter
Permalink | Reply | 2 comments |
headers
Michael Haardt | 6 Dec 2005 09:40
Picon

Re: values of notify ":priority" tag


On Mon, Dec 05, 2005 at 01:31:58PM -0000, Nigel Swinson wrote:
> "This makes it sound like there are hard and fast rules between
> user status notifications and the setting of the priority parameter,
> yet the discussion is very brief and doesn't elaborate to rigorously
> define all those rules.  I also feel uneasy about adding syntax that
> permits only 3 levels of priority.   I think we should either drop the
> parameter, or extend it to allow an almost arbitrary number and style
> of priority statuses, even if we only define 3 for now.  I'm thinking
> of the Priority/X-Priority/X-MSMail-Priority mess in mail headers.
> I'd suggest a string which could be used with the relational draft to
> do numeric comparisons if desired."

Personally, I wonder why priorities are considered so useful and the
option is not just dropped, but that's me.

Assuming the majority likes :priority, I agree to the above and suggest
to allow arbitrary values, like :from does, because each method might
use different data formats as sender.  For SMTP, it is certainly a
mail address, for SMS a phone number or an alphanumeric sender tag.
Saying :priority must be defined as in RFCs relevant to e-mail makes
sense for SMTP, but not neccessarily for SMS.

I think the notify extension should focus on being a framework to be
filled with methods that interface different media, inside and outside
the internet.

Michael
(Continue reading)

Permalink | Reply | 12 comments |
headers
Nigel Swinson | 6 Dec 2005 13:33
Favicon

Re: values of notify ":priority" tag


> What are the use cases for priorities other than those in RFC 1327?
> Sure, infinite priority gradations sound appealing in theory, but what
> will they really be used for?

The fact that we ended up with Priority/X-Priority/X-MSMail-Priority makes me think that the needs of the
original field proved insufficent, and so further fields were defined.  Personally I hate the fact that
the task list in my iPAQ only allows me only three levels.  There seem to be no technical restrictions for
allowing arbitary levels, so why make such a crippled feature?

> Personally, I wonder why priorities are considered so useful and the
> option is not just dropped, but that's me.
> 
> I think the notify extension should focus on being a framework to be
> filled with methods that interface different media, inside and outside
> the internet.
> 
> Michael

I agree with this approach.  Priority notifications can be added later if they prove desirable enough, but I
think the feature is going to dramatically slow down the spec, needlessly so.

Nigel
Permalink | Reply | 1 comment |
headers
Barry Leiba | 6 Dec 2005 20:28
Picon
Favicon

Re: values of notify ":priority" tag


> Assuming the majority likes :priority, I agree to the above and suggest
> to allow arbitrary values, like :from does, because each method might
> use different data formats as sender.  For SMTP, it is certainly a
> mail address, for SMS a phone number or an alphanumeric sender tag.
> Saying :priority must be defined as in RFCs relevant to e-mail makes
> sense for SMTP, but not neccessarily for SMS.

Hm, but that rather misses the point of :priority.  It's not meant to specify
some channel-specific priority setting, but to define the priority of the
notification itself.  It's saying, "It is very important (or normal importance
or low importance) that this notification be sent to the user."  That importance
might be used in some way to determine how (or whether) to perform the
notification.

Suppose, for instance, we have a notification mechanism that is able to
determine "how busy" I am.  That mechanism might decide to match the
notification's priority my busy status, informing me only of high-
priority notifications if I am "very busy", of all notifications if I am
"not busy at all", and so on.

Alternatively, some notification mechanism might know, per user, of a set
of different ways that different users could be notified, and it might use
the importance of the notification to decide which to use.  (This use-case
certainly argues for more than three levels.  On the other hand, I can't
imagine how more than a few choices could reasonably be coded into a script.)

It certainly COULD be used to set the value of an X-Priority header for
an email-based notification, if the mechanism decided to define that.  But
that's not basically what it's there for.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Michael Haardt | 7 Dec 2005 11:53
Picon

Re: values of notify ":priority" tag


On Tue, Dec 06, 2005 at 02:28:37PM -0500, Barry Leiba wrote:
> Suppose, for instance, we have a notification mechanism that is able to
> determine "how busy" I am.  That mechanism might decide to match the
> notification's priority my busy status, informing me only of high-
> priority notifications if I am "very busy", of all notifications if I am
> "not busy at all", and so on.

So that's what :priority is about: A second channel to the Sieve
implementation, besides the one that is used to set/manage a filter,
which tells the filter notify backend how to behave.  Looking at it that
way, of course I would prefer to change the filter, depending on the busy
status, but that may not always be possible if the busy status is detected
in another medium without a channel back to Sieve filter management.

Of course I could pass the priority as attribute of the notification
and let whatever receives notifications filter them.  So we still have
notification method specific priorities there, although not to specify
the quality of notification service, but the importance of notifications
to the recipient.

Which notification method is meant to make use of this feature and how
would it be implemented? Or are there implementations already?

Michael
Permalink | Reply | 2 comments |

Gmane