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

Hi Randall Gellens and ben,

Thank you for your reply.
I combined the comments from both of you (comments from ben surrounded with
double [ben]----) and gave some other comments inline.

----- Original Message -----
From: "Randall Gellens" <randy at qualcomm.com>
To: "Gang Liang" <lianggang79 at huawei.com>; <lemonade at ietf.org>
Sent: Saturday, August 05, 2006 9:04 AM
Subject: Re: [lemonade] some questions in
draft-ietf-lemonade-notifications-03

>I haven't seen any replies to your questions. Here are my views.
>
>
> At 1:48 PM +0800 7/27/06, Gang Liang wrote:
>
>> Questions 1:
>>
>> In 10.2 (Provision Entries), "push.shared" is defined as an
>> attribute of in-band notifications (not the attribute of outband
>> notifications) while in the first example in 10.4 "push.shared"
>> is regarded as the attribute of outband notifications.
>>
>> Why? Maybe "push.shared" should be defined as an attribute of
>> outband notifications too.
>
> I have concerns about the concept of using mailbox annotations for this
> purpose. For one thing, it seems to be have problems in the case where
> users have multiple devices.
>
In 10.2 "push.shared" is defined as an attribute of in-band notification
while in the example in 10.4 it's regarded as the attribute of outband
notification.
Maybe it's because there is a typo in the example or some other mistakes.
>
>> Question 2:
>>
>> In 10.3
>>
>> "limit.priv" = "size=" nz-number |
>> "total=" nz-number
>>
>> ;the maximum number of bytes to send in notification payloads or the
>> total number of messages to send. Both per-day
>>
>> 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.
>
[ben]-----------------------------
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.
[ben]--------------------------------
I agree.
>> Question 3:
>>
>> In 10.3:
>>
>> "push.priv" = "push" / "pull"
>>
>> ;specifies whether the client expects new messages to be pushed via the
>> unsolicited FETCH response defined above, or via client issued FETCH in
>> response to an EXISTS response.
>>
>> 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.
[ben]-----------------------------------------
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).
[ben]-----------------------------------------
>More specifically on your question of including the
> message itself in the notification, I think that is feasible with small
> messages, but not large ones. Also, to the extent that notifications are
> unreliable, this would only be an ancillary service; that is, the client
> may get messages via notifications, but if this fails for any reason the
> client will get them normally.

Your views make sense.
Using MMS to push email or notifications is just an example. What I want to
talk about is the feasibility and rationality of pushing an email via
outband notification. E.g. if the client is GPRS online and the email is
very urgent, maybe it's more appropriate to push the email directly in the
notification instead of pushing a wake-up notification that makes the client
to create a connection with server to fetch the email.
>
>> Question 4:
>>
>> In 13.8
>>
>> It MUST be possible to provide acknowledgment by the target to the
>> messaging system or to repeat notification until such an acknowledgement
>> is provided if supported by the notification channel.
>>
>> 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.
[ben]-------------------------------------------
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.
[ben]--------------------------------------------
If the messaging system can not receive the acknowledgment for a
notification, maybe it's because the client is unavailable or the
notification is lost or some other reasons. For the listed two reasons, the
approach may be different.
I think it's a waste to provide acknowledgments for all of the
notifications or to send repeated notifications.
>
>> If so, maybe it's more appropriate to send a notification after
>> determining that the client is online (e.g. according to presence status
>> of the client provided by presence enabler).
>
How do you think this approach?

Another question:
In 13.8: A client can recover all missing events next time it connects to
the server and the server MUST buffer the notifications and make them
available to the MUA when it comes back to the server.

Which notifications MUST the server buffer? All missing notifications or all
of the notifications since the last connection? If the notifications that
the server MUST buffer are all missing notifications, how the server
determine what notifications are missing? According to acknowledgment?

> --
> Randall Gellens
> Opinions are personal; facts are suspect; I speak for myself only
> -------------- Randomly-selected tag: ---------------
> I had a fortune cookie the other day and it said, "Outlook not
> so good." I said, "Sure, but Microsoft ships it anyway."
> --Tom Singer
>
> _______________________________________________
> lemonade mailing list
> lemonade at ietf.org
> https://www1.ietf.org/mailman/listinfo/lemonade
>

Regards,
Gang Liang