Internet Engineering Task Force Internet Draft Nomura/Schulzrinne Fujitsu/Columbia U. draft-nomura-cdi-mmusic-mupdate-00.txt June 24, 2002 Expires: November 2002 SIP Event Notification for Metadata Update Protocol STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 metadata using SIP event notification. This protocol improves metadata coherency and efficiency between content providers and receivers by up-to-date notifications when metadata changes. This protocol can also be applied to several systems such as a streaming video distribution system and a web content ditsribution system. 1 Introduction Metadata can describe content features and its structures of multimedia content and web pages. Metadata is a principal element for content providers or receivers to manage and distribute multimedia and web content [1]. It allows users to initiate streaming media sessions, schedule delivery of downloadable or multicast content or Nomura/Schulzrinne [Page 1] Internet Draft mupdate June 24, 2002 listen to live multicast sessions [2]. Since content and its structure described by metadata changes as time elapses, a content receiver needs to be notified of changes in order to avoid stale state of metadata and content. This document defines an update notification protocol for metadata using SIP Event Notification framework [3]. It satisfies the requirements for multimedia and web content management such as an update notification, session keep-alive, status confirmation and authentication of subscriber. In addition, using SIP framework, extensiblity and flexiblity is provided. This document also gives a guideline for metadata description and update information formats used in the protocol. The guideline includes candidate description formats and delta description methods. 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 [4]. Notifier: A notifier is a user agent which generates NOTIFY requests and receives SUBSCRIBE requests. Subscriber: A subscriber is a user agent which receives NOTIFY requests from notifiers and generates SUBSCRIBE requests. Session: An identical metadata state between a notifier and a subscriber. Delta: Differences between the latest metadata state and the previous state of metadata. 3 Overview of the content distribution system Elements of the System: This protocol is used in a content distribution system consists of at least two hosts, one is a content server and the other is a content client. Target Content: All content such as a multimedia streaming data, multimedia file, and Web content consists web pages. Three Transport Model: A content distribution system has three transports, (1) content transport, (2) metadata transport and (3) update notification (UN) transport. Nomura/Schulzrinne [Page 2] Internet Draft mupdate June 24, 2002 Content Server Content Client content |-------content data------>| Content Transport | | metadata |---------Request--------->| Metadata Transport |<--------Response---------| (e.g. HTTP) | | metadata or |<------notification-------| Update Notification delta |-------Acknowledge------->| Transport This protocol is used by Update Notification Transport but it can be used in Metadata Transport if required. 1. Content Transport This transport is used to transmit content in the system. Any existing transport mechanism can be applied. The transport is specified in metadata transmitted by Metadata Transport. This document does not require particular content transport. 2. Metadata Transport This transport is used to transmit metadata or delta information in the system. Any existing transport mechanism can be applied but the simplest transport is HTTP. The transport is specified and selected in UN transmitted by UN transport. This document assumes that Metadata transport does not provide Update Notification Transport. 3. Update Notification Transport This transport is used to transmit update notifications from a content server to a content client. When Request/Response protocol like HTTP is used in Metadata Transport and the system requires up-to-date content distribution, this transport is necessary. The problem of using HTTP for the metadata transport is an inefficient refresh mechanism by polling. The freshness of metadata has to be improved to send HTTP requests frequently but the frequent requests increase the load on the host receiving the unnecessary requests. The detail of this problem has been introduced in RUP requirements [5]. The update notification like this protocol and RUP activities aims to solve this problem. Nomura/Schulzrinne [Page 3] Internet Draft mupdate June 24, 2002 4 Overview of SIP Event Notification 4.1 Basic Protocol Operations SIP [6] 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. The following diagram shows basic protocol operations in SIP Event. Protocol details are shown in section 5. Subscriber Notifier |-----SUBSCRIBE---->| Request state subscription |<-------200--------| Acknowledge subscription |<------NOTIFY----- | Return current state information |--------200------->| |<------NOTIFY----- | Return current state information |--------200------->| There are several reasons to use SIP Event for metadata update notification. 4.2 Features of SIP Event Notification 1. Simple: SIP Event consists of just two messages to satisfy RUP requirement and Program guide requirement. 2. Standard: Since SIP Event is used by many applications in IMPP [7] 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 mupdate June 24, 2002 5 Protocol Details 5.1 Initialize First of all, a subscriber of metadata MUST send a SUBSCRIBE request to a notifier in order to prepare to receive a subsequent update notification from the notifier. 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 a subscriber and notifier. 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 "metadataupdate". This header also appears in NOTIFY requests. If the SUBSCRIBE request is not related to existing sessions and the notifier can authenticate the request successfully, the notifier sends a 200 (OK) response to the subscriber. If the notifier can't authenticate or accept the request, the notifier sends a 4xx response and does not send a NOTIFY request. A notifier 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 notifier sends a NOTIFY request immediately to the same subscriber. 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 subscriber receives the request, the subscriber tries to obtain metadata specified in the body. If the subscriber gets it successfully, it sends 200 (OK) response to the notifier. If not, the subscriber sends 4xx response. 5.2 Update Notification Nomura/Schulzrinne [Page 5] Internet Draft mupdate June 24, 2002 When metadata changes and it affects an existing subscription, notifier 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 subscriber receives the request, the subscriber tries to obtain delta information specified in the body. If the subscriber successfully gets it and updates metadata, it sends 200 (OK) response to the notifier. If not, the subscriber sends 4xx response. 5.3 Session Keep Alive At any time before a subscription expires, the subscriber may send a SUBSCRIBE request to the notifier. The notifier sends a SUBSCRIBE response and a NOTIFY request with delta information to communicate up-to-date metadata status. If the subscriber receives the NOTIFY message which includes the same timestamp as the previous NOTIFY message, the subscriber does not have to obtain delta information. In this case, a notifier sends it just for a confirmation of the metadata status as an immediate response for a SUBSCRIBE request. If the timestamp is updated, the subscriber 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. 5.4 Polling metadata status If a subscriber does not want to receive an update notification, a subscriber may poll metadata status to send a SUBSCRIBE with an "Expires" of 0. 5.5 Confirming the status of Subscribers If a notifier needs to confirm the current status of a subscriber 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 subscriber. When the notifier receives the response with 200 (OK), the notifier confirms that the subscriber's status is up-to-date. If not, the notifier can decide that the subscriber has stale metadata. 5.6 Timer Expiration Nomura/Schulzrinne [Page 6] Internet Draft mupdate June 24, 2002 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 a subscriber and notifier is not persistent but sporadic. In this case, subscriber may require the long expiration time such as 1 day or 1 week. If a subscriber receives NOTIFY request on the session which already has been terminated because the timer has expired, the subscriber SHOULD try to subscribe it again. 5.7 Invalid update notification If a subscriber receives invalid NOTIFY message such as a discontinuous version number or CSeq, the subscriber SHOULD close the session and restart the session from Initialize step. As a result, the subscriber can obtain latest full metadata states. 6 Descriptions of Metadata and Update information 6.1 Candidate Metadata Description MPEG-7 [8] can describe metadata of content by using XML. It defines XML schema representing general multimedia content and structure of content group. WCIP [9] provides a description format of a data structure for web content group in order to achieve cache coherency between an origin web notifier and a surrogate. These two approaches are very similar in terms of describing a structure of content group. If metadata appears in a body of SIP Event, a data type MUST be specified in Content-Type in header field. 6.2 Metadata based Invalidation Metadata can describe availability information for content. If a subscriber recognizes that the availability has been invalid, the subscriber can invalidate content spontaneously without being notified by a NOTIFY request from the notifier. Availability information in metadata can contribute to reduce NOTIFY messages indicating the invalidation operation. In this case, update notifications are just used to substitute invalid metadata for updated metadata. Removing content due to updating metadata may be required on a system provides a content coherency between two hosts. Nomura/Schulzrinne [Page 7] Internet Draft mupdate June 24, 2002 6.3 Delta Description Separate description between metadata and delta is RECOMMENDED. Metadata may describe delta information between two metadata. However, describing delta information using metadata makes metadata description complex and less extensible. Let's assume that one text notation in metadata should be substituted another text and metadata described by XML. In terms of a general tree structure such a XML, to identify child node information requires all of parent node information to which child node belongs because child node itself does not have identity information. In this case, delta information must contain all of parent node information in a document from a root node to a leaf node in order to describe the only one text to be substituted. Since metadata schema should provide identity information for every child nodes in order to describe delta information, it results that metadata schema becomes complex and difficult to extensible. To avoid the problem, it is useful to keep metadata from delta information and introduce differencing algorithm and description such as the UNIX "diff" command described in delta encoding in HTTP [10]. Even though additional "diff" mechanism is required, this function is enough simple and make metadata schema simple and extensible. 7 Example Message Flow Subscriber Notifier | F1 SUBSCRIBE | |------------------>| | F2 200 OK | |<------------------| | F3 NOTIFY | |<------------------| | F4 200 OK | |------------------>| | | | |<-- Update metadata | | | F5 NOTIFY | |<------------------| | F6 200 OK | |------------------>| Nomura/Schulzrinne [Page 8] Internet Draft mupdate June 24, 2002 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: metadataupdate Contact: Expires: 300 Content-Length: 0 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: metadataupdate 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: metadataupdate Subscription-State: active;expires=599 Max-Forwards: 70 CSeq: 3487 NOTIFY Content-Type: text/xml Content-Length: ... Version: 1 Last-Modified: Mon, 24 Jun 2002 08:03:55 GMT Metadata-URI: http://metadata.notifier.com/program1/02080355.xml F4 200 OK subscriber.com-> notifier.com Nomura/Schulzrinne [Page 9] Internet Draft mupdate June 24, 2002 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 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: metadataupdate Subscription-State: active;expires=543 Max-Forwards: 70 Content-Type: text/plain Content-Length: ... Version: 2 Last-Modified: Mon, 24 Jun 2002 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 8 Security Considerations TBD 9 Bibliography [1] L. Amini et al., "Distribution requirements for content internetworking," Internet Draft, Internet Engineering Task Force, Feb. 2002. Work in progress. Nomura/Schulzrinne [Page 10] Internet Draft mupdate June 24, 2002 [2] Y. Nomura and H. Schulzrinne, "Protocol requirements for internet program guides," Internet Draft, Internet Engineering Task Force, Feb. 2002. Work in progress. [3] A. Roach, "SIP-specific event notification," Internet Draft, Internet Engineering Task Force, Mar. 2002. Work in progress. [4] S. Bradner, "Key words for use in RFCs to indicate requirement levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. [5] I. Cooper, D. Li, M. Dahlin, and M. Hamilton, "Requirements for a resource update protocol," Internet Draft, Internet Engineering Task Force, Mar. 2002. Work in progress. [6] J. Rosenberg, H. Schulzrinne, et al., "SIP: Session initiation protocol," Internet Draft, Internet Engineering Task Force, Feb. 2002. Work in progress. [7] J. Rosenberg, "Session initiation protocol (SIP) extensions for presence," Internet Draft, Internet Engineering Task Force, May 2002. Work in progress. [8] ISO (International Organization for Standardization), "Overview of the MPEG-7 standard," ISO Standard ISO/IEC JTC1/SC29/WG11 N4509, International Organization for Standardization, Geneva, Switzerland, Dec. 2001. [9] D. Li, P. Cao, and M. Dahlin, "WCIP: Web cache invalidation protocol," Internet Draft, Internet Engineering Task Force, Mar. 2001. Work in progress. [10] 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. 10 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 Nomura/Schulzrinne [Page 11] Internet Draft mupdate June 24, 2002 USA Email: schulzrinne@cs.columbia.edu Nomura/Schulzrinne [Page 12]