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