Internet Engineering Task Force
Internet Draft Nomura/Schulzrinne
Fujitsu/Columbia U.
draft-nomura-mmusic-img-notify-00.txt
July 12, 2004
Expires: December 2004
SIP Event Notification for Internet Media Guides
STATUS OF THIS MEMO
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
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Abstract
This document specifies an update notification protocol for
Internet Media Guides (IMGs) using SIP event notification. The
mechanism achieves the timely delivery of IMGs and avoids that
IMG receivers have to poll for updates.
1 Introduction
Internet Media Guides (IMGs) [1] [2] provide and deliver structured
collections of multimedia descriptions expressed using SDP [3],
SDPng [4] or other description formats. They are used to describe
sets of multimedia services (e.g. television program schedules,
content delivery schedules) and refer to other networked resources
including web pages.
IMG metadata may be delivered to a potentially large audience, who
use it to join a subset of the sessions described, and who may need
to be notified of changes to the IMG metadata.
Nomura/Schulzrinne [Page 1]
Internet Draft IMG Notify July 12, 2004
Since content and its structure described by IMG metadata changes as
time elapses, an IMG receiver needs to be notified of changes
so that IMG metadata and content do not become stale.
This document defines an update notification protocol for IMGs
using SIP Event Notification framework [5], which satisfies
the IMG requirements [1] and matches the IMG framework [2].
The authors assume that SIP event is not a mechanism just for
a presence service, but applicable for many services such as IMGs.
As the IMG framework defines the IMG operations, an update notification
mechanism is necessary for scalable delivery. In addition, SIP event
satisfies IMG requirements with minimum implementation cost for
an unicast transport protocol, thus it provides necessary and
sufficient mechanism for the IMG update notification.
2 Terminology
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 [6].
Internet Media Guide (IMG): IMG is a generic term to describe
the formation, delivery and use of IMG metadata. The
definition of the IMG is intentionally left imprecise.
IMG Element: The smallest atomic element of metadata that can be
transmitted separately by IMG operations and referenced
individually from other IMG elements.
IMG Metadata: A set of metadata consisting of one or more IMG
elements. IMG metadata describes the features of multimedia
content used to enable selection of and access to media
sessions containing content. For example, metadata may
consist of the URI, title, airtime, bandwidth needed, file
size, text summary, genre and access restrictions.
IMG Delivery: The process of exchanging IMG metadata both in
terms of large scale and atomic data transfers.
IMG Sender: An IMG sender is a logical entity that sends IMG
metadata to one or more IMG receivers.
IMG Receiver: An IMG receiver is a logical entity that receives
IMG metadata from an IMG sender.
Nomura/Schulzrinne [Page 2]
Internet Draft IMG Notify July 12, 2004
3 Overview of Protocol Operations
3.1 IMG Operations and SIP Event Notification
This section shows basic protocol sequences when an IMG receiver
retrieves IMG metadata from an IMG sender and get notified of the
updates. As shown in Figure 1, the protocol operations between an
IMG receiver and IMG sender can be described by IMG operations
detailed in the IMG framework [2].
This document assumes that there are simple mapping rules between
IMG operations and SIP Event Notification mechanisms. A SIP
SUBSCRIBE is an instance of IMG SUBSCRIBE and a SIP NOTIFY is an
instance of IMG NOTIFY. This document does not define a protocol
instance for an IMG QUERY and IMG RESOLVE. We anticipate that the
IMG QUERY-RESOLVE operation will be a trivial usage of HTTP,
although other transport protocol options may be beneficial to
consider too.
+----------+ +------------+
| IMG | | IMG |
| Sender | | Receiver |
+----------+ +------------+
| |
|<----------IMG QUERY -----------|
| |
|----------IMG RESOLVE---------->|
| |
: :
(time passes)
: :
| |
|<---------IMG SUBSCRIBE---------|
| |
|-----------IMG NOTIFY---------->|
: :
(time passes)
: :
|-----------IMG NOTIFY---------->|
| |
Figure 1: Update Notification Sequence Example
Nomura/Schulzrinne [Page 3]
Internet Draft IMG Notify July 12, 2004
3.2 Overview of SIP Event Notification
SIP [7] is a text-based request/response protocol. A SIP request
consists of a request-line, header field and message body like HTTP.
A SIP response also consists of a status-line, header field and body.
SIP Event has the same feature as SIP but SIP Event needs only two
messages, SUBSCRIBE and NOTIFY, to notify an event to subscribers.
Since the protocol intends to do this, it does not require SIP
messages to establish a session.
Fig. 2 shows basic protocol operations in SIP Event.
Protocol details are shown in section 4.
IMG Receiver IMG Sender
|-----SUBSCRIBE---->| Request state subscription
|<-------200--------| Acknowledge subscription
|<------NOTIFY----- | Return current state information
|--------200------->|
|<------NOTIFY----- | Return current state information
|--------200------->|
Fig. 2 SIP Event Notification Sequence
There are several reasons to use SIP Event for metadata update
notification.
1. Simple: SIP Event consists of just two messages to satisfy
IMG requirement.
2. Standard: Since SIP Event is used by many applications in
presence and call services, there are a lot of
implementations based on it as a standard specification.
SIP Event is carefully designed to make it secure.
3. Extensible: SIP Event can take advantage of SIP functions
and services such as a proxy and so on.
4. Independent of transport protocols: SIP runs on top of
several different transport protocols. Therefore, it is
possible to use various transports such as UDP, TCP and
multicast.
Nomura/Schulzrinne [Page 4]
Internet Draft IMG Notify July 12, 2004
4 Protocol Details
4.1 Initialize
An IMG receiver MUST send a SUBSCRIBE request to an IMG sender in
order to prepare to receive a subsequent update notification from
the IMG sender.
The SUBSCRIBE request includes identity information in its headers
defined by SIP Events framework. As defined in SIP, To, From, Call-
ID, Event and Contact header can be used to identify a session
between an IMG receiver and sender. Each parameter in the headers
depends on the implementations.
In this phase, the SUBSCRIBE request MAY contain a body indicating
what metadata status will be subscribed.
The name of this package is "img". This header also appears in
NOTIFY requests.
If the SUBSCRIBE request is not related to existing sessions and the
IMG sender can authenticate the request successfully, the IMG sender
sends a 200 (OK) response to the IMG receiver. If the IMG sender can't
authenticate or accept the request, the IMG sender sends a 4xx response
and does not send a NOTIFY request.
An IMG sender MUST authenticate all subscription requests. This
authentication can be done using any of the mechanisms defined in SIP
and SIP Events.
After sending the SUBSCRIBE response, the IMG sender sends a NOTIFY
request immediately to the same IMG receiver. The request contains an
URI indicating a metadata location or metadata. Metadata indicated by
URI or contained in the body MUST describe the latest full state when
the NOTIFY request is sent. "Content-Type:" header in the NOTIFY
request MUST indicate a data type of the body.
The body in NOTIFY request MUST contains a version number and a
timestamp. The version number increases by exactly one for each
NOTIFY message as defined in SIP Event. The time stamp indicates
latest modified time of metadata status.
When the IMG receiver receives the request, the IMG receiver tries to
retrieve IMG metadata specified in the body. If the IMG receiver gets it
successfully, it sends 200 (OK) response to the IMG sender. If not, the
IMG receiver sends 4xx response.
4.2 Update Notification
Nomura/Schulzrinne [Page 5]
Internet Draft IMG Notify July 12, 2004
When metadata changes and it affects an existing subscription,
IMG sender sends a NOTIFY request on a session related to the metadata
status. The request body SHOULD contain metadata delta location or
metadata delta. The format of metadata delta is discussed in section
6.
When the IMG receiver receives the request, the IMG receiver tries to
obtain delta information specified in the body. If the IMG receiver
successfully gets it and updates metadata, it sends 200 (OK) response
to the IMG sender. If not, the IMG receiver sends 4xx response.
4.3 Session Keep Alive
At any time before a subscription expires, the IMG receiver may send a
SUBSCRIBE request to the IMG sender. The IMG sender sends a SUBSCRIBE
response and a NOTIFY request with delta information to communicate
up-to-date metadata status.
If the IMG receiver receives the NOTIFY message which includes the same
timestamp as the previous NOTIFY message, the IMG receiver does not
have to obtain delta information. In this case, an IMG sender sends it
just for a confirmation of the metadata status as an immediate
response for a SUBSCRIBE request.
If the timestamp is updated, the IMG receiver MUST obtain new delta in
the same way as receiving an update notification.
This mechanism can be applicable not only to refresh the timer but
also to confirm the current metadata status.
4.4 Polling metadata status
If an IMG receiver does not want to receive an update notification, an
IMG receiver may poll metadata status to send a SUBSCRIBE with an
"Expires" of 0.
4.5 Confirming the status of IMG receiver
If an IMG sender needs to confirm the current status of an IMG receiver
which subscribes metadata status, it may send NOTIFY request
including a body which indicates a current delta information and wait
a NOTIFY response from the IMG receiver. When the IMG sender receives the
response with 200 (OK), the IMG sender confirms that the IMG receiver's
status is up-to-date. If not, the IMG sender can decide that the
IMG receiver has stale metadata.
4.6 Timer Expiration
Nomura/Schulzrinne [Page 6]
Internet Draft IMG Notify July 12, 2004
Expiration time depends on the system. If the system requires short
duration to guarantee metadata coherency, it should be a small value.
In some system, a connection between an IMG receiver and IMG sender is not
persistent but sporadic. In this case, IMG receiver may require the
long expiration time such as 1 day or 1 week.
If an IMG receiver receives NOTIFY request on the session which already
has been terminated because the timer has expired, the IMG receiver
SHOULD try to subscribe it again.
4.7 Invalid update notification
If an IMG receiver receives invalid NOTIFY message such as a
discontinuous version number or CSeq, the IMG receiver SHOULD close the
session and restart the session from Initialize step. As a result,
the IMG receiver can obtain latest full metadata states.
5 IMG Descriptions
5.1 IMG Metadata and IMG Envelope
IMG Metadata and IMG Envelope may be defined in another document
and referred in this document.
5.2 IMG Delta
IMG Delta description may be defined in another document.
Delta encoding in HTTP [8] may be applicable to describe
differences between two IMG Metadata. While the algorithm requires
"diff" mechanism, it is likely to be simple and extensible.
XPath [9] may be applicable to describe differences for XML based
IMG metadata.
Nomura/Schulzrinne [Page 7]
Internet Draft IMG Notify July 12, 2004
6 Example Message Flow
IMG Receiver IMG Sender
| F1 SUBSCRIBE |
|------------------>|
| F2 200 OK |
|<------------------|
| F3 NOTIFY |
|<------------------|
| F4 200 OK |
|------------------>|
| |
| |<-- Update metadata
| |
| F5 NOTIFY |
|<------------------|
| F6 200 OK |
|------------------>|
F1 SUBSCRIBE subscriber.com->notifier.com
SUBSCRIBE sip:metadata@notifier.com SIP/2.0
Via: SIP/2.0/TCP host1.subscriber.com;branch=z9hG4bKnashds7
To: <sip:metadata@notifier.com>
From: <sip:metadata@subscriber.com>;tag=xfg9
Call-ID: 7070@host1.subscriber.com
CSeq: 15024 SUBSCRIBE
Max-Forwards: 70
Event: img
Contact: <sip:metadata@host.subscriber.com>
Expires: 300
Content-Length: 0
Nomura/Schulzrinne [Page 8]
Internet Draft IMG Notify July 12, 2004
F2 200 OK notifier.com->subscriber.com
SIP/2.0 200 OK
Via: SIP/2.0/TCP host1.subscriber.com;branch=z9hG4bKnashds7
;received=192.0.2.2
To: <sip:metadata@notifier.com>;tag=ffd2
From: <sip:metadata@subscriber.com>;tag=xfg9
Call-ID: 7070@host1.subscriber.com
CSeq: 15024 SUBSCRIBE
Event: img
Expires: 300
Contact: <sip:metadata@host2.notifier.com>
Content-Length: 0
F3 NOTIFY notifier.com-> subscriber.com
NOTIFY metadata@host.subscriber.com SIP/2.0
Via: SIP/2.0/TCP host2.notifier.com;branch=z9hG4bKna998sk
From: <sip:metadata@notifier.com>;tag=ffd2
To: <sip:metadata@subscriber.com>;tag=xfg9
Call-ID: 7070@host1.subscriber.com
Event: img
Subscription-State: active;expires=599
Max-Forwards: 70
CSeq: 3487 NOTIFY
Content-Type: text/xml
Content-Length: ...
Version: 1
Last-Modified: Mon, 24 Jun 2004 08:03:55 GMT
Metadata-URI: http://metadata.notifier.com/program1/02080355.xml
F4 200 OK subscriber.com-> notifier.com
SIP/2.0 200 OK
Via: SIP/2.0/TCP host2.notifier.com;branch=z9hG4bKna998sk
;received=192.0.2.2
From: <sip:metadata@subscriber.com>;tag=ffd2
To: <sip:metadata@notifier.com>;tag=xfg9
Call-ID: 7070@host1.subscriber.com
CSeq: 3487 NOTIFY
Nomura/Schulzrinne [Page 9]
Internet Draft IMG Notify July 12, 2004
F5 NOTIFY notifier.com -> subscriber.com
NOTIFY sip:metadata@host.subscriber.com SIP/2.0
Via: SIP/2.0/TCP host2.notifier.com;branch=z9hG4bKna998sl
From: <sip: metadata@notifier.com>;tag=ffd2
To: <sip:metadata@subscriber.com>;tag=xfg9
Call-ID: 7070@host1.subscriber.com
CSeq: 3488 NOTIFY
Event: img
Subscription-State: active;expires=543
Max-Forwards: 70
Content-Type: text/plain
Content-Length: ...
Version: 2
Last-Modified: Mon, 24 Jun 2004 09:19:31 GMT
Delta-URI: http://delta.notifier.com/program1/02091931.txt
F6 200 OK subscriber.com-> notifier.com
SIP/2.0 200 OK
Via: SIP/2.0/UDP notifier.example.com;branch=z9hG4bKna998sl
;received=192.0.2.2
From: <sip:metadata@subscriber.com>;tag=ffd2
To: <sip:metadata@notifier.com>;tag=xfg9
Call-ID: 7070@host1.subscriber.com
CSeq: 3488 NOTIFY
Content-Length: 0
7 Security Considerations
TBD
8 References
[1] Y. Nomura, R. Walsh, J-P. Luoma, H. Asaeda, and H. Schulzrinne,
"A framework for the usage of Internet media guides," Internet Draft
draft-ietf-mmusic-img-framework-07, Internet Engineering Task Force,
June 2004. Work in progress.
[2] Y. Nomura, R. Walsh, J-P. Luoma, J. Ott, and H. Schulzrinne,
"Requirements for Internet Media Guides," Internet Draft
draft-ietf-mmusic-img-req-07, Internet Engineering Task Force, June
2004. Work in progress.
Nomura/Schulzrinne [Page 10]
Internet Draft IMG Notify July 12, 2004
[3] M. Handley and V. Jacobson, "SDP: session description protocol,"
RFC 2327, Internet Engineering Task Force, Apr. 1998.
[4] D. Kutscher, J. Ott, and C. Bormann, "Session description and
capability negotiation," Internet Draft draft-ietf-mmusic-sdpng-07,
Internet Engineering Task Force, Oct. 2003. Work in progress.
[5] A. B. Roach, "Session initiation protocol (sip)-specific event
notification," RFC 3265, Internet Engineering Task Force, June 2002.
[6] S. Bradner, "Key words for use in RFCs to indicate requirement
levels," RFC 2119, Internet Engineering Task Force, Mar. 1997.
[7] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J.
Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session
initiation protocol," RFC 3261, Internet Engineering Task Force, June
2002.
[8] J. Mogul, B. Krishnamurthy, F. Douglis, A. Feldmann, Y. Goland,
A. van Hoff, and D. Hellerstein, "Delta encoding in HTTP," RFC 3229,
Internet Engineering Task Force, Jan. 2002.
[9] A. Berglund, et al., XML Path Language (XPath) 2.0,
W3C, Nov. 2003
9 Author's Addresses
Yuji Nomura
Fujitsu Laboratories Ltd.
4-1-1 Kamikodanaka, Nakahara-ku, Kawasaki 211-8588
Japan
Email: nom@flab.fujitsu.co.jp
Henning Schulzrinne
Dept. of Computer Science
Columbia University
1214 Amsterdam Avenue
New York, NY 10027
USA
Email: schulzrinne@cs.columbia.edu
Nomura/Schulzrinne [Page 11]