Subject: values of notify ":priority" tag

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 02 Dec 2005 16:44:36 -0700

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

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 03 Dec 2005 14:52:59 +0000

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)?

---

From: "Nigel Swinson" <[email-masked]>
Date: Mon, 5 Dec 2005 13:31:58 -0000

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 5 Dec 2005 13:06:01 -0600

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

Sorry, I wasn't here for that.

> "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 rigoro…

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

---

From: Michael Haardt <[email-masked]>
Date: Tue, 6 Dec 2005 09:40:18 +0100

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

---

From: "Nigel Swinson" <[email-masked]>
Date: Tue, 6 Dec 2005 12:33:42 -0000

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

> filled with methods that interface different media, inside and outside

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

---

From: Barry Leiba <[email-masked]>
Date: Tue, 06 Dec 2005 14:28:37 -0500

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

Which is why I've suggested, in my last editing pass (which Alexey now has,
and y'all haven't seen yet), to suggest changing it to ":importance",
rather than ":priority".

Of course, we still might decide that it's a bad idea, and take it out.  But
let's just be clear about why it's there in the first place, before we do that.

Barry

--
Barry Leiba, Pervasive Computing Technology  ([email-masked])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam

---

From: Michael Haardt <[email-masked]>
Date: Wed, 7 Dec 2005 11:53:10 +0100

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

---

From: Barry Leiba <[email-masked]>
Date: Wed, 07 Dec 2005 13:01:25 -0500

> in another medium without a channel back to Sieve filter management.

Right, exactly.

> and let whatever receives notifications filter them.

Yes, that's one way to handle them; that's the argument for having "mailto"
set "X-Priority", and having "XMPP" set "Priority" consistent with RFC 1327.
And that's certainly a valid thing to do with it.

> would it be implemented? Or are there implementations already?

We had an experimental notification mechanism here, which used user "context"
to determine how to notify the user.  It used the :priority in addition to
information the "context server" knew about the user to decide whether or not
to notify, and to pick the ultimate notification channel.

That sort of thing can't really be done in the Sieve script, so it makes
sense to give the notification mechanism as much information as we can,
so that it can do it.

Barry

---

From: Michael Haardt <[email-masked]>
Date: Wed, 7 Dec 2005 19:31:19 +0100

> sense to give the notification mechanism as much information as we can,

Cool.  For the first time, ":priority" (or ":importance", as you
suggested) makes perfect sense to me and I no longer think it should be
dropped from the notify framework, but described much better instead.

I wonder if there is a common denominator of X-Priority, XMPP, your
context server, syslog, usenet article scores and possibly other things
that do not address the quality of service, but importance of messages
to people.

Is importance a one-dimensional quantity? I have a feeling it isn't,
and if so, trying to describe it by a single numeric value will fail.
But that is just a feeling.

Michael

---

From: Dave Cridland <[email-masked]>
Date: Thu, 08 Dec 2005 15:17:55 +0000

> option is not just dropped, but that's me.

Which is an interesting point.

I can only think of three levels of priority, and it's not really 
priority at all.

1) I'd like to be told about this sort of message, at some point, if 
you can.

2) I need to be told about this message.

3) I absolutely must be made immediately aware of this message.

The trouble is, that no amount of priority twiddling will express 
this - the only place to express it is in what method is used.

This in turn makes me wonder whether we actually need an intermediate 
service which dispatches the notifications at some point in the 
future, which can be told how best to contact us, depending on the 
importance of us reacting to that notification.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

---

From: Michael Haardt <[email-masked]>
Date: Thu, 8 Dec 2005 17:26:31 +0100

On Thu, Dec 08, 2005 at 10:59:07AM -0500, Mark E. Mallett wrote:
> On Thu, Dec 08, 2005 at 03:17:55PM +0000, Dave Cridland wrote:
> > 
> That's certainly what I had assumed- especially when people were talking
> about things like the need to rate-limit notifications, or to be aware
> about the recipients state WRT to reception of notifications or
> priorities.  It would be natural to build that kind of logic into a
> seperate notification utility, not into a Sieve engine.
> 
> Making the priority value some opaque string makes sense to me too,
> or even pushing it off to one of the :attributes tag=value list
> elements that Michael Haardt was talking about.

Note I just changed my mind and now support keeping ":priority"
(Barry suggested to rename it to ":importance") in the generic
framework.

After thinking about it, I remembered to have wished for some time my
MUA knew something about importance of messages, like news readers often
offer as "scoring", although they use just a single number for that.

I miss a common approach to _values_ of importance, but now think it
is an important attribute that should be offered to implement by
all methods, thus it makes sense to have it as option in the framework.
Much like ":from".

Michael

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 08 Dec 2005 09:31:36 -0700

Dave Cridland wrote:

> 1) I'd like to be told about this sort of message, at some point, if you 
> can.
> 

Don't these levels map to "non-urgent", "normal", and "urgent" from RFC 
1327?

Peter

-- 
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Thu, 08 Dec 2005 17:49:08 +0100

> (Barry suggested to rename it to ":importance") in the generic

I was just going to suggest ":urgency" to get the idea more clearly
across when the message from Peter Saint-Andre ticked in :-)

(important things aren't always urgent.)
-- 
Kjetil T.

---

From: "Mark E. Mallett" <[email-masked]>
Date: Thu, 8 Dec 2005 10:59:07 -0500

mm

---

From: Michael Haardt <[email-masked]>
Date: Thu, 8 Dec 2005 18:01:55 +0100

> (important things aren't always urgent.)

I was thinking of importance and that it may not be one-dimensional, but
couldn't say why I felt that way.  Right, urgency is a second dimension
and it even has a name. :)

I am afraid someone may be able to name further dimensions, so instead of
adding ":urgency" as well, I suggest to allow non-numeric string values
for ":importance", or however that single that-stuff-matters-to-me-option
should be called.  But again, it's just a feeling there may be more.

Philosophy at IETF; who would have thought that.

Michael

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 08 Dec 2005 11:08:02 -0700

Kristin Hubner wrote:
> 
> On Dec 8, 2005, at 8:31 AM, Peter Saint-Andre wrote:
> 
>> Dave Cridland wrote:
>>
>> Don't these levels map to "non-urgent", "normal", and "urgent" from 
>> RFC 1327?
> 
> The RFC 1327 values relate to MTA processing priority -- how "quickly" 
> (relative
> to other messages) an MTA is supposed to try to deliver the messages, as in
> perhaps the MTA should try to delivery all "urgent" messages before 
> trying to
> delivery any "normal" or "nonurgent" messages (even if "normal" or 
> "nonurgent"
> messages have already been enqueued awaiting delivery).  The X.400 MTS 
> field
> that RFC 1327 suggests translating to and from an RFC 822 "Priority:" 
> header line
> value is not really intended as a field of user relevance at all.
> 
> In contrast, a header line such as "Importance" relates to what _users_ 
> think
> about a message -- that some message is especially important, or that it is
> desirable to display some message with some sort of "notice me" icon.  (And
> the discouraged Precedence: header line was sort of a ambiguous mess of 
> both
> -- perhaps part of the reason its use got discouraged?)
> 
>  From RFC 2076 (Internet Message Headers):
> 
>    Can be "normal", "urgent" or "non-   Priority:      RFC 1327, not for
>    urgent" and can influence                           general usage.
>    transmission speed and delivery.
> 
>    Sometimes used as a priority         Precedence:    Non-standard,
>    value which can influence                           controversial,
>    transmission speed and delivery.                    discouraged.
>    Common values are "bulk" and
>    "first-class". Other uses is to
>    control automatic replies and to
>    control return-of-content
>    facilities, and to stop mailing
>    list loops.
> 
>    A hint from the originator to the    Importance:    RFC 1327 and
>    recipients about how important a                    RFC 1911,
>    message is. Values: High, normal                    experimental
>    or low. Not used to control
>    transmission speed.
> 
> I would like to retain the distinction between, at a minimum, priority and
> importance, priority influencing transmission speed (when practical) while
> importance is an indication to be passed along to the end user (when
> practical).  Because while there is often overlap (and some defaulting may
> make sense), whether a message is "time critical" really is not the same
> thing as whether a message is "important".

Ah, OK, thanks for the clarification. No matter what we call it, I don't 
see a need for more than three levels of "importance": high, medium, and 
low.

Peter

---

From: Kristin Hubner <[email-masked]>
Date: Thu, 08 Dec 2005 10:04:17 -0800

to other messages) an MTA is supposed to try to deliver the messages, 
as in

In contrast, a header line such as "Importance" relates to what _users_ 
think
about a message -- that some message is especially important, or that 
it is
desirable to display some message with some sort of "notice me" icon.  
(And
the discouraged Precedence: header line was sort of a ambiguous mess of 
both
-- perhaps part of the reason its use got discouraged?)

I would like to retain the distinction between, at a minimum, priority 
and
importance, priority influencing transmission speed (when practical) 
while
importance is an indication to be passed along to the end user (when
practical).  Because while there is often overlap (and some defaulting 
may
make sense), whether a message is "time critical" really is not the same
thing as whether a message is "important".

Regards,

Kristin

---

From: Ned Freed <[email-masked]>
Date: Fri, 09 Dec 2005 14:24:57 -0800 (PST)

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

Perhaps, but it doesn't follow that the insufficiency was a lack of possible
values. As Kristin pointed out, there are various quite different semantics
associated with these fields. X-Priority in particular seems mostly to
be aligned with the X.400 concept of importance as opposed to priority, and
I've seen X-MSMail-Priority used in several different ways even among
Microsoft software.

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

This is also incorrect, I'm afraid. There may be little difficulty associated
with using lots of levels when all it does is order things, but that's not all
these fields are used for. The X.400 concept of priority, for example, affects
both processing priority and message timeouts. (Actually, this last may be more
a GOSIP thing than a pure X.400 thing - I no longer recall which of the many
specifications says what about it.) Each priority level ends up having a bunch
of settings associated with it, and that means there's real overhead associated
with having lots of levels.

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

I also have no problem with not having a general priority/importance parameter.
If we do have such a parameter we have to get it right, and that means the
reality of there being a limited number of levels available in lots of
environments has to be accomodated.

				Ned