Internet Engineering Task Force
Internet Draft Nomura/Schulzrinne
Fujitsu/Columbia U.
draft-nomura-mmusic-img-requirements-00.txt
February 24, 2003
Expires: August 2003
Protocol Requirements for Internet Media 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.
Abstract
This memo specifies requirements for a protocol for accessing and
updating Internet Media Guide (IMG) information for media-on-demand
and multicast applications. The requirements details general protocol
operations and description formats transmitted by an uni- or bi-
directional transport based on the IMG framework.
1 Introduction
An Internet Media Guide (IMG) [1] describes one or more multimedia
items, available either for download, streaming or multicast
distribution [2]. There may also be meta-guides, i.e., IMGs that
describe other IMGs. IMGs allow users to initiate streaming media
sessions, schedule delivery of downloadable or multicast content or
listen to live multicast sessions.
Nomura/Schulzrinne [Page 1]
Internet Draft IMG Requirements February 24, 2003
Protocols are needed to request, transmit and update such IMGs, as
well as let users know if the IMG has changed. The same host can
serve and produce IMG information.
This draft classifies the features, protocol components and
description formats of the IMG 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 [3].
Internet Media Guide (IMG): An IMG is a set of meta-data
describing the features of multimedia content. For example,
meta-data may consist of the URI, title, air time,
bandwidth needed, file size, text summary, genre, and
access restrictions.
IMG source: An IMG source is a logical entity that sends IMGs to
one or more IMG receivers.
IMG receiver: An IMG receiver is a logical entity that receives
IMGs from an IMG source.
3 Overview
3.1 Features of an IMG
IMG 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 medias.
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, the IMG may
be made available for download from a different set of servers.
3.2 Devices Using the IMG
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 IMGs can be sent
and received by, among others, by cellular phones, PDA (Personal
Nomura/Schulzrinne [Page 2]
Internet Draft IMG Requirements February 24, 2003
Digital Assistant), personal computer, streaming video server, set-
top box, video camera, and PVR (Personal Video Recorder).
4 Requirements
4.1 On-demand Retrieval on a Bi-directional Transport
Since an IMG may contain a large amount of data, the IMG receiver
needs to be able to access the guide when convenient (e.g., when
sufficient network bandwidth is available to the user).
If the IMG receiver and source does not support a bi-directional
transport, the on-demand retrieval is not required.
4.2 Receiving IMGs without a request
Instead of requesting the MG periodically, a user may want to simply
receive updated versions when they become available [4]. Here,
multicast distribution [5] is an efficient mechanism as long as the
MG data volume is small.
If the IMG receiver and source does not support a multicast
transport, this is not required.
4.3 Customized IMG
User may require a subset of the IMG according to their preference
(type of content, media format, appropriate age group, etc.) and
configuration.
4.4 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.
4.5 Many Kinds of Multimedia Content
IMGs may describe a variety of media formats, not just (say) MPEG-
derived formats. For example, IMGs may describe a executable binary
file such as a game program. IMGs may describe other IMGs. IMGs
should be able to describe parts of multimedia streams, e.g., a news
story within a news magazine.
4.6 IMG as Web
IMGs should allow for a web structure, i.e., where IMG 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
Nomura/Schulzrinne [Page 3]
Internet Draft IMG Requirements February 24, 2003
in the same IMG.
4.7 Change Notification
Since IMGs can change at any time, receivers of IMGs should be
notified of such changes, without necessarily re-sending the whole
IMG. 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.
4.8 Reliable Message Exchange
If the IMG receiver and source supports a bi-directional transport,
this protocol should support a reliable message exchange.
4.9 Multiple Sources
Users should be able to obtain IMGs from any number of sources, i.e.,
there is no (single) root node in the tree.
5 Protocol Components
5.1 General Operations
Protocols for IMG access can be divided into three operations [4]:
IMG RETRIEVE: A user can obtain an IMG listing one or more
multimedia resources, selecting an appropriate subset.
IMG SUBSCRIBE: A user can subscribe to change notifications for
meta-data elements of interest, or new IMG elements
matching a profile.
IMG NOTIFY: When the IMG source and receiver supports the uni-
directional transport and detects a change in IMG, the
source simply sends a notification message to the receiver.
When the IMG source and receiver supports the bi-
directional transport, and detects a change in the IMG,
which has been subscribed to by a receiver, the source
sends a notification message to the receiver. The receiver
Nomura/Schulzrinne [Page 4]
Internet Draft IMG Requirements February 24, 2003
replies with an acknowledgement. This message may be
forwarded to a suitable device.
5.2 IMG Data Format
An IMG may refer multiple content, and content may consist of sub-
content. Each sub-content is described by a set of parameters. Thus,
an IMG is structured data [4].
An IMG may refer (via URI) to other IMGs. Such references improve
flexibility and scalability and simplifies decentralized management
of IMGs. However, it makes update notifications somewhat more
challenging.
5.3 User Preferences
A user may specify his preferences in the IMG SUBSCRIBE message and
may want to keep a particular part of the IMG up-to-date.
A user should be able to select parts of the IMG by using an IMG
RETRIEVE. 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.
6 Related Protocols
SDPng [6] 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 [7] can describe meta-data of content by using XML. It
defines an XML schema for general multimedia content and has a IMG
structure.
SAP [5] 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 [8] and SIP-specific event notification [9] can be used to notify
subscribers of the update of the IMG. Since IMGs are likely to be
referencable by URLs, [10] describes a means to notify users of
changes in those URLs.
Nomura/Schulzrinne [Page 5]
Internet Draft IMG Requirements February 24, 2003
HTTP or SOAP can be used to request a IMG. SOAP could be used to
define queries.
7 Security Considerations
TBD
8 Acknowledgements
The authors would like to thank Juka-Pekka Luoma (Nokia), Rod Walsh
(Nokia) and Toni Paila (Nokia) for thier comments on the draft.
9 Bibliography
[1] Y. Nomura and H. Schulzrinne, "A framework for Internet Media
Guides," internet draft, Internet Engineering Task Force, Feb. 2003.
Work in progress.
[2] B. Quinn and K. Almeroth, "IP multicast applications: Challenges
and solutions," RFC 3170, Internet Engineering Task Force, Sept.
2001.
[3] S. Bradner, "Key words for use in rfcs to indicate requirement
levels," RFC 2119, Internet Engineering Task Force, Mar. 1997.
[4] J. Luoma, "MUPPET: Internet media guide unidirectional," internet
draft, Internet Engineering Task Force, Dec. 2002. Work in progress.
[5] M. Handley, C. E. Perkins, and E. Whelan, "Session announcement
protocol," RFC 2974, Internet Engineering Task Force, Oct. 2000.
[6] D. Kutscher, J. Ott, and C. Bormann, "Session description and
capability negotiation," internet draft, Internet Engineering Task
Force, July 2002. Work in progress.
[7] 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.
[8] 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.
[9] A. B. Roach, "Session initiation protocol (sip)-specific event
notification," RFC 3265, Internet Engineering Task Force, June 2002.
Nomura/Schulzrinne [Page 6]
Internet Draft IMG Requirements February 24, 2003
[10] 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
Nomura/Schulzrinne [Page 7]