Subject: Re: subject: and method: / Re: Working Group Last Call on draft-ietf-sieve-notify-05.txt

From: Michael Haardt <[email-masked]>
Date: Wed, 03 Jan 2007 15:23:13 +0100

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

---

From: "Nigel Swinson" <[email-masked]>
Date: Wed, 3 Jan 2007 16:28:47 -0000

> 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

---

From: "Aaron Stone" <[email-masked]>
Date: Wed, 3 Jan 2007 17:22:35 -0000

> What is the utility of using notify with email?  Why not just use redirect

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

---

From: "Nigel Swinson" <[email-masked]>
Date: Wed, 3 Jan 2007 17:49:03 -0000

> its Received headers, hence the thorny issues with catching message loops)

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

> it were an email. In a non-privacy-centric situation, perhaps a lot of

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

---

From: "Aaron Stone" <[email-masked]>
Date: Wed, 3 Jan 2007 20:30:19 -0000

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

> 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

---

From: "Nigel Swinson" <[email-masked]>
Date: Thu, 4 Jan 2007 00:01:17 -0000

> They even seem to suggest that the subject would be hardcoded in the

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

---

From: Michael Haardt <[email-masked]>
Date: Thu, 04 Jan 2007 15:56:02 +0100

>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

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 18 Jan 2007 19:45:54 +0000

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

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