Internet Engineering Task Force

INTERNET-DRAFT  Nomura/Schulzrinne
draft-nomura-mmusic-pguide-requirements-00.ps  Fujitsu/Columbia U.

February 22, 2002 Expires: July 2002

Protocol Requirements for Internet Program Guides

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.

Copyright Notice

Copyright (c) The Internet Society (2002). All Rights Reserved.

Abstract This memo specifies requirements for protocol for accessing and updating program guide information

for media-on-demand and multicast applications.

1 Introduction

A program guide describes one or more multimedia items, available either for download, streaming or multicast distribution. There may also be meta-guides, i.e., program guides that describe other program guides. Program guides allow users to initiate streaming media sessions, schedule delivery of downloadable or multicast content or listen to live multicast sessions.

Protocols are needed to transmit and update such program guides, as well as let users know if a program guide has changed. The same host can serve and produce program guide information.

This draft classifies the features and use cases of the program guide and shows requirements and describes some possible solutions.

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

3 Overview

3.1 Definition of Program Guide

INTERNET-DRAFT  draft-nomura-mmusic-pguide-requirements-00.ps  February 22, 2002

A program guide is a set of meta-data describing the features of multimedia content. For example, metadata may consist of the URI, title, air time, bandwidth needed, file size, text summary, genre, and access restrictions.

3.2 Features of a Program Guide

Program guide data may be updated as time elapses because content described in the guide may be changed. For example, the airtime of an event such as a concert or sports event may change, possibly affecting the air time of subsequent programs.

Also, content may be made available only temporarily, e.g., via multicast, based on popularity. If a particular program proves to be popular, additional sessions might be added. Similarly, a program may be made available for download from a different set of servers.

3.3 Devices Using the Program Guide

We assume that any Internet host can be a source of content and thus meta data. Some of the content sources and sinks may only be connected to the Internet sporadically. Also, a single human user may use many different devices to access meta data, including bandwidth-constrained mobile devices. Thus, we envision that program guides can be sent and received by, among others, by cellular phones, PDA (Personal Digital Assistant), personal computer, streaming video server, set-top box, video camera, and PVR (Personal Video Recorder).

4 Use Case Models of The Program Guide

Typical use case models of the program guide are following four models divided into using ways (automatically, manually) and obtaining time of content (real time and time shift). Table 1 shows these models and typical examples.

Manually Automatically
Real Time (1) TV  (3) Live conference broadcasting
Time Shift (2) VCR (4) Preference-based recording

(1) Television model: A human user manually uses the program guide, specifies the content and watches it in real time. If the airtime is changed suddenly and the sender of the program guide notifies the user, the user can follow the preferred content manually.

(2) VCR model: A human user manually uses the program guide, specifies content to be stored. The user watches it by time-shift. If the airtime is changed suddenly and the sender of the program guide notifies the user, the user can manually specify the preferred content again.

(3) Live conference broadcasting model: A device uses the program guide automatically, specifies content and shows it to users when it is available. If the availability is changed suddenly and the sender of the program guide notifies the device of the change, the device can follow this change automatically.

(4) Preference-based recording model: A device uses the program guide to store content automatically according to a user’s direction such as a preference and configuration. If the availability is changed suddenly and the sender of the program guide notifies the device, the device can follow this change automatically.

5 Requirements

5.1 On-demand Retrieval

Since the program guide may contain a large amount of data, the client needs to be able to access the guide when convenient (e.g., when sufficient network bandwidth is available to the user). Thus, the protocol must support request-response operation.

5.2 Customized Program Guide

User may require a subset of the program guide according to their preference (type of content, media format, appropriate age group, etc.) and configuration.

5.3 Different Kinds of Devices

The protocol is designed to be sufficiently simple so as to be implemented on the small devices such as a cellular phone and PDA.

5.4 Many Kinds of Multimedia Content

Program guides may describe a variety of media formats, not just (say) MPEG-derived formats. Program guides may describe other program guides. Program guides should be able to describe parts of multimedia streams, e.g., a news story within a news magazine.

5.5 Program Guide as Web

Program guides should allow for a web structure, i.e., where a program guide may refer to other guides or actual meta data. Just like the web, links (with meta data about the linked-to entity) and content should be able to appear in the same program guide.

5.6 Change Notification

Since program guides can change at any time, receivers of program guides should be notified of such changes, without necessarily re-sending the whole program guide. Depending on the size of the guide, the interested party may want to defer retrieving the actual information. The change notification should be addressed to a logical user, not a host, since users may change devices.

As an example, consider a storage device requires the up-to-date video file from an IP-reachable video camera but the camera is connected only sporadically. When the camera is connected on the network and has a new video object, the storage device must be notified of its availability immediately.

5.7 Reliable Message Exchange

This protocol requires a reliable message exchange.

5.8 Multiple Sources

Users should be able to obtain program guides from any number of sources, i.e., there is no (single) root node in the tree.

6 Protocol Components

Protocols for program guide access can be divided into three components:

Program guide request: A user can obtain a program guide listing one or more multimedia resources, selecting an appropriate subset.

Notification request: A user can subscribe to change notifications for meta-data elements of interest, or new program guide elements matching a profile.

Update notification: When the program guide owner detects a change in the program guide which has been subscribed to by a receiver, the owner sends a notification message to the receiver. The receiver replies with an acknowledgement. This message may be forwarded to a suitable device.

7 Related Protocols

SDPng [2] can describe meta-data for content by using XML. Since SDPng addresses multiparty multimedia conferences, it is necessary to extend the XML schema in order to describe general multimedia content.

MPEG-7 [3] can describe meta-data of content by using XML. It defines an XML schema for general multimedia content and has a program guide structure.

SAP [4] distributes session descriptions via multicast. It does not support fine-grained meta data selection and update notifications, as it always sends the whole meta data. Given the lack of a wide-area multicast infrastructure, it is likely only deployable within a local area network.

SIP [5] and SIP-specific event notification [6] can be used to notify subscribers of the update of the program guide. Since program guides are likely to be referencable by URLs, [7] describes a means to notify users of changes in those URLs.

HTTP or SOAP can be used to request a program guide. SOAP could be used to define queries.

8 Open Issues

The content and format for a meta program guide remain to be determined.

The consumer should be able to select parts of a program guide. If an XML-based format is used, this appears to be a special case of an XML query operation (http://www.w3.org/XML/Query).

Unlike for presence, where likely only the last state is of interest, update notifications for disconnected users may need to be queued.

9 Security Considerations

TBD

References

[1] S. Bradner, “Key words for use in RFCs to indicate requirement levels,” Request for Comments 2119, Internet Engineering Task Force, Mar. 1997.

[2] D. Kutscher, J. Ott, and C. Bormann, “Session description and capability negotiation,” Internet Draft, Internet Engineering Task Force, Nov. 2001. Work in progress.

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

[4] M. Handley, C. Perkins, and E. Whelan, “Session announcement protocol,” Request for Comments 2974, Internet Engineering Task Force, Oct. 2000.

[5] J. Rosenberg, H. Schulzrinne, et al., “SIP: Session initiation protocol,” Internet Draft, Internet Engineering Task Force, Feb. 2002. Work in progress.

[6] A. Roach, “SIP-specific event notification,” Internet Draft, Internet Engineering Task Force, Feb. 2002. Work in progress.

[7] X. Wu and H. Schulzrinne, “Use SIP MESSAGE method for shared web browsing,” Internet Draft, Internet Engineering Task Force, Nov. 2001. Work in progress.

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 USA Email: schulzrinne@cs.columbia.edu

Full Copyright Statement

Copyright (c) The Internet Society (2002). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an ”AS IS” basis and THE IN-TERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WAR-RANTIES, 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.