[Top] [All Lists]

Re: Working Group Last Call on draft-ietf-sieve-notify-05.txt

2006-12-19 11:10:59

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.