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

["Aaron Stone" <aaron@xxxxxxxxxxxxxx>]

On Mon, Dec 18, 2006, Alexey Melnikov <alexey.melnikov@xxxxxxxxx> said:

> Michael Haardt wrote:
> 
>>>Optional tagged arguments can appear in any order, but they must appear 
>>>before positional arguments.
>>>So if we switch to make the method argument positional, the usage 
>>>statement needs to be modified to become:
>>>
>>>   Usage:  notify 
>>>           [":from" string]
>>>           [":importance" <"1" / "2" / "3">]
>>>           [":options" string-list]
>>>           [":message" string]
>>>           string    
>>>
>>
>>If you write it as
>>
>>  <method: string>
>>
>>it looks much better.
>>
> I agree.
> 
>>But should this start a lengthy discussion
>>in the group, then never mind.
>>  
>>
> I would like to hear at least two other opinions in favor of keeping or 
> changing the current behavior.

I apologize for not being on top of this 1-2 months ago. This is so much
different than Vacation as to cause unreasonable confusion on the part of
end-users writing their own scripts. It is also different in xmpp vs.
mail.

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

Presumably the body would be [MAY be?] empty. 

>From draft-ietf-sieve-notify-xmpp-02:

   o  The XMPP <message/> stanza MAY include a <subject/> child element
      whose value is some configurable text indicating that the message
      is a Sieve notification.

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 

Basically that breaks every extant implementation, doesn't it.

Aaron