Re: subject: and method: / Re: Working Group Last Call on draft-

Dilyan Palauzov wrote:

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