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

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

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