Network Working Group M. Dolly Internet-Draft AT&T Intended status: Standards Track S. Loreto Expires: September 7, 2009 Ericsson K. Bogestam March 6, 2009 Session Initiation Protocol (SIP) Event Package for Content Push Delivery draft-mdolly-sipping-push-01 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 7, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Dolly, et al. Expires September 7, 2009 [Page 1] Internet-Draft Content Push Delivery over SIP March 2009 Abstract This document specifies an event package for content push delivery protocol over SIP. The purpose is to allow an application on a UA to subscribe to updates to its own application events containing either content or references to the content. This document describes how content can be pushed out to an application by the use of push events. A new SIP event package is defined for notification of push events for content delivery. Dolly, et al. Expires September 7, 2009 [Page 2] Internet-Draft Content Push Delivery over SIP March 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Definitions and Document Conventions . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. WAP (Wireless Application Protocol) Push . . . . . . . . . 4 3.2. Web . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2.1. Reversed Ajax . . . . . . . . . . . . . . . . . . . . 5 3.2.2. Bidirectional-streams Over Synchronous HTTP (BOSH) . . 5 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Motivation Scenarios . . . . . . . . . . . . . . . . . . . . . 5 6. Push Delivery Framework . . . . . . . . . . . . . . . . . . . 6 7. Discovery of Push AS . . . . . . . . . . . . . . . . . . . . . 6 8. Push delivery stages . . . . . . . . . . . . . . . . . . . . . 7 9. The "push" event package (Normative) . . . . . . . . . . . . . 7 9.1. Event Package Definition . . . . . . . . . . . . . . . . . 8 9.2. Event Package Name . . . . . . . . . . . . . . . . . . . . 8 9.3. Event Package Parameters . . . . . . . . . . . . . . . . . 8 9.4. Event parameters . . . . . . . . . . . . . . . . . . . . . 8 9.5. Parameters format . . . . . . . . . . . . . . . . . . . . 8 9.6. Dev-cap . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.7. Event-app-id . . . . . . . . . . . . . . . . . . . . . . . 9 10. Push AS Processing of SUBSCRIBE Requests . . . . . . . . . . . 9 11. Push Enrollment . . . . . . . . . . . . . . . . . . . . . . . 10 11.1. Initiation of a Push Enrollment . . . . . . . . . . . . . 10 11.2. The Profile Enrollment Confirmation . . . . . . . . . . . 10 11.3. Content Push . . . . . . . . . . . . . . . . . . . . . . . 11 12. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . . . 11 13. Subscription Duration . . . . . . . . . . . . . . . . . . . . 11 14. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . . . 11 15. Deployment considerations . . . . . . . . . . . . . . . . . . 12 15.1. Support for NATs . . . . . . . . . . . . . . . . . . . . . 12 15.2. Handling of Forked Requests . . . . . . . . . . . . . . . 12 15.3. Rate of Notifications . . . . . . . . . . . . . . . . . . 12 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 16.1. SIP Event Package . . . . . . . . . . . . . . . . . . . . 12 17. Security Considerations . . . . . . . . . . . . . . . . . . . 13 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 18.1. Normative References . . . . . . . . . . . . . . . . . . . 13 18.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Dolly, et al. Expires September 7, 2009 [Page 3] Internet-Draft Content Push Delivery over SIP March 2009 1. Introduction 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. 2. Definitions and Document Conventions 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 [RFC2119] and indicate requirement levels for compliant implementations. 3. Overview This section provides an overview of the push and how other protocols or technology solves the problem. 3.1. WAP (Wireless Application Protocol) Push 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. Dolly, et al. Expires September 7, 2009 [Page 4] Internet-Draft Content Push Delivery over SIP March 2009 3.2. Web 3.2.1. Reversed Ajax 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. 3.2.2. Bidirectional-streams Over Synchronous HTTP (BOSH) The BOSH [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. 4. Use Cases 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. 5. Motivation Scenarios 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 Dolly, et al. Expires September 7, 2009 [Page 5] Internet-Draft Content Push Delivery over SIP March 2009 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. 6. Push Delivery Framework 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 7. Discovery of Push AS The [I-D.ietf-sipping-config-framework] describes how SIP User Agents can discover sources. TBD Dolly, et al. Expires September 7, 2009 [Page 6] Internet-Draft Content Push Delivery over SIP March 2009 8. Push delivery stages 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 9. The "push" event package (Normative) 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 [RFC3265] 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. Dolly, et al. Expires September 7, 2009 [Page 7] Internet-Draft Content Push Delivery over SIP March 2009 9.1. Event Package Definition This section defines a new SIP event package [RFC3265]. 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 9.2. Event Package Name 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 [RFC3265]. 9.3. Event Package Parameters 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. 9.4. Event parameters 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. 9.5. Parameters format A Push Receiver or ApplicationMUST use the following format for oma- app: In the following ABNF, SEMI, , EQUAL and token are defined in [RFC3261]. Dolly, et al. Expires September 7, 2009 [Page 8] Internet-Draft Content Push Delivery over SIP March 2009 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] 9.6. Dev-cap 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 [RFC3261] 9.7. Event-app-id 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]. 10. Push AS Processing of SUBSCRIBE Requests 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. Dolly, et al. Expires September 7, 2009 [Page 9] Internet-Draft Content Push Delivery over SIP March 2009 11. Push Enrollment 11.1. Initiation of a Push Enrollment 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. 11.2. The Profile Enrollment Confirmation 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, Dolly, et al. Expires September 7, 2009 [Page 10] Internet-Draft Content Push Delivery over SIP March 2009 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" 11.3. Content Push 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. 12. SUBSCRIBE Bodies This package defines no new use of the SUBSCRIBE request body. 13. Subscription Duration It is recommended that default subscription duration be 86400 seconds (one day). 14. NOTIFY Bodies 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. Dolly, et al. Expires September 7, 2009 [Page 11] Internet-Draft Content Push Delivery over SIP March 2009 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. 15. Deployment considerations 15.1. Support for NATs 15.2. Handling of Forked Requests 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 [RFC3265]. It does not support the creation of multiple subscriptions using forked SUBSCRIBE requests. 15.3. Rate of Notifications 16. IANA Considerations There are two IANA considerations associated with this document, SIPEvent Package and SIP configuration profile types. These are outlined in the following sub-sections. 16.1. SIP Event Package 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) Dolly, et al. Expires September 7, 2009 [Page 12] Internet-Draft Content Push Delivery over SIP March 2009 Predefined Header FieldParameter Name Values Reference ---------------------------- --------------------------------- Event profile-typeYes[RFCXXXX] 17. Security Considerations The security considerations listed in SIP events [RFC3265], which the Push mechanism extends, apply in entirety. In particular, authentication and message integrity SHOULD be applied to subscriptions with the Push extension. 18. References 18.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. 18.2. Informative References [BOSH] Paterson, I., Smith, D., and P. Saint-Andre, "Bidirectional-streams Over Synchronous HTTP (BOSH)", XSF XEP 0124, February 2007. [I-D.ietf-sipping-config-framework] Channabasappa, S., "A Framework for Session Initiation Protocol User Agent Profile Delivery", draft-ietf-sipping-config-framework-15 (work in progress), February 2008. Dolly, et al. Expires September 7, 2009 [Page 13] Internet-Draft Content Push Delivery over SIP March 2009 Authors' Addresses Martin Dolly AT&T 200 Laurel Ave Middletown, NJ, US Phone: Email: mdolly@att.com Salvatore Loreto Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: salvatore.loreto@ericsson.com Kent Bogestam Sweden Email: kent.bogestam@cumbari.com Dolly, et al. Expires September 7, 2009 [Page 14]