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

Re: retrying to send notifications

2007-01-29 11:58:52


Hello,

>   SHOULD ignore the notification and not retry indefinitely.

means that the notification service is unreliable:

Not only are some notification services unreliable, some, including some SMS
variants, provide no way to determine if the notification was ever delivered.

if an SMS is to be
sentfrom the mail server to an sms gateway, and there is a temporary
problem, the suggestion sais that it shall not be retired. But the
user may rely on receiving the notifications.

If so the more fool they. I'm sorry, the issue of end users placing unwarranted
faith in inherently unreliable services is not a problem we should, or can, be
trying to solve here.

I will also point out that no amount of retrying will get a notification
through when the end device is switched off or otherwise unable to receive the
notification. In fact retrying too often will in quite a few cases cause
overall service reliability to drop precipitously.

What about including expire: parameter and saying that the
implementation shall not try after the message has expired (thus
removing indefinetely)?

Exactly what is an implementation supposed to do with such a parameter? Even in
the very restricted subcase of SMS, there are many possible implementation
approaches. For example, an obvious way for an email system to send a
notification to SMS is through an email gateway. This would presumably leverage
the existing queuing capabilites of the email system. The expire parameter
could in theory be respected by the email system, but once the notification is
passed through the gateway to SMS there may or may not be a way to pass the
parameter on to the other side. And if a receipt is requested (assuming the
email gateway even supports making such a request), the task of coordinating
that receipt to the original request goes far beyond anything most
implementations are likely to want to do.

As another example, suppose the sieve implementation is prepared to speak SMPP
to an SMSC. For some types of messages you can specify stuff like number of
retries or expiration date. But not for others, including what SMS calls
notifications. (I'm actually not entirely sure whether it makes sense for a
sieve notify to generate an SMS notification, but it certainly sounds
reasonable.) You can also ask for a delivery receipt, but now you're back to
the receipt correlation problem. (You can also poll using the SMS query
primitive, but this is frowned upon.)

The elephant in the corner in all this is the need for one or more additional
queues. System admins don't like queues - every one we require implementations
to have is another thing they have to continuously monitor, which in turn
increases operational costs. Further exacerbating the problem is when the queue
has a different format or interface than existing queues on the system,
requiring different/additional tools, training, etc. (This last is why
leveraging an existing email gateway to SMS, even one with limited
capabilities, may prove to be a lot more popular than people might initially
believe.)

And this is just SMS. There are all sorts of other ways to send notifications,
each with its own peculiarities.

The bottom line is that while I would have no problem with defining such a
parameter, we realistically cannot mandate that implementations actually
support it if we define it. And this will be true even if the underlying
notification service supports expiration dates, or retries, or whatever. And
saying MUST or SHALL isn't going to help: All it will do is force some
implementations into incomliance, which IMO is a bad thing.

                                Ned

P.S. I should also mention that since our implementation has full a SMPP
implementation that leverages our existing queuing facilities we probably won't
have a problem implementing this, in the SMS case at least. But I suspect
we're an unusual case.

<Prev in Thread] Current Thread [Next in Thread>