[Top] [All Lists]

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

2007-01-18 13:06:53

Dilyan Palauzov wrote:


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.

<Prev in Thread] Current Thread [Next in Thread>
  • Re: subject: and method: / Re: Working Group Last Call on draft-ietf-sieve-notify-05.txt, Alexey Melnikov <=