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

From: Randall Gellens <[email-masked]>
Date: Fri, 4 Aug 2006 18:04:42 -0700

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), &quot;push.shared&quot; is defined as 
> an attribute of in-band notifications (not the attribute of outband 
> notifications) while in the first example in 10.4 
> &quot;push.shared&quot; is regarded as the attribute of outband 
> notifications.
>
>  Why? Maybe &quot;push.shared&quot; 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.

>  Question 2:
>
>  In 10.3
>
>  &quot;limit.priv&quot; = &quot;size=&quot; nz-number  | 
> &quot;total=&quot; 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.

>  Question 3:
>
>  In 10.3:
>
>  &quot;push.priv&quot; = &quot;push&quot; / &quot;pull&quot;
>
>  ;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.  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.

>  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.

>  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).

-- 
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: "Ben Last" <[email-masked]>
Date: Tue, 8 Aug 2006 09:03:02 +0100

From: Randall Gellens [mailto:[email-masked]] 
Sent: 05 August 2006 02:05

>> (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?
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.

>> through MMS channel. If it's possible, maybe we could define such an 
>> attribute for outband notification.
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).

>> for per-notification and the messaging system should repeat the same 
>> notification (not send the following notifications) until receive the

>> acknowledgment for the notification?

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