Session Initiation Protocol (SIP) Event Package for Content Push Delivery

Push service are usually based on information preference expressed in advanced, in a sort of Publish/Subscribe model. A client might "subscribe" to various information "channels". Whenever new content is available on one of those channels the server would push that information out of the user. Nowadays many applications depend on being able to get content delivered on by a an supporting network service on a scheduled and non scheduled delivery model based on the networks knowledge rather then a trial and error model as provided by a pull model. Specifically service that needs real time information as stock market updates or earthquake alerts relies on a working push model. This specification define the scenarios and requirements necessary to use SIP in a Push service. In particular it shows what is necessary to define/extend in sip to let applications on the client subscribe to events in the network, how those events can be delivered and what type of content can be delivered by them.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and indicate requirement levels for compliant implementations.

This section provides an overview of the push and how other protocols or technology solves the problem.

WAP Push is implemented in all mobile clients and the base for carring content and update applications on the mobile client e.g. MMS, location services, device management etc. A Push Initiator(PI) is the actor that holds the original content. It communicates with a Push Proxy Gateway (PPG) using the Push Access Protocol (PAP). The PPG uses the Push Over-The-Air (OTA) Protocol typically SMS to deliver the push content to the client. PAP is based on standard Internet protocols; XML is used to express the delivery instructions, and the push content can be any MIME media type. Also HTTP based delivery exists but it has not really taken off as an alternative.

This is a popular technique in the WEB environment. The client uses http and requests a web page over a TCP connection, the server returns the data as slowly as possible, trying to maintain an open connection for as long as possible. The problem with this solution is that it requires a TCP connection to be open for each application expecting a push to be delivered at sometime in the future, this may course a resource problem in the network.

The BOSH protocol defines a mechanism to efficiently transport arbitrary content over HTTP in both directions between a client and server. It make use of multiple synchronous HTTP request/response pairs without requiring the use of polling or asynchronous chunking. BOSH is largely used in the development of Web Applications that require both "push" and "pull" communications. This mechanism requires only one HTTP connection to be open between the User Agent and the Server.

A Push Application requests push events from a Push server. A Push Application MAY request from more then one Push Server. A push server delivers content directly by imbedding small content into the notification itself or indirectly by supporting content indirection to one or more pushes clients.

There is a need for a push content model in the SIP environment to create the possibility to support a view where the network, not the client, has the knowledge about content availability and thereby need to take the delivery decisions to push content to the client. Currently such a mechanism is missing in SIP. In the mobile environment a push mechanism, WAP Push, has been very successful due to strong support for the standard gining the ability for any mobile application to take advantage of a generic push capability. In the fixed environment does such a standard not exist, instead do the market relay on different implementations of delaying the HTTP response or pure pull models. A common push model for fixed and mobile environment will benefit all parties. The proposed push specification in this document allows for a Service / Content Providers to at a low cost feed content updates into an application. It will also solve one of our current problem with the current need to create a new event package for each new service type something that in realty is undo able is it exists an endless number of possible services. This proposal provides a push model based on SUBSRIBE / NOTIFY model, as this will provide the best model to ensure the required functionality. A push model based on MESSAGE will be to complex as it needs to meet the requirements of a push service e.g. need support of GRUU and additional subscription to a Reg-event package. Using INVITE / MSRP on the other hand will provide an overhead when the content is small or content indirection is used. The proposal will cover the push delivery mechanism and how add and remove resource to the push service but not any application specific services as for example subscription. This will allow for example for: SIP applications to get content updates directly or indirectly without the need to implement other protocol. Non SIP application that don’t want or can’t have a TCP connection (reverse Ajax) open during the whole time the terminal is connected to the network.

This section specifies the push delivery framework. It provides the requirements push delivery stages and presents the associated security requirements. It supports two push delivery stages – enrollment and content delivery

The describes how SIP User Agents can discover sources. TBD

The specified in this document requires an application to initiate push delivery by explicitly request and register for Push events. It also requires one or more Push Servers which provides the push data. The processes that lead an application to obtain push content, can be explained in three stages, termed the profile delivery stages. Push Initiating: the process by which an application initiates the push delivery, and if successful, enrolls with one or more Push servers capable of providing push content. A successful enrollment is indicated by a notification with the accepted push resources that will be delivered in the push events in the form of (contents or content indirection information). Depending on the request, this could also eventually results in a subscription to notification of profile changes. Push Content Retrieval: the process by which a application retrieves push contents, if the push enrollment was successful. Change Notification: the process by which an application is notified of any changes to an enrolled profile. This may provide the application with modified profile data or content indirection information

The “push” Event Package defines a configuration framework, and allow for SIP applications to subscribe with a specific push event deliveries on an application server. The “push” event package specified in this document proposes and specifies an event package according to The Push Agent uses the app profile type to subscribe to content for Push Application s. The oma-app profile allows a Push Application to provide application-specific content. The oma-app profile type MUST follow the steps of Profile Enrolment and Profile Content Retrieval as defined in [SIP_UA_Prof]. Profile Enrolment is the process by which the Push Receiver Agent requests and if successful, subscribes with a Push Application corresponding to the Profile Delivery Server and the Profile Content Retrieval is the process by which an application on a device receives profile content.

This section defines a new SIP event package . The purpose of this event package is to send to subscribers notification of content updates to the subscribed push resources via content indirection [I-D.ietf-sip- content-indirect-mech] or directly in the body of the NOTIFY

The name of this package is "push ". This value appears in the Event header field present in SUBSCRIBE and NOTIFY requests for this package as defined in .

This package defines the event-app-id, dev-cap as new parameters for the event Header. The "event-app-id" parameter is used to indicate the token name of the push events the user agent wishes to obtain content or URIs for and to be notified of subsequent changes.

The following table shows the use of Event header parameters in SUBSCRIBE requests for the push event package:

Event header push -------------------- --------------- event-app-id mandatory dev-cap optional extension optional The Push Application and the Push AS MAY support extensions to the push event. Extensions MUST be registered via IANA. The Push Application and Push AS MUST ignore extensions that they do not support.

A Push Receiver or ApplicationMUST use the following format for oma-app: In the following ABNF, SEMI, , EQUAL and token are defined in .

EVENT-APP-ID SEMI DEV-CAP EVENT-APP-ID = “event-app-id” EQUAL event-app-id-list DEV-CAP = "OMA-UAProf" EQUAL quoted-string event-app-id-list = DQUOTE app *("," app) DQUOTE app = 1*(%x21 / %x23-2B / %x2D-7E) DQUOTE = %x22 ;as per section 6.1 of [RFC2234] OMA-UAProf = [OMA-UAProf]

This parameter is useful to the Push AS to affect the content provided. In some scenarios it is desirable to provide different services based upon this parameter. e.g., feature property X in a service may work differently on two versions of the same user agent. This gives the Push Application the ability to compensate for, or take advantage of, the differences. The DEV-CAP parameter is a parameter that provides an optional method of getting the device capabilities. When using DEV-CAP Parameter, the "vendor", "model" and "version" parameter SHOULD not be used. The DEV-CAP Parameter SHOULD use the [OMA-UAProf] reference to the device capabilities. If the DEV-CAP Parameter is not available the UA SHOULD include a User-Agent header containing the model, vendor, and version of the Push Application according to the rules and procedures of

The event-app-id parameter provides the reference for the Push Application / AS to the requested resources. The value of a event-app-id MUST be a URI [reference].

A successful SUBSCRIBE request results in a NOTIFY with either profile contents or a pointer to it (via Content Indirection). The SUBSCRIBE SHOULD be either authenticated, or transmitted over an integrity protected SIP communications channel.

To initiate Push Enrolment the Push Receiver agent sends a SIP SUBSCRIBE with the with the event header set to push. During the push Enrolment the Push Application sends a SIP SUBSCRIBE, optionally including the specific applications and versions being requested using the "event-app-id" parameter. The event-app-id parameter MAY contain one or more Application Resource Identifiers. The Push AS MUST respond with its supported Application Resource Identifiers in the event-app-id parameter of the push event in the confirming NOTIFY message.

The Push Application only subscribes to one application (app1), and supports UAProf. The Push AS supports app1.

SUBSCRIBE sip:user-aor@example.com SIP/2.0: Event: push;resource-type=event-app-id="app1"; dev-cap= "http://wap.company.com/UAProf/model.xml" NOTIFY Event: push; event-app-id =”app1” The Push Application only subscribes to one application (app1), and does not support UAProf. The Push AS supports app1.

SUBSCRIBE sip:user-aor@example.com SIP/2.0 Event: push; event-app-id =”app1” NOTIFY Event: push; event-app-id="app1” * The Push Application subscribes to multiple applications (app1, app2 and app3), and supports UAProf. The Push AS supports app1, app2, and app3.

SUBSCRIBE sip:user-aor@example.com SIP/2.0 Event: push;event-app-id="app1, app2, app3"; dev-cap= "http://wap.company.com/UAProf/model.xml" NOTIFY Event: push; event-app-id="app1, app2, app3” * The Push Application subscribes to multiple applications (app1, app2 and app3), and does not support UAProf. The Push AS supports app1, app2.

SUBSCRIBE sip:user-aor@example.com SIP/2.0 Event: push;event-app-id=" app1, app2, app3"; NOTIFY Event: push; event-app-id="app1, app2”

A successful Push Enrollment may result in continuous delivery of notifications to the Push Receiver Agent. The Push Application MUST only include exactly one value referring to the targeted Application Resource Identifier in the event-app-id parameter in the NOTIFY.

This package defines no new use of the SUBSCRIBE request body.

It is recommended that default subscription duration be 86400 seconds (one day).

The Accept header of the SUBSCRIBE MUST support the MIME type message/external-body indicating support for content indirection the Push AS SHOULD use content indirection [I-D.ietf-sip-content-indirect-mech] in the NOTIFY body for providing the profiles. When delivering push content via indirection the push AS MUST include the Content-ID MIME header described in [I-D.ietf-sip-content-indirect-mech] for each profile URI. This is to avoid unnecessary download of the profiles. The Content-Type MUST be specified for each URI. For minimal interoperability, the profile delivery server MUST support the "http:" and "https:" URI schemes for content indirection. Other URI schemes MAY also be provided in the content indirection. However the security considerations are define for content indirection using HTTP and HTTPS. Other protocols MAY be supported for content indirection, but are out of scope of this document. The NOTIFY body MAY include the actual content itself. The header of the NOTIFY MUST then include the Content-Length and Content-Type headers indicating size and type of the content.

This Event package allows the creation of only one dialog as a result of an initial SUBSCRIBE request as described in section 4.4.9 of . It does not support the creation of multiple subscriptions using forked SUBSCRIBE requests.

There are two IANA considerations associated with this document, SIPEvent Package and SIP configuration profile types. These are outlined in the following sub-sections.

This specification registers a new event package as defined in [RFC3265]. The following information required for this registration:

Package Name: push Package or Template-Package: This is a package Published Document: RFC XXXX Persons to Contact: New event header parameters: profile-type (Note to RFC Editor: Please fill in XXXX with the RFC number of this specification) The following table illustrates the additions to the IANA SIP Header Field Parameters and Parameter Values: (Note to RFC Editor: Please fill in XXXX with the RFC number of this specification)

Predefined Header FieldParameter Name Values Reference ---------------------------- --------------------------------- Event profile-typeYes[RFCXXXX]

The security considerations listed in SIP events , which the Push mechanism extends, apply in entirety. In particular, authentication and message integrity SHOULD be applied to subscriptions with the Push extension.