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: From: ;tag=xfg9 Call-ID: 7070@host1.subscriber.com CSeq: 15024 SUBSCRIBE Max-Forwards: 70 Event: img Contact: 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: ;tag=ffd2 From: ;tag=xfg9 Call-ID: 7070@host1.subscriber.com CSeq: 15024 SUBSCRIBE Event: img Expires: 300 Contact: 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: ;tag=ffd2 To: ;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: ;tag=ffd2 To: ;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: ;tag=ffd2 To: ;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: ;tag=ffd2 To: ;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]