draft-ietf-mmusic-img-framework-00.txt   draft-ietf-mmusic-img-framework-01.txt 
Internet Engineering Task Force MMUSIC WG Internet Engineering Task Force MMUSIC WG
Internet Draft Y. Nomura Internet Draft Y. Nomura
Fujitsu Labs. Fujitsu Labs.
R. Walsh R. Walsh
J. 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-00.txt draft-ietf-mmusic-img-framework-01.txt
November 17, 2003 December 2, 2003
Expires: May 2004 Expires: March 2004
A Framework for the Usage of Internet Media Guides A Framework for the Usage of Internet Media Guides
STATUS OF THIS MEMO STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
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
skipping to change at page 2, line 8 skipping to change at page 2, line 8
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 several use case session description format. This document describes several use case
scenarios requirering the IMG framework, a generalized model for IMG scenarios requirering the IMG framework, a generalized model for IMG
delivery mechanisms, and the use of existing protocol to create an delivery mechanisms, and the use of existing protocol to create an
IMG delivery infrastructure. IMG delivery infrastructure.
Table of Contents Table of Contents
1 Introduction ........................................ 3 1 Introduction ........................................ 3
1.1 Background and Motivation ........................... 3 1.1 Background and Motivation ........................... 3
1.2 Scope of this Document .............................. 3 1.2 Scope of this Document .............................. 4
2 Terminology ......................................... 4 2 Terminology ......................................... 4
3 Use Cases Requiring IMG Framework ................... 4 3 Use Cases Requiring IMG Framework ................... 5
3.1 Connectivity-based Use Cases ........................ 4 3.1 Connectivity-based Use Cases ........................ 5
3.1.1 IP Datacast to a Wireless Receiver .................. 4 3.1.1 IP Datacast to a Wireless Receiver .................. 5
3.1.2 Regular Fixed Dial-up Internet Connection ........... 6 3.1.2 Regular Fixed Dial-up Internet Connection ........... 6
3.1.3 Broadband Always-on Fixed Internet Connection ....... 6 3.1.3 Broadband Always-on Fixed Internet Connection ....... 6
3.2 Content-orientated Use Cases ........................ 6 3.2 Content-orientated Use Cases ........................ 6
3.2.1 File Distribution ................................... 7 3.2.1 File Distribution ................................... 7
3.2.2 TV and Radio Program Delivery ....................... 7 3.2.2 TV and Radio Program Delivery ....................... 7
3.2.3 Media Coverage of a Live Event ...................... 7 3.2.3 Media Coverage of a Live Event ...................... 8
3.2.4 Distance Learning ................................... 8 3.2.4 Distance Learning ................................... 8
3.2.5 Multiplayer Gaming .................................. 8 3.2.5 Multiplayer Gaming .................................. 8
4 IMG Common Framework Model .......................... 8 4 IMG Common Framework Model .......................... 8
4.1 IMG Data-Type ....................................... 9 4.1 IMG Data Types ...................................... 9
4.1.1 Complete Description ................................ 9 4.1.1 Complete Description ................................ 9
4.1.2 Delta Description ................................... 9 4.1.2 Delta Description ................................... 9
4.1.3 Pointer ............................................. 9 4.1.3 Pointer ............................................. 10
4.2 Operation Set for IMG Delivery ...................... 10 4.2 Operation Set for IMG Delivery ...................... 10
4.2.1 IMG ANNOUNCE ........................................ 10 4.2.1 IMG ANNOUNCE ........................................ 10
4.2.2 IMG QUERY ........................................... 10 4.2.2 IMG QUERY ........................................... 10
4.2.3 IMG RESOLVE ......................................... 10 4.2.3 IMG RESOLVE ......................................... 11
4.2.4 IMG SUBSCRIBE ....................................... 11 4.2.4 IMG SUBSCRIBE ....................................... 11
4.2.5 IMG NOTIFY .......................................... 11 4.2.5 IMG NOTIFY .......................................... 11
4.3 IMG Entities ........................................ 11 4.3 IMG Entities ........................................ 12
4.4 Overview of Protocol Operations ..................... 12 4.4 Overview of Protocol Operations ..................... 12
5 Deployment Scenarios for IMG Entities ............... 13 5 Deployment Scenarios for IMG Entities ............... 13
5.1 One-to-many Unidirectional Multicast ................ 14 5.1 Intermediary Cases .................................. 13
5.2 One-to-one Bi-directional Unicast ................... 15 5.2 One-to-many Unidirectional Multicast ................ 15
5.3 Combined Operations with Common Metadata ............ 15 5.3 One-to-one Bi-directional Unicast ................... 15
5.4 Combined Operations with Common Metadata ............ 16
6 Applicability of Existing Protocols to the 6 Applicability of Existing Protocols to the
Proposed Framework Model ............................ 16 Proposed Framework Model ....................................... 17
6.1 Summary of Limitations of Existing Protocols ........ 16 6.1 Summary of Limitations of Existing Protocols ........ 17
6.2 Existing Protocol Fit to the IMG Framework Model 6.2 Existing Protocol Fit to the IMG Framework Model
6.3 Outstanding IMG Mechanism Needs ..................... 18 6.3 Outstanding IMG Mechanism Needs ..................... 19
6.3.1 A Multicast Transport Protocol ...................... 19 6.3.1 A Multicast Transport Protocol ...................... 19
6.3.2 Usage of Unicast Transport Protocols ................ 19 6.3.2 Usage of Unicast Transport Protocols ................ 20
6.3.3 The Metadata Envelope ............................... 20 6.3.3 The Metadata Envelope ............................... 20
6.3.4 Baseline (Meta)Data Model Specification ............. 21 6.3.4 Baseline (Meta)Data Model Specification ............. 21
7 Security Considerations ............................. 22 6.4 IMG Needs Fitting the IETF's Scope .................. 22
8 Normative References ................................ 23 7 Security Considerations ............................. 23
9 Infomative References ............................... 25 8 Normative References ................................ 24
10 Acknowledgements .................................... 25 9 Informative References .............................. 25
11 Authors' Addresses .................................. 25 10 Acknowledgements .................................... 26
12 Bibliography ........................................ 26 11 Authors' Addresses .................................. 26
1 Introduction 1 Introduction
1.1 Background and Motivation 1.1 Background and Motivation
An Internet Media Guide (IMG) is a structured collection of Internet Media Guide (IMG) provide structured collections of
multimedia session descriptions expressed using SDP, SDPng or some multimedia descriptions expressed using SDP, SDPng or some similar
similar session description format. It is used to describe a set of description format. It is used to describe sets of multimedia
multimedia sessions (e.g. television program schedules, content sessions (e.g. television program schedules, content delivery
delivery schedules etc.) but may also refer to other networked schedules etc.) and refer to other networked resources including web
resources including web pages. An IMG provides an envelope for pages. IMGs provide an envelope for metadata formats and session
metadata formats and session descriptions defined elsewhere with the descriptions defined elsewhere with the aim of facilitating
aim of facilitating structuring, versioning, referencing, structuring, versioning, referencing, distributing, and maintaining
distributing, and maintaining (caching, updating) such information. (caching, updating) such information.
Firstly, this document explains several use case scenarios Firstly, this document explains several use case scenarios requiring
requirering the IMG framework. IMGs are inherently required to be the IMG framework. IMGs are inherently required to be independent of
independent of any particular access network, and link in general. any particular access network, and link in general. Therefore, they
Therefore, they are suitable in many Internet access scenarios are suitable in many Internet access scenarios including fixed and
including fixed and mobile devices, wired and satellite and mobile devices, wired and satellite and terrestrial radio, always-on
terrestrial radio, always-on Internet and intermittent connectivity, Internet and intermittent connectivity, and so on. Furthermore, IMGs
and so on. Furthermore, IMGs provides essential functions that provides essential functions that facilitate better distribution of
facilitate better distribution of content. Section 3 describes how content. Section 3 describes how IMGs and IMG delivery mechanisms
IMGs and IMG delivery mechanisms contribute for the scenarios. contribute for the scenarios.
Then, this document defines a generalized model for IMG delivery Then, this document defines a generalized model for IMG delivery
mechanisms and their deployment in network entities regarding the use mechanisms and their deployment in network entities regarding the use
case scenarios. The IMG must be delivered to a potentially large case scenarios. IMG metadata must be delivered to a potentially large
audience, who use it to join a subset of the sessions described, and audience, who use it to join a subset of the sessions described, and
who may need to be notified of changes to the IMG. Hence, a framework who may need to be notified of changes to the IMG metadata. Hence, a
for distributing IMGs in various different ways is needed to framework for distributing IMG metadata in various different ways is
accommodate the needs of different audiences: For traditional needed to accommodate the needs of different audiences: For
broadcast-style scenarios, multicast-based (push) distribution of traditional broadcast-style scenarios, multicast-based (push)
IMGs needs to be supported. Where no multicast is available, distribution of IMG metadata needs to be supported. Where no
unicast-based push is required, too. multicast is available, unicast-based push is required, too.
Finally, this document outlines the use of existing protocol to Finally, this document outlines the use of existing protocols to
create an IMG delivery infrastructure. It aims to organize existing create an IMG delivery infrastructure. It aims to organize existing
protocol into common model and show their capabilities and protocols into common model and show their capabilities and
limitations from the view point of IMG delivery functions. One of the limitations from the view point of IMG delivery functions. One of the
multicast- enabling IMG requirements is scaling well to a large multicast-enabling IMG requirements is scaling well to a large number
number of hosts and IMG senders in a network. Another issue is the of hosts and IMG senders in a network. Another issue is the need for
need for flexibility and diversity in delivery methods, whereas flexibility and diversity in delivery methods, whereas existing
existing protocols tend to be bound to a specific application. protocols tend to be bound to a specific application.
1.2 Scope of this Document 1.2 Scope of this Document
This document defines the a common framework model for the delivery This document defines a common framework model for the delivery of
of Internet Media Guides (IMG). The framework describes existing Internet Media Guide (IMG) metadata. The framework describes existing
mechanisms and the level to which they support and enable the mechanisms and the level to which they support and enable the
framework. The requirements for IMG delivery mechanisms and framework. The requirements for IMG delivery mechanisms and
descriptions can be found in [1]. descriptions can be found in [1].
A brief run through the usage and use cases of media guide is A brief run through the usage and use cases of media guide is
provided to illustrate the relevance of IMGs before the framework provided to illustrate the relevance of IMGs before the framework
model is presented. The framework model defines the data types, model is presented. The framework model defines the data types,
operations and entities which are needed. These are then shown in a operations and entities which are needed. These are then shown in a
number of simplified deployment scenarios. number of simplified deployment scenarios.
Existing protocols are organized and referenced against the framework Existing protocols are organized and referenced against the framework
model to show the degree to which they fulfil IMG framework and model to show the degree to which they fulfill IMG framework and
requirements. This also makes it straightforward to identify gaps so requirements. This also makes it straightforward to identify gaps so
that new protocols needs are made apparent. that new protocols needs are made apparent.
2 Terminology 2 Terminology
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
SHOULD NOT, RECOMMENDED, MAY, and "OPTIONAL" in this document are to "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
be interpreted as described in RFC 2119 [2]. document are to be interpreted as described in RFC 2119 [1].
Internet Media Guide (IMG): An IMG is a set of meta-data Internet Media Guide (IMG): IMG is a generic term to describe
describing the features of multimedia content. For example, the formation, delivery and use of IMG metadata. The
meta-data may consist of the URI, title, air time, definition of the IMG is intentionally left imprecise.
bandwidth needed, file size, text summary, genre, and
access restrictions. IMG Metadata: This is a set of metadata describing the features
of multimedia content used to enable selection of and
access to media sessions containing content. For example,
metadata may consist of the URI, title, airtime, bandwidth
needed, file size, text summary, genre, and access
restrictions.
IMG Delivery: The process of exchanging IMG metadata both in IMG Delivery: The process of exchanging IMG metadata both in
terms of large scale and atomic data transfers. terms of large scale and atomic data transfers.
IMG Sender: An IMG sender is a logical entity that sends IMGs to IMG Sender: An IMG sender is a logical entity that sends IMGs to
one or more IMG receivers. one or more IMG receivers.
IMG Receiver: An IMG receiver is a logical entity that receives IMG Receiver: An IMG receiver is a logical entity that receives
IMGs from an IMG source. IMGs from an IMG sender.
IMG Transceiver: An IMG transceiver combines an IMG receiver and IMG Transceiver: An IMG transceiver combines an IMG receiver and
sender. It may modify original IMGs or merge several IMGs sender. It may modify original IMGs or merge several IMGs
from a different IMG sender. from a different IMG sender.
IMG Operations: An atomic process for the IMG protocol to IMG Operation: An atomic process for the IMG transport protocol
deliver IMG or control the IMG sender or IMG receiver. to deliver IMG metadata or control IMG sender(s) or IMG
receiver(s).
IMG Transport Protocol: A protocol that transports IMG metadata
from IMG sender to IMG receiver(s)
3 Use Cases Requiring IMG Framework 3 Use Cases Requiring IMG Framework
3.1 Connectivity-based Use Cases 3.1 Connectivity-based Use Cases
3.1.1 IP Datacast to a Wireless Receiver 3.1.1 IP Datacast to a Wireless Receiver
IP Datacast is the delivery of IP-based services over broadcast IP Datacast is the delivery of IP-based services over broadcast
radio. Internet content delivery is therefore unidirectional in this radio. Internet content delivery is therefore unidirectional in this
case. However, there can be significant benefits from being able to case. However, there can be significant benefits from being able to
provide rich media one-to-many services to such receivers. provide rich media one-to-many services to such receivers.
There are two main classes of receiver in this use case: fixed There are two main classes of receiver in this use case: fixed
mains-powered; and mobile battery-powered. Both of these are affected mains-powered; and mobile battery-powered. Both of these are affected
by radio phenomena and so robust, or error-resilient, delivery is by radio phenomena and so robust, or error-resilient, delivery is
important. Carouselled metadata transfer provides a base level of important. Carouselled metadata transfer provides a base level of
robustness for an IP datacast based announcement system, although the robustness for an IP datacast based announcement system, although the
skipping to change at page 5, line 23 skipping to change at page 5, line 37
robustness for an IP datacast based announcement system, although the robustness for an IP datacast based announcement system, although the
design of carouselled transfer should enable battery-powered design of carouselled transfer should enable battery-powered
receivers to go through periods of sleep to extend their operational receivers to go through periods of sleep to extend their operational
time between charges. Insertion of Forward Error Correction (FEC) time between charges. Insertion of Forward Error Correction (FEC)
data into metadata announcements improves error resilience, and data into metadata announcements improves error resilience, and
reordering (interleaving) data blocks further increases tolerance to reordering (interleaving) data blocks further increases tolerance to
burst errors. burst errors.
To enable receivers to more accurately specify the metadata they are To enable receivers to more accurately specify the metadata they are
interested in, the unidirectional delivery is distributed between interested in, the unidirectional delivery is distributed between
several logical channels. Such that a receiver need only access the several logical channels. This is so that a receiver need only access
channels of interest and thus reduce the amount of time and the channels of interest and thus can reduce the amount of time and
processing of IP data (and storage). Also, hierarchical channels processing of IP data (and storage). Also, hierarchical channels
enable receivers to subscribe to a root, possibly well known, enable receivers to subscribe to a root, possibly well known,
multicast channel/group and progressively access only those multicast channel/group and progressively access only those
additional channels based on metadata in parent channels. additional channels based on metadata in parent channels.
In some cases the receiver may be multi-access, such that it is In some cases the receiver may be multi-access, such that it is
capable of bi-directional communications. This enables a multitude of capable of bi-directional communications. This enables a multitude of
options, but most importantly it enables NACK based reliability and options, but most importantly it enables NACK based reliability and
the individual retrieval of missed or not-multicasted sets of the individual retrieval of missed or not-multicasted sets of
metadata. metadata.
Thus, essential IMG features in this case include: robust Thus, essential IMG features in this case include: robust
unidirectional delivery (with optional levels of reliability unidirectional delivery (with optional levels of reliability
including "plug-in FEC") which implies easily identifiable including "plug-in FEC") which implies easily identifiable
segmentation f delivery data to enable FEC, carousel, interleaving segmentation of delivery data to enable FEC, carousel, interleaving
and other schemes possible; effective identification of metadata sets and other schemes possible; effective identification of metadata sets
(probably uniquely) to enable more efficient use of multicast and (probably uniquely) to enable more efficient use of multicast and
unicast retrieval over multiple access systems regardless of the unicast retrieval over multiple access systems regardless of the
parts of metadata and application specific extensions in use; parts of metadata and application specific extensions in use;
prioritization of metadata, which can (for instance) be achieved by prioritization of metadata, which can (for instance) be achieved by
spreading it between channels and allocating/distributing bandwidth spreading it between channels and allocating/distributing bandwidth
accordingly. accordingly.
Furthermore, some cases require IMG metadata authentication and some Furthermore, some cases require IMG metadata authentication and some
group security/encryption and supporting security message exchanges group security/encryption and supporting security message exchanges
(out of band from the IMG multicast sessions). (out of band from the IMG multicast sessions).
3.1.2 Regular Fixed Dial-up Internet Connection 3.1.2 Regular Fixed Dial-up Internet Connection
Dial-up connections tend to be reasonably slow (<56kbps in any case) Dial-up connections tend to be reasonably slow (<56kbps in any case)
and thus large data transfers are less feasible, especially during an and thus large data transfers are less feasible, especially during an
active application session (such as a file transfer described by an active application session (such as a file transfer described by IMG
IMG). They can also be intermittent, especially if a user is paying metadata). They can also be intermittent, especially if a user is
for the connected time, or connected through a less reliable paying for the connected time, or connected through a less reliable
exchange. Thus this favors locally stored IMGs over web-based exchange. Thus this favors locally stored IMG metadata over web-based
browsing, especially where parts of the metadata change infrequently. browsing, especially where parts of the metadata change infrequently.
There may be no service provider preference over unicast and There may be no service provider preference over unicast and
multicast transport for small and medium numbers of users as the multicast transport for small and medium numbers of users as the
last-mile dial-up connection limits per-user congestion, and a user last-mile dial-up connection limits per-user congestion, and a user
may prefer the more reliable option (unicast unless reliable may prefer the more reliable option (unicast unless reliable
multicast is provided). multicast is provided).
3.1.3 Broadband Always-on Fixed Internet Connection 3.1.3 Broadband Always-on Fixed Internet Connection
Typically bandwidth is less of an issue to a broadband user and Typically bandwidth is less of an issue to a broadband user and
skipping to change at page 6, line 35 skipping to change at page 6, line 47
providers, ISPs and users having no other requirements, then web- providers, ISPs and users having no other requirements, then web-
based browsing may be equally suitable. However, broadband users based browsing may be equally suitable. However, broadband users
sharing a local area network, especially wireless, may benefit more sharing a local area network, especially wireless, may benefit more
from local storage features than on-line browsing, especially if they from local storage features than on-line browsing, especially if they
have intermittent Internet access. have intermittent Internet access.
Broadband enables rich media services, which are increasingly Broadband enables rich media services, which are increasingly
bandwidth hungry. Thus backbone operators may prefer multicast bandwidth hungry. Thus backbone operators may prefer multicast
communications to reduce overall congestion, if they have the communications to reduce overall congestion, if they have the
equipment and configuration to support this. Thus, broadband users equipment and configuration to support this. Thus, broadband users
may be forced to retrieve IMGs over multicast if the respective may be forced to retrieve IMG metadata over multicast if the
operators require this to keep system-wide bandwidth usage feasible. respective operators require this to keep system-wide bandwidth usage
feasible.
3.2 Content-orientated Use Cases 3.2 Content-orientated Use Cases
IMGs will be able to support a very wide range of use cases for IMGs will be able to support a very wide range of use cases for
content/media delivery. The following few sections just touch the content/media delivery. The following few sections just touch the
surface of what is possible and are intended to provide an surface of what is possible and are intended to provide an
understanding of the scope of the scope and type of IMG usage. Many understanding of the scope and type of IMG usage. Many more examples
more examples may be relevant, for instance those detailed in[3]. may be relevant, for instance those detailed in[3]. There are
There are several unique features of IMGs that set them apart from several unique features of IMGs that set them apart from related
related application areas such as SLP based service location application areas such as SLP based service location discovery, LDAP
discovery, LDAP based indexing services and search engines such as based indexing services and search engines such as Google. Features
Google. Features unique to IMGs include: unique to IMGs include:
o IMG information is generally time-related o IMG metadata is generally time-related
o The are timeliness requirements in the delivery of IMG o There are timeliness requirements in the delivery of IMG
information metadata
o IMG information may be updated as time elapses or when an o IMG metadata may be updated as time elapses or when an event
event arises arises
3.2.1 File Distribution 3.2.1 File Distribution
IMGs support the communication of file delivery session properties, IMGs support the communication of file delivery session properties,
enabling the scheduled delivery or synchronization of files between a enabling the scheduled delivery or synchronization of files between a
number of hosts. An IMG can provide a description to each file in a number of hosts. For example, the metadata that IMGs provide could be
file delivery session, assisting users or receiving software in subsequently used by a different application (outside the scope of
selecting individual files for reception. IMGs) to download a file with a software update. An IMG metadata can
provide a description to each file in a file delivery session,
assisting users or receiving software in selecting individual files
for reception.
For example, when a content provider wants to distribute a large For example, when a content provider wants to distribute a large
amount of data in file format to thousands clients, the content amount of data in file format to thousands clients, the content
provider can use IMG to schedule the delivery effectively. Since IMG provider can use IMG metadata to schedule the delivery effectively.
can describe time-related data for each client, the content provider Since IMG metadata can describe time-related data for each receiver,
can schedule delivery time for each client. This can save network the content provider can schedule delivery time for each receiver.
bandwidth and capacity of delivery servers. In addition, IMG can be This can save network bandwidth and capacity of delivery senders. In
used to synchronize a set of files between a source host and addition, IMG metadata can be used to synchronize a set of files
destination host, when those files change as time elapses. between a sender host and receiver host, when those files change as
time elapses.
3.2.2 TV and Radio Program Delivery 3.2.2 TV and Radio Program Delivery
A source of audio/video streaming content can use the IMG to describe A sender of audio/video streaming content can use the IMG metadata to
the scheduling and other properties of audio/video sessions and describe the scheduling and other properties of audio/video sessions
events within those sessions, such as individual TV and radio and events within those sessions, such as individual TV and radio
programs and segments within those programs. IMG information programs and segments within those programs. IMG metadata describing
describing audio/video streaming content could be represented in a audio/video streaming content could be represented in a format
format similar to that of a TV guide in newspapers, or an Electronic similar to that of a TV guide in newspapers, or an Electronic Program
Program Guide available on digital TV receivers. Guide available on digital TV receivers.
Similarly to file reception, TV and radio programs can be selected Similarly to file reception, TV and radio programs can be selected
for reception either manually by the end-user or automatically based for reception either manually by the end-user or automatically based
on the content descriptions and the preferences of the user. The on the content descriptions and the preferences of the user. The
received TV and radio content can be either presented in real time or received TV and radio content can be either presented in real time or
recorded for consuming later. There may be changes in the scheduling recorded for consuming later. There may be changes in the scheduling
of a TV or a radio program, possibly affecting the transmission times of a TV or a radio program, possibly affecting the transmission times
of subsequent programs. IMG information can be used to notify of subsequent programs. IMG metadata can be used to notify receivers
receivers of such changes, enabling users to be prompted or recording of such changes, enabling users to be prompted or recording times to
times to be adjusted. be adjusted.
3.2.3 Media Coverage of a Live Event 3.2.3 Media Coverage of a Live Event
The media coverage of a live event such as a rock concert or a sports The media coverage of a live event such as a rock concert or a sports
event is a special case of regular TV/radio programming. There may be event is a special case of regular TV/radio programming. There may be
unexpected changes in the scheduling of live event, or the event may unexpected changes in the scheduling of live event, or the event may
be unscheduled to start with (such as breaking news). In addition to be unscheduled to start with (such as breaking news). In addition to
audio/video streams, textual information relevant to the event (e.g., audio/video streams, textual information relevant to the event (e.g.
statistics of the players during a football match) may be sent to statistics of the players during a football match) may be sent to
user terminals. Different transport modes or even different access user terminals. Different transport modes or even different access
technologies could be used for the different media: for example, a technologies could be used for the different media: for example, a
unidirectional datacast transport could be used for the audio/video unidirectional datacast transport could be used for the audio/video
streams and an interactive cellular connection for the textual data. streams and an interactive cellular connection for the textual data.
IMG information should enable terminals to discover the availability IMG metadata should enable terminals to discover the availability of
of different media used to cover a live event. different media used to cover a live event.
3.2.4 Distance Learning 3.2.4 Distance Learning
An IMG could describe compound sessions or services enabling several IMG metadata could describe compound sessions or services enabling
alternative interaction modes between the participants. For example, several alternative interaction modes between the participants. For
the combination of one-to-many media streaming, unicast messaging and example, the combination of one-to-many media streaming, unicast
download of presentation material could be useful for distance messaging and download of presentation material could be useful for
learning. distance learning.
3.2.5 Multiplayer Gaming 3.2.5 Multiplayer Gaming
Multiplayer games are an example of real-time multiparty Multiplayer games are an example of real-time multiparty
communication sessions that could be advertised using IMGs. A gaming communication sessions that could be advertised using IMGs. A gaming
session could be advertised either by a dedicated server, or by the session could be advertised either by a dedicated server, or by the
terminals of individual users. A user could use IMGs to learn of terminals of individual users. A user could use IMGs to learn of
active multiplayer gaming sessions, or advertise the users interest active multiplayer gaming sessions, or advertise the users interest
in establishing such a session. in establishing such a session.
4 IMG Common Framework Model 4 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; the need to deliver the
descriptions. In some cases, the descriptions are multicast enablers descriptions. In some cases, the descriptions are multicast enablers
(such as the session parameters of SDP) and are thus intrinsically (such as the session parameters of SDP) and are thus intrinsically
part of the delivery aspects, and in other cases descriptors are part of the delivery aspects, and in other cases descriptions are
application-specific (both machine and human readable). Thus, the application-specific (both machine and human readable). Thus, the
technologies can be roughly divided into three areas: technologies can be roughly divided into three areas:
o Application-specific Metadata -- data describing the services' o Application-specific Metadata -- data describing the services'
content and media which are both specific to certain content and media which are both specific to certain
applications and generally human readable. applications and generally human readable.
o Delivery Descriptors -- the descriptions (metadata) that are o Delivery Descriptors -- the descriptors (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, fundamental metadata element identification and structure, fundamental
session descriptors. session descriptors.
o Delivery Protocol -- 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
delivery protocol consists of two functions: carrying IMG delivery 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 protocol. These functions are not always exclusive, an IMG transport protocol. These functions are not always
therefore some messages may combine control messages and exclusive, therefore some messages may combine control
metadata carriage functions metadata to reduce the amount of messages and metadata carriage functions metadata to reduce
the messaging. the amount of the messaging.
4.1 IMG Data-Type 4.1 IMG Data Types
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: general: Complete description, delta description and pointer.
4.1.1 Complete Description 4.1.1 Complete Description
A Complete Description provides a complete syntax and semantics to A Complete Description provides a complete syntax and semantics to
describe a set of metadata, which does not need any additional describe a set of metadata, which does not need any additional
information from other IMG entity. information from other IMG entity.
Note, this is not to be confused with a complete IMG, which, although Note, this is not to be confused with "complete IMG metadata", which,
vaguely defined here, represents the complete database of a sender although vaguely defined here, represents the complete database of a
(or related group of senders -- potentially the complete Internet IMG sender (or related group of senders -- potentially the complete
knowledge). A sender will generally deliver only subsets of metadata Internet IMG knowledge). A sender will generally deliver only subsets
from its complete database of metadata in a particular data exchange. of metadata from its complete database of metadata in a particular
data exchange.
4.1.2 Delta Description 4.1.2 Delta Description
A Delta Description provides only part of a Complete Description, A Delta Description provides only part of a Complete Description,
defining the difference from a previous version of the Compete defining the difference from a previous version of the Complete
Description in question. This descriptor may be used to reduce Description in question. This descriptor may be used to reduce
network resource usage (it may be more bandwidth and congestion network resource usage (it may be more bandwidth and congestion
friendly), for instance, data consistency is essential and, small and friendly), for instance, data consistency is essential and, small and
frequent changes occur to the Complete Description. Thus, this frequent changes occur to the Complete Description. Thus, this
descriptor itself cannot represent complete metadata set until it is descriptor itself cannot represent complete metadata set until it is
combined with existing, or future, description knowledge. combined with existing, or future, description knowledge.
4.1.3 Pointer 4.1.3 Pointer
A pointer provided a simple identifier or locator, such as a URL, A pointer provided a simple identifier or locator, such as a URL,
that the receiver is able to reference specific metadata with. This that the receiver is able to reference (or reference and locate)
may be used to separately obtain metadata (complete or delta specific metadata with. This may be used to separately obtain
descriptions) or perform another IMG management function such as data metadata (complete or delta descriptions) or perform another IMG
expire (and erasure). The pointer does not include metadata par se management function such as data expire (and erasure). The pointer
(although it may also appear as a data field in complete or delta may be used to reference IMG metadata elements within the IMG
descriptors). transport session and across IMG transport sessions. The pointer does
not include metadata par se (although it may also appear as a data
field in complete or delta descriptors).
4.2 Operation Set for IMG Delivery 4.2 Operation Set for IMG Delivery
A finite set of operations both meets the IMG requirements [1] and A finite set of operations both meets the IMG requirements [2] 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.
4.2.1 IMG ANNOUNCE 4.2.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 networks)
an IMG receiver may not need to send any message to an IMG sender an IMG receiver may not need to send any message to an IMG sender
prior to IMGs delivery. In this case, a IMG sender can initiate prior to IMG metadata delivery. In this case, an IMG sender can
unsolicited distribution for IMGs and an IMG sender is the only initiate unsolicited distribution for IMG metadata and an IMG sender
entity which can maintain the distribution (this includes scenarios is the only entity which can maintain the distribution (this includes
with multiple and co-operative senders). This operation is useful scenarios with multiple and co-operative senders). This operation is
when there are considerably large number IMG receivers or IMG useful when there are considerably large number IMG receivers or IMG
receiver(s) do not have a guaranteed uplink connection to the IMG receiver(s) do not have a guaranteed uplink connection to the IMG
sender(s). The sender may also include authentication data in the sender(s). The sender may also include authentication data in the
announce operation so that receivers may check the authenticity of announce operation so that receivers may check the authenticity of
the metadata. This operation is able to carry any of the IMG data- the metadata. This operation is able to carry any of the IMG data-
types. types.
Note, there is no restriction to prevent IMG ANNOUNCE from being used Note, 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) is able to subscribe/register receivers to the (possibly out of band) is able to subscribe/register receivers to the
IMG ANNOUNCE operation. IMG ANNOUNCE operation.
skipping to change at page 10, line 44 skipping to change at page 11, line 14
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
send an IMG QUERY message and initiate a receiver-driven IMG delivery send an IMG QUERY message and initiate a receiver-driven IMG delivery
session. The IMG receiver expects a synchronous response to the session. The IMG receiver expects a synchronous response to the
subsequent request from the IMG sender. This operation can be used subsequent request from the IMG sender. This operation can be used
where a bi-directional transport network is available between the IMG where a bi-directional transport network is available between the IMG
sender and receiver. Some IMG receivers may want to obtain IMG sender and receiver. Some IMG receivers may want to obtain IMG
metadata when a resource is available or just to avoid caching metadata when a resource is available or just to avoid caching
unsolicited IMG metadata. The IMG receiver must indicate the extent unsolicited IMG metadata. The IMG receiver must indicate the extent
and data type of metadata wanted in some message in the operation and data type of metadata wanted in some message in the operation
(Extent indicates the number and grouping of metadata descriptions). (Extent indicates the number and grouping of metadata descriptions).
In some cases requesting a sender's whole IMG may be feasible, in In some cases requesting a sender's complete IMG metadata may be
others it may not. feasible, in others it may not.
4.2.3 IMG RESOLVE 4.2.3 IMG RESOLVE
An IMG sender synchronously responds and sends IMG metadata to an IMG An IMG sender synchronously responds and sends IMG metadata to an IMG
QUERY which has been sent by an IMG receiver. This operation can be QUERY which has been sent by an IMG receiver. 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. If the IMG QUERY specifies a subset of the IMG sender and receiver. If the IMG QUERY specifies a subset of
IMG metadata (extent and data type) that the IMG sender has the IMG metadata (extent and data type) that the IMG sender has the
subset, the IMG sender can resolve this, otherwise it should indicate subset, the IMG sender can resolve this, otherwise it should indicate
that it is not able to resolve the query. The IMG sender may that it is not able to resolve the query. The IMG sender may
authenticate the IMG receiver to investigate the IMG QUERY operation authenticate the IMG receiver to investigate the IMG QUERY operation
in order to determine whether the IMG receiver is authorized to be in order to determine whether the IMG receiver is authorized to be
sent that metadata. The sender may also include authentication data sent that metadata. The sender may also include authentication data
in the resolve operation so that receivers may check the authenticity in the resolve operation so that receivers may check the authenticity
of the metadata. This operation may carry any of the IMG data-types. of the metadata. This operation may carry any of the IMG data types.
4.2.4 IMG SUBSCRIBE 4.2.4 IMG SUBSCRIBE
If an IMG receiver wants to be notified when metadata which the IMG If an IMG receiver wants to be notified when metadata which the IMG
receiver holds is stale, the IMG receiver can start the IMG SUBSCRIBE receiver holds is stale, the IMG receiver can start the IMG SUBSCRIBE
operation prior in order to solicit notify messagess. Since the IMG operation prior in order to solicit notify messages. Since the IMG
receiver doesn't know when metadata will be updated and the notify receiver doesn't know when metadata will be updated and the notify
message will arrive, this operations does not synchronize with the message will arrive, this operations does not synchronize with the
notify message. The IMG receiver may wait for the notify message for notify message. The IMG receiver may wait for the notify message for
a long time. The IMG sender may authenticate the IMG receiver to a long time. The IMG sender may authenticate the IMG receiver to
investigate whether an IMG SUBSCRIBE operation is from an authorized investigate whether an IMG SUBSCRIBE operation is from an authorized
receiver. receiver.
4.2.5 IMG NOTIFY 4.2.5 IMG NOTIFY
An IMG receiver needs the response to an earlier IMG SUBSCRIBE and An IMG receiver needs the response to an earlier IMG SUBSCRIBE and
the IMG NOTIFY indicates that an updated IMG is available or part of the IMG NOTIFY indicates that updated IMG metadata is available or
the existing IMG is stale. An IMG NOTIFY may be delivered more than part of the existing IMG metadata is stale. An IMG NOTIFY may be
once during the time an IMG SUBSCRIBE is active. This operation may delivered more than once during the time an IMG SUBSCRIBE is active.
carry any of the IMG data-types. The sender may also include This operation may carry any of the IMG data types. The sender may
authentication data in the notify operation so that receivers may also include authentication data in the notify operation so that
check the authenticity of the messages. receivers may check the authenticity of the messages.
4.3 IMG Entities 4.3 IMG Entities
There are several fundamental IMG entities that indicate the There are several fundamental IMG entities that indicate the
capability to perform certain roles. An Internet host involved in IMG capability to perform certain roles. An Internet host involved in IMG
operations may adopt one or more of these roles: operations may adopt one or more of these roles:
IMG Announcer : send IMG ANNOUNCE IMG Announcer : send IMG ANNOUNCE
IMG Listener : receive IMG ANNOUNCE IMG Listener : receive IMG ANNOUNCE
IMG Querier : send IMG QUERY to receive IMG RESOLVE IMG Querier : send IMG QUERY to receive IMG RESOLVE
skipping to change at page 12, line 26 skipping to change at page 12, line 41
| IMG Listener | IMG Subscriber | IMG Querier | | IMG Listener | IMG Subscriber | IMG Querier |
+------------------+------------------+------------------+ +------------------+------------------+------------------+
| IMG Receiver | | IMG Receiver |
+------------------+------------------+------------------+ +------------------+------------------+------------------+
Figure 1: Relationship with IMG Entities Figure 1: Relationship with IMG Entities
4.4 Overview of Protocol Operations 4.4 Overview of Protocol Operations
The figure 2 gives an overview of the relationship between transport The 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 (note, it is not a protocol
stack). stack).
+--------------------------------------------------+ +--------------------------------------------------+
IMG | | IMG | |
Data-type | 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 |
+--------------+----+----------------+-------------+ +--------------+----+----------------+-------------+
IMG | | | IMG | | |
Transport | P-to-M | P-to-P | Transport | P-to-M | P-to-P |
| | | | | |
+--------------+-----------------------------------+ +--------------+-----------------------------------+
Figure 2: IMG Operations and IMG Data-type
Figure 2: IMG Operations and IMG Data type
5 Deployment Scenarios for IMG Entities 5 Deployment Scenarios for IMG Entities
This section provides some basic deployment scenarios for IMG This section provides some basic deployment scenarios for IMG
entities that illustrate common threads from protocols to use cases. entities that illustrate common threads from protocols to use cases.
For the purposes of clarity, this document presents the simple For the purposes of clarity, this document presents the simple
dataflow from sender to receiver as shown in figure 3 dataflow from sender to receiver as shown in figure 3
+-------------+ +---------------+ +-------------+ +---------------+
| 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
Some IMG may be distributed to a large number of receivers. If, for 5.1 Intermediary Cases
example, a particular IMG is public information and the sender
provides the same information for all receivers. This kind of IMG may
be distributed from one sender to multiple receivers (figure 4)
and/or or may be relayed across a set of IMG transceivers that
receive the IMG, possibly filter or modify its content, and then
forward it. The relayed network architecture is similar to content
distribution network architecture[4] (CDNs). Existing CDNs may carry
IMGs. Satellite and peer-to-peer networks may also carry IMGs.
IMG sender and receiver are logical functions and it is possible for
some or all hosts in a system to perform both roles, as, for
instance, in many-to-many communications or where a transceiver or
proxy is used to combine or aggregate IMG data for some receivers. An
IMG receiver may be allowed to receive IMG metadata from any number
of senders.
The IMG is used to find, obtain, manage and play content. The IMG Some IMG metadata may be distributed to a large number of receivers.
metadata distribution may be modified as they are distributed. For If, for example, some IMG metadata is public information and the
example, a server may use an IMG to retrieve media content via sender provides the same information for all receivers. This kind of
unicast and then make it available at scheduled times via multicast, IMG metadata may be distributed from one sender to multiple receivers
thus requiring a change of the corresponding metadata. IMG (Figure 4) and/or or may be relayed across a set of IMG transceivers
transceivers may add or delete information or aggregate IMGs from that receive the IMG metadata, possibly filter or modify its content,
different senders. For example, a rating service may add its own and then forward it. The relayed network architecture is similar to
content ratings or recommendations to existing meta-data. content distribution network architecture [3] (CDNs). Existing CDNs
may carry IMG metadata. Satellite and peer-to-peer networks may also
carry IMG metadata.
+----------+ +----------+ +----------+ +----------+
| IMG | | IMG | | IMG | | IMG |
| Sender |---- ---->| Receiver | | Sender |---- ---->| Receiver |
+----------+ \ / +----------+ +----------+ \ / +----------+
\ / \ /
. \ +-----------+ / . . \ +-----------+ / .
. -->|IMG |----- . . -->|IMG |----- .
. -->|Transceiver| \ . . -->|Transceiver| \ .
/ +-----------+ \ / +-----------+ \
+----------+ / \ +----------+ +----------+ / \ +----------+
| IMG | / ---->| IMG | | IMG | / ---->| IMG |
| Sender |---- | Receiver | | Sender |---- | Receiver |
+----------+ +----------+ +----------+ +----------+
Figure 4: A Relay Network with an IMG Transceiver Figure 4: A Relay Network with an IMG Transceiver
5.1 One-to-many Unidirectional Multicast IMG senders and receivers are logical functions and it is possible
for some or all hosts in a system to perform both roles, as, for
instance, in many-to-many communications or where a transceiver is
used to combine or aggregate IMG metadata for some receivers. An IMG
receiver may be allowed to receive IMG metadata from any number of
senders.
The IMG metadata is used to find, obtain, manage and play content.
The IMG metadata distribution may be modified as they are
distributed. For example, a server may use IMGs to retrieve media
content via unicast and then make it available at scheduled times via
multicast, thus requiring a change of the corresponding metadata. IMG
transceivers may add or delete information or aggregate IMG metadata
from different senders. For example, a rating service may add its own
content ratings or recommendations to existing meta-data. An
implication of changing (or aggregating) IMG metadata from one or
more senders is that the original authenticity is lost. Thus for
deployments requiring these kind of features, the original metadata
should be reasonably fragmented already (allowing the intermediary to
replace a small fragment without changing the authenticity of the
remainder). It may be beneficial to use smaller fragments for more
volatile parts, and larger one for more stable parts.
5.2 One-to-many Unidirectional Multicast
This case implies many receivers and one or more senders implementing This case implies many receivers and one or more senders implementing
IMG ANNOUNCER and IMG LISTENER operations as shown in figure 5. IMG ANNOUNCER and IMG 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
5.2 One-to-one Bi-directional Unicast 5.3 One-to-one Bi-directional Unicast
Both query/resolve (figure 6) and subscribe/notify (figure 7) message
exchange operations are feasible.
+----------+ +----------+ +----------+ +----------+
| IMG |<------(1)------| IMG | | IMG |<------(1)------| IMG |
| Resolver |-------(2)----->| Querier | | Resolver |-------(2)----->| Querier |
+----------+ +----------+ +----------+ +----------+
Figure 6: Query/Resolve Deployment Example Figure 6: Query/Resolve Deployment Example
Both query/resolve (figure 6) and subscribe/notify (figure 7) message
exchange operations are feasible.
+----------+ +------------+ +----------+ +------------+
| |<-------(1)--------| | | |<-------(1)--------| |
| IMG |--------(2)------->| IMG | | IMG |--------(2)------->| IMG |
| Notifier | (time passes) | Subscriber | | Notifier | (time passes) | Subscriber |
| |--------(3)------->| | | |--------(3)------->| |
+----------+ +------------+ +----------+ +------------+
Figure 7: Subscribe/Notify Deployment Example Figure 7: Subscribe/Notify Deployment Example
5.3 Combined Operations with Common Metadata 5.4 Combined Operations with Common Metadata
As shown in figure 8, a common data model for multiple protocol As shown in figure 8, a common data model for multiple protocol
operations allows a diverse range of senders and receivers to provide operations allows a diverse range of senders and receivers to provide
consistent and interoperable IMGs. consistent and interoperable IMGs.
IMG Metadata IMG Senders IMG Receivers IMG Metadata IMG Senders IMG Receivers
+--------------+ +--------------+
+-----------+ ---->| IMG Listener | +-----------+ ---->| IMG Listener |
| IMG | / +--------------+ | IMG | / +--------------+
/| Announcer |----- /| Announcer |-----
+-------------+ / +-----------+ \ +--------------+ +-------------+ / +-----------+ \ +--------------+
| IMG |-+ / ---->| IMG Listener | | IMG |-+ / ---->| IMG Listener |
| Description | |-+ / | - - - - - - -| | Description | |-+ / | - - - - - - -|
| metadata 1 | | | / +-----------+ /--->| IMG Querier | | metadata 1 | | | / +-----------+ /--->| IMG Querier |
+-------------+ | | -----| IMG |<----/ +--------------+ +-------------+ | | -----| IMG |<----/ +--------------+
+-------------+ | \ | Resolver | +-------------+ | \ | Resolver |
+-------------+ \ +-----------+<----\ +--------------+ +-------------+ \ +-----------+<----\ +--------------+
\ \--->| 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
6 Applicability of Existing Protocols to the Proposed Framework Model 6 Applicability of Existing Protocols to the Proposed Framework Model
6.1 Summary of Limitations of Existing Protocols 6.1 Summary of Limitations of Existing Protocols
SDP[5] has a text-encoded syntax to specify multimedia sessions for SDP [4] has a text-encoded syntax to specify multimedia sessions for
announcements and invitations. Although SDP is extensible, it has announcements and invitations. Although SDP is extensible, it has
limitations such as structured extensibility and capability to carry limitations such as structured extensibility and capability to carry
another multimedia session descriptors. another multimedia session descriptors.
These are mostly overcome by the XML-based SDPng[6] , which is These are mostly overcome by the XML-based SDPng [5] , which is
intended for both two-way negotiation and also unidirectional intended for both two-way negotiation and also unidirectional
delivery. Since SDPng addresses multiparty multimedia conferences, it delivery. Since SDPng addresses multiparty multimedia conferences, it
is necessary to extend the XML schema in order to describe general is necessary to extend the XML schema in order to describe general
multimedia content. multimedia content.
MPEG-7[7] is a collection of XML-based description tools for general MPEG-7 [6] is a collection of XML-based description tools for general
multimedia content including structured multimedia sessions. TV- multimedia content including structured multimedia sessions. TV-
Anytime Forum[8] provides descriptions based on MPEG-7 for TV Anytime Forum [7] provides descriptions based on MPEG-7 for TV
specific program guides. These are likely to be limited to describe specific program guides. These are likely to be limited to describe
pictures, music and movies, thus it may be necessary to extend these pictures, music and movies, thus it may be necessary to extend these
descriptions in order to define a variety of documents, game descriptions in order to define a variety of documents, game
programs, binary files, live event and so on. programs, binary files, live event and so on.
HTTP[9] is a well known information retrieval protocol using bi- HTTP [8] is a well known information retrieval protocol using bi-
directional transport and widely used to deliver web-based content directional transport and widely used to deliver web-based content
descriptions to many hosts. However, it has well recognized descriptions to many hosts. However, it has well recognized
limitations of scalability in the number of HTTP clients since it limitations of scalability in the number of HTTP clients since it
relies on the polling mechanism to keep information consistent relies on the polling mechanism to keep information consistent
between the server and client. between the server and client.
SAP[10] distributes session descriptions via multicast. It does not SAP [9] is an announcement protocol that distributes session
support fine-grained meta data selection and update notifications, as descriptions via multicast. It does not support fine-grained meta
it always sends the whole meta data. Given the lack of a wide-area data selection and update notifications, as it always sends the whole
multicast infrastructure, it is likely only deployable within a local meta data. Given the lack of a wide-area multicast infrastructure, it
area network. is likely only deployable within a local area network.
SIP[11] and SIP-specific event notification[12] can be used to notify SIP [10] and SIP-specific event notification [11] can be used to
subscribers of the update of IMG for bi-directional transport. It is notify subscribers of the update of IMG metadata for bi-directional
necessary for SIP Event to define an event package for each specific transport. It is necessary for SIP Event to define an event package
application such as [13]. for each specific application such as [12].
6.2 Existing Protocol Fit to the IMG Framework Model 6.2 Existing Protocol Fit to the IMG Framework Model
SDP: The SDP format could be used to describe session-level SDP: The SDP format 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 Descriptors. Although there are extension to be included in Complete Descriptors. Although there are extension
points in SDP allowing the format to be extended, there are 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 can not provide with Partial Descriptors and Pointers SDP syntax can not provide with Partial Descriptors and Pointers
without significant unused overhead. Because it is expected that the without significant unused overhead. Because it is expected that the
information conveyed by SDP is just a small subset of IMG information conveyed by SDP is just a small subset of IMG metadata
information, the use of SDP for other than session-level IMG the use of SDP for other than session-level IMG parameters may not be
parameters may not be reasonable. reasonable.
SDPng: Similar to SDP, this format could also be used for SDPng: 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 is much more flexible with regards SDP, the XML-based format of SDPng is much more flexible with regards
to extensions and combining with other description formats. to extensions and combining with other description formats.
MPEG-7: Descriptions based on the MPEG-7 standard could provide MPEG-7: Descriptions based on the MPEG-7 standard 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: this is well in line with the IMG
usage scenarios of IMGs introduced in 3.2. Because MPEG-7 is based on usage scenarios of IMGs introduced in 3.2. Because MPEG-7 is based on
XML, it is well suited for for combining with other XML-based formats XML, it is well suited for combining with other XML-based formats
such as SDPng. such as SDPng.
HTTP: The HTTP protocol can be used as a bi-directional/unicast IMG HTTP: The HTTP protocol can be used as a bi-directional/unicast IMG
delivery protocol. Being a request-reply oriented protocol, HTTP is transport protocol. Being a request-reply oriented protocol, HTTP is
well suited for implementing synchronous operations such as QUERY, 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 fulfil IMG sender periodically. So alone, HTTP is not sufficient to fulfill IMG
needs in a unicast deployment. requirements in a unicast deployment.
SAP: The announcement mechanism provided by SAP provides SAP: The announcement mechanism provided by SAP 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 mechanism However, the limitations of SAP as a generic IMG transport protocol
include: include:
- Lack of reliability (through forward error correction / retransmissions) - Lack of reliability (through forward error correction / retransmissions)
- Lack of payload segmentation - Lack of payload segmentation
- Limited payload size - Limited payload size
- Only one description allowed per SAP message - Only one description allowed per SAP message
- Lack of congestion control - Lack of congestion control
- Lack of Internet standard authentication / encryption mechanisms - Lack of Internet standard authentication / encryption mechanisms
- It is an Experimental RFC with no support for progressing further - It is an Experimental RFC with no support for progressing further
In principle, the current SAP protocol could be extended to get In principle, the current SAP protocol could be extended to get
around its limitations (e.g. the use of a multipart MIME type in the around its limitations (e.g. the use of a multipart MIME type in the
SAP payload has been proposed, enabling multiple descriptions to be SAP payload has been proposed, enabling multiple descriptions to be
carried in a single SAP message). However, the amount of changes carried in a single SAP message). However, the amount of changes
needed in SAP to address all of the above limitations would needed in SAP to address all of the above limitations would
effectively result in a new protocol. Due to these limitations, the effectively result in a new protocol. Due to these limitations, the
use of SAP as an IMG transport mechanism is not recommended. use of SAP as an IMG transport protocol is not recommended.
SIP: The SIP-specific event mechanism described in RFC 3265 [11] SIP: The SIP-specific event mechanism described in [11] provides a
provides a way to implement IMG SUBSCRIBE and IMG NOTIFY operations way to implement IMG SUBSCRIBE and IMG NOTIFY operations via a bi-
via a bidirectional unicast connection. However, there are directional unicast connection. However, there are scalability
scalability problems with this approach, as RFC 3265 currently does problems with this approach, as RFC 3265 currently does not consider
not consider multicast. multicast.
6.3 Outstanding IMG Mechanism Needs 6.3 Outstanding IMG Mechanism Needs
Several outstanding needs result from the IMG requirements, framework Several outstanding needs result from the IMG requirements, framework
model and existing relevant mechanisms as already shown in this model and existing relevant mechanisms as already shown in this
document. Four specific groupings of work are readily apparent which document. Four specific groupings of work are readily apparent which
are: (a) specification of an adequate multicast and unidirectional are: (a) specification of an adequate multicast and unidirectional
capable announcement protocol; (b) specification of the use of capable announcement protocol; (b) specification of the use of
existing unicast protocols to enable unicast subscribe and existing 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; agreement on basic metadata application metadata syntax(es) used; 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.
6.3.1 A Multicast Transport Protocol 6.3.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 data. As discussed, it fails unidirectional/multicast delivery of IMG metadata. As discussed, it
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 so we recommend that this be unidirectional and multicast deployments.
taken on as an official IETF work item.
The Asynchronous Layered Coding (ALC)[14] protocol from the IETF The Asynchronous Layered Coding (ALC) [13] 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 fulfils 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 work-in-progress fully ALC is not fully specified, although RMT has a work-in-progress fully
specified protocol using ALC called FLUTE (File Delivery over specified protocol using ALC called FLUTE (File Delivery over
Unidirectional Transport)[15]. FLUTE seems to be the only fully Unidirectional Transport) [14]. FLUTE seems to be the only fully
specified transport and open specification on which a new IMG specified transport and open specification on which a new IMG
announcement protocol could be designed. Thus we recommend that ALC announcement protocol could be designed. Thus we recommend that ALC
and FLUTE be the starting points for this protocol's design. 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 Thus, we recommend only to attempt this if ALC-based protocols are
later found to be insufficient. later found to be insufficient.
skipping to change at page 20, line 4 skipping to change at page 20, line 29
6.3.2 Usage of Unicast Transport Protocols 6.3.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 and point-to-point essential for the use of IMGs in a unicast and 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, SIP events, HTTP, etc). In particular, both harnessed for this (SIP, SIP events, HTTP, etc). In particular, both
SUBSCRIBE-NOTIFY and QUERY-RESOLVE operation pairs must be enabled. SUBSCRIBE-NOTIFY and QUERY-RESOLVE operation pairs must be enabled.
We anticipate that the FETCH operation will be a trivial usage of We anticipate that the FETCH operation will be a trivial usage of
HTTP, although other transport options may be beneficial to consider HTTP, although other transport options may be beneficial to consider
too. Thus, it is important that this specification is taken on as an too.
official work item in the IETF. It is also important that individual
interest in specialist areas (such as peer-to-peer) is welcome too
should a part of the community benefit from this.
6.3.3 The Metadata Envelope 6.3.3 The Metadata Envelope
To be able to handle multiple metadata syntaxes, a common minimal set To be able to handle multiple metadata syntaxes, a common minimal set
of information is needed to handle discrete blocks of metadata. The of information is needed to handle discrete blocks of metadata. The
IMG framework model data types defined in this document. This minimal IMG framework model data types defined in this document. This minimal
set of information field will be named a `metadata envelope' and set of information field will be named a `metadata envelope' and
must: must:
1. Uniquely identify the block of metadata, regardless of 1. Uniquely identify the block of metadata, regardless of
skipping to change at page 21, line 21 skipping to change at page 21, line 42
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, XML service metadata into its `super-syntax'. For example, XML
enables referencing (pointing to) other resources as well enables referencing (pointing to) other resources as well
as embedding generic text objects. as 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
feasible if a useful syntax were not capable of feasible if a useful syntax were not capable of
extensibility in this way. It also introduces a larger extensibility in this way. It also introduces a larger
`implementation interpretation' variety which would hinder 'implementation interpretation' variety which would hinder
interoperability. Thus this option is not recommended. interoperability. Thus this option is not recommended.
6.3.4 Baseline (Meta)Data Model Specification 6.3.4 Baseline (Meta)Data Model Specification
It is likely that more than one of these options will fulfill the It is likely that more than one of these options will fulfill the
needs of IMGs so the selection, and possibly optimization, is left needs of IMGs so the selection, and possibly optimization, is left
for subsequent specification and feedback from implementation for subsequent specification and feedback from implementation
experience. Such a specification is essential for IMG delivery and so experience. Such a specification is essential for IMG delivery and so
should be an official IETF work item. should be an official IETF work item.
Relevant work-in-progress ensures that support of one, or very few, Relevant work-in-progress ensures that support of one, or very few,
metadata syntaxes is not sufficient. Whereas the transport protocol metadata syntaxes is not sufficient. Whereas the transport protocol
should not restrict the metadata format, the metadata envelope may should not restrict the metadata format, the metadata envelope may
influence the choice metadata. However, metadata in binary format influence the choice metadata. However, metadata in binary format
should not be prevented, in addition to the more abundant text and should not be prevented, in addition to the more abundant text and
XML syntaxes currently available. XML syntaxes currently available.
In most cases the actual content of metadata will be application, or In most cases the actual content of metadata will be application, or
service domain, specific. For instance, digital cinema distribution service domain, specific. For instance, digital cinema distribution
and television channels will have many different requirements. The and television channels will have many different requirements. The
task of specifying the bulk of the worldfs metadata is well beyond task of specifying the bulk of the world's metadata is well beyond
the scope of this document: a framework for the delivery of IMGs. We the scope of this document: a framework for the delivery of IMG
do anticipate that existing and future metadata specifications, metadata. We do anticipate that existing and future metadata
including those of several working groups and standardization bodies, specifications, including those of several working groups and
shall be able to use the services of the IMG framework. However, it standardization bodies, shall be able to use the services of the IMG
is not essential to the current IMG work to specify standards with framework. However, it is not essential to the current IMG work to
application-specific metadata. specify standards with application-specific metadata.
It is essential that the three IMG data-types are enabled, but it may It is essential that the three IMG data types are enabled, but it may
not be necessary to achieve this for every metadata syntax available, not be necessary to achieve this for every metadata syntax available,
nor may it be important to the IETF to cover every possibility for nor may it be important to the IETF to cover every possibility for
this. Generally, Complete Descriptions will be correct for existing this. Generally, Complete Descriptions will be correct for existing
syntaxes (e.g. for XML may be validated according to existing syntaxes (e.g. for XML may be validated according to existing
schema). Pointer data-types may be served by a new syntax (extremely schema). Pointer data types may be served by a new syntax (extremely
minimal), although it is feasible that the proposed metadata envelope minimal), although it is feasible that the proposed metadata envelope
specification will contain enough information to implement the specification will contain enough information to implement the
Pointer data type. Partial Descriptions may need new or modified Pointer data type. Partial Descriptions may need new or modified
syntaxes and semantics (e.g. XML schema) as mandatory fields for a syntaxes and semantics (e.g. XML schema) as mandatory fields for a
Complete Description may be redundant for a Partial Description. Complete Description may be redundant for a Partial Description.
During and following the specification of the metadata envelope, During and following the specification of the metadata envelope,
enabling the delivery of Partial Descriptions should be considered. enabling the delivery of Partial Descriptions should be considered.
To gain implementation experience, it is essential to agree the basic To gain implementation experience, it is essential to agree the basic
of some metadata in interoperability tests and subsequently in of some metadata in interoperability tests and subsequently in
widespread deployments. So we anticipate that a minimal IMG data widespread deployments. So we anticipate that a minimal IMG data
model would be useful to the Internet community, although it should model would be useful to the Internet community.
not be informational rather than mandatory. This may not need to be
an official IETF work item. 6.4 IMG Needs Fitting the IETF's Scope
A Multicast Transport Protocol is essential to IMG delivery for
unidirectional and multicast deployments and no alternative exists
which fulfils the IMG requirements. We recommend that the
specification of this be taken on as an official work item in the
IETF.
Specification of the usage of unicast transport protocols is
essential for IMG delivery and control involving unicast
communications, and will relate to existing IETF standard transport
protocols. Thus, we recommend that the specification of this be taken
on as an official work item in the IETF.
The metadata envelope functionality is essential for the IMG delivery
fulfilling the IMG requirements. It is a required feature for IMG
metadata transport and maintenance. Thus, we recommend that the
metadata envelope specification be taken on as an official work item
in the IETF.
(Meta)data model specification and application specific metadata do
not easily fit into the IETF scope and several other standardization
bodies are well placed to do this work. We recommend that aspect
shall not be an official IETF work item.
Note, we acknowledge the need to exchange and agree on a baseline
metadata model and application specific metadata for the purposes of
interoperability testing between different implementations of IMG
related IETF protocols. However, we feel that the IETF standards
process is not required for this.
7 Security Considerations 7 Security Considerations
The IMG framework is developed from the IMG Requirements document [1] The IMG framework is developed from the IMG Requirements document [2]
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 system would inherit the security considerations of specific IMG specification would inherit the security considerations of
protocols used, although this is out side the scope of this document. specific protocols used, although this is outside the scope of this
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 IMGs may reveal information Individual and Group Privacy: Customized IMG metadata may reveal
about the habits and preferences of a user and may thus deserve information about the habits and preferences of a user and may thus
confidentiality protection, even though the information itself is deserve confidentiality protection, even though the information
public. Capturing and protecting this IMG information requires the itself is public. Capturing and protecting this IMG metadata requires
same actions and measures as for other point-to-point and multicast the same actions and measures as for other point-to-point and
Internet communications. Naturally, the risk depends on the amount of multicast Internet communications. Naturally, the risk depends on the
individual or group personalization the snooped sessions contain. amount of individual or group personalization the snooped sessions
Further consideration is valuable at both transport and metadata contain. Further consideration is valuable at both transport and
levels. metadata levels.
IMG Authenticity: In some cases, the receiver needs to be assured of IMG Authenticity: In some cases, the receiver needs to be assured of
the origin of an IMG or its modification history. This can prevent the origin of IMG metadata or its modification history. This can
denial of service or hijacking attempts which give an IMG receiver prevent denial of service or hijacking attempts which give an IMG
incorrect information in or about the metadata, thus preventing receiver incorrect information in or about the metadata, thus
successful access of the media or directing the IMG receiver to the preventing successful access of the media or directing the IMG
incorrect media ? possibly with tasteless material. Action upon receiver to the incorrect media possibly with tasteless material.
detection of unauthorized data insertion is out of scope of this Action upon detection of unauthorized data insertion is out of scope
document. of this document.
Receiver Authorization: Some or all of any IMG sender's metadata may Receiver Authorization: Some or all of any IMG sender's metadata may
be private or valuable enough to allow access to only certain be private or valuable enough to allow access to only certain
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. Encryption and the required security parameters
exchange are outside the scope of this document. 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 delivery protocols executable code at any stage. However, as some IMG transport
may be capable of delivering arbitrary files, it is RECOMMENDED that protocols may be capable of delivering arbitrary files, it is
the FLUTE delivery service does not have write access to the system RECOMMENDED that the FLUTE delivery service does not have write
or any other critical areas. access to the system or any other critical areas.
Protocol Specific Attacks: It is recommended that developers of any Protocol Specific Attacks: It is recommended that developers of any
IMG protocol take account of the above risks in addition to any IMG protocol take account of the above risks in addition to any
protocol design and deployment environment risks that may be protocol design and deployment environment risks that may be
reasonably identified. Currently this framework document does not reasonably identified. Currently this framework document does not
recommend or mandate the use of any specific protocols, however the recommend or mandate the use of any specific protocols, however the
deployment of IMG using specific protocol instantiations will deployment of IMGs using specific protocol instantiations will
naturally be subject to the security considerations of those naturally be subject to the security considerations of those
protocols. protocols.
Security Improvement Opportunity: The security properties of one Security Improvement Opportunity: The security properties of one
channel and protocol can be improved through the use of another channel and protocol can be improved through the use of another
channel and protocol. For example, a secure unicast channel can be channel and protocol. For example, a secure unicast channel can be
used to deliver the keys and initialization vectors for an encryption used to deliver the keys and initialization vectors for an encryption
algorithm used on a multicast channel. The exploitation of this algorithm used on a multicast channel. The exploitation of this
opportunity is specific to the protocols used and is outside the opportunity is specific to the protocols used and is outside the
scope of this document. scope of this document.
8 Normative References 8 Normative References
[1] S. Bradner, "Key words for use in RFCs to indicate requirement
levels," RFC 2119, Internet Engineering Task Force, Mar. 1997.
[1] Y. Nomura et al., "Protocol requirements for Internet media [2] Y. Nomura et al., "Protocol requirements for Internet media
guides," Internet Draft draft-ietf-mmusic-img-req-00, Internet guides," Internet Draft draft-ietf-mmusic-img-req-00, Internet
Engineering Task Force, Sept. 2003. Work in progress. Engineering Task Force, Sept. 2003. Work in progress.
[2] S. Bradner, "Key words for use in RFCs to indicate requirement [3] M. Day, B. Cain, G. Tomlinson, and P. Rzewski, "A model for
levels," RFC 2119, Internet Engineering Task Force, Mar. 1997.
[3] B. Quinn and K. Almeroth, "IP multicast applications: Challenges
and solutions," RFC 3170, Internet Engineering Task Force, Sept.
2001.
[4] M. Day, B. Cain, G. Tomlinson, and P. Rzewski, "A model for
content internetworking (CDI)," RFC 3466, Internet Engineering Task content internetworking (CDI)," RFC 3466, Internet Engineering Task
Force, Feb. 2003. Force, Feb. 2003.
[5] M. Handley and V. Jacobson, "SDP: session description protocol," [4] M. Handley and V. Jacobson, "SDP: session description protocol,"
RFC 2327, Internet Engineering Task Force, Apr. 1998. RFC 2327, Internet Engineering Task Force, Apr. 1998.
[6] D. Kutscher, J. Ott, and C. Bormann, "Session description and [5] D. Kutscher, J. Ott, and C. Bormann, "Session description and
capability negotiation," internet draft, Internet Engineering Task capability negotiation," Internet Draft draft-ietf-mmusic-sdpng-07,
Force, Mar. 2003. Work in progress. Internet Engineering Task Force, Oct. 2003. Work in progress.
[7] ISO (International Organization for Standardization), "Overview [6] ISO (International Organization for Standardization), "Overview
of the MPEG-7 standard," ISO Standard ISO/IEC JTC1/SC29/WG11 N4509, of the MPEG-7 standard," ISO Standard ISO/IEC JTC1/SC29/WG11 N4509,
International Organization for Standardization, Geneva, Switzerland, International Organization for Standardization, Geneva, Switzerland,
Dec. 2001. Dec. 2001.
[8] TVA. Forum, "Metadata specification S-3," TV-Anytime Forum [7] T.-A. Forum, "Metadata specification S-3," TV-Anytime Forum
Specification SP003v1.2 Part A, TV, TV-Anytime Forum, June 2002. Specification SP003v1.2 Part A, TV, TV-Anytime Forum, June 2002.
[9] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, and T. Berners- [8] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, and T. Berners-
Lee, "Hypertext transfer protocol -- HTTP/1.1," RFC 2068, Internet Lee, "Hypertext transfer protocol -- HTTP/1.1," RFC 2068, Internet
Engineering Task Force, Jan. 1997. Engineering Task Force, Jan. 1997.
[10] M. Handley, C. E. Perkins, and E. Whelan, "Session announcement [9] M. Handley, C. E. Perkins, and E. Whelan, "Session announcement
protocol," RFC 2974, Internet Engineering Task Force, Oct. 2000. protocol," RFC 2974, Internet Engineering Task Force, Oct. 2000.
[11] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J. [10] 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.
[12] A. B. Roach, "Session initiation protocol (sip)-specific event [11] 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.
[14] M. Luby, J. Gemmell, L. Vicisano, L. Rizzo, and J. Crowcroft, [13] 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, Dec. 2002.
9 Infomative References 9 Informative References
[12] J. Rosenberg, "A presence event package for the session
[13] J. Rosenberg, "A presence event package for the session
initiation protocol (SIP)," internet draft, Internet Engineering Task initiation protocol (SIP)," internet draft, Internet Engineering Task
Force, Jan. 2003. Work in progress. Force, Jan. 2003. Work in progress.
[15] T. Paila et al., "FLUTE - file delivery over unidirectional [14] T. Paila, "FLUTE - file delivery over unidirectional transport,"
transport," Internet Draft draft-ietf-rmt-flute-02, Internet Internet Draft draft-ietf-rmt-flute-06, Internet Engineering Task
Engineering Task Force, Sept. 2003. Work in progress. Force, Nov. 2003. Work in progress.
10 Acknowledgements 10 Acknowledgements
The authors would like to thank Joerg Ott, Colin Perkins, Toni Paila The authors would like to thank Joerg Ott, Colin Perkins, Toni Paila
and Petri Koskelainen on for their ideas and input to this document. and Petri Koskelainen on for their ideas and input to this document.
11 Authors' Addresses 11 Authors' Addresses
Yuji Nomura Yuji Nomura
Fujitsu Laboratories Ltd. Fujitsu Laboratories Ltd.
 End of changes. 

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