Internet Engineering Task Force                                MMUSIC WG
Internet Draft                                                 Y. Nomura
                                                           Fujitsu Labs.
                                                                R. Walsh
                                                              J-P. Luoma
                                                                   Nokia
                                                               H. Asaeda
                                                                   INRIA
                                                          H. Schulzrinne
                                                     Columbia University
draft-ietf-mmusic-img-framework-01.txt
draft-ietf-mmusic-img-framework-02.txt
December 2, 22, 2003
Expires: March June 2004

           A Framework for the Usage of 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 document defines a framework for the delivery of Internet Media
   Guides (IMGs). An IMG is a structured collection of multimedia
   session descriptions expressed using SDP, SDPng or some similar
   session description format. This document describes several use case
   scenarios requirering the IMG framework, a generalized
   model for IMG delivery mechanisms, and the use of existing protocol
   to create an IMG delivery infrastructure.

Table of Contents

   1          Introduction ........................................    3
   1.1        Background and Motivation ...........................    3
   1.2        Scope of this Document ..............................    4    2
   2          Terminology .........................................    4    3          Use Cases Requiring IMG Framework ...................    5
   3.1        Connectivity-based Use Cases ........................    5
   3.1.1      IP Datacast to a Wireless Receiver ..................    5
   3.1.2      Regular Fixed Dial-up Internet Connection ...........    6
   3.1.3      Broadband Always-on Fixed Internet Connection .......    6
   3.2        Content-orientated Use Cases ........................    6
   3.2.1      File Distribution ...................................    7
   3.2.2      TV and Radio Program Delivery .......................    7
   3.2.3      Media Coverage of a Live Event ......................    8
   3.2.4      Distance Learning ...................................    8
   3.2.5      Multiplayer Gaming ..................................    8
   4
   3          IMG Common Framework Model ..........................    8
   4.1    5
   3.1        IMG Data Types ......................................    9
   4.1.1    5
   3.1.1      Complete IMG Description ................................    9
   4.1.2 ............................    5
   3.1.2      Delta IMG Description ...................................    9
   4.1.3 ...............................    6
   3.1.3      IMG Pointer .............................................   10
   4.2 .........................................    6
   3.2        Operation Set for IMG Delivery ......................   10
   4.2.1    6
   3.2.1      IMG ANNOUNCE ........................................   10
   4.2.2    6
   3.2.2      IMG QUERY ...........................................   10
   4.2.3    7
   3.2.3      IMG RESOLVE .........................................   11
   4.2.4    7
   3.2.4      IMG SUBSCRIBE .......................................   11
   4.2.5    7
   3.2.5      IMG NOTIFY ..........................................   11
   4.3    8
   3.2.6      Binding Between IMG Operations and Data Types .......    8
   3.3        IMG Entities ........................................   12
   4.4    8
   3.4        Overview of Protocol Operations .....................   12
   5    9
   4          Deployment Scenarios for IMG Entities ...............   13
   5.1    9
   4.1        Intermediary Cases ..................................   13
   5.2   10
   4.2        One-to-many Unidirectional Multicast ................   15
   5.3   11
   4.3        One-to-one Bi-directional Unicast ...................   15
   5.4   12
   4.4        Combined Operations with Common Metadata ............   16
   6   12
   5          Applicability of Existing Protocols to the
   Proposed Framework Model .......................................   17
   6.1   13
   5.1        Summary of Limitations of Existing Protocols ........   17
   6.2   13
   5.2        Existing Protocol Fit to the IMG Framework Model
   6.3
   5.3        Outstanding IMG Mechanism Needs .....................   19
   6.3.1   16
   5.3.1      A Multicast Transport Protocol ......................   19
   6.3.2   16
   5.3.2      Usage of Unicast Transport Protocols ................   20
   6.3.3      The Metadata   17
   5.3.3      IMG Transfer Envelope ...............................   20
   6.3.4   17
   5.3.4      Baseline (Meta)Data Model Specification .............   21
   6.4   18
   5.4        IMG Needs Fitting the IETF's Scope ..................   22
   7   18
   6          Security Considerations .............................   23
   8   19
   7          Normative References ................................   24
   9   21
   8          Informative References ..............................   25
   10   22
   9          Acknowledgements ....................................   26
   11   22
   10         Authors' Addresses ..................................   26   22

1 Introduction

1.1 Background and Motivation

   Internet Media Guide (IMG) Guides (IMGs) provide and deliver structured
   collections of multimedia descriptions expressed using SDP, SDPng or
   some similar description format. It is They are used to describe sets of
   multimedia sessions (e.g. television program schedules, content
   delivery schedules etc.) and refer to other networked resources
   including web pages. IMGs provide an envelope for metadata formats
   and session descriptions defined elsewhere with the aim of
   facilitating structuring, versioning, referencing, distributing, and
   maintaining (caching, updating) such information.

   Firstly, this document explains several use case scenarios requiring
   the

   IMG framework. IMGs are inherently required to metadata must be independent delivered to a potentially large audience, who
   use it to join a subset of
   any particular access network, and link in general.  Therefore, they
   are suitable in many Internet access scenarios including fixed and
   mobile devices, wired and satellite and terrestrial radio, always-on
   Internet and intermittent connectivity, the sessions described, and so on. Furthermore, IMGs
   provides essential functions that facilitate better distribution who may need
   to be notified of
   content. Section 3 describes how IMGs and IMG delivery mechanisms
   contribute for the scenarios.

   Then, this document defines a generalized model for IMG delivery
   mechanisms and their deployment in network entities regarding the use
   case scenarios. IMG metadata must be delivered to a potentially large
   audience, who use it to join a subset of the sessions described, and
   who may need to be notified of changes to the changes to the IMG metadata. 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.

   Finally,

   This document defines a common framework model for IMG delivery
   mechanisms and their deployment in network entities.  There are three
   fundamental components in IMG framework model:  data types, operation
   sets and entities. These components specify a set of framework
   guideline for IMG delivery to efficiently deliver and describe IMG
   metadata. The data types give common base descriptions on top of an
   application-specific IMG metadata. IMG operations cover traditional
   broadcast-style scenarios, multicast-based distributions, unicast-
   based push and interactive retrievals similar to web pages.  Since we
   envision that any Internet host can be a sender and receiver of IMG
   metadata, an host involved in IMG operations perform one or more of
   roles defined as the entities in IMG framework model.  These are then
   shown in a number of simplified deployment scenarios. The
   requirements for IMG delivery mechanisms and descriptions can be
   found in [1].

   Then, this document outlines the use of existing protocols to create
   an IMG delivery infrastructure. It aims to organize existing
   protocols into common model and show their capabilities and
   limitations from the view point viewpoint of IMG delivery functions. One of the
   multicast-enabling IMG requirements is scaling well to a large number
   of hosts and IMG senders in a network. Another issue is the need for
   flexibility and diversity in delivery methods, whereas existing
   protocols tend to be bound to a specific application.

1.2 Scope of

2 Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this Document

   This
   document defines a common framework model for the delivery of are to be interpreted as described in RFC 2119 [2].

        Internet Media Guide (IMG) metadata. The framework describes existing
   mechanisms and the level (IMG): IMG is a generic term to which they support and enable describe
             the
   framework. The requirements for IMG delivery mechanisms and
   descriptions can be found in [1].

   A brief run through the usage and use cases of media guide is
   provided to illustrate the relevance of IMGs before the framework
   model is presented. The framework model defines the data types,
   operations and entities which are needed. These are then shown in a
   number of simplified deployment scenarios.

   Existing protocols are organized and referenced against the framework
   model to show the degree to which they fulfill IMG framework and
   requirements. This also makes it straightforward to identify gaps so
   that new protocols needs are made apparent.

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

        Internet Media Guide (IMG): IMG is a generic term to describe
             the formation, 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: This is a  A set of metadata describing 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, genre and access restrictions.

        IMG Description: A collection of IMG metadata which has a
             relationship to other IMG metadata. There are three data
             types to describe the relationship: Complete IMG
             Descriptions, Delta IMG Description and IMG pointer.

        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 IMGs IMG
             metadata to one or more IMG receivers.

        IMG Receiver: An IMG receiver is a logical entity that receives
             IMGs
             IMG metadata from an IMG sender.

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

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

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

3 Use Cases Requiring receiver(s).

        IMG Framework

3.1 Connectivity-based Use Cases

3.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 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 errors.

   To enable receivers to more accurately specify the metadata they are
   interested in, the unidirectional delivery is distributed between
   several logical channels. This is so that a receiver need only access
   the channels of interest and thus can reduce the amount of time and
   processing of IP data (and storage). Also, hierarchical channels
   enable receivers to subscribe to a root, possibly well known,
   multicast channel/group and progressively access only those
   additional channels based on metadata in parent channels.

   In some cases the receiver may be multi-access, such that it is
   capable of bi-directional communications. 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
   metadata.

   Thus, essential IMG features in this case include: robust
   unidirectional delivery (with optional levels of reliability
   including "plug-in FEC") 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).

3.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).

3.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 IMG QUERY, 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 more
   from local storage features than on-line browsing, especially if they
   have intermittent Internet access.

   Broadband enables rich media services, which are increasingly
   bandwidth hungry. Thus backbone operators may prefer multicast
   communications to reduce overall congestion, if they have the
   equipment and configuration to support this. Thus, broadband users
   may be forced to retrieve IMG metadata over multicast if the
   respective operators require this to keep system-wide bandwidth usage
   feasible.

3.2 Content-orientated Use Cases
   IMGs will be able to support a very wide range of use cases for
   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[3].  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
          metadata

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

3.2.1 File Distribution

   IMGs support the communication of file delivery session properties,
   enabling the scheduled delivery or synchronization of files between a
   number of hosts. For example, the metadata that IMGs provide could be
   subsequently used by a different application (outside the scope of
   IMGs) to download a file with a software update. Transport Session: An 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.
   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 capacity of delivery senders. In
   addition, IMG metadata can be used to synchronize a set of files association between a sender host and receiver host, when those files change as
   time elapses.

3.2.2 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.

   Similarly to file reception, 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 consuming later. 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 such changes, enabling users to be prompted or recording times to
   be adjusted.

3.2.3 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, sender and
             one or more IMG receivers within 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 scope of the players during a football match) may be sent to
   user terminals. Different an IMG
             transport modes or even different access
   technologies could be used for the different media: for example, a
   unidirectional datacast protocol.  An IMG transport could be used for the audio/video
   streams and an interactive cellular connection for the textual data. session involves a
             series of IMG metadata should enable terminals to discover the availability transport protocol interactions that provide
             delivery of
   different media used to cover a live event.

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

3.2.5 Multiplayer Gaming

   Multiplayer games are an example of real-time multiparty
   communication sessions that could be advertised using IMGs. IMG
             receiver(s).

        IMG Transfer: A gaming
   session could be advertised either by a dedicated server, or by the
   terminals transfer of individual users. A user could use IMGs to learn IMG metadata consisting of
   active multiplayer gaming sessions, or advertise the users interest
   in establishing such a session.

4 Complete
             IMG Descriptions, Delta IMG Descriptions and/or IMG
             Pointers.

3 IMG Common Framework Model

   Two common elements are found in all of existing IMG candidate cases:
   the need to describe the services; the need to deliver the
   descriptions. In some cases, the descriptions are multicast enablers
   (such as the session parameters of SDP) and are thus intrinsically
   part of the delivery aspects, and in other cases descriptions are
   application-specific (both machine and human readable). Thus, the
   technologies can be roughly divided into three areas:

        o Application-specific Metadata -- data describing the services'
          content and media which are both specific to certain
          applications and generally human readable.

        o Delivery Descriptors Descriptions -- the descriptors descriptions (metadata) that are
          essential to enable (e.g. multicast) delivery. These include
          framing (headers) for application-specific metadata, the
          metadata element identification and structure, fundamental
          session descriptors. descriptions.

        o Delivery Protocols -- the methods and protocols to exchange
          descriptions between the senders and the receivers.  An IMG
          delivery
          transport protocol consists of two functions: carrying IMG
          metadata from an IMG sender to an IMG receiver and controlling
          an IMG transport protocol. These functions are not always
          exclusive, therefore some messages may combine control
          messages and metadata carriage functions metadata to reduce
          the amount of the messaging.

4.1

3.1 IMG Data Types

   A data model is needed to precisely define the terminology and
   relationships between sets, supersets and subsets of metadata. A
   precise data model is essential for the implementation of IMGs
   although it is not within the scope of this framework and requires a
   separate specification. However there are three IMG data types in
   general: Complete description, delta description IMG Descriptions, Delta IMG Description and pointer.

4.1.1 IMG
   Pointer.

3.1.1 Complete IMG Description

   A Complete IMG Description provides a complete syntax and semantics
   to describe a set of metadata, which does not need any additional
   information from any other IMG entity. element.

   Note, this is not to be confused with "complete IMG metadata", which,
   although vaguely defined here, represents the complete IMG metadata
   database of a an IMG sender (or related group of IMG senders --
   potentially the complete Internet IMG knowledge). A An IMG sender will
   generally deliver only subsets of metadata from its complete database of metadata
   in a particular
   data exchange.

4.1.2 IMG transport session.

3.1.2 Delta IMG Description

   A Delta IMG Description provides only part of a Complete IMG
   Description, defining the difference from a previous version of the
   Complete IMG Description in question. This descriptor Delta transfers may be used to
   reduce network resource usage (it may be more bandwidth and
   congestion friendly), for instance, instance when data consistency is essential and,
   and small and frequent changes occur to the Complete Description. IMG elements. Thus, this
   descriptor
   description itself cannot represent complete metadata set until it is
   combined with existing, or future, description knowledge.

4.1.3

3.1.3 IMG Pointer

   A pointer provided

   An IMG Pointer provides a simple identifier or locator, such as a URL,
   URI, that the IMG receiver is able to reference (or reference and
   locate) specific metadata with. This may be used to separately obtain
   metadata (complete (Complete or delta descriptions) Delta IMG Descriptions) or perform another IMG
   management function such as data expire (and erasure). The pointer IMG
   Pointer may be used to reference IMG metadata elements within the IMG
   transport session and across IMG transport sessions. The This pointer
   type does not include metadata par per se (although it may also appear as
   a data field in complete Complete or delta Delta IMG descriptors).

4.2

3.2 Operation Set for IMG Delivery

   A finite set of operations both meets the IMG requirements [2] [1] and
   fits the roles of existing protocols. These are crystallized in the
   next few sections.

4.2.1

3.2.1 IMG ANNOUNCE

   When an IMG receiver participates in unidirectional communications
   (e.g. over satellite, terrestrial radio and wired multicast networks)
   an IMG receiver may not need to send any message to an IMG sender
   prior to IMG metadata delivery. In this case, an IMG sender can
   initiate unsolicited distribution for IMG metadata and an IMG sender
   is the only entity which can maintain the distribution (this includes
   scenarios with multiple and co-operative IMG senders). This operation
   is useful when there are considerably large number IMG receivers or
   IMG receiver(s) do not have a guaranteed uplink connection to the IMG
   sender(s). The IMG sender may also include authentication data in the
   announce operation so that IMG receivers may check the authenticity
   of the metadata. This operation is able to carry any of the IMG data- data
   types.

   Note, there is no restriction to prevent IMG ANNOUNCE from being used
   in an asynchronous solicited manner, where a separate operation
   (possibly out of band) is able to subscribe/register IMG receivers to
   the IMG ANNOUNCE operation.

4.2.2

3.2.2 IMG QUERY

   If an IMG receiver needs to obtain IMG metadata, an IMG receiver can
   send an IMG QUERY message and initiate a receiver-driven IMG delivery
   transport session. The IMG receiver expects a synchronous response to
   the subsequent request from the IMG sender. This operation can be
   used where a bi-directional transport network is available between
   the IMG sender and receiver. Some IMG receivers may want to obtain
   IMG metadata when a resource is available or just to avoid caching
   unsolicited IMG metadata. The IMG receiver must indicate the extent
   and data type of metadata wanted in some message in the operation
   (Extent indicates the number and grouping of metadata descriptions).
   In some cases requesting a an IMG sender's complete IMG metadata may be
   feasible, in others it may not.

4.2.3

3.2.3 IMG RESOLVE

   An IMG sender synchronously responds and sends IMG metadata to an IMG
   QUERY which has been sent by an IMG receiver. This operation can be
   used where a bi-directional transport network is available between
   the IMG sender and receiver. If the IMG QUERY specifies a subset of
   IMG metadata (extent and data type) that is available to the IMG sender has the
   subset,
   sender, the IMG sender can resolve this, otherwise query; otherwise, it should
   indicate that it is not able to resolve the query. The IMG sender may
   authenticate the IMG receiver to investigate the IMG QUERY operation
   in order to determine whether the IMG receiver is authorized to be
   sent that metadata. The sender may also include authentication data
   in the resolve operation so that IMG receivers may check the
   authenticity of the metadata. This operation may carry any of the IMG
   data types.

4.2.4

3.2.4 IMG SUBSCRIBE

   If an IMG receiver wants to be notified when metadata which the IMG
   receiver metadata it
   holds is stale, the IMG receiver can start use the IMG SUBSCRIBE operation prior
   in advance in order to solicit notify messages. messages from an IMG sender.
   Since the IMG receiver doesn't know when metadata will be updated and
   the notify message will arrive, this operations operation does not synchronize
   with the notify message. messages. The IMG receiver may wait for the notify message
   messages for a long time. The IMG sender may authenticate the IMG receiver IMG sender may authenticate the IMG
   receiver to investigate whether an IMG SUBSCRIBE operation is from an
   authorized IMG receiver.

3.2.5 IMG NOTIFY

   An IMG NOTIFY is used in response to an earlier IMG SUBSCRIBE.  An
   IMG NOTIFY generates a notify message indicating that updated IMG
   metadata is available or part of the existing IMG metadata is stale.
   An IMG NOTIFY may be delivered more than once during the time an IMG
   SUBSCRIBE is active. This operation may carry any of the IMG data
   types. The IMG sender may also include authentication data in the IMG
   NOTIFY operation so that IMG receivers may check the authenticity of
   the messages.

3.2.6 Binding Between IMG Operations and Data Types

   There is a need to provide a binding between the various IMG
   operations and IMG data types to allow management of each discrete
   set of IMG metadata transferred using an IMG operation. This binding
   must be independent of any particular metadata syntax used to
   represent a set of IMG metadata, as well as be compatible with any
   IMG transport protocol. The binding must uniquely identify the set of
   IMG metadata delivered within an IMG transfer, regardless of the
   metadata syntax used. The uniqueness may only be needed within the
   domains the metadata is used but this must enable globally unique
   identification to support Internet usage. Scope/domain specific
   identifications should not 'leak' outside of the scope, and always
   using globally unique identification (e.g. based on URIs) should
   avoid this error.

   The binding must provide versioning to
   investigate whether an IMG SUBSCRIBE operation is from an authorized
   receiver.

4.2.5 IMG NOTIFY

   An IMG receiver needs the response to an earlier transferred IMG SUBSCRIBE metadata
   so that changes can be easily handled and stale data identified, and
   give temporal validity of the transferred IMG NOTIFY indicates that updated metadata. It must
   expire the IMG metadata is available or
   part of by indicating an expiry time, and may
   optionally provide a time (presumably in the future) from when the existing
   IMG metadata is stale. An becomes valid. Temporal validity of IMG NOTIFY metadata may be
   delivered more than once during the time
   changeable for an IMG SUBSCRIBE is active.
   This operation may carry any transfer, and even for specific versions of the
   IMG data types. The sender may
   also include authentication data in the notify operation so that
   receivers may check transfer. Furthermore, the authenticity binding must be independent of the messages.

4.3
   metadata syntax(es) used for the IMG metadata, in the sense that no
   useful syntax should be excluded.

3.3 IMG Entities

   There are several fundamental IMG entities that indicate the
   capability to perform certain roles. An Internet host involved in IMG
   operations may adopt one or more of these roles:

   IMG Announcer : send IMG ANNOUNCE

   IMG Listener : receive IMG ANNOUNCE
   IMG Querier : send IMG QUERY to receive IMG RESOLVE

   IMG Resolver : receive IMG QUERY then send IMG RESOLVE

   IMG Subscriber: send IMG SUBSCRIBE then receive IMG NOTIFY

   IMG Notifier : receive IMG SUBSCRIBE then send IMG NOTIFY

   Finally, the figure 1 shows a relationship between IMG entities and the
   IMG sender and receiver.

        +--------------------------------------------------------+
        |                      IMG Sender                        |
        +------------------+------------------+------------------+
        |  IMG Announcer   |   IMG Notifier   |    IMG Resolver  |
        +------------------+------------------+------------------+
                |                    ^                  ^
   message      |                    |                  |
   direction    v                    v                  v
        +------------------+------------------+------------------+
        |   IMG Listener   |  IMG Subscriber  |    IMG Querier   |
        +------------------+------------------+------------------+
        |                      IMG Receiver                      |
        +------------------+------------------+------------------+

   Figure 1: Relationship with IMG Entities

4.4

3.4 Overview of Protocol Operations

   The figure 2 gives an overview of the relationship between transport
   cases, IMG Operations and IMG data types (note, it is not a protocol
   stack).

4 Deployment Scenarios for IMG Entities

   This section provides some basic deployment scenarios for IMG
   entities that illustrate common threads from protocols to use cases.
   For the purposes of clarity, this document presents the simple
   dataflow from an IMG sender to an IMG receiver, as shown in figure 3.

               +--------------------------------------------------+
    IMG        |                                                  |
    Data types |       Complete Desc., Delta Desc., Pointer       |
               |                                                  |
               +-------------------+----------------+-------------+
    IMG        |    IMG ANNOUNCE   |  IMG SUBSCRIBE |  IMG QUERY  |
    Operations |                   |  IMG NOTIFY    | IMG RESOLVE |
               +--------------+----+----------------+-------------+
    IMG        |              |                                   |
    Transport  |   P-to-M     |              P-to-P               |
               |              |                                   |
               +--------------+-----------------------------------+

   Figure 2: IMG Operations and IMG Data type

5 Deployment Scenarios for IMG Entities

   This section provides some basic deployment scenarios for IMG
   entities that illustrate common threads from protocols to use cases.
   For the purposes of clarity, this document presents the simple
   dataflow from sender to receiver as shown in figure 3

            +-------------+                +---------------+
            | IMG Sender  |                | IMG Receiver  |
            |             |--------------->|               |
            +-------------+                +---------------+

   Figure 3: A Simple IMG Sender to IMG Receiver Relationship

5.1

4.1 Intermediary Cases

   Some IMG metadata may be distributed to a large number of IMG
   receivers. If, for example, some IMG metadata is public information
   and the IMG sender provides the same information for all IMG
   receivers. This kind of IMG metadata may be distributed from one IMG
   sender to multiple IMG receivers (Figure 4) and/or or may be relayed
   across a set of IMG transceivers that receive the IMG metadata,
   possibly filter or modify its content, and then forward it. The
   relayed network architecture is similar to content distribution
   network architecture [3] (CDNs). Existing CDNs may carry IMG
   metadata. Satellite and peer-to-peer networks may also carry IMG
   metadata.

    +----------+                                    +----------+
    | IMG      |                                    | IMG      |
    | Sender   |----                           ---->| Receiver |
    +----------+    \                         /     +----------+
                     \                       /
         .            \   +-----------+     /            .
         .             -->|IMG        |-----             .
         .             -->|Transceiver|     \            .
                      /   +-----------+      \
    +----------+     /                        \     +----------+
    | IMG      |    /                          ---->| IMG      |
    | Sender   |----                                | Receiver |
    +----------+                                    +----------+

   Figure 4: A Relay Network with an IMG Transceiver

   IMG senders and receivers are logical functions and it is possible
   for some or all hosts in a system to perform both roles, as, for
   instance, in many-to-many communications or where a transceiver is
   used to combine or aggregate IMG metadata for some IMG receivers. An
   IMG receiver may be allowed to receive IMG metadata from any number
   of IMG senders.

   The

   IMG metadata is used to find, obtain, manage and play content.
   The IMG
   metadata distribution distributions may be modified as they are distributed. For
   example, a server may use IMGs to retrieve media content via unicast
   and then make it available at scheduled times via multicast, thus
   requiring a change of the corresponding metadata. IMG transceivers
   may add or delete information or aggregate IMG metadata from
   different IMG senders. For example, a rating service may add its own
   content ratings or recommendations to existing meta-data. An
   implication of changing (or aggregating) IMG metadata from one or
   more IMG senders is that the original authenticity is lost. Thus for
   deployments requiring these kind of features, the original metadata
   should be reasonably fragmented already (allowing the intermediary to
   replace a small fragment without changing the authenticity of the
   remainder). It may be beneficial to use smaller fragments for more
   volatile parts, and larger one for more stable parts.

5.2

4.2 One-to-many Unidirectional Multicast

   This case implies many IMG receivers and one or more IMG senders
   implementing IMG ANNOUNCER and IMG LISTENER operations as shown in
   figure 5.

               Unidirectional            +----------+
              --------------->           |   IMG    |
                  downlink               | Listener |
                           ------------->|    1     |
                          /              +----------+
    +-----------+        /                    .
    | IMG       |--------                     .
    | Announcer |        \                    .
    +-----------+         \              +----------+
                           ------------->|   IMG    |
                                         | Listener |
                                         |    #     |
                                         +----------+

   Figure 5: IMG Unidirectional Multicast Distribution Example

5.3

4.3 One-to-one Bi-directional Unicast

          +----------+                +----------+
          |   IMG    |<------(1)------|   IMG    |
          | Resolver |-------(2)----->| Querier  |
          +----------+                +----------+

   Figure 6: Query/Resolve Deployment Example

   Both query/resolve (figure 6) and subscribe/notify (figure 7) message
   exchange operations are feasible.

         +----------+                   +------------+
         |          |<-------(1)--------|            |
         |   IMG    |--------(2)------->|    IMG     |
         | Notifier |   (time passes)   | Subscriber |
         |          |--------(3)------->|            |
         +----------+                   +------------+

   Figure 7: Subscribe/Notify Deployment Example

5.4

4.4 Combined Operations with Common Metadata

   As shown in figure 8, a common data model for multiple protocol
   operations allows a diverse range of IMG senders and receivers to
   provide consistent and interoperable IMGs. sets of IMG metadata.

         +----------+                   +------------+
         |          |<-------(1)--------|            |
         |   IMG    |--------(2)------->|    IMG     |
         | Notifier |   (time passes)   | Subscriber |
         |          |--------(3)------->|            |
         +----------+                   +------------+

   Figure 7: Subscribe/Notify Deployment Example

    IMG Metadata             IMG Senders             IMG Receivers

                                                     +--------------+
                             +-----------+      ---->| IMG Listener |
                             | IMG       |     /     +--------------+
                            /| Announcer |-----
    +-------------+        / +-----------+     \     +--------------+
    |    IMG      |-+     /                     ---->| IMG Listener |
    | Description | |-+  /                           | - - - - - - -|
    | metadata  1 | | | /    +-----------+      /--->| IMG Querier  |
    +-------------+ | | -----| IMG       |<----/     +--------------+
      +-------------+ | \    | Resolver  |
        +-------------+  \   +-----------+<----\     +--------------+
                          \                     \--->| IMG Querier  |
                           \ +-----------+           | - - - - - - -|
                            \| IMG       |<--------->| IMG          |
                             | Notifier  |           | Subscriber   |
                             +-----------+           +--------------+

   Figure 8: Combined System with Common Metadata

6

5 Applicability of Existing Protocols to the Proposed Framework Model

6.1

5.1 Summary of Limitations of Existing Protocols

   SDP [4] has a text-encoded syntax to specify multimedia sessions for
   announcements and invitations. Although SDP is extensible, it has
   limitations such as structured extensibility and capability to carry
   another
   reference properties of a multimedia session descriptors. from the description of
   another session.

   These are mostly overcome by the XML-based SDPng [5] , [5], 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.

   MPEG-7 [6] is a collection of XML-based description tools for general
   multimedia content including structured multimedia sessions. TV-
   Anytime Forum [7] provides descriptions based on MPEG-7 for TV
   specific program guides. These are likely to be limited to describe
   pictures, music and movies, thus it may be necessary to extend these
   descriptions in order to define a variety of documents, game
   programs, binary files, live event events and so on.

   HTTP [8] 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 [9] is an announcement protocol that distributes session
   descriptions via multicast. It does not support fine-grained meta
   data metadata
   selection and update notifications, as it always sends the whole
   meta data.
   metadata. Given the lack of a wide-area multicast infrastructure, it
   is likely only deployable within a local area network.

   SIP [10] and SIP-specific event notification [11] can be used to
   notify subscribers of the update of IMG metadata for bi-directional
   transport. It is necessary for SIP Event to define an event package
   for each specific application such as [12].

6.2

5.2 Existing Protocol Fit to the IMG Framework Model

   SDP: The SDP format could be used to describe session-level
   parameters (e.g. scheduling, addressing and the use of media codecs)
   to be included in Complete Descriptors. IMG Descriptions. Although there are
   extension points in SDP allowing the format to be extended, there are
   limitations in the flexibility of this extension mechanism. However,
   SDP syntax can not cannot provide with Partial Descriptors Deleta IMG Descriptions and IMG Pointers
   without significant unused overhead. Because it is expected that the
   information conveyed by SDP is just a small subset of IMG metadata
   the use of SDP for other than session-level IMG parameters may not be
   reasonable.

   SDPng: Similar to SDP, this format could also be used for
   representing session-level parameters of IMG metadata. Compared to
   SDP, the XML-based format of SDPng is much more flexible with regards
   to extensions and combining with other description formats.

   MPEG-7: Descriptions based on the MPEG-7 standard could provide
   application-specific metadata describing the properties of multimedia
   content beyond parameters carried in SDP or SDPng descriptions.
   MPEG-7 provides a machine-readable format of representing content
   categories and attributes, helping end-users or receiving software in
   choosing content for reception: this is well in line with the IMG
   usage scenarios of IMGs introduced in 3.2. Because MPEG-7 is based on
   XML, it is well suited for combining with other XML-based formats
   such as SDPng.

   HTTP: The HTTP protocol can be used as a bi-directional/unicast IMG
   transport protocol. Being a request-reply oriented protocol, HTTP is
   well suited for implementing synchronous operations such as QUERY,
   RESOLVE and even SUBSCRIBE. However, HTTP does not provide
   asynchronous operations such as ANNOUNCE and NOTIFY and to implement
   asynchronous operations using HTTP, IMG receivers should poll the IMG
   sender periodically. So alone, HTTP is not sufficient to fulfill IMG
   requirements in a unicast deployment.

   SAP: The announcement mechanism provided by SAP provides
   unidirectional delivery of session discovery information. Although
   SDP is the default payload format of SAP, the use of a MIME type
   identifier for the payload allows arbitrary payload formats to be
   used in SAP messages. Thus, SAP could be used to implement the
   (multicast and unicast) IMG ANNOUNCE and IMG NOTIFY operations.
   However, the limitations of SAP as a generic IMG transport protocol
   include:

   - Lack of reliability (through forward error correction /
   retransmissions)

   - Lack of payload segmentation

   - Limited payload size

   - Only one description allowed per SAP message

   - Lack of congestion control

   - Lack of Internet standard authentication / encryption mechanisms

   - It is an Experimental RFC with no support for progressing further

   In principle, the current SAP protocol could be extended to get
   around its limitations (e.g. the use of a multipart MIME type in the
   SAP payload has been proposed, enabling multiple descriptions to be
   carried in a single SAP message). However, the amount of changes
   needed in SAP to address all of the above limitations would
   effectively result in a new protocol. Due to these limitations, the
   use of SAP as an IMG transport protocol is not recommended.

   SIP: The SIP-specific event mechanism described in RFC 3265 [11]
   provides a way to implement IMG SUBSCRIBE and IMG NOTIFY operations
   via a bi-
   directional bi-directional unicast connection. However, there are
   scalability problems with this approach, as RFC 3265 currently does
   not consider multicast.

6.3

5.3 Outstanding IMG Mechanism Needs

   Several outstanding needs result from the IMG requirements, framework
   model and existing relevant mechanisms as already shown in this
   document. Four specific groupings of work are readily apparent which
   are: (a) specification of an adequate multicast and unidirectional
   capable announcement protocol; (b) specification of the use of
   existing unicast protocols to enable unicast subscribe and
   announcement/notification functionality; (c) specification of the
   metadata envelope which is common to, and independent of, the
   application metadata syntax(es) used; agreement on basic metadata
   models to enable interoperability testing of the above. The following
   sections describe each of these.

6.3.1

5.3.1 A Multicast Transport Protocol

   SAP is currently the only open standard protocol suited to the
   unidirectional/multicast delivery of IMG metadata. As discussed, it
   fails to meet the IMG requirements in many ways and, since it is not
   designed to be extensible, we recognize that a new multicast
   transport protocol for announcements needs to be specified to meet
   IMG needs. This protocol will be essential to IMG delivery for
   unidirectional and multicast deployments.

   The Asynchronous Layered Coding (ALC) [13] protocol from the IETF
   Reliable Multicast Transport (RMT) working group is very interesting
   as it fulfils many of the requirements, is extensible and has the
   ability to `plug-in' both FEC (Forward Error Correction -- for
   reliability) and CC (Congestion Control) functional blocks -- it is
   specifically designed for unidirectional multicast object transport.
   ALC is not fully specified, although RMT has a work-in-progress fully
   specified protocol using ALC called FLUTE (File Delivery over
   Unidirectional Transport) [14]. FLUTE seems to be the only fully
   specified transport and open specification on which a new IMG
   announcement protocol could be designed. Thus we recommend that ALC
   and FLUTE be the starting points for this protocol's design.

   Developing a new protocol from scratch, or attempting to improve SAP,
   is also feasible, although it would involve repeating many of the
   design processes and decisions already made by the IETF for ALC.
   Thus, we recommend only to attempt this if ALC-based protocols are
   later found to be insufficient.

   In particular, any announcement protocol must feature sufficient
   scalability, flexibility and reliability to meet IMG needs. Also, the
   ANNOUNCE operation must be supported and also NOTIFY capability could be
   investigated for both hybrid unicast-multicast and unidirectional
   unicast systems.

6.3.2

5.3.2 Usage of Unicast Transport Protocols

   A thorough description of the use of existing unicast protocols is
   essential for the use of IMGs in a unicast and point-to-point
   environment. Such a specification does not currently exist, although
   several usable unicast transport protocols and specifications can be
   harnessed for this (SIP, SIP events, HTTP, etc). In particular, both
   SUBSCRIBE-NOTIFY and QUERY-RESOLVE operation pairs must be enabled.
   We anticipate that the FETCH operation will be a trivial usage of
   HTTP, although other transport options may be beneficial to consider
   too.

6.3.3 The Metadata Envelope

   To be able to handle multiple metadata syntaxes, a common minimal set
   of information is needed to handle discrete blocks of metadata. The
   IMG framework model data types defined in this document. This minimal
   set of information field will be named a `metadata envelope' and
   must:

        1.   Uniquely identify the block of metadata, regardless of
             metadata syntax used. The uniqueness may only be needed
             within the domains the metadata is used but this must
             enable globally unique identification to support Internet
             usage. Scope/domain specific identifications should not
             `leak' outside of the scope, and always using globally
             unique identification (e.g. based on URIs) should avoid
             this error.

        2.   Version the block so that changes can be easily handled this (SIP [10], SIP events [11], HTTP [8], etc.) In
   particular, both SUBSCRIBE-NOTIFY and
             stale data identified.

        3.   Give the temporal validity of the block. It QUERY-RESOLVE operation pairs
   must expire be enabled.  We anticipate that the
             block (expiry time), and may optionally provide FETCH operation will be a time
             (presumably in the future) from when the block becomes
             valid. Temporal validity
   trivial usage of HTTP, although other transport options may be changeable
   beneficial to consider too.

5.3.3 IMG Transfer Envelope

   Section 3.2.6 of this document discussed the need for a block, binding between
   IMG Operations and
             even Data Types. Such a specific version of binding can be realized by
   defining a block.

        4.   Be independent common minimal set of the metadata syntax(es) used for the information needed needed to manage
   IMG metadata block, in the sense that no useful syntax should
             be excluded.

   For blocks transfers, and by including this information with multiple descriptors, it is assumed that any
   descriptors inherit the parameters
   set of the (super)blocks. Thus the
   above information will implicitly describe the individual
   descriptors. IMG metadata delivered to IMG receiver(s).

   Four options for metadata IMG transfer envelope transport delivery are feasible:

        1.   Embedding in a transport protocol header. This can be done
             with either header extensions of existing protocols, or
             newly defined header fields of a new (or new version of a)
             transport protocol.  However, multiple methods for the
             variety of transport protocols may hinder interoperability.

        2.   A separate envelope object (a form of metadata itself)
             delivered in-band with the metadata. This would complicate
             delivery as the envelope and `service' metadata objects
             would have to be bound, e.g. by pairing some kind of
             transport object numbers (analogous to port number pairs
             sometimes used for RTP and RTSP).

        3.   A metadata wrapper which points to and/or embeds the
             service metadata into its `super-syntax'. For example, XML
             enables referencing (pointing to) other resources as well
             as embedding generic text objects.

        4.   Embedding in the metadata itself. However, this requires
             new field in many metadata syntaxes and would not be
             feasible if a useful syntax were not capable of
             extensibility in this way. It also introduces a larger
             'implementation interpretation' variety which would hinder
             interoperability. Thus this option is not recommended.

6.3.4 Baseline (Meta)Data Model Specification

   It is likely that more than one of these options will fulfill the
   needs of IMGs so the selection, and possibly optimization, is left
   for subsequent specification and feedback from implementation
   experience. Such a specification is essential for IMG delivery and so
   should be an official IETF work item.

   Relevant work-in-progress ensures that support of one, or very few,
   metadata syntaxes is not sufficient. Whereas the transport protocol
   should not restrict the metadata format, the metadata envelope may
   influence the choice metadata. However, metadata in binary format
   should not be prevented, in addition to the more abundant text and
   XML syntaxes currently available.

   In most cases the actual content of metadata will be application, or
   service domain, specific. For instance, digital cinema distribution
   and television channels will have many different requirements. The
   task of specifying these options will fulfill the bulk
   needs of IMGs so the world's metadata selection, and possibly optimization, is well beyond
   the scope of this document: left
   for subsequent specification and feedback from implementation
   experience. Such a framework specification is essential for the IMG delivery of and so
   should be an official IETF work item.

   When there are superset/subset relations between IMG
   metadata. We do anticipate descriptions, it
   is assumed that existing and future metadata
   specifications, including those the IMG descriptions of several working groups and
   standardization bodies, shall be able to use the services subset inherit the
   parameters of the superset. Thus, an IMG
   framework. However, it is not essential to transfer envelope carrying
   the current IMG work descriptions of a superset may implicitly define parameters
   of IMG descriptors belonging to
   specify standards with application-specific metadata.

   It is essential that the three its subset. The relations between IMG data types are enabled, but it
   descriptions may
   not be necessary span from one IMG transfer envelope to achieve this for every metadata syntax available,
   nor another.

5.3.4 Baseline (Meta)Data Model Specification

   A minimal IMG data model may it be important to the IETF useful to cover every possibility for
   this. Generally, Complete Descriptions will any implementer/deployment
   of IMGs. The purpose would be correct for existing to ensure that multiple metadata
   syntaxes (e.g. for XML may (SDP, MPEG-7, etc) can be validated according to existing
   schema). Pointer related within the same body of
   IMG knowledge, regardless of any specific metadata and data types may be served models
   provided by a new syntax (extremely
   minimal), although it is feasible that the proposed metadata envelope
   specification will contain enough information to implement the
   Pointer data type. Partial Descriptions syntaxes.

   Further work may need new or modified
   syntaxes be needed to meet application-specific requirements
   at defining metadata and semantics (e.g. XML schema) as mandatory fields data models for a
   Complete Description may the successful deployment of
   IMGs in various environments. Existing (and future) work on these
   would need to be redundant for a Partial Description.
   During and following mapped to the specification IMG data types and use of the metadata envelope,
   enabling the delivery of Partial Descriptions should be considered.

   To gain implementation experience, it IMG
   transfer envelope concept as described above.

   This document is essential to agree a framework for the basic delivery of some metadata in interoperability tests and subsequently in
   widespread deployments. So we anticipate that a minimal IMG data
   model would be useful to Metadata and
   thus further discussion on the Internet community.

6.4 definition data models for IMGs is
   beyond its scope.

5.4 IMG Needs Fitting the IETF's Scope

   A Multicast Transport Protocol is essential to IMG delivery for
   unidirectional and multicast deployments and no alternative exists
   which fulfils the IMG requirements. We recommend that the
   specification of this be taken on as an official work item in the
   IETF.

   Specification of the usage of unicast transport protocols is
   essential for IMG delivery and control involving unicast
   communications, and will relate to existing IETF standard transport
   protocols. Thus, we recommend that the specification of this be taken
   on as an official work item in the IETF.

   The metadata IMG transfer envelope functionality is essential for the IMG
   delivery fulfilling the IMG requirements. It is a required feature
   for IMG metadata transport and maintenance. Thus, we recommend that
   the
   metadata IMG transfer envelope specification be taken on as an official
   work item in the IETF.

   (Meta)data model specification and application specific metadata do
   not easily fit into the IETF scope and several other standardization
   bodies are well placed to do this work. We recommend that aspect
   shall not be an official IETF work item.

   Note, we acknowledge the need to exchange and agree on a baseline
   metadata model and application specific metadata for the purposes of
   interoperability testing between different implementations of IMG
   related IETF protocols. However, we feel that the IETF standards
   process is not required for this.

7

6 Security Considerations

   The IMG framework is developed from the IMG Requirements document [2] [1]
   and so the selection of specific protocols and mechanism for use with
   the IMG framework must also take into account the security
   considerations of the IMG Requirements document. This framework
   document does not mandate the use of specific protocols. However, an
   IMG specification would inherit the security considerations of
   specific protocols used, although this is outside the scope of this
   document.

   Protocol instantiations which are used to provide IMG operations will
   have very different security considerations depending on their scope
   and purpose. However, there are several general issues which are
   valuable to consider and, in some cases, provide technical solutions
   to deal with. These are described below.

   Individual and Group Privacy: Customized IMG metadata may reveal
   information about the habits and preferences of a user and may thus
   deserve confidentiality protection, even though if the original information
   itself is
   were public. Capturing Snooping and protecting this IMG metadata requires the
   same actions and measures as for other point-to-point and multicast
   Internet communications. Naturally, the risk of snooping depends on
   the amount of individual or group personalization the snooped sessions
   contain. IMG
   metadata contains. Further consideration is valuable at both
   transport and metadata levels.

   IMG Authenticity: In some cases, the IMG receiver needs to be assured
   of the origin of IMG metadata or its modification history. This can
   prevent denial of service or hijacking attempts which give an IMG
   receiver incorrect information in or about the metadata, thus
   preventing successful access of the media or directing the IMG
   receiver to the incorrect media possibly with tasteless material.
   Action upon detection of unauthorized data insertion is out of scope
   of this document.

   IMG Receiver Authorization: Some or all of any IMG sender's metadata
   may be private or valuable enough to allow access to only certain IMG
   receivers and thus make it worth authenticating users. Encrypting the
   data is also a reasonable step, especially where group communications
   methods results in unavoidable snooping opportunities for
   unauthorized nodes. Encryption and the required security parameters
   exchange are outside the scope of this document.

   Unidirectional Specifics: A difficulty that is faced by
   unidirectional delivery operations is that many protocols providing
   application-level security are based on bi-directional
   communications. The application of these security protocols in case
   of strictly unidirectional links is not considered in the present
   document.

   Malicious Code: Currently, IMGs are not envisaged to deliver
   executable code at any stage. However, as some IMG transport
   protocols may be capable of delivering arbitrary files, it is
   RECOMMENDED that the FLUTE delivery service does not have write
   access to the system or any other critical areas.

   Protocol Specific Attacks: It is recommended that developers of any
   IMG protocol take account of the above risks in addition to any
   protocol design and deployment environment risks that may be
   reasonably identified. Currently this framework document does not
   recommend or mandate the use of any specific protocols, however the
   deployment of IMGs using specific protocol instantiations will
   naturally be subject to the security considerations of those
   protocols.

   Security Improvement Opportunity: The security properties of one
   channel and protocol can be improved through the use of another
   channel and protocol. For example, a secure unicast channel can be
   used to deliver the keys and initialization vectors for an encryption
   algorithm used on a multicast channel. The exploitation of this
   opportunity is specific to the protocols used and is outside the
   scope of this document.

8

7 Normative References

   [1] Y. Nomura, "Protocol requirements for Internet media guides,"
   Internet Draft draft-ietf-mmusic-img-req-02, Internet Engineering
   Task Force, Dec.  2003.  Work in progress.

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

   [2] Y. Nomura et al., "Protocol requirements for Internet media
   guides," Internet Draft draft-ietf-mmusic-img-req-00, Internet
   Engineering Task Force, Sept. 2003.  Work in progress.

   [3] M. Day, B. Cain, G. Tomlinson, and P. Rzewski, "A model for
   content internetworking (CDI)," RFC 3466, Internet Engineering Task
   Force, Feb.  2003.

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

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

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

   [7] T.-A. Forum, "Metadata specification S-3," TV-Anytime Forum
   Specification SP003v1.2 Part A, TV, TV-Anytime Forum, June 2002.

   [8] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, and T. Berners-
   Lee, "Hypertext transfer protocol -- HTTP/1.1," RFC 2068, Internet
   Engineering Task Force, Jan. 1997.

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

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

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

   [13] M. Luby, J. Gemmell, L. Vicisano, L. Rizzo, and J. Crowcroft,
   "Asynchronous layered coding (ALC) protocol instantiation," RFC 3450,
   Internet Engineering Task Force, Dec. 2002.

9

8 Informative References

   [12] J. Rosenberg, "A presence event package for the session
   initiation protocol (SIP)," internet draft, Internet Engineering Task
   Force, Jan. 2003.  Work in progress.

   [14] T. Paila, "FLUTE - file delivery over unidirectional transport,"
   Internet Draft draft-ietf-rmt-flute-06, draft-ietf-rmt-flute-07, Internet Engineering Task
   Force, Nov. Dec. 2003.  Work in progress.

10

9 Acknowledgements

   The authors would like to thank Joerg Ott, Colin Perkins, Toni Paila
   and Petri Koskelainen on for their ideas and input to this document.

11

10 Authors' Addresses

   Yuji Nomura
   Fujitsu Laboratories Ltd.
   4-1-1 Kamikodanaka, Nakahara-ku, Kawasaki 211-8588
   Japan
   Email: nom@flab.fujitsu.co.jp

   Rod Walsh
   Nokia Corporation
   Nokia Research Center
   P.O. Box 100, FIN-33721 Tampere
   Finland
   Email: rod,walsh@nokia.com

   Juha-Pekka Luoma
   Nokia Corporation
   Nokia Research Center
   P.O. Box 100, FIN-33721 Tampere
   Finland
   Email: juha-pekka.luoma@nokia.com

   Hitoshi Asaeda
   INRIA
   Project PLANETE
   2004, Route des Lucioles, BP93,
   06902 Sophia Antipolis,
   France
   Email: Hitoshi.Asaeda@sophia.inria.fr

   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 (2003). 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 INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.