On Wed, 2005-02-02 at 02:21 +0000, Nigel Swinson wrote:
It seems to me that the notify extension is trying to do too much in
supporting notification by email, SMS or indeed any arbitrary
notification mechanism. It was pointed out quickly how many complex
internationalization issues you have to deal with when composing
emails, but you have completely different concerns when dealing with
SMS messages, so I'm not sure it makes sense to bundle them. I think
we should therefore have something more along these lines:
Syntax: sms [":recipient" <recipient-numbers: string-list>] [:limit
<number>] <message: string>
as a general point, I think it's not worthwhile to standardise
specifically on SMS. it's not _that_ universal, and it's also being
phased out by MMS, which is just good old MIME documents (transported by
HTTP for the last hops, but SMTP for routing).
a limit on message length is a good option to add, but it shouldn't be
based on SMS chunk size.
The :recipient tag specifies the target phone numbers to send this SMS
to. If not present, the implementation should try to send the SMS to
the owner of the script where the number is held by the sieve
implementation, ie a mailbox property. If present, specifies the
target number, and it can also be a list of numbers if more than one
recipient is desired. Each phone number must begin with a + and
include the country code to ensure that the script will work
regardless of location of server/script.
is it important to trap this at compile-time?
The proposal in draft-ietf-sieve-notify-02.txt is this:
Syntax: notify [":method" string]
[":id" string]
[":options" 1*(string-list / number)]
[<":low" / ":normal" / ":high">]
["message:" string]
I'm thinking it's got too many things in it which are trying to be
super-generic to cover all uses (:method/:id/:options), but in actual
fact we'll quickly regret this and prefer specific extensions for
notifying through different channels with well defined and well
documented arguments.
you may be right. separate extension names for each notify method may
be the way to go. how many methods are we talking about? we've been
loosely discussing a Jabber notification method where I work. (SMS/MMS
costs money :)
Which brings me on to variables. Each of these different notification
types, and also the vacation extension to a certain degree, has the
need to author messages, and likely include sections of the triggering
message. So suppose I want to author what I think is a fairly
reasonable SMS which looks like this:
[To:<recipient-addresss>From:<sender-address>] <Subject>\r\n<body>
One way to get his is using the proposed $name$ variables which seem
pretty ugly next to what we've worked so hard on with the variables
extension, and also is pretty inflexible. If we use the variables
extension as is, then we could do this:
if header :matches “*” “To” {
set “Recipient” “${1}”
}
if header :matches “*” “From” {
set “Sender” “${1}”
}
if header :matches “*” “Subject” {
set “Subject” “${1}”
}
set “Message” “[To: {$Recipient} From: {$Sender}] {$Subject}”
(you'll have to switch the arguments, it's header COMPARATOR header-name
pattern)
(I note that my intuative use of * won't work cos * in matches
according to variables is non-greedy, yet * with regex is greedy, but
I thought I'd do that deliberately to make you think...)
greediness doesn't come into play here, as :matches "*" == :regex
"^(.*)$"
This seems like a lot of work to do something pretty "standard".
agreed.
I wonder if it would make sense for us to add associative arrays
containing entries of specific interest to the sieve script author.
[...]
Then I would end up with an array like this:
This would produce an array with these entries:
$HEADERS[‘Received’][0] = “from p01m168.mxlogic.net [bla bla] ”
$HEADERS[‘Received’][1] = “from unknown [208.184.76.39] [bla bla] ”
$HEADERS[‘Date’][0] = “Thu, 27 Jan 2005 09:56:56 -0800 (PST)”
$HEADERS[‘To’][0] = “Nigel(_dot_)Swinson(_at_)rockliffe(_dot_)com”
$HEADERS[‘From’][0] = “majordomo(_at_)vpnc(_dot_)org”
$HEADERS[‘Subject’][0] = “Welcome to ietf-mta-filters”
this is just a different syntax for:
${header.received.n1} = “from p01m168.mxlogic.net [bla bla] ”
${header.received.n2} = from unknown [208.184.76.39] [bla bla] ”
${header.date} = “Thu, 27 Jan 2005 09:56:56 -0800 (PST)”
(the variables draft doesn't allow the last component of the variable
name to be a number. I think that is an aspect we can change if we want
to, but it must be done now.)
anyhow, doing it via a namespace makes it more natural to present the
information in a parsed manner. e.g., you could have an
header.date.year == "2005" in addition.
(the variables draft allows header.date and header.date.year to
co-exist, as the namespace is defined as the bit before the last full
stop.)
--