RE: [lemonade] some questions in draft-ietf-lemonade-notifications-03

["Ben Last" <Ben.Last at emccsoft.com>]

From: Randall Gellens [mailto:randy at qualcomm.com] 
Sent: 05 August 2006 02:05

>At 1:48 PM +0800 7/27/06, Gang Liang wrote:
>>  What's the benefit of limiting the total number of messages
>> (notifications) per-day? If the number of notifications sent that day

>> has reached the limit (e.g. 10 notifications per-day ) but then a
very 
>> important email arrives, what should the server do?
>I agree.  The issue of throttling is one that will need to be
addressed, but a simplistic per-day limit doesn't seem to be the way to
solve it.

I'd argue that throttling is a *client* issue, not a server issue, in
that the user is in more direct control of the mobile client and can
make decisions about incurring download costs.  For example, our client
allows a variety of options about when synchronizations take plae and
how messages and attachment are downloaded (on demand, in anticipation,
etc).  I don't know for sure what the situation is in the US, but in
Europe the data charges applicable can vary like crazy depending on
where one is, and it's awkward to have to change server settings as you
move from roaming zone to roaming zone.  And I absolutely agree with
Randall that a per-day limit is overly simplistic.

>>  Is it possible to push new messages via outband notifications? E.g. 
>> through MMS channel. If it's possible, maybe we could define such an 
>> attribute for outband notification.
>Personally, I don't see much benefit in using MMS to push mail or
notifications.

I agree; I certainly don't see any benefit over using SMS to do
notifications.  Right now, it costs a minimum of 30p (UK prices) to
originate an MMS via UK messaging providers (that price is a bulk one),
but SMS messages can cost as little as 3.5p (again, in bulk).  An SMS
gives enough space to send the basic values needed for an OOB
notification (EXISTS count, etc).

More to the point, though, on a flat-rate data plan there is no extra
cost to the user for receiving in-band notification of update events.
Even when data's charged by the megabyte the cost per in-band
notification is likely to be tiny.  The cost of an SMS or MMS is likely
to be several times more than the in-band cost, and it has to be borne
by the server operator (who may then have to find a way to pass it on to
the end-user).

>> Does it mean that the target (client) should provide acknowledgment 
>> for per-notification and the messaging system should repeat the same 
>> notification (not send the following notifications) until receive the

>> acknowledgment for the notification?
>This is what I think the document is saying, but personally I have
concerns with this approach.

And I'd point to the notes above about SMS/MMS costs here.  Personally
I'd worry about any system that might start sending repeated
notifications.  However, the receipt reporting for SMS messages is
usually extremely reliable, so it's possible to conclude with a high
degree of assurance that an SMS has reached the target device (not,
however, whether any software on the device has read the message).  That
would help reduce the need for an active client response.

Regards,
ben

--
lemonade mailing list
lemonade at ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade


_______________________________________________
lemonade mailing list
lemonade at ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade