Sorry for the late reply, but I sent this previously with a sender
that's not subscribed to the list.
On Wed, Feb 02, 2005 at 02:21:49AM -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.
It may be easier to specify different actions than different extensions
to notify, at least current extension specifications make me think so.
So I don't mind to split things up.
we should therefore have something more along these lines:
Syntax: sms [":recipient" <recipient-numbers: string-list>]
[:limit <number>] <message: string>
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.
As long as that's not a "SHOULD try", it is fine with me. Enforcing a new
mailbox property in order to use this extension would not be nice at all.
So what if no number is specified, either explicit or implicit? Should
the action be ignored or cause the script to fail? The same question
arises on invalid number strings. I vote for ignoring invalid numbers
and actions without any number at all.
If present, specifies the target number, and it
can also be a list of numbers if more than one recipient is desired.
Please let the implementation limit the maximum amount of specified
recipients or sms actions.
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.
I think that must be a MUST. :) I am sure the TON/NPI for the
international numbers you described is defined by a standard that could
be referenced here, I just don't know which one.
The message is a string, whereby variable expansion is also
permitted. The limit is the maximum number of SMS messages that the
server can send. Given that each message typically has a cost associated
with it, the limit by default will be whatever produces the least cost
which in today?s terms is 1 message (140 bytes) but may change in the
future.
Over here, up to 160 octets do fit in a single message. I think that
the EUR currency sign is encoded in two octets, though. The character
set is IA5, so we have to specify what happens to unicode characters that
can not be translated to IA5. I am used to gateways just dropping them.
Of course you could apply the length after IA5 translation, but how
about specifying the cost in number of messages (:parts)?
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>
I prefer this:
From <sender-address> To <recipient-address>:
<Subject>\r\n<body>
I would like to allow the implementation to use a different default
format. In case it has access to a language mailbox property, it should
be allowed to send a message in the users native language by default.
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.
Agreed.
There are two remaining issues: Rate limiting and security. I suggest
a new extension which specifies a condition for rate limiting, e.g.
named token buckets, to keep that out of sms. It may be useful to forward
mail to expensive gateway addresses as well. The sms/notify extension
should not offer builtin rate limiting. With concern to security: The
implementation SHOULD enforce that SMS are only sent to verified numbers.
Otherwise, one typo suffices to annoy someone else like hell, apart
from letting him read part of your mail.
Michael