ietf-mta-filters
[Top] [All Lists]

Re: Sieve-Notify and potential associative arrays.

2005-02-16 06:16:46

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