Internet Engineering Task Force                                MMUSIC WG
Internet Draft                                                 Y. Nomura
                                                           Fujitsu Labs.
                                                                R. Walsh
                                                              J-P. Luoma
                                                               H. Asaeda
                                                          H. Schulzrinne
                                                     Columbia University
April 13, 2004
Expires: October 2004

           A Framework for the Usage of Internet Media Guides


   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-

   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

   To view the list Internet-Draft Shadow Directories, see


   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 a generalized
   model for IMG delivery mechanisms, and the use of existing protocol
   to create an IMG delivery infrastructure.

Y. Nomura et. al.                                             [Page 1]

Internet Draft               IMG Framework                April 13, 2004

Table of Contents

   1          Introduction ........................................    2
   2          Terminology .........................................    3
   3          IMG Common Framework Model ..........................    5
   3.1        IMG Data Types ......................................    5
   3.1.1      Complete IMG Description ............................    5
   3.1.2      Delta IMG Description ...............................    6
   3.1.3      IMG Pointer .........................................    6
   3.2        Operation Set for IMG Delivery ......................    6
   3.2.1      IMG ANNOUNCE ........................................    6
   3.2.2      IMG QUERY ...........................................    7
   3.2.3      IMG RESOLVE .........................................    7
   3.2.4      IMG SUBSCRIBE .......................................    7
   3.2.5      IMG NOTIFY ..........................................    8
   3.2.6      Binding Between IMG Operations and Data Types .......    8
   3.3        IMG Entities ........................................    9
   3.4        Overview of Protocol Operations .....................    9
   4          Deployment Scenarios for IMG Entities ...............   10
   4.1        Intermediary Cases ..................................   10
   4.2        One-to-many Unidirectional Multicast ................   12
   4.3        One-to-one Bi-directional Unicast ...................   13
   4.4        Combined Operations with Common Metadata ............   13
   5          Applicability of Existing Protocols to the
   Proposed Framework Model .......................................   13
   5.1        Existing Protocol Fit to the IMG Framework Model
   5.2        Outstanding IMG Mechanism Needs .....................   16
   5.2.1      A Multicast Transport Protocol ......................   16
   5.2.2      Usage of Unicast Transport Protocols ................   17
   5.2.3      IMG Transfer Envelope ...............................   17
   5.2.4      Baseline (Meta)Data Model Specification .............   18
   5.3        IMG Needs Fitting the IETF's Scope ..................   18
   6          Security Considerations .............................   19
   7          IANA Considerations .................................   21
   8          References ..........................................   21
   9          Acknowledgements ....................................   21
   10         Authors' Addresses ..................................   22
   11         Full Copyright Statement ............................   22

1 Introduction

   Internet Media Guides (IMGs) provide and deliver structured
   collections of multimedia descriptions expressed using SDP, SDPng or
   some similar description format. They are used to describe sets of
   multimedia sessions (e.g. television program schedules, content
   delivery schedules etc.) and refer to other networked resources

Y. Nomura et. al.                                             [Page 2]

Internet Draft               IMG Framework                April 13, 2004

   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.

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

   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, a 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 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.

2 Terminology

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

        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.

Y. Nomura et. al.                                             [Page 3]

Internet Draft               IMG Framework                April 13, 2004

        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 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 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
             series of IMG transport protocol interactions that provide
             delivery of IMG metadata from the IMG sender to the IMG

        IMG Transfer: A transfer of IMG metadata consisting of Complete
             IMG Descriptions, Delta IMG Descriptions and/or IMG

Y. Nomura et. al.                                             [Page 4]

Internet Draft               IMG Framework                April 13, 2004

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 Descriptions -- the 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 descriptions.

        o Delivery Protocols -- the methods and protocols to exchange
          descriptions between the senders and the receivers.  An IMG
          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.

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 IMG Descriptions, Delta IMG Description and IMG

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

   Note, this is not to be confused with "complete IMG metadata", which,
   although vaguely defined here, represents the complete IMG metadata
   database of an IMG sender (or related group of IMG senders --

Y. Nomura et. al.                                             [Page 5]

Internet Draft               IMG Framework                April 13, 2004

   potentially the complete Internet IMG knowledge). An IMG sender will
   generally deliver only subsets of metadata from its complete database
   in a particular 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. Delta transfers may be used to
   reduce network resource usage (it may be more bandwidth and
   congestion friendly), for instance when data consistency is essential
   and small and frequent changes occur to IMG elements. Thus, this
   description itself cannot represent complete metadata set until it is
   combined with existing, or future, description knowledge.

3.1.3 IMG Pointer

   An IMG Pointer provides a simple identifier or locator, such as a
   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 or Delta IMG Descriptions) or perform another IMG
   management function such as data expiry (and erasure). The IMG
   Pointer may be used to reference IMG metadata elements within the IMG
   transport session and across IMG transport sessions. This pointer
   type does not include metadata per se (although it may also appear as
   a data field in Complete or Delta IMG descriptors).

3.2 Operation Set for IMG Delivery

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


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

Y. Nomura et. al.                                             [Page 6]

Internet Draft               IMG Framework                April 13, 2004

   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) enables IMG receivers to subscribe/register to
   the IMG ANNOUNCE operation.


   If an IMG receiver needs to obtain IMG metadata, an IMG receiver can
   send an IMG QUERY message and initiate a receiver-driven IMG
   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 an IMG sender's complete IMG metadata may be
   feasible, in others it may not.


   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, the IMG sender can resolve 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.


   If an IMG receiver wants to be notified when the IMG metadata it
   holds is stale, the IMG receiver can use the IMG SUBSCRIBE operation
   in advance in order to solicit notify messages from an IMG sender.

   This operation may provide the IMG sender with specific details of
   which metadata or notification services it is interested in (in the
   case where the IMG sender offers more than the simplest "all data"
   service). The operation implicitly provides the functionality of
   unsubscribing to inform an IMG sender that an IMG receiver wishes to
   stop getting certain (or all) notifications. It should be noted that

Y. Nomura et. al.                                             [Page 7]

Internet Draft               IMG Framework                April 13, 2004

   the unsubscription may be provided implicitly by the expiry (timeout)
   of a subscription before it is renewed.  However, these details
   belong to the messaging protocol and are beyond the scope of this

   Since the IMG receiver doesn't know when metadata will be updated and
   the notify message will arrive, this operation does not synchronize
   with the notify messages.  The IMG receiver may wait for notify
   messages for a long time. The IMG sender may authenticate the IMG
   receiver to investigate whether an IMG SUBSCRIBE operation is from an
   authorized IMG receiver.


   An IMG NOTIFY is used asynchronously 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 the transferred IMG metadata
   so that changes can be easily handled and stale data identified, and
   give temporal validity of the transferred IMG metadata. It must
   expire the IMG metadata by indicating an expiry time, and may
   optionally provide a time (presumably in the future) from when the
   IMG metadata becomes valid. Temporal validity of IMG metadata may be
   changeable for an IMG transfer, and even for specific versions of the
   IMG transfer. Furthermore, the binding must be independent of the
   metadata syntax(es) used for the IMG metadata, in the sense that no

Y. Nomura et. al.                                             [Page 8]

Internet Draft               IMG Framework                April 13, 2004

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

3.4 Overview of Protocol Operations

   Figure 2 gives an overview of the relationship between transport

Y. Nomura et. al.                                             [Page 9]

Internet Draft               IMG Framework                April 13, 2004

   cases, IMG Operations and IMG data types (note, it is not a protocol

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

   Figure 2: IMG Operations and IMG Data type

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 Sender  |                | IMG Receiver  |
            |             |--------------->|               |
            +-------------+                +---------------+

   Figure 3: A Simple IMG Sender to IMG Receiver Relationship

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

Y. Nomura et. al.                                            [Page 10]

Internet Draft               IMG Framework                April 13, 2004

   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.

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

   IMG metadata is used to find, obtain, manage and play content. IMG
   metadata 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

Y. Nomura et. al.                                            [Page 11]

Internet Draft               IMG Framework                April 13, 2004

   remainder). It may be beneficial to use smaller fragments for more
   volatile parts, and larger one for more stable parts.

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

             +----------+                +----------+
             |   IMG    |                |   IMG    |
             | Resolver |                | Querier  |
             +----------+                +----------+
                 |                                |
                 |-----------IMG QUERY ---------->|
                 |                                |
                 |<---------IMG RESOLVE-----------|
                 |                                |

   Figure 6: Query/Resolve Sequence Example

Y. Nomura et. al.                                            [Page 12]

Internet Draft               IMG Framework                April 13, 2004

4.3 One-to-one Bi-directional Unicast

   Both query/resolve (figure 6) and subscribe/notify (figure 7) message
   exchange operations are feasible.  The "time passes" activities of
   figure 7 are purely for example.

            +----------+                   +------------+
            |   IMG    |                   |    IMG     |
            | Notifier |                   | Subscriber |
            +----------+                   +------------+
                 |                                |
                 |<---------IMG SUBSCRIBE---------|
                 :                                :
                            (time passes)
                 :                                :
                 |-----------IMG NOTIFY---------->|
                 :                                :
                            (time passes)
                 :                                :
                 |-----------IMG NOTIFY---------->|
                 |                                |

   Figure 7: Subscribe/Notify Sequence Example

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 sets of IMG metadata.

5 Applicability of Existing Protocols to the Proposed Framework Model

5.1 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 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 cannot provide 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

Y. Nomura et. al.                                            [Page 13]

Internet Draft               IMG Framework                April 13, 2004

   the use of SDP for other than session-level IMG parameters may not be

    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

   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. MPEG-7 is based on XML so
   it is well suited for combining with other XML-based formats such as

   TV-Anytime Forum: The TV-Anytime Forum [3] provides descriptions
   based on XML schema for TV-specific program guides.  TV-Anytime uses
   the MPEG-7 User description profile to a limited extent (for user

Y. Nomura et. al.                                            [Page 14]

Internet Draft               IMG Framework                April 13, 2004

   preferences and usage history) and also a TV-Anytime-specific data
   model for other schema - which are optimised to describe broadcast
   schedules, on-demand program guides and program events.

   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

   - Lack of reliability (through forward error correction /

   - 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 [4]
   provides a way to implement IMG SUBSCRIBE and IMG NOTIFY operations
   via a bi-directional unicast connection. However, there are

Y. Nomura et. al.                                            [Page 15]

Internet Draft               IMG Framework                April 13, 2004

   scalability problems with this approach, as RFC 3265 currently does
   not consider multicast.

   RTSP: The RTSP protocol defines a retrieval and update notification
   mechanism, named DESCRIBE and ANNOUNCE, for the description of a
   presentation or media object in order to initialize a streaming
   session.  These methods are subset of the entire streaming control
   operations in RTSP, thus these could not be available for individual
   mechanisms.  However, the DESCRIBE method in RTSP could be IMG QUERY,
   RESOLVE and SUBSCRIBE, and the ANNOUNCE could be a IMG NOTIFY for a
   streaming session controlled by RTSP.

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

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

Y. Nomura et. al.                                            [Page 16]

Internet Draft               IMG Framework                April 13, 2004

   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 NOTIFY capability could be
   investigated for both hybrid unicast-multicast and unidirectional
   unicast systems.

5.2.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 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 [7], SIP events [4], HTTP [8], 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.

5.2.3 IMG Transfer Envelope

   Section 3.2.6 of this document discussed the need for binding between
   IMG Operations and Data Types. Such a binding can be realized by
   defining a common minimal set of information needed to manage IMG
   metadata transfers, and by including this information with any set of
   IMG metadata delivered to IMG receiver(s).

   Four options for IMG transfer envelope 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 RTCP [9]).

        3.   A metadata wrapper which points to and/or embeds the

Y. Nomura et. al.                                            [Page 17]

Internet Draft               IMG Framework                April 13, 2004

             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.

   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.

   When there are superset/subset relations between IMG descriptions, it
   is assumed that the IMG descriptions of the subset inherit the
   parameters of the superset. Thus, an IMG transfer envelope carrying
   the IMG descriptions of a superset may implicitly define parameters
   of IMG descriptors belonging to its subset. The relations between IMG
   descriptions may span from one IMG transfer envelope to another.

5.2.4 Baseline (Meta)Data Model Specification

   A minimal IMG data model may be useful to any implementer/deployment
   of IMGs. The purpose would be to ensure that multiple metadata
   syntaxes (SDP, MPEG-7, etc) can be related within the same body of
   IMG knowledge, regardless of any specific metadata and data models
   provided by the metadata syntaxes.

   Further work may be needed to meet application-specific requirements
   at defining metadata and data models for the successful deployment of
   IMGs in various environments. Existing (and future) work on these
   would need to be mapped to the IMG data types and use of the IMG
   transfer envelope concept as described above.

   This document is a framework for the delivery of IMG Metadata and
   thus further discussion on the definition data models for IMGs is
   beyond its scope.

5.3 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

Y. Nomura et. al.                                            [Page 18]

Internet Draft               IMG Framework                April 13, 2004


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

6 Security Considerations

   The IMG framework is developed from the IMG Requirements document [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

   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 if the original information
   were public. 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

Y. Nomura et. al.                                            [Page 19]

Internet Draft               IMG Framework                April 13, 2004

   the amount of individual or group personalization the snooped 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

   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

   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

Y. Nomura et. al.                                            [Page 20]

Internet Draft               IMG Framework                April 13, 2004

   opportunity is specific to the protocols used and is outside the
   scope of this document.

7 IANA Considerations

   There are no IANA considerations within this document.

8 References

   [1] Y. Nomura, R. Walsh, J-P. Luoma, J. Ott, and H. Schulzrinne,
   "Protocol requirements for Internet media guides," Internet Draft
   draft-ietf-mmusic-img-req-04, Internet Engineering Task Force, April
   2004.  Work in progress.

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

   [3] TV-Anytime Forum, "Broadcast and On-line Services: Search,
   select, and rightful use of content on personal storage systems
   ("TV-Anytime Phase 1"); Part 2: System description," ETSI-TS 102
   822-2: System Description, V1.1.1, October 2003.

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

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

   [6] T. Paila, M. Luby, R. Lehtonen, V. Roca, R. Walsh, "FLUTE - file
   delivery over unidirectional transport," Internet Draft draft-ietf-
   rmt-flute-07, Internet Engineering Task Force, Dec. 2003.  Work in

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

   [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] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: a
   transport protocol for real-time applications," RFC 3550, Internet
   Engineering Task Force, July 2003.

9 Acknowledgements

Y. Nomura et. al.                                            [Page 21]

Internet Draft               IMG Framework                April 13, 2004

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

10 Authors' Addresses

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

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

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

   Hitoshi Asaeda
   Project PLANETE
   2004, Route des Lucioles, BP93,
   06902 Sophia Antipolis,

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

11 Full Copyright Statement

   Copyright (C) The Internet Society (2004). 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.

   This document and the information contained herein are provided on an

Y. Nomura et. al.                                            [Page 22]

Internet Draft               IMG Framework                April 13, 2004


Intellectual Property

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