draft-ietf-mmusic-img-framework-08.txt   draft-ietf-mmusic-img-framework-09.txt 
Internet Engineering Task Force MMUSIC WG MMUSIC Working Group Y. Nomura
Internet Draft Y. Nomura Internet-Draft Fujitsu Labs.
Fujitsu Labs. Expires: June 23, 2006 R. Walsh
R. Walsh
J-P. Luoma J-P. Luoma
Nokia Nokia
H. Asaeda H. Asaeda
INRIA INRIA
H. Schulzrinne H. Schulzrinne
Columbia University Columbia University
draft-ietf-mmusic-img-framework-08.txt December 19, 2005
July 19, 2004
Expires: January 2005
A Framework for the Usage of Internet Media Guides A Framework for the Usage of Internet Media Guides
draft-ietf-mmusic-img-framework-09
STATUS OF THIS MEMO Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, each author represents that any
patent or other IPR claims of which I am aware have been disclosed, applicable patent or other IPR claims of which he or she is aware
and any of which I become aware will be disclosed, in accordance have been or will be disclosed, and any of which he or she becomes
with RFC 3668." aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than a "work in as reference material or to cite them other than as "work in
progress." progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract Abstract
This document defines a framework for the delivery of Internet Media This document defines a framework for the delivery of Internet Media
Guides (IMGs). An IMG is a structured collection of multimedia Guides (IMGs). An IMG is a structured collection of multimedia
session descriptions expressed using SDP, SDPng or some similar session descriptions expressed using SDP, SDPng or some similar
session description format. This document describes a generalized session description format. This document describes a generalized
model for IMG delivery mechanisms, the use of existing protocols and model for IMG delivery mechanisms, the use of existing protocols and
the need for additional work to create an IMG delivery the need for additional work to create an IMG delivery
infrastructure. infrastructure.
Table of Contents Table of Contents
1 Introduction ........................................ 2 1 Introduction ........................................ 3
2 Terminology ......................................... 3 2 Terminology ......................................... 3
2.1 New Terms ........................................... 4
3 IMG Common Framework Model .......................... 5 3 IMG Common Framework Model .......................... 5
3.1 IMG Data Types ...................................... 5 3.1 IMG Data Types ...................................... 5
3.1.1 Complete IMG Description ............................ 5 3.1.1 Complete IMG Description ............................ 5
3.1.2 Delta IMG Description ............................... 6 3.1.2 Delta IMG Description ............................... 6
3.1.3 IMG Pointer ......................................... 6 3.1.3 IMG Pointer ......................................... 6
3.2 Operation Set for IMG Delivery ...................... 6 3.2 IMG Entities ........................................ 6
3.2.1 IMG ANNOUNCE ........................................ 6 3.3 Operation Set for IMG Delivery ...................... 7
3.2.2 IMG QUERY ........................................... 7 3.3.1 IMG ANNOUNCE ........................................ 7
3.2.3 IMG RESOLVE ......................................... 7 3.3.2 IMG QUERY ........................................... 8
3.2.4 IMG SUBSCRIBE ....................................... 7 3.3.3 IMG RESOLVE ......................................... 8
3.2.5 IMG NOTIFY .......................................... 8 3.3.4 IMG SUBSCRIBE ....................................... 8
3.2.6 Binding Between IMG Operations and Data Types ....... 8 3.3.5 IMG NOTIFY .......................................... 9
3.3 IMG Entities ........................................ 9 3.3.6 Binding Between IMG Operations and Data Types ....... 9
3.4 Overview of Protocol Operations ..................... 10 3.4 Overview of Protocol Operations ..................... 9
4 Deployment Scenarios for IMG Entities ............... 10 4 Deployment Scenarios for IMG Entities ............... 10
4.1 Intermediary Cases .................................. 11 4.1 Intermediary Cases .................................. 10
4.2 One-to-many Unidirectional Multicast ................ 12 4.2 One-to-many Unidirectional Multicast ................ 12
4.3 One-to-one Bi-directional Unicast ................... 13 4.3 One-to-one Bi-directional Unicast ................... 12
4.4 Combined Operations with Common Metadata ............ 14 4.4 Combined Operations with Common Metadata ............ 14
5 Applicability of Existing Protocols to the 5 Applicability of Existing Protocols to the
Proposed Framework Model ............................ 14 Proposed Framework Model ............................ 14
5.1 Existing Standard Fit to the IMG Framework Model .... 14 5.1 Existing Standard Fitting the IMG Framework Model ... 14
5.2 Outstanding IMG Mechanism Needs ..................... 16 5.2 IMG Mechanism Needs Not Yet Met ..................... 16
5.2.1 A Multicast Transport Protocol ...................... 16 5.2.1 A Multicast Transport Protocol ...................... 16
5.2.2 Usage of Unicast Transport Protocols ................ 17 5.2.2 Usage of Unicast Transport Protocols ................ 17
5.2.3 IMG Envelope ........................................ 17 5.2.3 IMG Envelope ........................................ 17
5.2.4 Baseline (Meta)Data Model Specification ............. 18 5.2.4 Metadata Data Model ................................. 18
6 Security Considerations ............................. 19 6 Security Considerations ............................. 18
7 IANA Considerations ................................. 20 7 IANA Considerations ................................. 19
8 Normative References ................................ 20 8 Normative References ................................ 20
9 Informative References .............................. 21 9 Informative References .............................. 20
10 Acknowledgements .................................... 21 10 Acknowledgements .................................... 21
11 Authors' Addresses .................................. 22 11 Authors' Addresses .................................. 21
12 Full Copyright Statement ............................ 23
1 Introduction 1 Introduction
Internet Media Guides (IMGs) provide and deliver structured Internet Media Guides (IMGs) provide and deliver structured
collections of multimedia descriptions expressed using SDP [2], collections of multimedia descriptions expressed using SDP [2],
SDPng [3] or other description formats. They are used to describe SDPng [3] or other description formats. They are used to describe
sets of multimedia services (e.g. television program schedules, sets of multimedia services (e.g., television program schedules,
content delivery schedules) and refer to other networked content delivery schedules) and refer to other networked resources
resources including web pages. IMGs provide an envelope for metadata including web pages. IMGs provide an envelope for metadata formats
formats and session descriptions defined elsewhere with the aim of and session descriptions defined elsewhere with the aim of
facilitating structuring, versioning, referencing, distributing, and facilitating structuring, versioning, referencing, distributing, and
maintaining (caching, updating) such information. maintaining (caching, updating) such information.
IMG metadata may be delivered to a potentially large audience, who IMG metadata may be delivered to a potentially large audience, who
use it to join a subset of the sessions described, and who may need 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 to be notified of changes to the IMG metadata. Hence, a framework for
distributing IMG metadata in various different ways is needed to distributing IMG metadata in various different ways is needed to
accommodate the needs of different audiences: For traditional accommodate the needs of different audiences: For traditional
broadcast-style scenarios, multicast-based (push) distribution of IMG broadcast-style scenarios, multicast-based (push) distribution of IMG
metadata needs to be supported. Where no multicast is available, metadata needs to be supported. Where no multicast is available,
unicast-based push is required too. unicast-based push is required.
This document defines a common framework model for IMG delivery This document defines a common framework model for IMG delivery
mechanisms and their deployment in network entities. There are mechanisms and their deployment in network entities. There are
three fundamental components in IMG framework model: data types, three fundamental components in IMG framework model: data types,
operation sets and entities. These components specify a set of operation sets and entities. These components specify a set of
framework guidelines for efficient delivery and description of IMG framework guidelines for efficient delivery and description of IMG
metadata. The data types give generalized means to deliver and metadata. The data types give generalized means to deliver and
manage the consistency of application-specific IMG metadata. IMG manage the consistency of application-specific IMG metadata. IMG
operations cover traditional broadcast-style scenarios, operations cover broadcast, multicast distribution, event
multicast-based distributions, unicast-based push and interactive notification upon change, unicast-based push and interactive
retrievals similar to web pages. Since we envision that any retrievals similar to web pages.
Internet host can be a sender and receiver of IMG metadata, a host
involved in IMG operations performs one or more of the roles Since we envision that any Internet host can be a sender and receiver
defined as the entities in IMG framework model. These are then of IMG metadata, a host involved in IMG operations performs one or
shown in a number of simplified deployment scenarios. The more of the roles defined as the entities in IMG framework model.
requirements for IMG delivery mechanisms and descriptions can be The requirements for IMG delivery mechanisms and descriptions can be
found in the IMG requirements document [4]. found in the IMG requirements document [4].
Then, this document outlines the use of existing protocols to create This document outlines the use of existing protocols to create
an IMG delivery infrastructure. It aims to organize existing an IMG delivery infrastructure. It aims to organize existing
protocols into a common model and show their capabilities and protocols into a common model and show their capabilities and
limitations from the viewpoint of IMG delivery functions. One of the limitations from the viewpoint of IMG delivery functions.
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 2 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1]. 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 Internet Media Guide (IMG): IMG is a generic term to describe
the formation, delivery and use of IMG metadata. The the formation, delivery and use of IMG metadata. The
definition of the IMG is intentionally left imprecise. [4] definition of the IMG is intentionally left imprecise [4].
IMG Element: The smallest atomic element of metadata that can be IMG Element: The smallest atomic element of metadata that can be
transmitted separately by IMG operations and referenced transmitted separately by IMG operations and referenced
individually from other IMG elements. [4] individually from other IMG elements [4].
IMG Metadata: A set of metadata consisting of one or more IMG IMG Metadata: A set of metadata consisting of one or more IMG
elements. IMG metadata describes the features of multimedia elements. IMG metadata describes the features of multimedia
content used to enable selection of and access to media content used to enable selection of and access to media
sessions containing content. For example, metadata may sessions containing content. For example, metadata may
consist of the URI, title, airtime, bandwidth needed, file consist of the URI, title, airtime, bandwidth needed, file
size, text summary, genre and access restrictions. [4] size, text summary, genre and access restrictions [4].
IMG Description: A collection of IMG metadata which has a IMG Description: A collection of IMG metadata with a data
relationship to other IMG metadata. There are three data type indicating a self-contained set or a subset of IMG
types to describe the relationship: Complete IMG metadata, or a reference to IMG metadata.
Descriptions, Delta IMG Description and IMG pointer.
IMG Delivery: The process of exchanging IMG metadata both in IMG Delivery: The process of exchanging IMG metadata both in
terms of large scale and atomic data transfers. [4] terms of large scale and atomic data transfers [4].
IMG Sender: An IMG sender is a logical entity that sends IMG IMG Sender: An IMG sender is a logical entity that sends IMG
metadata to one or more IMG receivers. [4] metadata to one or more IMG receivers [4].
IMG Receiver: An IMG receiver is a logical entity that receives IMG Receiver: An IMG receiver is a logical entity that receives
IMG metadata from an IMG sender. [4] IMG metadata from an IMG sender [4].
IMG Transceiver: An IMG transceiver combines an IMG receiver and IMG Transceiver: An IMG transceiver combines an IMG receiver and
sender. It may modify received IMG metadata or merge IMG sender. It may modify received IMG metadata or merge IMG
metadata received from a several different IMG senders. [4] metadata received from a several different IMG senders [4].
IMG Operation: An atomic operation of an IMG transport protocol, IMG Operation: An atomic operation of an IMG transport protocol,
used between IMG sender(s) and IMG receiver(s) for the used between IMG sender(s) and IMG receiver(s) for the
delivery of IMG metadata and for the control of IMG delivery of IMG metadata and for the control of IMG
sender(s)/receiver(s). [4] sender(s)/receiver(s) [4].
IMG Transport Protocol: A protocol that transports IMG metadata IMG Transport Protocol: A protocol that transports IMG metadata
from an IMG sender to IMG receiver(s). [4] from an IMG sender to IMG receiver(s) [4].
IMG Transport Session: An association between an IMG sender and IMG Transport Session: An association between an IMG sender and
one or more IMG receivers within the scope of an IMG one or more IMG receivers within the scope of an IMG
transport protocol. An IMG transport session involves a transport protocol. An IMG transport session involves a
time bound series of IMG transport protocol interactions time bound series of IMG transport protocol interactions
that provide delivery of IMG metadata from the IMG sender that provide delivery of IMG metadata from the IMG sender
to the IMG receiver(s). [4] to the IMG receiver(s) [4].
IMG Transfer: A transfer of IMG metadata consisting of Complete IMG Transfer: IMG Transfer: A transfer of IMG metadata from an
IMG Descriptions, Delta IMG Descriptions and/or IMG IMG sender to IMG receiver(s).
Pointers.
3 IMG Common Framework Model 3 IMG Common Framework Model
Two common elements are found in all of existing IMG candidate cases: Two common elements are found in all of existing IMG candidate cases:
the need to describe the services; the need to deliver the the need to describe the services and the need to deliver the
descriptions. In some cases, the descriptions are multicast enablers descriptions. In some cases, the descriptions provide multicast
(such as the session parameters of SDP) and are thus intrinsically addresses and thus are part of the transport configuration. In other
part of the delivery aspects, and in other cases descriptions are cases, descriptions are specific to the media application and may be
application-specific (both machine and human readable). Thus, the either meant for human or machine consumption. Thus, the technologies
technologies can be roughly divided into three areas: can be roughly divided into three areas:
o Application-specific Metadata -- data describing the services' o Application-specific Metadata -- data describing the content
content and media which are both specific to certain of services and media which are both specific to certain
applications and generally human readable. applications and generally human readable.
o Delivery Descriptions -- the descriptions (metadata) that are o Delivery Descriptions -- the descriptions (metadata) that are
essential to enable (e.g. multicast) delivery. These include essential to enable (e.g., multicast) delivery. These include
framing (headers) for application-specific metadata, the framing (headers) for application-specific metadata, the
metadata element identification and structure, and fundamental metadata element identification and structure, and fundamental
session data. session data.
o Delivery Protocols -- the methods and protocols to exchange o Delivery Protocols -- the methods and protocols to exchange
descriptions between the senders and the receivers. An IMG descriptions between the senders and the receivers. An IMG
transport protocol consists of two functions: carrying IMG transport protocol consists of two functions: carrying IMG
metadata from an IMG sender to an IMG receiver and controlling metadata from an IMG sender to an IMG receiver and controlling
an IMG transport protocol. These functions are not always an IMG transport protocol. These functions are not always
exclusive, therefore some messages may combine control exclusive, therefore some messages may combine control
skipping to change at page 5, line 48 skipping to change at page 5, line 49
A data model is needed to precisely define the terminology and A data model is needed to precisely define the terminology and
relationships between sets, supersets and subsets of metadata. A relationships between sets, supersets and subsets of metadata. A
precise data model is essential for the implementation of IMGs precise data model is essential for the implementation of IMGs
although it is not within the scope of this framework and requires a although it is not within the scope of this framework and requires a
separate specification. However there are three IMG data types in separate specification. However there are three IMG data types in
general: Complete IMG Descriptions, Delta IMG Descriptions and IMG general: Complete IMG Descriptions, Delta IMG Descriptions and IMG
Pointers. Pointers.
3.1.1 Complete IMG Description 3.1.1 Complete IMG Description
A Complete IMG Description provides a complete syntax and semantics A complete IMG description provides a self-contained set of metadata
to describe a set of metadata, which does not need any additional for one media object or service, i.e., it does not need additional
information from any other IMG element. information from any other IMG element. This is not to be confused
with "complete IMG metadata", which, although vaguely defined here,
Note, this is not to be confused with "complete IMG metadata", which, represents the complete IMG metadata database of an IMG sender (or
although vaguely defined here, represents the complete IMG metadata related group of IMG senders -- potentially the complete Internet IMG
database of an IMG sender (or related group of IMG senders -- knowledge). An IMG sender will generally deliver only subsets of
potentially the complete Internet IMG knowledge). An IMG sender will metadata from its complete database in a particular IMG transport
generally deliver only subsets of metadata from its complete database session.
in a particular IMG transport session.
3.1.2 Delta IMG Description 3.1.2 Delta IMG Description
A Delta IMG Description provides only part of a Complete IMG A Delta IMG Description provides only part of a Complete IMG
Description, defining the difference from a previous version of the Description, defining the difference from a previous version of the
Complete IMG Description in question. Delta transfers may be used to Complete IMG Description. Delta IMG Descriptions may be used to
reduce network resource usage (it may be more bandwidth and reduce network resource usage, for instance when data consistency
congestion friendly), for instance when data consistency is essential is essential and small and frequent changes occur to IMG elements.
and small and frequent changes occur to IMG elements. Thus, this Thus, this description does not represent a complete set of metadata
description itself cannot represent a complete metadata set until it until it is combined with other metadata that may already exist or
is combined with existing, or future, description knowledge. arrive in the future.
3.1.3 IMG Pointer 3.1.3 IMG Pointer
An IMG Pointer provides a simple identifier or locator, such as a An IMG pointer, typically a URI, identifies or locates metadata. This
URI, that the IMG receiver is able to reference (or reference and may be used to separately obtain metadata (Complete or Delta IMG
locate) specific metadata with. This may be used to separately obtain Descriptions) or perform another IMG management function such as data
metadata (Complete or Delta IMG Descriptions) or perform another IMG expiry (and erasure). The IMG Pointer may be used to reference IMG
management function such as data expiry (and erasure). The IMG metadata elements within the IMG transport session and across IMG
Pointer may be used to reference IMG metadata elements within the IMG transport sessions. This pointer type does not include IMG metadata
transport session and across IMG transport sessions. This pointer per se (although it may also appear as a data field in Complete or
type does not include IMG metadata per se (although it may also Delta IMG descriptors).
appear as a data field in Complete or Delta IMG descriptors).
3.2 Operation Set for IMG Delivery 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 to receive IMG RESOLVE
IMG Resolver: receives IMG QUERY then send IMG RESOLVE
IMG Subscriber: sends IMG SUBSCRIBE then receive IMG NOTIFY
IMG Notifier: receives IMG SUBSCRIBE then send 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 A finite set of operations both meets the IMG requirements [4] and
fits the roles of existing protocols. These are crystallized in the fits the roles of existing protocols. These are crystallized in the
next few sections. next few sections.
3.2.1 IMG ANNOUNCE 3.3.1 IMG ANNOUNCE
When an IMG receiver participates in unidirectional communications When an IMG receiver participates in unidirectional communications
(e.g. over satellite, terrestrial radio and wired multicast networks) (e.g., over satellite, terrestrial radio and wired multicast
an IMG receiver may not need to send any IMG message to an IMG sender networks) an IMG receiver may not need to send any IMG message to an
prior to IMG metadata delivery. In this case, an IMG sender can IMG sender prior to IMG metadata delivery. In this case, an IMG
initiate unsolicited distribution for IMG metadata and an IMG sender sender can initiate unsolicited distribution for IMG metadata and an
is the only entity which can maintain the distribution (this includes IMG sender is the only entity which can maintain the distribution
scenarios with multiple and co-operative IMG senders). This operation (this includes scenarios with multiple and co-operative IMG senders).
is useful when there are considerably large numbers of IMG receivers This operation is useful when there is large numbers of IMG receivers
or the IMG receiver(s) do not have a guaranteed uplink connection to or the IMG receivers do not have a guaranteed uplink connection to
the IMG sender(s). The IMG sender may also include authentication the IMG sender. The IMG sender may also include authentication data
data in the announce operation so that IMG receivers may check the in the announce operation so that IMG receivers may check the
authenticity of the metadata. This operation is able to carry any of authenticity of the metadata. This operation can carry any of the
the IMG data types. IMG data types.
Note, there is no restriction to prevent IMG ANNOUNCE from being used There is no restriction to prevent IMG ANNOUNCE from being used
in an asynchronous solicited manner, where a separate operation in an asynchronous solicited manner, where a separate operation
(possibly out of band) enables IMG receivers to subscribe/register to (possibly out of band) enables IMG receivers to subscribe/register to
the IMG ANNOUNCE operation. the IMG ANNOUNCE operation.
3.2.2 IMG QUERY 3.3.2 IMG QUERY
If an IMG receiver needs to obtain IMG metadata, an IMG receiver can If an IMG receiver needs to obtain IMG metadata, an IMG receiver can
use an IMG QUERY operation and initiate a receiver-driven IMG use an IMG QUERY operation and initiate a receiver-driven IMG
transport session. The IMG receiver expects a synchronous response to transport session. The IMG receiver expects a synchronous response to
the subsequent request from the IMG sender. This operation can be the subsequent request from the IMG sender. This operation can be
used where a bi-directional transport network is available between used where a bi-directional transport network is available between
the IMG sender and receiver. Some IMG receivers may want to obtain the IMG sender and receiver. Some IMG receivers may want to obtain
IMG metadata when a resource is available or just to avoid caching IMG metadata when network connectivity is available or just to avoid
unsolicited IMG metadata. The IMG receiver must indicate the extent caching unsolicited IMG metadata. The IMG receiver must indicate the
and data type of metadata wanted in some message in the operation extent and data type of metadata wanted in some message in the
(extent indicates the number and grouping of metadata descriptions). operation. The extent indicates the number and grouping of metadata
In some cases requesting an IMG sender's complete IMG metadata may be descriptions. In some cases requesting an IMG sender's complete IMG
feasible, in others it may not. metadata collection, it may be feasible to request.
3.2.3 IMG RESOLVE 3.3.3 IMG RESOLVE
An IMG sender synchronously responds, and sends IMG metadata, to an An IMG sender synchronously responds, and sends IMG metadata, to an
IMG QUERY which has been sent by an IMG receiver. This operation IMG QUERY which has been sent by an IMG receiver. This operation
can be used where a bi-directional transport network is available can be used where a bi-directional transport network is available
between the IMG sender and receiver. If the IMG QUERY specifies a between the IMG sender and receiver. If the IMG QUERY specifies a
subset of IMG metadata (extent and data type) that is available to subset of IMG metadata (extent and data type) that is available to
the IMG sender, the IMG sender can resolve the query; otherwise, it 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 should indicate that it is not able to resolve the query. The IMG
sender may authenticate the IMG receiver to investigate the IMG sender may authenticate the IMG receiver to investigate the IMG
QUERY operation in order to determine whether the IMG receiver is QUERY operation in order to determine whether the IMG receiver is
authorized to be sent that metadata. The sender may also include authorized to be sent that metadata. The sender may also include
authentication data in the resolve operation so that IMG receivers authentication data in the resolve operation so that IMG receivers
may check the authenticity of the metadata. This operation may may check the authenticity of the metadata. This operation may
carry any of the IMG data types. carry any of the IMG data types.
3.2.4 IMG SUBSCRIBE 3.3.4 IMG SUBSCRIBE
If an IMG receiver wants to be notified when the IMG metadata it 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 holds is stale, the IMG receiver can use the IMG SUBSCRIBE operation
in advance in order to solicit notify messages from an IMG sender. in advance in order to solicit IMG NOTIFY messages from an IMG
sender.
This operation may provide the IMG sender with specific details of This operation may provide the IMG sender with specific details of
which metadata or notification services it is interested in (in the which metadata or notification services it is interested in in the
case where the IMG sender offers more than the simplest "all data" case where the IMG sender offers more than the simplest "all data"
service). This operation implicitly provides the functionality of service. This operation implicitly provides the functionality of
unsubscribing to inform an IMG sender that an IMG receiver wishes unsubscribing to inform an IMG sender that an IMG receiver wishes
to stop getting certain (or all) notifications. It should be noted to stop getting certain (or all) notifications. It should be noted
that unsubscription may be provided implicitly by the expiry that unsubscription may be provided implicitly by the expiry
(timeout) of a subscription before it is renewed. However, these (timeout) of a subscription before it is renewed.
details belong to a messaging protocol instantiation of this
operation are beyond the scope of this document.
Since the IMG receiver does not know when metadata will be updated Since the IMG receiver does not know when metadata will be updated
and the notify message will arrive, this operation does not and the notify message will arrive, this operation does not
synchronize with the notify messages. The IMG receiver may wait for synchronize with the notify messages. The IMG receiver may wait for
notify messages for a long time. The IMG sender may authenticate the notify messages for a long time. The IMG sender may authenticate the
IMG receiver to investigate whether an IMG SUBSCRIBE operation is IMG receiver to check whether an IMG SUBSCRIBE operation is from an
from an authorized IMG receiver. authorized IMG receiver.
3.2.5 IMG NOTIFY 3.3.5 IMG NOTIFY
An IMG NOTIFY is used asynchronously in response to an earlier IMG An IMG NOTIFY is used asynchronously in response to an earlier IMG
SUBSCRIBE. An IMG NOTIFY operation generates a notify message SUBSCRIBE. An IMG NOTIFY operation indicates that updated IMG
indicating that updated IMG metadata is available or part of the metadata is available or part of the existing IMG metadata is stale.
existing IMG metadata is stale. An IMG NOTIFY may be delivered more An IMG NOTIFY may be delivered more than once during the time an IMG
than once during the time an IMG SUBSCRIBE is active. This operation SUBSCRIBE is active. This operation may carry any of the IMG data
may carry any of the IMG data types. The IMG sender may also include types. The IMG sender may also include authentication data in the
authentication data in the IMG NOTIFY operation so that IMG receivers IMG NOTIFY operation so that IMG receivers may check the authenticity
may check the authenticity of the messages. of the messages.
3.2.6 Binding Between IMG Operations and Data Types 3.3.6 Binding Between IMG Operations and Data Types
There is a need to provide a binding between the various IMG There is a need to provide a binding between the various IMG
operations and IMG data types to allow management of each discrete operations and IMG data types to allow management of each discrete
set of IMG metadata transferred using an IMG operation. This binding set of IMG metadata transferred using an IMG operation. This binding
must be independent of any particular metadata syntax used to must be independent of any particular metadata syntax used to
represent a set of IMG metadata, as well as be compatible with any 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 transport protocol. The binding must uniquely identify the set of
IMG metadata delivered within an IMG transfer, regardless of the IMG metadata delivered within an IMG transfer, regardless of the
metadata syntax used. The uniqueness may only be needed within the metadata syntax used. The uniqueness may only be needed within the
domains the metadata is used but this must enable globally unique domains the metadata is used but this must enable globally unique
identification to support Internet usage. Scope/domain specific identification to support Internet usage. Scope/domain specific
identifications should not 'leak' outside of the scope, and always identifications should not 'leak' outside of the scope, and always
using globally unique identification (e.g. based on URIs) should using globally unique identification (e.g., based on URIs) should
avoid this error. avoid this error.
The binding must provide versioning to the transferred IMG metadata The binding must provide versioning to the transferred IMG metadata
so that changes can be easily handled and stale data identified, and so that changes can be easily handled and stale data identified, and
give temporal validity of the transferred IMG metadata. It must give temporal validity of the transferred IMG metadata. It must
expire the IMG metadata by indicating an expiry time, and may invalidate the IMG metadata by indicating an expiry time, and may
optionally provide a time (presumably in the future) from when the optionally provide a time (presumably in the future) from when the
IMG metadata becomes valid. Temporal validity of IMG metadata may be IMG metadata becomes valid. Temporal validity of IMG metadata may be
changeable for an IMG transfer, and even for specific versions of the changeable for an IMG transfer, and even for specific versions of the
IMG transfer. Furthermore, the binding must be independent 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 metadata syntax(es) used for the IMG metadata, in the sense that no
useful syntax should be excluded. 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
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.4 Overview of Protocol Operations 3.4 Overview of Protocol Operations
Figure 2 gives an overview of the relationship between transport Figure 2 gives an overview of the relationship between transport
cases, IMG Operations and IMG data types (note, it is not a protocol cases, IMG Operations and IMG data types. It is not a protocol
stack). Generalized multicast point-to-multipoint (P-to-M) and stack. Generalized multicast point-to-multipoint (P-to-M) and
unicast point-to-point (P-to-P) transports are shown. unicast point-to-point (P-to-P) transports are shown.
+--------------------------------------------------+ +--------------------------------------------------+
IMG | | IMG | |
Data types | Complete Desc., Delta Desc., Pointer | Data types | Complete Desc., Delta Desc., Pointer |
| | | |
+-------------------+----------------+-------------+ +-------------------+----------------+-------------+
IMG | IMG ANNOUNCE | IMG SUBSCRIBE | IMG QUERY | IMG | IMG ANNOUNCE | IMG SUBSCRIBE | IMG QUERY |
Operations | | IMG NOTIFY | IMG RESOLVE | Operations | | IMG NOTIFY | IMG RESOLVE |
+--------------+----+----------------+-------------+ +--------------+----+----------------+-------------+
skipping to change at page 11, line 8 skipping to change at page 10, line 39
+-------------+ +---------------+ +-------------+ +---------------+
| IMG Sender | | IMG Receiver | | IMG Sender | | IMG Receiver |
| |--------------->| | | |--------------->| |
+-------------+ +---------------+ +-------------+ +---------------+
Figure 3: A Simple IMG Sender to IMG Receiver Relationship Figure 3: A Simple IMG Sender to IMG Receiver Relationship
4.1 Intermediary Cases 4.1 Intermediary Cases
Some IMG metadata may be distributed to a large number of IMG Some IMG metadata may be distributed to a large number of IMG
receivers. If, for example, some IMG metadata is public information receivers, for example, when public metadata is distributed to all
and the IMG sender provides the same information for all IMG IMG receivers of a certain group. This kind of IMG metadata may be
receivers. This kind of IMG metadata may be distributed from one IMG distributed from one IMG sender to multiple IMG receivers (Figure 4)
sender to multiple IMG receivers (Figure 4) and/or or may be relayed or may be relayed across a set of IMG transceivers that receive the
across a set of IMG transceivers that receive the IMG metadata, IMG metadata, possibly filter or modify its content, and then forward
possibly filter or modify its content, and then forward it. it.
+----------+ +----------+ +----------+ +----------+
| IMG | | IMG | | IMG | | IMG |
| Sender |---- ---->| Receiver | | Sender |---- ---->| Receiver |
+----------+ \ / +----------+ +----------+ \ / +----------+
\ / \ /
. \ +-----------+ / . . \ +-----------+ / .
. -->|IMG |----- . . -->|IMG |----- .
. -->|Transceiver| \ . . -->|Transceiver| \ .
/ +-----------+ \ / +-----------+ \
skipping to change at page 11, line 38 skipping to change at page 11, line 32
Figure 4: A Relay Network with an IMG Transceiver Figure 4: A Relay Network with an IMG Transceiver
IMG senders and receivers are logical functions and it is possible 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 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 instance, in many-to-many communications or where a transceiver is
used to combine or aggregate IMG metadata for some IMG receivers. An used to combine or aggregate IMG metadata for some IMG receivers. An
IMG receiver may be allowed to receive IMG metadata from any number IMG receiver may be allowed to receive IMG metadata from any number
of IMG senders. of IMG senders.
IMG metadata is used to find, obtain, manage and play content. IMG IMG metadata is used to find, obtain, manage and play media content.
metadata distributions may be modified as they are distributed. For IMG metadata may be modified during IMG Transfer. For example, a
example, a server may use IMGs to retrieve media content via unicast server may use IMGs to retrieve media content via unicast and then
and then make it available at scheduled times via multicast, thus make it available at scheduled times via multicast, thus requiring a
requiring a change of the corresponding metadata. IMG transceivers change of the corresponding metadata. IMG transceivers may add or
may add or delete information or aggregate IMG metadata from delete information or aggregate IMG metadata from different IMG
different IMG senders. For example, a rating service may add its own senders. For example, a rating service may add its own content
content ratings or recommendations to existing metadata. An ratings or recommendations to existing metadata. An implication of
implication of changing (or aggregating) IMG metadata from one or changing (or aggregating) IMG metadata from one or more IMG senders
more IMG senders is that the original authenticity is lost. Thus for is that the original authenticity is lost. Thus, IMG metadata
deployments requiring these kind of features, the original metadata fragmented reasonably may be beneficial for the intermediary to
should be reasonably fragmented already (allowing the intermediary to
replace a small fragment without changing the authenticity of the replace a small fragment without changing the authenticity of the
remainder). It may be beneficial to use smaller fragments for more remainder. For example, smaller fragments may be appropriate for more
volatile parts, and larger ones for more stable parts. volatile parts, and larger ones may be appropriate for stable parts.
4.2 One-to-many Unidirectional Multicast 4.2 One-to-many Unidirectional Multicast
This case implies many IMG receivers and one or more IMG senders One-to-many unidirectional multicast case implies many IMG receivers
implementing IMG ANNOUNCER and IMG LISTENER operations as shown in and one or more IMG senders implementing IMG ANNOUNCER and IMG
Figure 5. LISTENER operations as shown in Figure 5.
Unidirectional +----------+ Unidirectional +----------+
---------------> | IMG | ---------------> | IMG |
downlink | Listener | downlink | Listener |
------------->| 1 | ------------->| 1 |
/ +----------+ / +----------+
+-----------+ / . +-----------+ / .
| IMG |-------- . | IMG |-------- .
| Announcer | \ . | Announcer | \ .
+-----------+ \ +----------+ +-----------+ \ +----------+
------------->| IMG | ------------->| IMG |
| Listener | | Listener |
| # | | # |
+----------+ +----------+
Figure 5: IMG Unidirectional Multicast Distribution Example Figure 5: IMG Unidirectional Multicast Distribution Example
Note, as defined in by the IMG requirements REL-4 [4], an IMG
transport protocol MUST support reliable message exchange.
This includes the one-to-many unidirectional multicast case,
however, the mechanism to provide this is beyond the scope of this
document.
4.3 One-to-one Bi-directional Unicast 4.3 One-to-one Bi-directional Unicast
Both query/resolve (Figure 6) and subscribe/notify (Figure 7) message In one-to-one bi-directional unicast case, both query/resolve
exchange operations are feasible. The "time passes" activities of (Figure 6) and subscribe/notify (Figure 7) message exchange
Figure 7 are purely for example. operations are feasible.
+----------+ +----------+ +----------+ +----------+
| IMG | | IMG | | IMG | | IMG |
| Resolver | | Querier | | Resolver | | Querier |
+----------+ +----------+ +----------+ +----------+
| | | |
|<----------IMG QUERY -----------| |<----------IMG QUERY -----------|
| | | |
|----------IMG RESOLVE---------->| |----------IMG RESOLVE---------->|
| | | |
skipping to change at page 14, line 34 skipping to change at page 14, line 28
\ \--->| IMG Querier | \ \--->| IMG Querier |
\ +-----------+ | - - - - - - -| \ +-----------+ | - - - - - - -|
\| IMG |<--------->| IMG | \| IMG |<--------->| IMG |
| Notifier | | Subscriber | | Notifier | | Subscriber |
+-----------+ +--------------+ +-----------+ +--------------+
Figure 8: Combined System with Common Metadata Figure 8: Combined System with Common Metadata
5 Applicability of Existing Protocols to the Proposed Framework Model 5 Applicability of Existing Protocols to the Proposed Framework Model
5.1 Existing Standard Fit to the IMG Framework Model 5.1 Existing Standard Fitting the IMG Framework Model
SDP: The SDP format could be used to describe session-level SDP: The SDP format [2] could be used to describe session-level
parameters (e.g. scheduling, addressing and the use of media codecs) parameters (e.g., scheduling, addressing and the use of media codecs)
to be included in Complete IMG Descriptions. Although there are to be included in Complete IMG Descriptions. Although there are
extension points in SDP allowing the format to be extended, there are extension points in SDP allowing the format to be extended, there are
limitations in the flexibility of this extension mechanism. However, limitations in the flexibility of this extension mechanism. However,
SDP syntax cannot provide IMG Descriptions and IMG Pointers without SDP syntax cannot provide IMG Descriptions and IMG Pointers without
significant unused overhead. It is expected that the information significant overhead. It is expected that the information conveyed by
conveyed by SDP is just a small subset of IMG metadata, thus the use SDP is just a small subset of IMG metadata, thus, the use of SDP for
of SDP for other than session parameters may not be reasonable. other than session parameters may not be reasonable.
SDPng: Similar to SDP, this format could also be used for SDPng [3]: Similar to SDP, this format could also be used for
representing session-level parameters of IMG metadata. Compared to representing session-level parameters of IMG metadata. Compared to
SDP, the XML-based format of SDPng should be much more flexible with SDP, the XML-based format of SDPng should be much more flexible and
regards to extensions and combining with other description formats. allow extensions and integration with other description formats.
MPEG-7: Descriptions based on the MPEG-7 standard could provide MPEG-7: Descriptions based on the MPEG-7 standard [5] could provide
application-specific metadata describing the properties of multimedia application-specific metadata describing the properties of multimedia
content beyond parameters carried in SDP or SDPng descriptions. content beyond parameters carried in SDP or SDPng descriptions.
MPEG-7 provides a machine-readable format of representing content MPEG-7 provides a machine-readable format of representing content
categories and attributes, helping end-users or receiving software in categories and attributes, helping end-users or receiving software in
choosing content for reception: this is well in line with the IMG choosing content for reception. MPEG-7 is based on XML so it is well
usage scenarios of IMGs introduced in 3.2. MPEG-7 is based on XML so suited to be combined with other XML-based formats such as SDPng.
it is well suited for combining with other XML-based formats such as
SDPng.
TV-Anytime Forum: The TV-Anytime Forum [5] provides descriptions TV-Anytime Forum: The TV-Anytime Forum [6] provides descriptions
based on XML schema for TV-specific program guides. TV-Anytime uses based on XML schema for TV-specific program guides. TV-Anytime uses
the MPEG-7 User description profile to a limited extent (for user the MPEG-7 User description profile to a limited extent, only for
preferences and usage history) and also a TV-Anytime-specific data user preferences and usage history, and also a TV-Anytime-specific
model for other schema - which are optimised to describe broadcast data model for other schema. These are optimised to describe
schedules, on-demand program guides and program events. broadcast schedules, on-demand program guides and program events.
HTTP: The HTTP protocol can be used as a bi-directional/unicast IMG HTTP: The HTTP protocol [7] can be used as a bi-directional unicast
transport protocol. Being a request-reply oriented protocol, HTTP is IMG transport protocol. Being a request-reply oriented protocol, HTTP
well suited for implementing synchronous operations such as QUERY, is well suited for implementing synchronous operations such as QUERY,
RESOLVE and even SUBSCRIBE. However, HTTP does not provide RESOLVE and even SUBSCRIBE. However, HTTP does not provide
asynchronous operations such as ANNOUNCE and NOTIFY and to implement asynchronous operations such as ANNOUNCE and NOTIFY and to implement
asynchronous operations using HTTP, IMG receivers should poll the IMG asynchronous operations using HTTP, IMG receivers should poll the IMG
sender periodically. So alone, HTTP is not sufficient to fulfill IMG sender periodically. Thus, by itself, HTTP is not sufficient to
requirements in a unicast deployment. fulfill all of the IMG requirements [4] in a unicast deployment.
SAP: The announcement mechanism provided by SAP provides SAP: The announcement mechanism provided by SAP [8] provides
unidirectional delivery of session discovery information. Although unidirectional delivery of session discovery information. Although
SDP is the default payload format of SAP, the use of a MIME type SDP is the default payload format of SAP, the use of a MIME type
identifier for the payload allows arbitrary payload formats to be identifier for the payload allows arbitrary payload formats to be
used in SAP messages. Thus, SAP could be used to implement the used in SAP messages. Thus, SAP could be used to implement the
(multicast and unicast) IMG ANNOUNCE and IMG NOTIFY operations. 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 However, SAP lacks scalable and efficient reliability, extensibility
for payload size, congestion control, and only one description
allowed per SAP message due to lack of payload segmentation.
In principle, the current SAP protocol could be extended to get In principle, SAP could be extended to get around its limitations.
around its limitations (e.g. the use of a multipart MIME type in the However, the amount of changes needed in SAP to address all of the
SAP payload enabling multiple descriptions to be carried in a single above limitations would effectively result in a new protocol. Due to
SAP message). However, the amount of changes needed in SAP to address these limitations, the use of SAP as an IMG transport protocol is NOT
all of the above limitations would effectively result in a new RECOMMENDED.
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 [6] SIP: The SIP-specific event mechanism described in RFC 3265 [9]
provides a way to implement IMG SUBSCRIBE and IMG NOTIFY operations provides a way to implement IMG SUBSCRIBE and IMG NOTIFY operations
via a bi-directional unicast connection. However, there are via a bi-directional unicast connection. However, there are
scalability problems with this approach, as RFC 3265 currently does scalability problems with this approach, as RFC 3265 currently does
not consider multicast. not consider multicast.
RTSP: The RTSP protocol defines a retrieval and update notification RTSP: The RTSP protocol [10] defines a retrieval and update
mechanism, named DESCRIBE and ANNOUNCE, for the description of a notification mechanism, named DESCRIBE and ANNOUNCE, for the
presentation or media object in order to initialize a streaming description of a presentation or media object in order to initialize
session. These methods are subset of the entire streaming control a streaming session. These methods are subset of the entire streaming
operations in RTSP, thus these could not be available for individual control operations in RTSP, thus these could not be available for
mechanisms. However, the DESCRIBE method in RTSP could be use to individual mechanisms. However, the DESCRIBE method in RTSP could be
instantiate IMG QUERY, IMG RESOLVE and IMG SUBSCRIBE, and the RTSP used to instantiate IMG QUERY, IMG RESOLVE and IMG SUBSCRIBE, and the
ANNOUNCE could be use to instantiate an IMG NOTIFY for a streaming RTSP ANNOUNCE could be used to instantiate an IMG NOTIFY for a
session controlled by RTSP. streaming session controlled by RTSP.
5.2 Outstanding IMG Mechanism Needs 5.2 IMG Mechanism Needs Not Yet Met
Several outstanding needs result from the IMG requirements, framework Several needs result from the IMG requirements, framework model and
model and existing relevant mechanisms as already shown in this existing relevant mechanisms as already shown in this document. Four
document. Four specific groupings of work are readily apparent which specific groupings of work are readily apparent which are: (a)
are: (a) specification of an adequate multicast and unidirectional specification of an adequate multicast and unidirectional capable
capable announcement protocol; (b) specification of the use of announcement protocol; (b) specification of the use of existing
existing unicast protocols to enable unicast subscribe and unicast protocols to enable unicast subscribe and
announcement/notification functionality; (c) specification of the announcement/notification functionality; (c) specification of the
metadata envelope which is common to, and independent of, the metadata envelope which is common to, and independent of, the
application metadata syntax(es) used; (d) agreement on basic metadata application metadata syntax(es) used; (d) agreement on basic metadata
models to enable interoperability testing of the above. The following models to enable interoperability testing of the above. The following
sections describe each of these. sections describe each of these.
5.2.1 A Multicast Transport Protocol 5.2.1 A Multicast Transport Protocol
SAP is currently the only open standard protocol suited to the SAP is currently the only open standard protocol suited to the
unidirectional/multicast delivery of IMG metadata. As discussed, it unidirectional/multicast delivery of IMG metadata. As discussed, it
fails to meet the IMG requirements in many ways and, since it is not fails to meet the IMG requirements in many ways and, since it is not
designed to be extensible, we recognize that a new multicast designed to be extensible, we recognize that a new multicast
transport protocol for announcements needs to be specified to meet transport protocol for announcements needs to be specified to meet
IMG needs. This protocol will be essential to IMG delivery for IMG needs. This protocol will be essential to IMG delivery for
unidirectional and multicast deployments. unidirectional and multicast deployments.
The Asynchronous Layered Coding (ALC) [7] protocol from the IETF The Asynchronous Layered Coding (ALC) [11] protocol from the IETF
Reliable Multicast Transport (RMT) working group is very interesting Reliable Multicast Transport (RMT) working group is very interesting
as it fulfils many of the requirements, is extensible and has the as it fulfills many of the requirements, is extensible and has the
ability to 'plug-in' both FEC (Forward Error Correction -- for ability to 'plug-in' both FEC (Forward Error Correction -- for
reliability) and CC (Congestion Control) functional blocks -- it is reliability) and CC (Congestion Control) functional blocks -- it is
specifically designed for unidirectional multicast object transport. specifically designed for unidirectional multicast object transport.
ALC is not fully specified, although RMT has a fully specified ALC is not fully specified, although RMT working group had a fully
protocol using ALC called FLUTE (File Delivery over Unidirectional specified protocol using ALC called FLUTE (File Delivery over
Transport) [8]. FLUTE seems to be the only fully specified transport
and open specification on which a new IMG announcement protocol could Unidirectional Transport) [12]. FLUTE seems to be the only fully
be designed. Thus we recommend that ALC and FLUTE be the starting specified transport and open specification on which a new IMG
points for this protocol's design. 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, Developing a new protocol from scratch, or attempting to improve SAP,
is also feasible, although it would involve repeating many of the is also feasible, although it would involve repeating many of the
design processes and decisions already made by the IETF for ALC. 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 In particular, any announcement protocol must feature sufficient
scalability, flexibility and reliability to meet IMG needs. Also, the scalability, flexibility and reliability to meet IMG needs. Also, the
IMG ANNOUNCE operation must be supported and IMG NOTIFY capability IMG ANNOUNCE operation must be supported and IMG NOTIFY capability
could be investigated for both hybrid unicast-multicast and could be investigated for both hybrid unicast-multicast and
unidirectional unicast systems. unidirectional unicast systems.
5.2.2 Usage of Unicast Transport Protocols 5.2.2 Usage of Unicast Transport Protocols
A thorough description of the use of existing unicast protocols is A thorough description of the use of existing unicast protocols is
essential for the use of IMGs in a unicast point-to-point essential for the use of IMGs in a unicast point-to-point
environment. Such a specification does not currently exist, although environment. Such a specification does not currently exist, although
several usable unicast transport protocols and specifications can be several usable unicast transport protocols and specifications can be
harnessed for this (SIP [9], SIP events [6], HTTP [10], etc.) In harnessed for this (SIP [13], SIP events [9], HTTP [7], etc.) In
particular, both IMG SUBSCRIBE-NOTIFY and IMG QUERY-RESOLVE operation particular, both IMG SUBSCRIBE-NOTIFY and IMG QUERY-RESOLVE operation
pairs must be enabled. We anticipate that the IMG QUERY-RESOLVE pairs must be enabled. We anticipate that the IMG QUERY-RESOLVE
operation will be a trivial usage of HTTP, although other transport operation can be achieved using HTTP, although other transport
protocol options may be beneficial to consider too. protocol options may be beneficial to consider too.
5.2.3 IMG Envelope 5.2.3 IMG Envelope
Section 3.2.6 of this document discussed the need for binding between An IMG envelope provides binding between IMG Operations and data
IMG Operations and Data Types. Such a binding can be realized by types. Such a binding can be realized by defining a common minimal
defining a common minimal set of information needed to manage IMG set of information needed to manage IMG metadata transfers, and by
metadata transfers, and by including this information with any set of including this information with any set of IMG metadata delivered to
IMG metadata delivered to IMG receiver(s). IMG receivers.
Four options for IMG metadata transfer envelope delivery are Four options for IMG metadata transfer envelope delivery are
feasible: feasible:
1. Embedding in a transport protocol header. This can be done 1. Embedding in a transport protocol header. This can be done
with either header extensions of existing protocols, or with either header extensions of existing protocols, or
newly defined header fields of a new (or new version of a) newly defined header fields of a new (or new version of a)
transport protocol. However, multiple methods for the transport protocol. However, multiple methods for the
variety of transport protocols would hinder variety of transport protocols would hinder
interoperability and transport protocol independence. interoperability and transport protocol independence.
2. A separate envelope object, which points to the IMG 2. A separate envelope object, which points to the IMG
metadata 'object', delivered in-band with the metadata metadata 'object', delivered in-band with the metadata
transport protocol session. This might complicate transport protocol session. This might complicate
delivery as the envelope and 'service' metadata objects delivery as the envelope and 'service' metadata objects
would have to be bound, e.g. by pairing some kind of would have to be bound, e.g., by pairing some kind of
transport object numbers (analogous to port number pairs transport object numbers (analogous to port number pairs
sometimes used for RTP and RTCP [11]). This would also sometimes used for RTP and RTCP [14]). This would also
enable schemes which deliver enveope and metadata enable schemes which deliver enveope and metadata
'objects' on by different media, also using more than a 'objects' on by different media, also using more than a
single transport protocol. single transport protocol.
3. A metadata wrapper which points to and/or embeds the 3. A metadata wrapper which points to and/or embeds the
service metadata into its 'super-syntax'. For example, an service metadata into its 'super-syntax'. For example, an
XML would enable embedding generic text objects. XML would enable embedding generic text objects.
4. Embedding in the metadata itself. However, this requires 4. Embedding in the metadata itself. However, this requires
new field in many metadata syntaxes and would not be new field in many metadata syntaxes and would not be
skipping to change at page 18, line 52 skipping to change at page 18, line 29
experience. Such a specification is essential for IMG delivery. experience. Such a specification is essential for IMG delivery.
When there are superset/subset relations between IMG descriptions, When there are superset/subset relations between IMG descriptions,
it is assumed that the IMG descriptions of the subset inherit the it is assumed that the IMG descriptions of the subset inherit the
parameters of the superset. Thus, an IMG metadata transfer envelope parameters of the superset. Thus, an IMG metadata transfer envelope
carrying the IMG descriptions of a superset may implicitly define carrying the IMG descriptions of a superset may implicitly define
parameters of IMG descriptors belonging to its subset. The parameters of IMG descriptors belonging to its subset. The
relations between IMG descriptions may span from one envelope to relations between IMG descriptions may span from one envelope to
another according to a data model definition. another according to a data model definition.
5.2.4 Baseline (Meta)Data Model Specification 5.2.4 Metadata Data Model
A minimal IMG data model may be useful to any implementer/deployment
of IMGs. The purpose would be to ensure that multiple metadata A structured data model would allow reuse and extension of the set of
syntaxes (SDP, MPEG-7, etc.) can be related within the same body of metadata and may enable use of multiple syntaxes (SDP, MPEG-7, etc.)
IMG knowledge, regardless of any specific metadata and data models as part of the same body of IMG metadata.
provided by the metadata syntaxes.
Further work may be needed to meet application-specific requirements Further work may be needed to meet application-specific requirements
at defining metadata and data models for the successful deployment of at defining metadata and data models for the successful deployment of
IMGs in various environments. Existing (and future) work on these 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 would need to be mapped to the IMG data types and use of the IMG
transfer envelope concept as described above. transfer envelope concept as described above.
This document is a framework for the delivery of IMG metadata and This document is a framework for the delivery of IMG metadata and
thus further discussion on the definition data models for IMGs is thus further discussion on the definition data models for IMGs is
beyond its scope. beyond its scope.
6 Security Considerations 6 Security Considerations
The IMG framework is developed from the IMG requirements document [4] The IMG framework is developed from the IMG requirements document [4]
and so the selection of specific protocols and mechanism for use with and so the selection of specific protocols and mechanism for use with
the IMG framework must also take into account the security the IMG framework must also take into account the security
considerations of the IMG requirements document. This framework considerations of the IMG requirements document. This framework
document does not mandate the use of specific protocols. However, an document does not mandate the use of specific protocols. However, an
IMG specification would inherit the security considerations of IMG specification would inherit the security considerations of
specific protocols used, although this is outside the scope of this specific protocols used.
document.
Protocol instantiations which are used to provide IMG operations will Protocol instantiations which are used to provide IMG operations will
have very different security considerations depending on their scope have very different security considerations depending on their scope
and purpose. However, there are several general issues which are and purpose. However, there are several general issues which are
valuable to consider and, in some cases, provide technical solutions valuable to consider and, in some cases, provide technical solutions
to deal with. These are described below. to deal with. These are described below.
Individual and Group Privacy: Customized IMG metadata may reveal Individual and group privacy: Customized IMG metadata may reveal
information about the habits and preferences of a user and may thus information about the habits and preferences of a user and may thus
deserve confidentiality protection, even if the original information deserve confidentiality protection, even if the original information
were public. Snooping and protecting this IMG metadata requires the were public. Snooping and protecting this IMG metadata requires the
same actions and measures as for other point-to-point and multicast same actions and measures as for other point-to-point and multicast
Internet communications. Naturally, the risk of snooping depends on Internet communications. Naturally, the risk of snooping depends on
the amount of individual or group personalization the snooped IMG the amount of individual or group personalization the snooped IMG
metadata contains. Further consideration is valuable at network, metadata contains.
transport and metadata levels.
IMG Authenticity: In some cases, the IMG receiver needs to be assured IMG authenticity: In some cases, the IMG receiver needs to be assured
of the origin of IMG metadata or its modification history. This can of the sender or origin of IMG metadata or its modification history.
prevent denial of service or hijacking attempts which give an IMG This can prevent denial of service or hijacking attempts which give
receiver incorrect information in or about the metadata, thus an IMG receiver incorrect information in or about the metadata, thus
preventing successful access of the media or directing the IMG preventing successful access of the media or directing the IMG
receiver to the incorrect media possibly with tasteless material. 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 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 may be private or valuable enough to allow access to only certain IMG
receivers and thus make it worth authenticating users. Encrypting the receivers and thus make it worth authenticating users. Encrypting the
data is also a reasonable step, especially where group communications data is also a reasonable step, especially where group communications
methods results in unavoidable snooping opportunities for methods results in unavoidable snooping opportunities for
unauthorized nodes. Encryption and the required security parameters unauthorized nodes.
exchange are outside the scope of this document.
Unidirectional Specifics: A difficulty that is faced by Unidirectional specifics: A difficulty that is faced by
unidirectional delivery operations is that many protocols providing unidirectional delivery operations is that many protocols providing
application-level security are based on bi-directional application-level security are based on bi-directional
communications. The application of these security protocols in case communications. The application of these security protocols in case
of strictly unidirectional links is not considered in the present of strictly unidirectional links is not considered in the present
document. document.
Malicious Code: Currently, IMGs are not envisaged to deliver Malicious code: Currently, IMGs are not envisaged to deliver
executable code at any stage. However, as some IMG transport executable code at any stage. However, as some IMG transport
protocols may be capable of delivering arbitrary files, it is protocols may be capable of delivering arbitrary files, it is
RECOMMENDED that the IMG transport methods do not have write access RECOMMENDED that the IMG operations do not have write access to the
to the system or any other critical areas. 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
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.
7 IANA Considerations 7 IANA Considerations
There are no IANA considerations within this document. This document does not request any IANA action.
8 Normative References 8 Normative References
[1] S. Bradner, "Key words for use in RFCs to indicate requirement [1] S. Bradner, "Key words for use in RFCs to indicate requirement
levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. levels," RFC 2119, Internet Engineering Task Force, March 1997.
9 Informative References 9 Informative References
[2] M. Handley and V. Jacobson, "SDP: session description protocol," [2] M. Handley and V. Jacobson, "SDP: session description protocol,"
RFC 2327, Internet Engineering Task Force, Apr. 1998. RFC 2327, Internet Engineering Task Force, April 1998.
[3] D. Kutscher, J. Ott, and C. Bormann, "Session description and [3] D. Kutscher, J. Ott, and C. Bormann, "Session description and
capability negotiation," Internet Draft draft-ietf-mmusic-sdpng-07, capability negotiation," Internet Draft draft-ietf-mmusic-sdpng-07,
Internet Engineering Task Force, Oct. 2003. Work in progress. Internet Engineering Task Force, October 2003. Work in progress.
[4] Y. Nomura, R. Walsh, J-P. Luoma, J. Ott, and H. Schulzrinne, [4] Y. Nomura, R. Walsh, J-P. Luoma, J. Ott, and H. Schulzrinne,
"Requirements for Internet Media Guides," Internet Draft "Requirements for Internet Media Guides," Internet Draft
draft-ietf-mmusic-img-req-07, Internet Engineering Task Force, June draft-ietf-mmusic-img-req-08, Internet Engineering Task Force,
2004. Work in progress. December 2005. Work in progress.
[5] TV-Anytime Forum, "Broadcast and On-line Services: Search, [5] "Multimedia content description interface -- Part 1: Systems",
ISO/IEC 15938-1, July 2002.
[6] TV-Anytime Forum, "Broadcast and On-line Services: Search,
select, and rightful use of content on personal storage systems select, and rightful use of content on personal storage systems
("TV-Anytime Phase 1"); Part 2: System description," ETSI-TS 102 ("TV-Anytime Phase 1"); Part 2: System description," ETSI-TS 102
822-2: System Description, V1.1.1, October 2003. 822-2: System Description, V1.1.1, October 2003.
[6] A. B. Roach, "Session initiation protocol (sip)-specific event [7] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, L. Masinter, P.
Leach and T. Berners-Lee, "Hypertext transfer protocol -- HTTP/1.1,"
RFC 2616, Internet Engineering Task Force, June 1999.
[8] M. Handley, C. E. Perkins, and E. Whelan, "Session announcement
protocol," RFC 2974, Internet Engineering Task Force, October 2000.
[9] A. B. Roach, "Session initiation protocol (sip)-specific event
notification," RFC 3265, Internet Engineering Task Force, June 2002. notification," RFC 3265, Internet Engineering Task Force, June 2002.
[7] M. Luby, J. Gemmell, L. Vicisano, L. Rizzo, and J. Crowcroft, [10] H. Schulzrinne, A. Rao, and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, Internet Engineering Task Force,
April 1998.
[11] M. Luby, J. Gemmell, L. Vicisano, L. Rizzo, and J. Crowcroft,
"Asynchronous layered coding (ALC) protocol instantiation," RFC 3450, "Asynchronous layered coding (ALC) protocol instantiation," RFC 3450,
Internet Engineering Task Force, Dec. 2002. Internet Engineering Task Force, December 2002.
[8] T. Paila, M. Luby, R. Lehtonen, V. Roca, R. Walsh, "FLUTE - [12] T. Paila, M. Luby, R. Lehtonen, V. Roca, R. Walsh, "FLUTE -
file delivery over unidirectional transport," Internet Draft file delivery over unidirectional transport," RFC 3926,
draft-ietf-rmt-flute-08, Internet Engineering Task Force, Internet Engineering Task Force, October 2004.
June 2004. Work in progress.
[9] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J. [13] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J.
Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session
initiation protocol," RFC 3261, Internet Engineering Task Force, June initiation protocol," RFC 3261, Internet Engineering Task Force, June
2002. 2002.
[10] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, L. Masinter, P. [14] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP:
Leach and T. Berners-Lee, "Hypertext transfer protocol -- HTTP/1.1,"
RFC 2616, Internet Engineering Task Force, June 1999.
[11] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP:
a transport protocol for real-time applications," RFC 3550, Internet a transport protocol for real-time applications," RFC 3550, Internet
Engineering Task Force, July 2003. Engineering Task Force, July 2003.
10 Acknowledgements 10 Acknowledgements
The authors would like to thank Joerg Ott, Colin Perkins, Toni Paila, The authors would like to thank Spencer Dawkins, Jean-Pierre Evain,
Jean-Pierre Evain, Magnus Westerlund and Petri Koskelainen for their Ted Hardie, Petri Koskelainen, Joerg Ott, Colin Perkins, Toni Paila,
excellent ideas and input to this document. Magnus Westerlund, and for their excellent ideas and input to this
document.
11 Authors' Addresses 11 Authors' Addresses
Yuji Nomura Yuji Nomura
Fujitsu Laboratories Ltd. Fujitsu Laboratories Ltd.
4-1-1 Kamikodanaka, Nakahara-ku, Kawasaki 211-8588 4-1-1 Kamikodanaka, Nakahara-ku, Kawasaki 211-8588
Japan Japan
Email: nom@flab.fujitsu.co.jp Email: nom@flab.fujitsu.co.jp
Rod Walsh Rod Walsh
skipping to change at page 22, line 27 skipping to change at page 21, line 43
Email: rod.walsh@nokia.com Email: rod.walsh@nokia.com
Juha-Pekka Luoma Juha-Pekka Luoma
Nokia Research Center Nokia Research Center
P.O. Box 100, FIN-33721 Tampere P.O. Box 100, FIN-33721 Tampere
Finland Finland
Email: juha-pekka.luoma@nokia.com Email: juha-pekka.luoma@nokia.com
Hitoshi Asaeda Hitoshi Asaeda
INRIA INRIA
Project PLANETE PLANETE Research Team
2004, Route des Lucioles, BP93, 2004, Route des Lucioles, BP93,
06902 Sophia Antipolis, 06902 Sophia Antipolis,
France France
Email: Hitoshi.Asaeda@sophia.inria.fr Email: Hitoshi.Asaeda@sophia.inria.fr
Henning Schulzrinne Henning Schulzrinne
Dept. of Computer Science Dept. of Computer Science
Columbia University Columbia University
1214 Amsterdam Avenue 1214 Amsterdam Avenue
New York, NY 10027 New York, NY 10027
USA USA
Email: schulzrinne@cs.columbia.edu Email: schulzrinne@cs.columbia.edu
12 Full Copyright Statement Intellectual Property 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
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at line 1026 skipping to change at page 22, line 31
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 121 change blocks. 
374 lines changed or deleted 332 lines changed or added

This html diff was produced by rfcdiff 1.28, available from http://www.levkowetz.com/ietf/tools/rfcdiff/