Sorry for the late reply, but I sent this previously with a sender
that's not subscribed to the list.
:o)
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.
Ok :o)
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.
Good point, I'm fine with this.
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.
I think if phone numbers are supplied, then the implementation SHOULD raise a
compile error if the supplied string is not valid. If no phone number is
supplied then the implementation SHOULD try use a default, and if this is not
available then the implementation SHOULD notify the user of the error but MUST
NOT fail the execution of the script. I had a look to see what was specified
in the vacation draft, but didn't find any comments relating to what I think
are similair issues.
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.
Ok :o) And if more than the limit are specified, then this would be a compile
error?
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.
Ok, I guess when the time comes we'll need to find it and reference it.
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)?
The :limit parameter I was proposing was meant to apply after any character set
encoding of the message. I'm not familiar with IA5, I had hoped we could just
pipe UTF8 and then truncate at some appropriate point. So I'm not sure in what
way your proposed :parts differs to my :limit?
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.
I wasn't actually proposing we standardize the default message format, just
describing what I was going to use, but that is an interesting idea :o) That
could make your sieve action just:
sms;
If we are to offer a standard, then maybe we should just drop the "To" as well,
as in the vast majority of cases I'd imagine users will know who the message
was sent to.
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.
:o)
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.
Reminds me of an old post that I can't find just now todo with gathering
statistics about how long various extensions were taking so as to limit the
capabilities of scripts...
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.
I'm still dreaming of the day when phone numbers don't exist in the user domain
at all, and rather we move completely over to using the
localpart(_at_)domainname format for email, post, phone, sms, fax. I'm told
the model in the US is that the recipient pays for receiving an SMS, and I'm
amazed to hear that it works! Apparently you can disable SMS from certain
senders as a way of protecting against error/mallicious use.
Thanks for the comments!
Nigel