Request for Comments: 4435 Fujitsu Labs.
Category: Informational R. Walsh
J-P. Luoma
Nokia
H. Asaeda
Keio University
H. Schulzrinne
Columbia University
April 2006
A Framework for the Usage of Internet Media Guides (IMGs)
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
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 the Session Description Protocol
(SDP), SDPng, or some similar session description format. This
document describes a generalized model for IMG delivery mechanisms,
the use of existing protocols, and the need for additional work to
create an IMG delivery infrastructure.
Table of Contents
1. Introduction ....................................................3
2. Terminology .....................................................3
2.1. New Terms ..................................................4
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. IMG Entities ...............................................6
3.3. Operation Set for IMG Delivery .............................7
3.3.1. IMG ANNOUNCE ........................................7
3.3.2. IMG QUERY ...........................................8
3.3.3. IMG RESOLVE .........................................8
3.3.4. IMG SUBSCRIBE .......................................8
3.3.5. IMG NOTIFY ..........................................9
3.3.6. Binding between IMG Operations and Data Types .......9
3.4. Overview of Protocol Operations ...........................10
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 Bidirectional Unicast ..........................12
4.4. Combined Operations with Common Metadata ..................13
5. Applicability of Existing Protocols to the Proposed
Framework Model ................................................14
5.1. Existing Standard Fitting the IMG Framework Model .........14
5.2. IMG Mechanism Needs Which Are Not Met by Existing
Standards .................................................15
5.2.1. A Multicast Transport Protocol .....................16
5.2.2. Usage of Unicast Transport Protocols ...............16
5.2.3. IMG Envelope .......................................17
5.2.4. Metadata Data Model ................................18
6. Security Considerations ........................................18
7. Normative References ...........................................19
8. Informative References .........................................19
9. Acknowledgements ...............................................20
1. Introduction
Internet Media Guides (IMGs) provide and deliver structured
collections of multimedia descriptions expressed using SDP [2], SDPng
[3], or other description formats. They are used to describe sets of
multimedia services (e.g., television program schedules, content
delivery schedules) 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.
IMG metadata may be delivered to a potentially large audience, which
uses it to join a subset of the sessions described and which 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.
This document defines a common framework model for IMG delivery
mechanisms and their deployment in network entities. There are three
fundamental components in the IMG framework model: data types,
operation sets, and entities. These components specify a set of
framework guidelines for efficient delivery and description of IMG
metadata. The data types give generalized means to deliver and
manage the consistency of application-specific IMG metadata. IMG
operations cover broadcast, multicast distribution, event
notification upon change, 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 performs one or
more of the roles defined as the entities in the IMG framework model.
The requirements for IMG delivery mechanisms and descriptions can be
found in the IMG requirements document [4].
This document outlines the use of existing protocols to create an IMG
delivery infrastructure. It aims to organize existing protocols into
a common model and show their capabilities and limitations from the
viewpoint of IMG delivery functions.
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].
2.1. New Terms
Internet Media Guide (IMG): IMG is a generic term to describe the
formation, delivery, and use of IMG metadata. The definition of
the IMG is intentionally left imprecise [4].
IMG Element: The smallest atomic element of metadata that can be
transmitted separately by IMG operations and referenced
individually from other IMG elements [4].
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 a media
object’s URI, title, airtime, bandwidth needed, file size, text
summary, genre, and access restrictions [4].
IMG Description: A collection of IMG metadata with a data type
indicating a self-contained set or a subset of IMG metadata, or a
reference to IMG metadata.
IMG Delivery: The process of exchanging IMG metadata both in terms of
large-scale and atomic data transfers [4].
IMG Sender: An IMG sender is a logical entity that sends IMG metadata
to one or more IMG receivers [4].
IMG Receiver: An IMG receiver is a logical entity that receives IMG
metadata from an IMG sender [4].
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 [4].
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 sender(s)/receiver(s) [4].
IMG Transport Protocol: A protocol that transports IMG metadata from
an IMG sender to IMG receiver(s) [4].
IMG Transport Session: An association between an IMG sender and one
or more IMG receivers within the scope of an IMG transport
protocol. An IMG transport session involves a time-bound series
of IMG transport protocol interactions that provide delivery of
IMG metadata from the IMG sender to the IMG receiver(s) [4].
IMG Transfer: A transfer of IMG metadata from an IMG sender to IMG
receiver(s).
3. IMG Common Framework Model
Two common elements are found in all existing IMG candidate cases:
the need to describe the services and the need to deliver the
descriptions. In some cases, the descriptions provide multicast
addresses and thus are part of the transport configuration. In other
cases, descriptions are specific to the media application and may be
meant for either human or machine consumption. Thus, the
technologies can be roughly divided into three areas:
o Application-specific Metadata: data describing the content of
services 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, and fundamental
session data.
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 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 Descriptions, and IMG
Pointers.
3.1.1. Complete IMG Description
A Complete IMG Description provides a self-contained set of metadata
for one media object or service, i.e., it does not need additional
information from any other IMG element. 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 -- 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. Delta IMG Descriptions may be used to
reduce network resource usage, for instance, when data consistency is
essential and small and frequent changes occur to IMG elements.
Thus, this description does not represent a complete set of metadata
until it is combined with other metadata that may already exist or
arrive in the future.
3.1.3. IMG Pointer
An IMG Pointer identifies or locates metadata. 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 IMG metadata per se
(although it may also appear as a data field in Complete or Delta IMG
Descriptions).
3.2. 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, which are
defined in more detail in Section 3.3.
IMG Announcer: sends IMG ANNOUNCE
IMG Listener: receives IMG ANNOUNCE
IMG Querier: sends IMG QUERY and receives IMG RESOLVE
IMG Resolver: receives IMG QUERY then sends IMG RESOLVE
IMG Subscriber: sends IMG SUBSCRIBE then receives IMG NOTIFY
IMG Notifier: receives IMG SUBSCRIBE then sends IMG NOTIFY
Figure 1 shows the 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 between IMG Entities, Senders, and Receivers
3.3. Operation Set for IMG Delivery
A finite set of operations both meets the IMG requirements [4] and
fits the roles of existing protocols. These are crystallized in the
next few sections.
3.3.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 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 that can maintain the distribution
(this includes scenarios with multiple and cooperative IMG senders).
This operation is useful when there are large numbers of IMG
receivers or the IMG receivers do not have a guaranteed uplink
connection to the IMG sender. 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 can carry
any of the IMG data types.
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.
3.3.2. IMG QUERY
If an IMG receiver needs to obtain IMG metadata, an IMG receiver can
use an IMG QUERY operation 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 bidirectional transport network is available between the
IMG sender and receiver. Some IMG receivers may want to obtain IMG
metadata when network connectivity 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. The extent indicates the number and grouping of metadata
descriptions. In some cases, it may be feasible to request an IMG
sender’s complete metadata collection.
3.3.3. IMG RESOLVE
An IMG sender synchronously responds, and sends IMG metadata, to an
IMG QUERY that has been sent by an IMG receiver. This operation can
be used where a bidirectional 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 the query; otherwise, it should
indicate that it is not able to resolve the query. The IMG sender
may authenticate the IMG receiver during the QUERY operation to
determine if the IMG receiver is authorized to receive 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.
3.3.4. IMG SUBSCRIBE
If an IMG receiver wants to be notified when the IMG metadata it
holds becomes stale, the IMG receiver can use the IMG SUBSCRIBE
operation in advance in order to solicit IMG 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 the case
where the IMG sender offers more than the simplest "all data"
service. This 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
unsubscription may be provided implicitly by the expiry (timeout) of
a subscription before it is renewed.
Since the IMG receiver does not 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 check whether an IMG SUBSCRIBE operation is from an
authorized IMG receiver.
3.3.5. IMG NOTIFY
An IMG NOTIFY is used asynchronously in response to an earlier IMG
SUBSCRIBE. An IMG NOTIFY operation indicates 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.3.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. Care should be taken that
scope- and domain-specific identifiers do not leak outside the scope;
using globally unique identifiers such as URLs avoids these problems.
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
invalidate 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. The temporal validity of a metadata
object may need to be updated later. Furthermore, the binding must
be independent of any specific metadata syntax used for the IMG
metadata, in the sense that no useful syntax should be excluded.
3.4. Overview of Protocol Operations
Figure 2 gives an overview of the relationship between transport
cases, IMG operations, and IMG data types. It is not a protocol
stack. Generalized multicast point-to-multipoint (P-to-M) and
unicast point-to-point (P-to-P) transports are shown.
+--------------------------------------------------+
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 Transport, IMG Operations, and IMG Data Types
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, for example, when public metadata is distributed to all
IMG receivers of a certain group. This kind of IMG metadata may be
distributed from one IMG sender to multiple IMG receivers (Figure 4)
or may be relayed across a set of IMG transceivers that receive the
IMG metadata, possibly filter or modify its content, and then forward