Skip to main content

Requirements for Internet Media Guides (IMGs)

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 4473.
Authors Juha-Pekka Luoma , Henning Schulzrinne , Rod Walsh , Yuji Nomura , Joerg Ott
Last updated 2015-10-14 (Latest revision 2005-12-20)
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Informational
Additional resources Mailing list discussion
Stream WG state (None)
Document shepherd (None)
IESG IESG state Became RFC 4473 (Informational)
Action Holders
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Jon Peterson
Send notices to
MMUSIC Working Group                                           Y. Nomura
Internet-Draft                                             Fujitsu Labs.
Expires: June 23, 2006                                          R. Walsh
                                                              J-P. Luoma
                                                                  J. Ott
                                                     Universitaet Bremen
                                                          H. Schulzrinne
                                                     Columbia University
                                                       December 19, 2005

                 Requirements 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 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

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

Copyright Notice

   Copyright (C) The Internet Society (2005).


   This memo specifies requirements for a framework and protocols for
   accessing and updating Internet Media Guide (IMG) information for
   media-on-demand and multicast applications. These requirements are
   designed to guide choice and development of IMG protocols for

Y. Nomura et. al.                                             [Page 1]
Internet Draft              IMG Requirements         December 19, 2005

   efficient and scalable delivery.

Table of Contents

   1          Introduction ........................................    3
   1.1        Background and Motivation ...........................    3
   1.2        Scope of This Document ..............................    4
   2          Terminology .........................................    5
   2.1        New Terms ...........................................    5
   3          Problem Statement ...................................    6
   4          Use Cases Requiring IMGs ............................    7
   4.1        Connectivity-based Use Cases ........................    7
   4.1.1      IP Datacast to a Wireless Receiver ..................    7
   4.1.2      Regular Fixed Dial-up Internet Connection ...........    8
   4.1.3      Broadband Always-on Fixed Internet Connection .......    8
   4.2        Content-orientated Use Cases ........................    9
   4.2.1      TV and Radio Program Delivery .......................    9
   4.2.2      Media Coverage of a Live Event ......................   10
   4.2.3      Distance Learning ...................................   10
   4.2.4      Multiplayer Gaming ..................................   10
   4.2.5      File Distribution ...................................   10
   4.2.6      Coming-release and Pre-released Content .............   11
   5          Requirements ........................................   11
   5.1        General Requirements ................................   11
   5.1.1      Independence of IMG Operations from IMG Metadata ....   11
   5.1.2      Multiple IMG Senders ................................   11
   5.1.3      Modularity ..........................................   12
   5.2        Delivery Properties .................................   12
   5.2.1      Scalability .........................................   12
   5.2.2      Support for Intermittent Connectivity ...............   12
   5.2.3      Congestion Control ..................................   13
   5.2.4      Sender and Receiver Driven Delivery .................   13
   5.3        Customized IMGs .....................................   13
   5.4        Reliability .........................................   14
   5.4.1      Managing Consistency ................................   14
   5.4.2      Reliable Message Exchange ...........................   15
   5.5        IMG Descriptions ....................................   15
   6          Security Considerations .............................   17
   6.1        IMG Authentication and Integrity ....................   17
   6.2        Privacy .............................................   18
   6.3        Access Control for IMGs .............................   18
   6.4        Denial-of-Service attacks ...........................   19
   6.5        Replay Attacks ......................................   19
   7          IANA Considerations .................................   20
   8          Normative References ................................   20
   9          Informative References ..............................   20
   10         Acknowledgements ....................................   21
   11         Authors' Addresses ..................................   21

Y. Nomura et. al.                                             [Page 2]
Internet Draft              IMG Requirements         December 19, 2005

1 Introduction

1.1 Background and Motivation

   For some ten years, multicast-based (multimedia) conferences
   (including IETF WG sessions) as well as broadcasts of
   lectures/seminars, concerts, and other events have been used in the
   Internet, more precisely, on the MBONE. Schedules and descriptions
   for such multimedia sessions as well as the transport addresses,
   codecs, and their parameters have been described using SDP [2] as a
   rudimentary (but as of then largely sufficient) means. Dissemination
   of the descriptions has been performed using the Session Announcement
   Protocol (SAP) [3] and tools such as SD [4] or SDR [5]; descriptions
   have also been put up on web pages, sent by electronic mail, etc.

   Recently, interest has grown to expand -- or better: to generalize --
   the applicability of these kinds of session descriptions.
   Descriptions are becoming more elaborate in terms of included
   metadata; more generic regarding the types of media sessions; and
   possibly also support other transports than just IP (e.g. legacy TV
   channel addresses). This peers well with the DVB (Digital Video
   Broadcasting) [6] Organization's increased activities towards
   IP-based communications over satellite, cable, and terrestrial radio
   networks, also considering IP as the basis for TV broadcasts and
   further services. The program/content descriptions are referred to as
   Internet Media Guides (IMGs) and can be viewed as a generalization of
   Electronic Program Guides (EPGs) and multimedia session descriptions.

   An Internet Media Guide (IMG) has a structured collection of
   multimedia session descriptions expressed using SDP, SDPng [7] or
   some similar session description format. This is used to describe a
   set of multimedia services (e.g. television program schedules,
   content delivery schedules) but may also refer to other networked
   resources including web pages. IMGs provide the envelope for metadata
   formats and session descriptions defined elsewhere with the aim of
   facilitating structuring, versioning, referencing, distributing, and
   maintaining (caching, updating) such information.

   The 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 this information. Hence, a
   framework for distributing IMG metadata in various different ways is
   needed to accommodate the needs of different audiences: For
   traditional broadcast-style scenarios, multicast-based (push)
   distribution of IMG metadata needs to be supported. Where no
   multicast is available, unicast-based push is required, too.
   Furthermore, IMG metadata may need to be retrieved interactively,
   similar to web pages (e.g. after rebooting a system or when a user is

Y. Nomura et. al.                                             [Page 3]
Internet Draft              IMG Requirements         December 19, 2005

   browsing after network connectivity has been re-established).
   Finally, IMG metadata 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 airtime of subsequent media. This may be done by
   polling the IMG sender as well as by asynchronous change

   Furthermore, any Internet host can be a sender of content and thus an
   IMG sender. 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 metadata. Thus, we envision that
   IMG metadata 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 DVR (Digital
   Video Recorder) and that they be carried across arbitrary types of
   link layers, including bandwidth-constrained mobile networks.
   However, generally we expect IMG Senders to be well-connected hosts.

   Finally, with many potential senders and receivers, different types
   of networks, and presumably numerous service providers, IMG metadata
   may need to be combined, split, filtered, augmented, modified, etc.,
   on their way from the sender(s) to the receiver(s) to provide the
   ultimate user with a suitable selection of multimedia services
   according to her preferences, subscriptions, location, context (e.g.
   devices, access networks), etc.

1.2 Scope of This Document

   This document defines requirements that Internet Media Guide
   mechanisms must satisfy in order to deliver IMG metadata to a
   potentially large audience. Since IMGs can describe many kinds of
   multimedia content, IMG methods are generally applicable to several

   In considering wide applicability, this document provides the problem
   statement and existing mechanisms in this area. Then several use case
   scenarios for IMGs are explained including descriptions of how IMG
   metadata and IMG delivery mechanisms contribute to these scenarios.
   Following this, this document provides general requirements that are
   independent of any transport layer mechanism and application, such as
   delivery properties, reliability and IMG descriptions.

   This document reflects investigating work on delivery mechanisms for
   IMGs and generalizing work on session announcement and initiation
   protocols, especially in the field of the MMUSIC working group (SAP,
   SIP [8], SDP).

Y. Nomura et. al.                                             [Page 4]
Internet Draft              IMG Requirements         December 19, 2005

2 Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [1].

2.1 New Terms

        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.

        IMG Transceiver: An IMG transceiver combines an IMG receiver and
             sender. It may modify received IMG metadata or merge IMG
             metadata received from a several different IMG senders.

        IMG Operation: An atomic operation of an IMG transport protocol,
             used between IMG sender(s) and IMG receiver(s) for the
             delivery of IMG metadata and for the control of IMG

        IMG Transport Protocol: A protocol that transports IMG metadata
             from an IMG sender to IMG receiver(s).

        IMG Transport Session: An association between an IMG sender and
             one or more IMG receivers within the scope of an IMG
             transport protocol. An IMG transport session involves a
             time bound series of IMG transport protocol interactions

Y. Nomura et. al.                                             [Page 5]
Internet Draft              IMG Requirements         December 19, 2005

             that provide delivery of IMG metadata from the IMG sender
             to the IMG receiver(s).

3 Problem Statement

   As we enumerate the requirements for IMGs, it will become clear that
   they are not fully addressed by the existing protocols. The Framework
   for the Usage of Internet Media Guides [9] talks about these issues
   in more detail.

   The MMUSIC working group has long been investigating content, media
   and service information delivery mechanisms and protocols, and has
   itself produces Session Announcement Protocol (SAP), Session
   Description Protocol (SDP), and the Session Initiation Protocol
   (SIP). SDP is capable of describing multimedia sessions (i.e.
   content in a wider sense) by means of limited descriptive information
   intended for human perception plus transport, scheduling information,
   and codecs and addresses for setting up media sessions. SIP and SAP
   are protocols to distribute these session descriptions.

   However, we perceive a lack of a standard solution for scalable IMG
   delivery mechanism in the number of receivers with consistency of IMG
   metadata between an IMG sender and IMG receiver for both 
   bi-directional and unidirectional transport. With increased service
   dynamics and complexity, there is an increased requirement for
   updates to these content descriptions.

   HTTP [10] is a well known information retrieval protocol using
   bi-directional transport and widely used to deliver web-based
   content descriptions to many hosts. However, it has well recognized
   limitations of scalability in the number of HTTP clients since it
   relies on the polling mechanism to keep information consistent
   between the server and client.

   SAP [3] is an announcement protocol that distributes session
   descriptions via multicast. It does not support prioritization or
   fine-grained metadata selection and update notifications, as it
   places restrictions on metadata payload size and always sends the
   whole metadata. It requires a wide-area multicast infrastructure for
   it to be deployable beyond a local area network.

   SIP [8] and SIP-specific event notification [11] can be used to
   notify subscribers of the update of IMG metadata for bi-directional
   transport. However, it is necessary for SIP Event to define an event
   package as a standard protocol for each specific application
   including IMGs.

   We also perceive a lack of standard solution for flexible content

Y. Nomura et. al.                                             [Page 6]
Internet Draft              IMG Requirements         December 19, 2005

   descriptions to support a multitude of application-specific metadata
   and associated data models with differing amount of detail and
   different target audiences.

   SDP [2] has a text-encoded syntax to specify multimedia sessions for
   announcements and invitations. It is primarily intended to describe
   client capability requirements and enable client application
   selection. Although SDP is extensible, it has limitations such as
   structured extensibility and capability to reference properties of a
   multimedia session from the description of another session.

   These are mostly overcome by the XML-based SDPng [7], which is 
   intended for both two-way negotiation and also unidirectional
   delivery. Since SDPng addresses multiparty multimedia conferences, it
   is necessary to extend the XML schema in order to describe general
   multimedia content.

4 Use Cases Requiring IMGs

4.1 Connectivity-based Use Cases

4.1.1 IP Datacast to a Wireless Receiver

   IP Datacast is the delivery of IP-based services over broadcast
   radio. Internet content delivery is therefore unidirectional in this
   case. However, there can be significant benefits from being able to
   provide rich media one-to-many services to such receivers.

   There are two main classes of receiver in this use case: fixed
   mains-powered; and mobile battery-powered. Both of these are affected
   by radio phenomena and so robust, or error-resilient, delivery is
   important. Carouselled metadata transfer (cyclically repeated with
   fixed bandwidth) provides a base level of robustness for an IP
   datacast based announcement system, although the design of
   carouselled transfer should enable battery-powered receivers to go
   through periods of sleep to extend their operational time between
   charges. Insertion of Forward Error Correction (FEC) data into
   metadata announcements improves error resilience, and reordering
   (interleaving) data blocks further increases tolerance to burst

   To enable receivers to more accurately specify the metadata they
   are interested in, the unidirectional delivery may be distributed
   between several logical channels. This is so that a receiver needs
   only access the channels of interest and thus can reduce the amount
   of time, storage and CPU resources needed for processing the IP
   data. Also, hierarchical channels enable receivers to subscribe to
   a, possibly well known, root multicast channel/group and

Y. Nomura et. al.                                             [Page 7]
Internet Draft              IMG Requirements         December 19, 2005

   progressively access only those additional channels based on
   metadata in parent channels.

   In some cases the receiver may have multiple access interfaces adding
   bi-directional communications capability. This enables a multitude of
   options, but most importantly it enables NACK based reliability and
   the individual retrieval of missed or not-multicasted sets of

   Thus, essential IMG features in this case include: robust
   unidirectional delivery (with optional levels of reliability
   including "plug-in FEC" supported by a transport layer protocol)
   which implies easily identifiable segmentation of delivery data to
   enable FEC, carousel, interleaving and other schemes possible;
   effective identification of metadata sets (probably uniquely) to
   enable more efficient use of multicast and unicast retrieval over
   multiple access systems regardless of the parts of metadata and
   application specific extensions in use; prioritization of metadata,
   which can (for instance) be achieved by spreading it between channels
   and allocating/distributing bandwidth accordingly.

   Furthermore, some cases require IMG metadata authentication and some
   group security/encryption and supporting security message exchanges
   (out of band from the IMG multicast sessions).

4.1.2 Regular Fixed Dial-up Internet Connection

   Dial-up connections tend to be reasonably slow (<56kbps in any case)
   and thus large data transfers are less feasible, especially during an
   active application session (such as a file transfer described by IMG
   metadata). They can also be intermittent, especially if a user is
   paying for the connected time, or connected through a less reliable
   exchange. Thus this favors locally stored IMG metadata over web-based
   browsing, especially where parts of the metadata change infrequently.
   There may be no service provider preference over unicast and
   multicast transport for small and medium numbers of users as the
   last-mile dial-up connection limits per-user congestion, and a user
   may prefer the more reliable option (unicast unless reliable
   multicast is provided).

4.1.3 Broadband Always-on Fixed Internet Connection

   Typically bandwidth is less of an issue to a broadband user and
   unicast transport, such as using query-response methods, may be
   typical for a PC user. If a system were only used in this context,
   with content providers, ISPs and users having no other requirements,
   then web-based browsing may be equally suitable. However, broadband
   users sharing a local area network, especially wireless, may benefit

Y. Nomura et. al.                                             [Page 8]
Internet Draft              IMG Requirements         December 19, 2005

   more from local storage features than on-line browsing, especially if
   they have intermittent Internet access.

   Some services on broadband, such as live media broadcasting, benefit
   from multicast transport for streaming media because of scalability.
   In the cases where multicast transport is already available, it is
   convenient for a sender and receiver to retrieve IMG metadata over
   multicast transport. Thus, broadband users may be forced to retrieve
   IMG metadata over multicast if backbone operators require this to
   keep system-wide bandwidth usage feasible.

4.2 Content-orientated Use Cases

   IMGs will be able to support a very wide range of use cases for
   enabling content/media delivery. The following few sections just
   touch the surface of what is possible and are intended to provide an
   understanding of the scope and type of IMG usage. Many more examples
   may be relevant, for instance those detailed in [12]. There are
   several unique features of IMGs that set them apart from related
   application areas such as SLP based service location discovery, LDAP
   based indexing services and search engines such as Google. Features
   unique to IMGs include:

        o IMG metadata is generally time-related

        o There are timeliness requirements in the delivery of IMG

        o IMG metadata may be updated as time elapses or when an event

4.2.1 TV and Radio Program Delivery

   A sender of audio/video streaming content can use the IMG metadata to
   describe the scheduling and other properties of audio/video sessions
   and events within those sessions, such as individual TV and radio
   programs and segments within those programs. IMG metadata describing
   audio/video streaming content could be represented in a format
   similar to that of a TV guide in newspapers, or an Electronic Program
   Guide available on digital TV receivers.

   TV and radio programs can be selected for reception either manually
   by the end-user or automatically based on the content descriptions
   and the preferences of the user. The received TV and radio content
   can be either presented in real time or recorded for later
   consumption. There may be changes in the scheduling of a TV or a
   radio program, possibly affecting the transmission times of
   subsequent programs. IMG metadata can be used to notify receivers of

Y. Nomura et. al.                                             [Page 9]
Internet Draft              IMG Requirements         December 19, 2005

   such changes, enabling users to be prompted or recording times to be

4.2.2 Media Coverage of a Live Event

   The media coverage of a live event such as a rock concert or a sports
   event is a special case of regular TV/radio programming. There may be
   unexpected changes in the scheduling of live event, or the event may
   be unscheduled to start with (such as breaking news). In addition to
   audio/video streams, textual information relevant to the event (e.g.
   statistics of the players during a football match) may be sent to
   user terminals. Different transport modes or even different access
   technologies can be used for the different media: for example, a
   unidirectional datacast transport could be used for the audio/video
   streams and an interactive cellular connection for the textual data.
   IMG metadata should enable terminals to discover the availability of
   different media used to cover a live event.

4.2.3 Distance Learning

   IMG metadata could describe compound sessions or services enabling
   several alternative interaction modes between the participants. For
   example, the combination of one-to-many media streaming, unicast
   messaging and download of presentation material could be useful for
   distance learning.

4.2.4 Multiplayer Gaming

   Multiplayer games are an example of real time multiparty
   communication sessions that could be advertised using IMGs. A gaming
   session could be advertised either by a dedicated server, or by the
   terminals of individual users. A user could use IMGs to learn of
   active multiplayer gaming sessions, or advertise the users interest
   in establishing such a session.

4.2.5 File Distribution

   IMGs support the communication of file delivery session properties,
   enabling the scheduled delivery or synchronization of files between a
   number of hosts. The received IMG metadata could be subsequently used
   by any application (also outside the scope of IMGs), for example to
   download a file with a software update. IMG metadata can provide a
   description to each file in a file delivery session, assisting users
   or receiving software in selecting individual files for reception.

   For example, when a content provider wants to distribute a large
   amount of data in file format to thousands clients, the content
   provider can use IMG metadata to schedule the delivery effectively.

Y. Nomura et. al.                                            [Page 10]
Internet Draft              IMG Requirements         December 19, 2005

   Since IMG metadata can describe time-related data for each receiver,
   the content provider can schedule delivery time for each receiver.
   This can save network bandwidth and delivery capacity of senders. In
   addition, IMG metadata can be used to consistency check, and thus
   synchronize, a set of files between a sender host and receiver host,
   when those files change as time elapses.

4.2.6 Coming-release and Pre-released Content

   IMG metadata can be used to describe items of content before the
   details of their final release are known. A user may be interested
   in coming content (a new movie or software title where some aspects
   of the content description are known in advance) and so subscribe
   to an information service which notifies the user of changes to
   metadata describing that content. Thus, as the coming release, or
   pre-releases, (such as movie trailers or software demos) become
   available the IMG metadata changes and the user is notified of this
   change. For example, the user could see an announcement of a movie
   that will be released sometime in the next few months, and
   configure the user's terminal to receive and record any trailers or
   promotional material as they become available.

5 Requirements

5.1 General Requirements

5.1.1 Independence of IMG Operations from IMG Metadata

   REQ GEN-1: Carrying different kinds of IMG metadata format in the IMG
   message body MUST be allowed.

   REQ GEN-2: Delivery mechanisms SHOULD support many different
   applications' specific metadata formats to keep the system
   interoperable with existing applications.

   This provides flexibility in selecting/designing IMG transport
   protocol suited to various scenarios.

5.1.2 Multiple IMG Senders

   REQ GEN-3: IMG receivers MUST be allowed to communicate with any
   number of IMG senders simultaneously.

   This might lead to receiving redundant IMG metadata describing the
   same items, however it enables the IMG receiver access to more IMG
   metadata than may be available from a single IMG sender. This also
   provides flexibility for the IMG transport protocols and does not
   preclude a mechanism to solve inconsistency among IMG metadata due to

Y. Nomura et. al.                                            [Page 11]
Internet Draft              IMG Requirements         December 19, 2005

   multiple IMG senders. This document assumes a typical IMG environment
   will involve many more IMG receivers than IMG senders and that IMG
   senders are continually connected for the duration of interest
   (rather than intermittently connected).

5.1.3 Modularity

   REQ GEN-4: The IMG delivery mechanisms MUST allow the combination of
   several IMG Operations.

   This is for the purpose of extending functionality (e.g. several or
   one protocol(s) to provide all the needed operations). Applications
   can select an appropriate operation set to fulfill their purpose.

5.2 Delivery Properties

   This section describes general performance requirements based on the
   assumption that the range of IMG usage shall be important. However,
   it may be noted that requirements of delivery properties may vary
   based on the usage scenario, and thus some limited use
   implementations place less importance on some requirements.

   For example, it is clear that a multicast transport may provide more
   scalable delivery than a unicast transport, however scalability
   requirements do not preclude the unicast transport mechanisms. In
   this sense, scalability is always important for the protocols
   irrespective of transport mechanisms.

5.2.1 Scalability

   REQ DEL-1: The IMG system MUST be scalable to large numbers of
   messages, so as to allow design and use of delivery mechanisms that
   will not fail in delivering up-to-date information under huge numbers
   of transactions and massive quantities of IMG metadata.

   REQ DEL-2: IMGs SHOULD provide a method to prevent an IMG sender from
   sending unnecessary IMG metadata that have been stored or deleted in
   IMG receivers.

   REQ DEL-3: The protocol MUST be scalable to very large audience sizes
   requiring IMG delivery.

5.2.2 Support for Intermittent Connectivity

   REQ DEL-4: The system MUST enable IMG receivers with intermittent
   access to network resources (connectivity) to receive and adequately
   maintain sufficient IMG metadata.

Y. Nomura et. al.                                            [Page 12]
Internet Draft              IMG Requirements         December 19, 2005

   This allows intermittent access to save power where there is no need
   to keep communications links powered-up while they are sitting idle.
   For instance, in this situation periodic bursts of notifies, or a
   fast cycling update carousel, allows hosts to wake up for short
   periods of time and still be kept up-to-date. This can be beneficial
   for IMG receivers with sporadic connections to the fixed Internet,
   but is critical in the battery-powered wireless Internet.

   The implication of intermittent connectivity is that immediate
   distribution of changes becomes infeasible and so managing data
   consistency should be focused on the timely delivery of data.

5.2.3 Congestion Control

   REQ DEL-5: Internet-friendly congestion control MUST be provided for
   use on the public Internet.

   REQ DEL-6: An IMG entity SHOULD invalidate the IMG metadata item when
   an IMG metadata item has lifetime information and its lifetime is
   over. This will lessen the need for notifications of updates from the
   IMG sender to the IMG receiver to invalidate the item and may enable
   lesser congestion.

5.2.4 Sender and Receiver Driven Delivery

   REQ DEL-7: The system MUST be flexible in choosing sender-driven,
   receiver-driven or both delivery schemes.

   Sender-driven delivery achieves high scalability without interaction
   between the IMG sender and receiver. This avoids keeping track of a
   delivery state for every IMG receiver.

   In contrast, the receiver-driven delivery provides on-demand delivery
   for IMG receivers. Since an IMG sender's complete IMG metadata may be
   a very 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 IMG receiver).

5.3 Customized IMGs

   REQ CUS-1: The system MUST allow delivery of customized IMG metadata.

   The IMG receiver may require a subset of all the IMG metadata
   available according to their preferences (type of content, media
   description, appropriate age group, etc.) and configuration.

   The IMG receiver might send its preferences in the IMG operations
   which can specify user specific IMG metadata to be delivered. These

Y. Nomura et. al.                                            [Page 13]
Internet Draft              IMG Requirements         December 19, 2005

   preferences could consist of filtering rules. When receiving these
   messages, the IMG sender might respond with appropriate messages
   carrying a subset of IMG metadata which matches the IMG receiver's

   This mechanism can reduce the amount of IMG metadata delivered from
   the IMG sender to IMG receiver, and consequently it can save the
   resource consumption on the IMG entities and networks. It is
   typically useful in unicast cases and also beneficial in multicast
   cases where an IMG sender distributes the same IMG metadata to
   interested IMG receivers at the same time.

   For multicast and unicast cases where the IMG sender does not provide
   customized IMG metadata, the IMG receiver could receive all IMG
   metadata transmitted (on its joined channels). However, it may select
   and filter the IMG metadata to get customized IMG metadata by its
   preferences, and thus drop unwanted metadata immediately upon

   Customized metadata might be achieved by changing the IMG
   descriptions sent and IMG receivers and/or changing the delivery
   properties (channels used).

   Note, customization and scalability are only somewhat exclusive.
   Systems providing an IMG receiver to an IMG sender request-based
   customization, will be generally less scalable to massive IMG
   receiver populations than those without this return signaling
   technique. Thus, customization, as with any feature which affects
   scalability, should be carefully designed for the intended
   application, and it may not be possible that a one-size-fits-all
   solution for customization would meet the scalability requirements
   for all applications and deployment cases.

5.4 Reliability

5.4.1 Managing Consistency

   IMG metadata tends to change as time elapses, as new content is
   added, the old IMG metadata stored in the IMG receiver becomes
   unavailable and the parameters of the existing IMG metadata are

   REQ REL-1: The system MUST manage IMG metadata consistency.

   The IMG sender can either simply make updates available
   (unsynchronized) or IMG sender and receiver can interact to keep
   their copies of the IMG metadata synchronized.

Y. Nomura et. al.                                            [Page 14]
Internet Draft              IMG Requirements         December 19, 2005

   In the unsynchronized model, the IMG sender does not know whether a
   particular IMG receiver has an up-to-date copy of the IMG metadata.

   In the synchronized model, updating a cached copy of the IMG metadata
   is necessary to control consistency when the IMG sender or receiver
   could not communicate for a while. In this case, the IMG sender or
   receiver may need to confirm its consistency by IMG operations.

   REQ REL-2: Since IMG metadata can change at any time, IMG receivers
   SHOULD be notified of such changes.

   Fulfilling this requirements needs to be compatible with the
   scalability requirements for the number of IMG receivers and the
   consistency of metadata.

   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 (or user group), rather than a
   host, since users may change devices.

   Note that depending on the deployment environment and application
   specifics, the level of acceptable inconsistency varies. Thus, this
   document does not define inconsistency as specific time and state
   differences between IMG metadata stored in an IMG sender and IMG
   metadata stored in an IMG receiver.

   In general, the consistency of metadata for a content and media is
   more important immediately prior to and during the media's
   session(s). Hosts which forward (or otherwise resend) metadata may be
   less tolerant to inconsistencies as delivering out of date data is
   both misleading and bandwidth inefficient.

5.4.2 Reliable Message Exchange

   REQ REL-4: An IMG transport protocol MUST support reliable message

   The extent to which this could result in 100% error free delivery to
   100% of IMG receivers is a statistical characteristic of the
   protocols used. Usage of reliable IMG delivery mechanisms is expected
   to depend on the extent to which underlying networks provide
   reliability and, conversely, introduce errors. Note, some deployments
   of IMG transport protocols may not aim to provide perfect reception
   to all IMG receivers in all possible cases.

5.5 IMG Descriptions

   REQ DES-1: IMG metadata MUST be interoperable over any IMG transport

Y. Nomura et. al.                                            [Page 15]
Internet Draft              IMG Requirements         December 19, 2005

   protocol, such that an application receiving the same metadata over
   any one (or more) of several network connections and/or IMG transport
   protocols will interpret the metadata in exactly the same way. (This
   also relates to the 'Independence of IMG Operations from IMG
   Metadata' requirements.)

   REQ DES-2: IMG delivery MUST enable the carriage of any format of
   application-specific metadata.

   Thus, the system will support the description of many kinds of
   multimedia content, without the need for a single homogenous metadata
   syntax for all uses (which would be infeasible anyway). This is
   essential for environments using IMG systems to support many kinds of
   multimedia content and to achieve wide applicability.

   REQ DES-3: Whereas specific applications relying on IMGs will need to
   select one or more specific application-specific metadata formats
   (standard, syntax, etc.), the IMG system MUST be independent of this
   (it may be aware, but it will operate in the same way for all).

   Thus, a metadata transfer envelope format, that is uniform across all
   different application-specific IMG metadata formats, is needed. The
   envelope would reference (point to) or carry (as payload) 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 envelope would not need to be aware of the data model(s) in

   REQ DES-4: IMG metadata MUST be structured to enable fragmentation
   for efficient delivery.

   This is intended to ensure that and IMG sender with more than a
   trivial knowledge of metadata is able to deliver only part of its
   (and the global) complete IMG metadata knowledge. (For instance, a
   trivial quantity of knowledge could be a single SDP description.) In
   general, the resolution of this fragmentation will be very much
   dependent on the optimal delivery of a deployment, although some
   metadata syntaxes will inherently effect the sensible lower limit for
   a single element/fragment.

   REQ DES-5: A metadata transfer envelope MUST be defined to include
   essential parameters.

   Examples of essential parameters are those that allow the metadata in
   question to be uniquely identified and updated by new versions of the
   same metadata.

Y. Nomura et. al.                                            [Page 16]
Internet Draft              IMG Requirements         December 19, 2005

   REQ DES-6: It SHALL be possible to deduce the metadata format via the
   metadata transfer envelope.

   REQ DES-7: IMG senders SHALL use a metadata transfer envelope for
   each IMG metadata transfer.

   Thus, it will even be possible to describe relationships between
   syntactically dissimilar application-specific formats within the same
   body of IMG metadata knowledge. (E.g. a data model could be
   instantiated using both SDP and SDPng.)

   REQ DES-8: IMG metadata SHOULD support the description of differences
   between update version and old version of IMG metadata when IMG
   delivery mechanism carries updated IMG metadata and those differences
   are considerably little. (E.g. by providing a 'delta' of the two
   versions. This also relates the delivery property requirements for
   congestion control in Section 5.2.3).

6 Security Considerations

   Internet Media Guides are used to convey information about multimedia
   resources from one or more IMG senders across one or intermediaries
   to one or more IMG receivers. IMG metadata may be pushed to the IMG
   receivers or interactively retrieved by them. IMGs provide metadata
   as well as scheduling and rendezvous information about multimedia
   resources, etc. and requests for IMG metadata may contain information
   about the requesting users.

   The information contained in IMG metadata as well as the operations
   related to IMGs should be secured to avoid forged information,
   misdirected users, spoofed IMG senders, etc. and to protect user

   The remainder of section addresses the security requirements for

6.1 IMG Authentication and Integrity

   IMG metadata and its parts need to be protected against unauthorized
   altering/adding/deletion on the way. Their originator needs to be

   REQ AUT-1: It MUST be possible to authenticate the originator of a
   set of IMG metadata.

   REQ AUT-2: It MUST be possible to authenticate the originator of a
   subpart of IMG metadata (e.g. a delta or a subset of the

Y. Nomura et. al.                                            [Page 17]
Internet Draft              IMG Requirements         December 19, 2005

   REQ AUT-3: It MUST be possible to validate the integrity of IMG

   REQ AUT-4: It MUST be possible to validate the integrity of a subpart
   of IMG metadata (e.g. a delta or a subset of the information).

   REQ AUT-5: It MUST be possible to separate or combine individually
   authenticated pieces of IMG metadata (e.g. in an IMG transceiver)
   without invalidating the authentication.

   REQ AUT-6: It MUST be possible to validate the integrity of an
   individually authenticated piece of IMG metadata even after this
   piece had been separated from other pieces of IMG metadata and
   combined with other pieces to form new IMG metadata.

   REQ AUT-7: It MUST be possible to authenticate the originator of an
   IMG operation.

   REQ AUT-8: It MUST be possible to validate the integrity of any
   contents of an IMG operation (e.g. the subscription or inquiry

6.2 Privacy

   Customized IMG metadata and IMG metadata delivered by notification to
   individual users may reveal information about the habits and
   preferences of a user and may thus deserve confidentiality
   protection, even though the information itself is public.

   REQ PRI-1: It MUST be possible to keep user requests to subscribe to
   or retrieve certain (parts of) IMG metadata confidential.

   REQ PRI-2: It MUST be possible to keep IMG metadata, pieces of IMG
   metadata, or pointers to IMG metadata delivered to individual users
   or groups of users confidential.

   REQ PRI-3: It SHOULD be possible to ensure this confidentiality
   end-to-end, that is, to prevent intermediaries (such as IMG
   transceivers) from accessing the contained information.

6.3 Access Control for IMGs

   Some IMG metadata may be freely available, while access to other IMG
   metadata may be restricted to closed user groups (e.g. paying
   subscribers). Also, different parts of IMG metadata may be protected
   at different levels: e.g. metadata describing a media session may be
   freely accessible while rendezvous information to actually access the
   media session may require authorization.

Y. Nomura et. al.                                            [Page 18]
Internet Draft              IMG Requirements         December 19, 2005

   REQ ACC-1: It MUST be possible to authorize user access to IMG

   REQ ACC-2: It MUST be possible to authorize access of users to pieces
   of IMG metadata (delta information, subparts, pointers).

   REQ ACC-3: It MUST be possible to require different authorization for
   different parts of the same IMG metadata.

   REQ ACC-4: It MUST be possible to access selected IMG metadata

   REQ ACC-5: It MUST be possible for an IMG receiver to choose not to
   receive (parts of) IMG metadata in order to avoid being identified by
   the IMG sender.

   REQ ACC-6: It SHOULD be possible for an IMG transceiver to select
   suitable authorization methods which are compatible between both
   IMG senders and IMG receivers it interacts with.

   REQ ACC-7: It MAY be possible for IMG senders to require certain
   authorization that cannot be modified by intermediaries.

6.4 Denial-of-Service attacks

   Retrieving or distributing IMG metadata may require state in the IMG
   senders, transceivers, and/or receivers for the respective IMG
   transport sessions. Attackers may create large numbers of sessions
   with any of the above IMG entities to disrupt regular operation.

   REQ DOS-1: IMG operations SHOULD be authenticated.

   REQ DOS-2: It SHOULD be possible to avoid DoS attacks that build up
   session state in IMG entities to exhaust their resources.

   REQ DOS-3: It SHOULD be possible to avoid DoS attacks that exhaust
   resources of IMG entities by flooding them with IMG metadata.

   As an example, two potential solutions which may be considered are
   running an IMG entity in stateless mode or identification and
   discarding of malicious packets by an IMG entity.

6.5 Replay Attacks

   IMG metadata disseminated by an IMG sender or an IMG transceiver may
   be updated, deleted, or lose validity over time for some other
   reasons. Replaying outdated IMG metadata needs to be prevented.

Y. Nomura et. al.                                            [Page 19]
Internet Draft              IMG Requirements         December 19, 2005

   Furthermore, replay attacks may also apply to IMG operations (rather
   than just their payload). Replaying operations also needs to be

   REQ REP-1: IMG metadata MUST be protected against partial or full
   replacement of newer ("current") versions by older ones.

   In a system with multiple senders it may not be feasible to prevent
   some senders delivering older versions of metadata than others - as a
   result of imperfect sender-sender data consistency. Thus, replay
   attacks and delivery of inconsistent data requires that an IMG
   receiver veryfies that the IMG metadata is valid and reliable by
   using some security mechanism(s) (e.g. authorization, authentication
   or integrity).

   REQ REP-2: Mechanisms MUST be provided to mitigate replay attacks on
   the IMG operations.

   The level of threat from replay attacks varies very much depending on
   system scale and how well defined or open it is. Thus mitigating
   replay attacks may lead to different solutions for different systems,
   independent of the basic delivery method and metadata definitions. A
   system with multiple senders presents a more challenging scenario for
   handling replay attacks. As an example, bundling metadata with a
   security mechanism is one potential solution.

7 IANA Considerations

   This document does not request any IANA action.

8 Normative References

   [1] S. Bradner, "Key words for use in RFCs to indicate requirement
   levels," RFC 2119, Internet Engineering Task Force, March 1997.

9 Informative References

   [2] M. Handley and V. Jacobson, "SDP: session description protocol,"
   RFC 2327, Internet Engineering Task Force, April 1998.

   [3] M. Handley, C. E. Perkins, and E. Whelan, "Session announcement
   protocol," RFC 2974, Internet Engineering Task Force, October 2000.

   [4] Session Directory,

   [5] Session Directory Tool,

Y. Nomura et. al.                                            [Page 20]
Internet Draft              IMG Requirements         December 19, 2005

   [6] Digital Video Broadcasting Project,

   [7] D. Kutscher, J. Ott, and C. Bormann, "Session description and
   capability negotiation," Internet Draft draft-ietf-mmusic-sdpng-07,
   Internet Engineering Task Force, October 2003. Work in progress.

   [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

   [9] 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-09, Internet Engineering Task Force,
   December 2005. Work in progress.

   [10] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, L. Masinter, P.
   Leach and T. Berners-Lee, "Hypertext transfer protocol -- HTTP/1.1,"
   RFC 2616, Internet Engineering Task Force, June 1999.

   [11] A. B. Roach, "Session initiation protocol (sip)-specific event
   notification," RFC 3265, Internet Engineering Task Force, June 2002.

   [12] B. Quinn and K. Almeroth, "IP multicast applications: Challenges
   and solutions," RFC 3170, Internet Engineering Task Force, September

10 Acknowledgements

   The authors would like to thank Hitoshi Asaeda, Gonzalo Camarillo,
   Jean-Pierre Evain, Dirk Kutscher, Petri Koskelainen, Colin Perkins,
   Toni Paila and Magnus Westerlund for their excellent comments and
   ideas on this work.

11 Authors' Addresses

   Yuji Nomura
   Fujitsu Laboratories Ltd.
   4-1-1 Kamikodanaka, Nakahara-ku, Kawasaki 211-8588

   Rod Walsh
   Nokia Research Center
   P.O. Box 100, FIN-33721 Tampere

Y. Nomura et. al.                                            [Page 21]
Internet Draft              IMG Requirements         December 19, 2005

   Juha-Pekka Luoma
   Nokia Research Center
   P.O. Box 100, FIN-33721 Tampere

   Joerg Ott
   Universitaet Bremen
   MZH 5180
   Bibliothekstr. 1
   D-28359 Bremen

   Henning Schulzrinne
   Dept. of Computer Science
   Columbia University
   1214 Amsterdam Avenue
   New York, NY 10027

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

   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-

Y. Nomura et. al.                                            [Page 22]
Internet Draft              IMG Requirements         December 19, 2005

Disclaimer of Validity

   This document and the information contained herein are provided on

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.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Y. Nomura et. al.                                            [Page 23]