Internet Engineering Task Force Internet Draft Nomura/Schulzrinne Fujitsu/Columbia U. draft-nomura-mmusic-img-notify-01.txt July 18, 2005 Expires: January 2006 SIP Event Notification for Internet Media Guides 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 is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 a "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (C) The Internet Society (2005). 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], Nomura/Schulzrinne [Page 1] Internet Draft IMG Notify July 18, 2005 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. 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. Nomura/Schulzrinne [Page 2] Internet Draft IMG Notify July 18, 2005 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. 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]. +----------+ +------------+ | 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 18, 2005 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. 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 Nomura/Schulzrinne [Page 4] Internet Draft IMG Notify July 18, 2005 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. 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. Nomura/Schulzrinne [Page 5] Internet Draft IMG Notify July 18, 2005 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 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. Nomura/Schulzrinne [Page 6] Internet Draft IMG Notify July 18, 2005 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 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 Envelope The IMG envelope would reference or carry some application-specific metadata, and the envelope would support the maintenance of the application-specific metadata, which may also serve the metadata relationships determined by the data model(s) used. The IMG envelope is independent from the IMG transport protocol. There is no standard format for the IMG envelope yet. However, XML based format [8] and MIME based format are candidates for it. [8] defines essential description format for IMG envelope parameters such as version, reference, and validation using XML. On the other hand, the MIME based format has to be defined to support these parameters to meet the IMG requirements. When it will Nomura/Schulzrinne [Page 7] Internet Draft IMG Notify July 18, 2005 successfully reuse the existing MIME headers or define new headers, the cost to implement the IMG envelope may be less than xml based format. In either case, the IMG envelope will be independent from an IMG transport protocol. Therefore, this document does not assume any non-standard IMG envelope format. 6 Example Message Flow 6.1 Example MIME Header This section uses example MIME based description for IMG envelope in order to explain how the protocol works. As mentioned in Section 5, the standard IMG envelope format is still developing. Consequently, this example does not mean this protocol is subject to the MIME based IMG envelope. This section introduces four example MIME headers. Content-Type: application/xml Content-Type indicates a format of the IMG metadata description. If IMG metadata is described by an xml based format, application/xml is used. If SDP describes IMG metadata, application/sdp is appropriate. Content-ID: major.minor The IMG Envelope supports delta information between initial IMG metadata and update IMG metadata. Initial IMG metadata has certain version number described by "major" number. Update IMG metadata is also described by "minor" number. Expires: "valid until" IMG metadata may have period of validity. The MIME "Expires" header can be applicable to this purpose. IMG metadata may require "valid from" information. In this case, new MIME header will be defined to support this period. This example just uses "Expires" header. This example assume that this field value is defined by the RFC 1123[9]-date format. Nomura/Schulzrinne [Page 8] Internet Draft IMG Notify July 18, 2005 Content-Location: "metadata URI" "Metadata URI" identifies original IMG metadata. For instance, it may be URN as a name space or URL providing IMG metadata. 6.2 Example Flows When an IMG receiver needs to subscribe IMG metadata, it sends subscribe message to an IMG Sender (F1). If the sender accept this request, it sends the reply message (F2). After that message, the sender sends initial IMG metadata to the receiver (F3) and the receiver acknowledges the initial IMG metadata (F4). After a while, when metadata changes, the sender notifies this to the receiver (F5) and the receiver acknowledges it (F6). IMG Receiver IMG Sender | F1 SUBSCRIBE | |------------------>| | F2 200 OK | |<------------------| | F3 NOTIFY | |<------------------| | F4 200 OK | |------------------>| | | | |<-- Update metadata | | | F5 NOTIFY | |<------------------| | F6 200 OK | |------------------>| F1 SUBSCRIBE receiver.com->sender.com SUBSCRIBE sip:img@sender.com SIP/2.0 Via: SIP/2.0/TCP host1.receiver.com;branch=z9hG4bKnashds7 To: From: ;tag=xfg9 Call-ID: 7070@host1.receiver.com CSeq: 15024 SUBSCRIBE Max-Forwards: 70 Event: img Contact: Expires: 300 Content-Length: 0 Nomura/Schulzrinne [Page 9] Internet Draft IMG Notify July 18, 2005 F2 200 OK sender.com->receiver.com SIP/2.0 200 OK Via: SIP/2.0/TCP host1.receiver.com;branch=z9hG4bKnashds7 ;received=192.0.2.2 To: ;tag=ffd2 From: ;tag=xfg9 Call-ID: 7070@host1.receiver.com CSeq: 15024 SUBSCRIBE Event: img Expires: 300 Contact: Content-Length: 0 F3 NOTIFY sender.com-> receiver.com NOTIFY metadata@host.receiver.com SIP/2.0 Via: SIP/2.0/TCP host2.sender.com;branch=z9hG4bKna998sk From: ;tag=ffd2 To: ;tag=xfg9 Call-ID: 7070@host1.receiver.com Event: img Subscription-State: active;expires=599 Max-Forwards: 70 CSeq: 3487 NOTIFY Content-Type: application/xml Content-ID: 2798.8208 Expires: Mon, 25 Jul 2005 08:03:55 GMT Content-Location: http://sender.com/ID/2798 Content-Length: ... F4 200 OK receiver.com-> sender.com SIP/2.0 200 OK Via: SIP/2.0/TCP host2.sender.com;branch=z9hG4bKna998sk ;received=192.0.2.2 From: ;tag=ffd2 To: ;tag=xfg9 Call-ID: 7070@host1.receiver.com CSeq: 3487 NOTIFY Nomura/Schulzrinne [Page 10] Internet Draft IMG Notify July 18, 2005 F5 NOTIFY sender.com -> receiver.com NOTIFY sip:metadata@host.receiver.com SIP/2.0 Via: SIP/2.0/TCP host2.sender.com;branch=z9hG4bKna998sl From: ;tag=ffd2 To: ;tag=xfg9 Call-ID: 7070@host1.receiver.com CSeq: 3488 NOTIFY Event: img Subscription-State: active;expires=543 Content-Type: application/xml Content-ID: 2798.8344 Expires: Mon, 25 Jul 2005 14:00:00 GMT Content-Location: http://sender.com/ID/2798 Content-Length: ... F6 200 OK receiver.com-> sender.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.receiver.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-08, Internet Engineering Task Force, July 1804. 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 11] Internet Draft IMG Notify July 18, 2005 [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] R. Walsh, J-P. Luoma, J. Peltotalo, S. Peltotalo, and J. Greifenberg, "The IMG Envelope," Internet Draft draft-walsh-mmusic-img-envelope-03, Internet Engineering Task Force, Jun. 2005. Work in progress. [9] R. Braden., "Requirements for Internet Hosts -- Application and Support", RFC 1123, Internet Engineering Task Force, Oct. 1989. 9 Authors' 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 12] Internet Draft IMG Notify July 18, 2005 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2005). 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Nomura/Schulzrinne [Page 13]