wdiff draft-mdolly-sipping-push-00.txt draft-mdolly-sipping-push-01.txt

Network Working Group M. Dolly
Internet-Draft AT&T
Intended status: Standards Track K. Bogestam
Expires: April 30, 2009 S. Loreto
Expires: September 7, 2009 Ericsson
Oct 27, 2008

Framework for Content Push Delivery over the
K. Bogestam
March 6, 2009

Session Initiation Protocol (SIP)
draft-mdolly-sipping-push-00 Event Package for Content Push
Delivery
draft-mdolly-sipping-push-01

Status of this Memo

By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she

This Internet-Draft is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, submitted to IETF in accordance full conformance with Section 6 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 April 30, September 7, 2009.

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 a protocol 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. As part
of this framework, a A new SIP event package is defined for notification of push
events for content delivery.

Table of Contents

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

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.

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

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.

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

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.

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]. 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
[I-D.ietf-sipping-config-framework] 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.

Authors' Addresses

Martin Dolly
AT&T
200 Laurel Ave
Middletown, NJ,
US

Phone:
Email: mdolly@att.com

Kent Bogestam
Ericsson
Kistavaegen 27
Stockholm 164 80
Sweden

Email: kent.bogestam@ericsson.com

Salvatore Loreto
Ericsson
Hirsalantie 11
Jorvas 02420
Finland

Email: salvatore.loreto@ericsson.com

Full Copyright Statement

This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.

Kent Bogestam
Sweden

Email: kent.bogestam@cumbari.com