|This is retired content. This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.|
An SL message has the following life cycle only if the device security policy accepts this type of message.
The following is the life cycle of an SL message if the device security policy accepts this type of message:
- The Push Initiator (network) instructs the Push Proxy Gateway
to push an SL notification to the device by using the Push Access
Protocol. The Push Initiator creates the SL XML file with an
appropriate URI to the new service or update.
- The Push Proxy Gateway translates the XML file into WBXML, and
then sends the SL to the device by using the Push OTA Protocol.
Usually, Short Message Service (SMS) is the transmission channel.
- The device receives the SL notification and automatically
retrieves content from the server identified by the URI. Depending
actionattribute of the notification, the content is
retrieved immediately and then the new content is run (action
execute-low), or the content is retrieved immediately and
then placed in cache (action level:
If multiple SL notifications are received, they are processed in the order that they were received.
If content download fails, then the process is ended and the user does not receive a notification of the failure.
- If the content is placed in cache, an e-mail message is
generated that contains a hyperlink to the content. If the new SL
notification has the same
hrefvalue as a previously existing SL notification, the
newly cached content replaces the old content and the old e-mail
message is replaced with a new e-mail message.
Note: The Expires header should be contained in the loaded cache content. If the Expires header does not exist, the SL e-mail message does not expire automatically.