[Top] [All Lists]

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

2006-12-15 08:08:30

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]

If you write it as

  <method: string>

it looks much better.  But should this start a lengthy discussion
in the group, then never mind.

How about:

   If the notification method is capable of transmitting a timestamp outside
   the textual message, it SHOULD include the timestamp.

But I am also thinking that implementations may include the timestamp in 
the textual message, if one is not specified. So maybe "outside the 
textual message" should be dropped.

I suggest to keep the SHOULD on timestamps as message properties, and
not say anything else.  SMS, for example, do not have timestamps really.
At least I don't see the timestamp of delivery to the SMSC, but of
delivery to the cell phone.  People will be of different opinion on
preferring a timestamp inside the SMS text.  I can't even agree upon
recommending to include one.

I think the security consideration is generally applicable to a wide 
range of notification mechanisms, but the second quoted sentence can be 
changed to start with "For example, ..."?

As long as we don't agree on how to resolve the issue for mailto,
I suggest to avoid it as example.  If you need an example of loops,
consider mails triggering SMS that cause phone calls, which when
being absent cause mails.