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

From: Gang Liang <[email-masked]>
Date: Wed, 09 Aug 2006 11:04:09 +0800

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" <[email-masked]>
To: "Gang Liang" <[email-masked]>; <[email-masked]>
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), &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.
>
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
>>
>>  &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.
>
[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:
>>
>>  &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.
[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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/lemonade
>

Regards,
Gang Liang 

----------------------------------------------------
Lianggang
Huawei Technologies
Tel:+86 25 84676084
Mob:+86 13813998674
Fax:+86 25 84676060
Email:[email-masked]
---------------------------------------------------- 
_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: "Ben Last" <[email-masked]>
Date: Wed, 9 Aug 2006 09:36:18 +0100

Gang Liang [mailto:[email-masked]] wrote on 09 August 2006
>to create a connection with server to fetch the email.

I think, then, that one of the key factors is the amount of data you can
get into an outband notification.  You can fit 140 bytes into an SMS, so
there's not much room for more than a notification that events have
occurred.  You can fit far more into an MMS (with all the cost
implications) and if the client is SIP-addressible from the server over
something like IMS, you can push the whole email.  So one definition of
outband won't, of course, cover all.

However, I think that the decisions on (a) when to retrieve mail and (b)
how much to retrieve are better made by the client.  For example, if the
client can tell that the email is low-priority, or that it is in an area
where network access is slow and expensive, it may choose to retrieve
messages only once per hour, and to retrieve only the headers.  Or, if
it detects that it is in range of a usable wi-fi connection, and thus
has high-speed and low-cost access, it might choose to retrieve the
header and message text of new emails.  In the mobile phone environment,
I think there are many factors, which vary with time and location and
that are detectable only by the client, which might affect the client's
decisions about how to respond to the information that new messages (or
changes to messages) are available.

>notifications or to send repeated notifications.
OMA EMN, sends a timestamp, covers this, and Lemonade profile-bis-01
uses OMA EMN as the payload of a notification.  Thus the cost of a
missed message due to change A would be reduced, since the next message
sent due to change B would implicitly include the fact that change A had
occurred.  This lets the client make all the decisions (as above) and
avoids potential issues with duplication of notifications.

>"Randall Gellens" <[email-masked]> wrote:

Many presence systems allow the user to set their status as "offline"
(even though they're not really offline): the presence status is aimed
at other humans and gives the user's interruptability.  That may not be
appropriate for a server to use when determining whether to send new
mail notifications.

>In 13.8: "A client can recover all missing events next time it connects
to
>available to the MUA when it comes back to the server."
I wasn't going to respond to this since there are so many others far
better able and qualified on the list, but as I understand it, the
server may decide that the client has been away for too long and
terminate the session.  In this case, the client would not get a SESSION
response when it next connected and would have to perform a
state-comparison synchronization.  Thus the server does have the option
to avoid buffering if it becomes an excessive burden.

Regards to all
Ben
EMCC Software Ltd

---

From: <[email-masked]>
Date: Wed, 9 Aug 2006 11:57:16 +0300

Ben,
Why would anyone use MMS for notification? It it nothing more than a WAP Push (well, there is a bit more but from email notification point of view nothing useful). Why not use WAP Push right away (without all the hassle that comes with MMS)?

Best regards: Zoltán Ördögh
E-mail: zoltan dot ordogh at nokia dot com
Phone: +358 50 386 0566

>-----Original Message-----
>From: ext Ben Last [mailto:[email-masked]] 
>Sent: 09 August, 2006 11:36
>To: Gang Liang; [email-masked]
>Subject: RE: [lemonade] some questions in 
>I think, then, that one of the key factors is the amount of 
>data you can get into an outband notification.  You can fit 
>140 bytes into an SMS, so there's not much room for more than 
>a notification that events have occurred.  You can fit far 
>more into an MMS (with all the cost
>implications) and if the client is SIP-addressible from the 
>server over something like IMS, you can push the whole email.  
>So one definition of outband won't, of course, cover all.
>
>However, I think that the decisions on (a) when to retrieve 
>mail and (b) how much to retrieve are better made by the 
>client.  For example, if the client can tell that the email is 
>low-priority, or that it is in an area where network access is 
>slow and expensive, it may choose to retrieve messages only 
>once per hour, and to retrieve only the headers.  Or, if it 
>detects that it is in range of a usable wi-fi connection, and 
>thus has high-speed and low-cost access, it might choose to 
>retrieve the header and message text of new emails.  In the 
>mobile phone environment, I think there are many factors, 
>which vary with time and location and that are detectable only 
>by the client, which might affect the client's decisions about 
>how to respond to the information that new messages (or 
>OMA EMN, sends a timestamp, covers this, and Lemonade 
>profile-bis-01 uses OMA EMN as the payload of a notification.  
>Thus the cost of a missed message due to change A would be 
>reduced, since the next message sent due to change B would 
>implicitly include the fact that change A had occurred.  This 
>lets the client make all the decisions (as above) and avoids 
>potential issues with duplication of notifications.
>
>(even though they're not really offline): the presence status 
>is aimed at other humans and gives the user's 
>interruptability.  That may not be appropriate for a server to 
>use when determining whether to send new mail notifications.
>
>I wasn't going to respond to this since there are so many 
>others far better able and qualified on the list, but as I 
>understand it, the server may decide that the client has been 
>away for too long and terminate the session.  In this case, 
>the client would not get a SESSION response when it next 
>connected and would have to perform a state-comparison 
>synchronization.  Thus the server does have the option to 
>avoid buffering if it becomes an excessive burden.
>
>Regards to all
>Ben
>EMCC Software Ltd
>

---

From: <[email-masked]>
Date: Wed, 9 Aug 2006 14:21:51 +0300

>>Ben,
>>Why would anyone use MMS for notification? It it nothing more than a
>WAP Push (well, there is a bit more but from email 
>notification point of view
>>nothing useful). Why not use WAP Push right away (without all the
>hassle that comes with MMS)?
>
>I'd guess that it's because all the WAP-push-and-fetch 
>functionality is handled by the platform.  For example, on a 
>Symbian-based device, it's easy to write a watcher process 
>that will spot incoming MMS messages and process them, so from 
>the point of view of the programmer you get a messaging system 
>that will handle large messages as simply as SMS handles small 
>ones, without any additional hassle.  Sure, it's more complex 
>from the OS's point of view, but that's hidden from the 
>programmer.  Similarly, most message-service providers provide 
>APIs (over HTTP or RPC) that make sending MMS messages as easy 
>as sending SMSs.
Hmmm. You have a point about trying to make it as simple as sending
SMSes.
However, I feel that is is a waste of resources and bandwidth - I heard
it expressed from operators already (they are even reluctant to use Wap
Push and prefer SMS because it comsumes the least).
When You get an MMS, this goes down:
1. You get a Wap Push message to tell You that You have an MMS.
2. You do HTTP/GET to fetch the MMS Message.
3. You get the HTTP respnse that contains that the actual notification.
Now scale this up to a million user. This is the reason why I do not see
any reason why would anyone do MMS - it adds with way too much
signalling (and, consequently wait times) over the wireless network.
But, my understanding is that the client can decide which notification
medium to use (please correct if I am wrong), so one can choose to use
SMS, Wap Push, MMS, right?

---

From: "Ben Last" <[email-masked]>
Date: Wed, 9 Aug 2006 11:10:30 +0100

[email-masked] [mailto:[email-masked]] wrote on 09

>Why would anyone use MMS for notification? It it nothing more than a
WAP Push (well, there is a bit more but from email notification point of
view

I'd guess that it's because all the WAP-push-and-fetch functionality is
handled by the platform.  For example, on a Symbian-based device, it's
easy to write a watcher process that will spot incoming MMS messages and
process them, so from the point of view of the programmer you get a
messaging system that will handle large messages as simply as SMS
handles small ones, without any additional hassle.  Sure, it's more
complex from the OS's point of view, but that's hidden from the
programmer.  Similarly, most message-service providers provide APIs
(over HTTP or RPC) that make sending MMS messages as easy as sending
SMSs.

Regards
Ben
EMCC Software Ltd

---

From: "Ben Last" <[email-masked]>
Date: Wed, 9 Aug 2006 12:53:12 +0100

August 2006 12:22:
>My understanding is that the client can decide which notification
medium to use (please correct if I am wrong), so one can choose to use
SMS, Wap Push, MMS, right?
I'm not sure that would work in the real world (as opposed to the
standard).  It surely depends on whether the server has some way to send
SMS, MMS or WAP push messages.  That is, has the organization who have
installed and are running the server subscribed to a service that allows
them to send messages.  So the client can't arbitrarily choose a
notification medium.

Also: as far as I know there is no standard way to code up the sending
of an SMS.  Every messaging provider I've ever interfaced with has a
different way of doing it, so any server vendor would have to either
offer a set of different interfaces (and the number of these could be
very large) or expect the installation process to include coding up some
messaging-service-provider specific way to handle the messages.

Regards
Ben
EMCC Software Ltd

---

From: <[email-masked]>
Date: Wed, 9 Aug 2006 15:35:03 +0300

>Also: as far as I know there is no standard way to code up the 
>sending of an SMS.  Every messaging provider I've ever 
>interfaced with has a different way of doing it, so any server 
>vendor would have to either offer a set of different 
>interfaces (and the number of these could be very large) or 
>expect the installation process to include coding up some 
I think it only gets worse with MMS - especially that it has several
versions.