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.

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.

Table of Contents

1.  Introduction
2.  Definitions and Document Conventions
3.  Overview
    3.1.  WAP (Wireless Application Protocol) Push
    3.2.  Web
        3.2.1.  Reversed Ajax
        3.2.2.  Bidirectional-streams Over Synchronous HTTP (BOSH)
4.  Use Cases
5.  Motivation Scenarios
6.  Push Delivery Framework
7.  Discovery of Push AS
8.  Push delivery stages
9.  The “push” event package (Normative)
    9.1.  Event Package Definition
    9.2.  Event Package Name
    9.3.  Event Package Parameters
    9.4.  Event parameters
    9.5.  Parameters format
    9.6.  Dev-cap
    9.7.  Event-app-id
10.  Push AS Processing of SUBSCRIBE Requests
11.  Push Enrollment
    11.1.  Initiation of a Push Enrollment
    11.2.  The Profile Enrollment Confirmation
    11.3.  Content Push
12.  SUBSCRIBE Bodies
13.  Subscription Duration
14.  NOTIFY Bodies
15.  Deployment considerations
    15.1.  Support for NATs
    15.2.  Handling of Forked Requests
    15.3.  Rate of Notifications
16.  IANA Considerations
    16.1.  SIP Event Package
17.  Security Considerations
18.  References
    18.1.  Normative References
    18.2.  Informative References
§  Authors' Addresses

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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [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.

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] (Paterson, I., Smith, D., and P. Saint-Andre, “Bidirectional-streams Over Synchronous HTTP (BOSH),” February 2007.) 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 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] (Channabasappa, S., “A Framework for Session Initiation Protocol User Agent Profile Delivery,” February 2010.) describes how SIP User Agents can discover sources.

TBD

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] (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.)

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.

9.1.  Event Package Definition

This section defines a new SIP event package [RFC3265] (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.). 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] (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.).

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] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.).

	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] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.)

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.

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, 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.

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] (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.). 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)

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

17.  Security Considerations

The security considerations listed in SIP events [RFC3265] (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.), 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

18.2. Informative References

Authors' Addresses