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

[<Zoltan.Ordogh at nokia.com>]

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:Ben.Last at emccsoft.com] 
>Sent: 09 August, 2006 11:36
>To: Gang Liang; lemonade at ietf.org
>Subject: RE: [lemonade] some questions in 
>draft-ietf-lemonade-notifications-03
>
>Gang Liang [mailto:lianggang79 at huawei.com] wrote on 09 August 2006
>04:04:
>>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.
>
>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.
>
>>I think it's a waste to provide acknowledgments for all of the 
>>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" <randy at qualcomm.com> wrote:
>>>  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?
>
>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
>>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?
>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
>
>_______________________________________________
>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