[Top] [All Lists]

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

2006-12-20 13:57:43

        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.

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


abstract "expire:"

Aaron Stone wrote:
On Tue, Dec 19, 2006, Michael Haardt <michael(_at_)freenet-ag(_dot_)de> said:

On Mon, Dec 18, 2006 at 11:29:31PM -0000, Aaron Stone wrote:
I recognize that the point of notifications is to provide "one-liner"
updates, but giving different names to the subject and body fields isn't
good, and then using the subject/body distinction present in xmpp vs. mail
in opposite ways isn't good, either.

I'm definitely bringing up more than a WGLC should. Oops.

If instead we had:

Usage: notify [":from" string]
           [":importance" <"1" / "2" / "3">]
           [":options" string-list]
           [":subject" string]
           [":message" string]
"method:" string
Let's forget about XMPP and mailto for a second, as notify is a generic
framework.  The question is: Do we view abstract notification messages
in general to be tagged with a subject, with a few real methods not
offering one (like SMS), or do we view them being untagged with a few
real methods offering one (like mailto)?

To me, a notification is the second.  Notes attached to the refridgerator
do not have a subject, neither do messages in IRC or SMS. ICQ I don't
know. (Comsat? Never mind. ;) We will find a bunch attributes more offered
by at least one real method, and that's exactly why we have ":options".

That's why I vote against introducing ":subject".  To me, the karma of
a message does not include a subject. ;)

I had written (but edited out of my email) that if the methods each have
some sort of "subject" field to specify, then it would make sense for the
base spec to provide it. If we intend for XMPP to be our gateway out to
IRC, SMS, ICQ, AOL, etc etc. then we'll have to discuss how to degrade
gracefully when the user gives a subject, regardless if by :subject or by
:option "subject=This is a Sieve Notification", and transmit the message
across the other networks.

Before the end of WGLC on the notify base spec, I would like to know what
issues we're leaving for ourselves in each of the method specs, so I think
this will be a key issue to make consistent across methods.

I am also still not so happy about the keyword and syntax differences vs.
vacation, but I can live with it.