draft-ietf-mmusic-img-framework-01.txt   draft-ietf-mmusic-img-framework-02.txt 
skipping to change at page 1, line 13 skipping to change at page 1, line 13
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-P. Luoma J-P. Luoma
Nokia Nokia
H. Asaeda H. Asaeda
INRIA INRIA
H. Schulzrinne H. Schulzrinne
Columbia University Columbia University
draft-ietf-mmusic-img-framework-01.txt draft-ietf-mmusic-img-framework-02.txt
December 2, 2003 December 22, 2003
Expires: March 2004 Expires: June 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 1, line 45 skipping to change at page 1, line 45
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
To view the list Internet-Draft Shadow Directories, see To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document defines a framework for the delivery of Internet Media This document defines a framework for the delivery of Internet Media
Guides (IMGs). An IMG is a structured collection of multimedia Guides (IMGs). An IMG is a structured collection of multimedia
session descriptions expressed using SDP, SDPng or some similar session descriptions expressed using SDP, SDPng or some similar
session description format. This document describes several use case session description format. This document describes a generalized
scenarios requirering the IMG framework, a generalized model for IMG model for IMG delivery mechanisms, and the use of existing protocol
delivery mechanisms, and the use of existing protocol to create an to create an IMG delivery infrastructure.
IMG delivery infrastructure.
Table of Contents Table of Contents
1 Introduction ........................................ 3
1.1 Background and Motivation ........................... 3
1.2 Scope of this Document .............................. 4
2 Terminology ......................................... 4
3 Use Cases Requiring IMG Framework ................... 5
3.1 Connectivity-based Use Cases ........................ 5
3.1.1 IP Datacast to a Wireless Receiver .................. 5
3.1.2 Regular Fixed Dial-up Internet Connection ........... 6
3.1.3 Broadband Always-on Fixed Internet Connection ....... 6
3.2 Content-orientated Use Cases ........................ 6
3.2.1 File Distribution ................................... 7
3.2.2 TV and Radio Program Delivery ....................... 7
3.2.3 Media Coverage of a Live Event ...................... 8
3.2.4 Distance Learning ................................... 8
3.2.5 Multiplayer Gaming .................................. 8
4 IMG Common Framework Model .......................... 8
4.1 IMG Data Types ...................................... 9
4.1.1 Complete Description ................................ 9
4.1.2 Delta Description ................................... 9
4.1.3 Pointer ............................................. 10
4.2 Operation Set for IMG Delivery ...................... 10
4.2.1 IMG ANNOUNCE ........................................ 10
4.2.2 IMG QUERY ........................................... 10
4.2.3 IMG RESOLVE ......................................... 11
4.2.4 IMG SUBSCRIBE ....................................... 11
4.2.5 IMG NOTIFY .......................................... 11
4.3 IMG Entities ........................................ 12
4.4 Overview of Protocol Operations ..................... 12
5 Deployment Scenarios for IMG Entities ............... 13
5.1 Intermediary Cases .................................. 13
5.2 One-to-many Unidirectional Multicast ................ 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
Proposed Framework Model ....................................... 17
6.1 Summary of Limitations of Existing Protocols ........ 17
6.2 Existing Protocol Fit to the IMG Framework Model
6.3 Outstanding IMG Mechanism Needs ..................... 19
6.3.1 A Multicast Transport Protocol ...................... 19
6.3.2 Usage of Unicast Transport Protocols ................ 20
6.3.3 The Metadata Envelope ............................... 20
6.3.4 Baseline (Meta)Data Model Specification ............. 21
6.4 IMG Needs Fitting the IETF's Scope .................. 22
7 Security Considerations ............................. 23
8 Normative References ................................ 24
9 Informative References .............................. 25
10 Acknowledgements .................................... 26
11 Authors' Addresses .................................. 26
1 Introduction 1 Introduction ........................................ 2
2 Terminology ......................................... 3
3 IMG Common Framework Model .......................... 5
3.1 IMG Data Types ...................................... 5
3.1.1 Complete IMG Description ............................ 5
3.1.2 Delta IMG Description ............................... 6
3.1.3 IMG Pointer ......................................... 6
3.2 Operation Set for IMG Delivery ...................... 6
3.2.1 IMG ANNOUNCE ........................................ 6
3.2.2 IMG QUERY ........................................... 7
3.2.3 IMG RESOLVE ......................................... 7
3.2.4 IMG SUBSCRIBE ....................................... 7
3.2.5 IMG NOTIFY .......................................... 8
3.2.6 Binding Between IMG Operations and Data Types ....... 8
3.3 IMG Entities ........................................ 8
3.4 Overview of Protocol Operations ..................... 9
4 Deployment Scenarios for IMG Entities ............... 9
4.1 Intermediary Cases .................................. 10
4.2 One-to-many Unidirectional Multicast ................ 11
4.3 One-to-one Bi-directional Unicast ................... 12
4.4 Combined Operations with Common Metadata ............ 12
5 Applicability of Existing Protocols to the
Proposed Framework Model ....................................... 13
5.1 Summary of Limitations of Existing Protocols ........ 13
5.2 Existing Protocol Fit to the IMG Framework Model
5.3 Outstanding IMG Mechanism Needs ..................... 16
5.3.1 A Multicast Transport Protocol ...................... 16
5.3.2 Usage of Unicast Transport Protocols ................ 17
5.3.3 IMG Transfer Envelope ............................... 17
5.3.4 Baseline (Meta)Data Model Specification ............. 18
5.4 IMG Needs Fitting the IETF's Scope .................. 18
6 Security Considerations ............................. 19
7 Normative References ................................ 21
8 Informative References .............................. 22
9 Acknowledgements .................................... 22
10 Authors' Addresses .................................. 22
1.1 Background and Motivation 1 Introduction
Internet Media Guide (IMG) provide structured collections of Internet Media Guides (IMGs) provide and deliver structured
multimedia descriptions expressed using SDP, SDPng or some similar collections of multimedia descriptions expressed using SDP, SDPng or
description format. It is used to describe sets of multimedia some similar description format. They are used to describe sets of
sessions (e.g. television program schedules, content delivery multimedia sessions (e.g. television program schedules, content
schedules etc.) and refer to other networked resources including web delivery schedules etc.) and refer to other networked resources
pages. IMGs provide an envelope for metadata formats and session including web pages. IMGs provide an envelope for metadata formats
descriptions defined elsewhere with the aim of facilitating and session descriptions defined elsewhere with the aim of
structuring, versioning, referencing, distributing, and maintaining facilitating structuring, versioning, referencing, distributing, and
(caching, updating) such information. maintaining (caching, updating) such information.
Firstly, this document explains several use case scenarios requiring IMG metadata must be delivered to a potentially large audience, who
the IMG framework. IMGs are inherently required to be independent of use it to join a subset of the sessions described, and who may need
any particular access network, and link in general. Therefore, they to be notified of changes to the IMG metadata. Hence, a framework for
are suitable in many Internet access scenarios including fixed and distributing IMG metadata in various different ways is needed to
mobile devices, wired and satellite and terrestrial radio, always-on accommodate the needs of different audiences: For traditional
Internet and intermittent connectivity, and so on. Furthermore, IMGs broadcast-style scenarios, multicast-based (push) distribution of IMG
provides essential functions that facilitate better distribution of metadata needs to be supported. Where no multicast is available,
content. Section 3 describes how IMGs and IMG delivery mechanisms unicast-based push is required, too.
contribute for the scenarios.
Then, this document defines a generalized model for IMG delivery This document defines a common framework model for IMG delivery
mechanisms and their deployment in network entities regarding the use mechanisms and their deployment in network entities. There are three
case scenarios. IMG metadata must be delivered to a potentially large fundamental components in IMG framework model: data types, operation
audience, who use it to join a subset of the sessions described, and sets and entities. These components specify a set of framework
who may need to be notified of changes to the IMG metadata. Hence, a guideline for IMG delivery to efficiently deliver and describe IMG
framework for distributing IMG metadata in various different ways is metadata. The data types give common base descriptions on top of an
needed to accommodate the needs of different audiences: For application-specific IMG metadata. IMG operations cover traditional
traditional broadcast-style scenarios, multicast-based (push) broadcast-style scenarios, multicast-based distributions, unicast-
distribution of IMG metadata needs to be supported. Where no based push and interactive retrievals similar to web pages. Since we
multicast is available, unicast-based push is required, too. envision that any Internet host can be a sender and receiver of IMG
metadata, an host involved in IMG operations perform one or more of
roles defined as the entities in IMG framework model. These are then
shown in a number of simplified deployment scenarios. The
requirements for IMG delivery mechanisms and descriptions can be
found in [1].
Finally, this document outlines the use of existing protocols to Then, this document outlines the use of existing protocols to create
create an IMG delivery infrastructure. It aims to organize existing an IMG delivery infrastructure. It aims to organize existing
protocols 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 number multicast-enabling IMG requirements is scaling well to a large number
of hosts and IMG senders in a network. Another issue is the need for of hosts and IMG senders in a network. Another issue is the need for
flexibility and diversity in delivery methods, whereas existing flexibility and diversity in delivery methods, whereas 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
This document defines a common framework model for the delivery of
Internet Media Guide (IMG) metadata. The framework describes existing
mechanisms and the level to which they support and enable the
framework. The requirements for IMG delivery mechanisms and
descriptions can be found in [1].
A brief run through the usage and use cases of media guide is
provided to illustrate the relevance of IMGs before the framework
model is presented. The framework model defines the data types,
operations and entities which are needed. These are then shown in a
number of simplified deployment scenarios.
Existing protocols are organized and referenced against the framework
model to show the degree to which they fulfill IMG framework and
requirements. This also makes it straightforward to identify gaps so
that new protocols needs are made apparent.
2 Terminology 2 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1]. document are to be interpreted as described in RFC 2119 [2].
Internet Media Guide (IMG): IMG is a generic term to describe Internet Media Guide (IMG): IMG is a generic term to describe
the formation, delivery and use of IMG metadata. The the formation, delivery and use of IMG metadata. The
definition of the IMG is intentionally left imprecise. definition of the IMG is intentionally left imprecise.
IMG Metadata: This is a set of metadata describing the features IMG Element: The smallest atomic element of metadata that can be
of multimedia content used to enable selection of and transmitted separately by IMG operations and referenced
access to media sessions containing content. For example, individually from other IMG elements.
metadata may consist of the URI, title, airtime, bandwidth
needed, file size, text summary, genre, and access IMG Metadata: A set of metadata consisting of one or more IMG
restrictions. elements. IMG metadata describes the features of multimedia
content used to enable selection of and access to media
sessions containing content. For example, metadata may
consist of the URI, title, airtime, bandwidth needed, file
size, text summary, genre and access restrictions.
IMG Description: A collection of IMG metadata which has a
relationship to other IMG metadata. There are three data
types to describe the relationship: Complete IMG
Descriptions, Delta IMG Description and IMG pointer.
IMG Delivery: The process of exchanging IMG metadata both in 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 IMG
one or more IMG receivers. metadata to 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 sender. IMG metadata 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 received IMG metadata or merge IMG
from a different IMG sender. metadata received from a several different IMG senders.
IMG Operation: An atomic process for the IMG transport protocol IMG Operation: An atomic operation of an IMG transport protocol,
to deliver IMG metadata or control IMG sender(s) or IMG used between IMG sender(s) and IMG receiver(s) for the
receiver(s). delivery of IMG metadata and for the control of IMG
sender(s)/receiver(s).
IMG Transport Protocol: A protocol that transports IMG metadata IMG Transport Protocol: A protocol that transports IMG metadata
from IMG sender to IMG receiver(s) from an IMG sender to IMG receiver(s).
3 Use Cases Requiring IMG Framework
3.1 Connectivity-based Use Cases
3.1.1 IP Datacast to a Wireless Receiver
IP Datacast is the delivery of IP-based services over broadcast
radio. Internet content delivery is therefore unidirectional in this
case. However, there can be significant benefits from being able to
provide rich media one-to-many services to such receivers.
There are two main classes of receiver in this use case: fixed
mains-powered; and mobile battery-powered. Both of these are affected
by radio phenomena and so robust, or error-resilient, delivery is
important. Carouselled metadata transfer provides a base level of
robustness for an IP datacast based announcement system, although the
design of carouselled transfer should enable battery-powered
receivers to go through periods of sleep to extend their operational
time between charges. Insertion of Forward Error Correction (FEC)
data into metadata announcements improves error resilience, and
reordering (interleaving) data blocks further increases tolerance to
burst errors.
To enable receivers to more accurately specify the metadata they are
interested in, the unidirectional delivery is distributed between
several logical channels. This is so that a receiver need only access
the channels of interest and thus can reduce the amount of time and
processing of IP data (and storage). Also, hierarchical channels
enable receivers to subscribe to a root, possibly well known,
multicast channel/group and progressively access only those
additional channels based on metadata in parent channels.
In some cases the receiver may be multi-access, such that it is
capable of bi-directional communications. This enables a multitude of
options, but most importantly it enables NACK based reliability and
the individual retrieval of missed or not-multicasted sets of
metadata.
Thus, essential IMG features in this case include: robust
unidirectional delivery (with optional levels of reliability
including "plug-in FEC") which implies easily identifiable
segmentation of delivery data to enable FEC, carousel, interleaving
and other schemes possible; effective identification of metadata sets
(probably uniquely) to enable more efficient use of multicast and
unicast retrieval over multiple access systems regardless of the
parts of metadata and application specific extensions in use;
prioritization of metadata, which can (for instance) be achieved by
spreading it between channels and allocating/distributing bandwidth
accordingly.
Furthermore, some cases require IMG metadata authentication and some
group security/encryption and supporting security message exchanges
(out of band from the IMG multicast sessions).
3.1.2 Regular Fixed Dial-up Internet Connection
Dial-up connections tend to be reasonably slow (<56kbps in any case)
and thus large data transfers are less feasible, especially during an
active application session (such as a file transfer described by IMG
metadata). They can also be intermittent, especially if a user is
paying for the connected time, or connected through a less reliable
exchange. Thus this favors locally stored IMG metadata over web-based
browsing, especially where parts of the metadata change infrequently.
There may be no service provider preference over unicast and
multicast transport for small and medium numbers of users as the
last-mile dial-up connection limits per-user congestion, and a user
may prefer the more reliable option (unicast unless reliable
multicast is provided).
3.1.3 Broadband Always-on Fixed Internet Connection
Typically bandwidth is less of an issue to a broadband user and
unicast transport, such as using IMG QUERY, may be typical for a PC
user. If a system were only used in this context, with content
providers, ISPs and users having no other requirements, then web-
based browsing may be equally suitable. However, broadband users
sharing a local area network, especially wireless, may benefit more
from local storage features than on-line browsing, especially if they
have intermittent Internet access.
Broadband enables rich media services, which are increasingly
bandwidth hungry. Thus backbone operators may prefer multicast
communications to reduce overall congestion, if they have the
equipment and configuration to support this. Thus, broadband users
may be forced to retrieve IMG metadata over multicast if the
respective operators require this to keep system-wide bandwidth usage
feasible.
3.2 Content-orientated Use Cases
IMGs will be able to support a very wide range of use cases for
content/media delivery. The following few sections just touch the
surface of what is possible and are intended to provide an
understanding of the scope and type of IMG usage. Many more examples
may be relevant, for instance those detailed in[3]. There are
several unique features of IMGs that set them apart from related
application areas such as SLP based service location discovery, LDAP
based indexing services and search engines such as Google. Features
unique to IMGs include:
o IMG metadata is generally time-related
o There are timeliness requirements in the delivery of IMG
metadata
o IMG metadata may be updated as time elapses or when an event
arises
3.2.1 File Distribution
IMGs support the communication of file delivery session properties,
enabling the scheduled delivery or synchronization of files between a
number of hosts. For example, the metadata that IMGs provide could be
subsequently used by a different application (outside the scope of
IMGs) to download a file with a software update. An IMG metadata can
provide a description to each file in a file delivery session,
assisting users or receiving software in selecting individual files
for reception.
For example, when a content provider wants to distribute a large
amount of data in file format to thousands clients, the content
provider can use IMG metadata to schedule the delivery effectively.
Since IMG metadata can describe time-related data for each receiver,
the content provider can schedule delivery time for each receiver.
This can save network bandwidth and capacity of delivery senders. In
addition, IMG metadata can be used to synchronize a set of files
between a sender host and receiver host, when those files change as
time elapses.
3.2.2 TV and Radio Program Delivery
A sender of audio/video streaming content can use the IMG metadata to
describe the scheduling and other properties of audio/video sessions
and events within those sessions, such as individual TV and radio
programs and segments within those programs. IMG metadata describing
audio/video streaming content could be represented in a format
similar to that of a TV guide in newspapers, or an Electronic Program
Guide available on digital TV receivers.
Similarly to file reception, TV and radio programs can be selected
for reception either manually by the end-user or automatically based
on the content descriptions and the preferences of the user. The
received TV and radio content can be either presented in real time or
recorded for consuming later. There may be changes in the scheduling
of a TV or a radio program, possibly affecting the transmission times
of subsequent programs. IMG metadata can be used to notify receivers
of such changes, enabling users to be prompted or recording times to
be adjusted.
3.2.3 Media Coverage of a Live Event
The media coverage of a live event such as a rock concert or a sports
event is a special case of regular TV/radio programming. There may be
unexpected changes in the scheduling of live event, or the event may
be unscheduled to start with (such as breaking news). In addition to
audio/video streams, textual information relevant to the event (e.g.
statistics of the players during a football match) may be sent to
user terminals. Different transport modes or even different access
technologies could be used for the different media: for example, a
unidirectional datacast transport could be used for the audio/video
streams and an interactive cellular connection for the textual data.
IMG metadata should enable terminals to discover the availability of
different media used to cover a live event.
3.2.4 Distance Learning
IMG metadata could describe compound sessions or services enabling
several alternative interaction modes between the participants. For
example, the combination of one-to-many media streaming, unicast
messaging and download of presentation material could be useful for
distance learning.
3.2.5 Multiplayer Gaming IMG Transport Session: An association between an IMG sender and
one or more IMG receivers within the scope of an IMG
transport protocol. An IMG transport session involves a
series of IMG transport protocol interactions that provide
delivery of IMG metadata from the IMG sender to the IMG
receiver(s).
Multiplayer games are an example of real-time multiparty IMG Transfer: A transfer of IMG metadata consisting of Complete
communication sessions that could be advertised using IMGs. A gaming IMG Descriptions, Delta IMG Descriptions and/or IMG
session could be advertised either by a dedicated server, or by the Pointers.
terminals of individual users. A user could use IMGs to learn of
active multiplayer gaming sessions, or advertise the users interest
in establishing such a session.
4 IMG Common Framework Model 3 IMG Common Framework Model
Two common elements are found in all of existing IMG candidate cases: Two common elements are found in all of existing IMG candidate cases:
the need to describe the services; the need to deliver the the need to describe the services; 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 descriptions 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 descriptors (metadata) that are o Delivery Descriptions -- the descriptions (metadata) that are
essential to enable (e.g. multicast) delivery. These include essential to enable (e.g. multicast) delivery. These include
framing (headers) for application-specific metadata, the framing (headers) for application-specific metadata, the
metadata element identification and structure, fundamental metadata element identification and structure, fundamental
session descriptors. session descriptions.
o Delivery Protocols -- the methods and protocols to exchange o Delivery Protocols -- the methods and protocols to exchange
descriptions between the senders and the receivers. An IMG descriptions between the senders and the receivers. An IMG
delivery protocol consists of two functions: carrying IMG transport protocol consists of two functions: carrying IMG
metadata from an IMG sender to an IMG receiver and controlling metadata from an IMG sender to an IMG receiver and controlling
an IMG transport protocol. These functions are not always an IMG transport protocol. These functions are not always
exclusive, therefore some messages may combine control exclusive, therefore some messages may combine control
messages and metadata carriage functions metadata to reduce messages and metadata carriage functions metadata to reduce
the amount of the messaging. the amount of the messaging.
4.1 IMG Data Types 3.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: Complete description, delta description and pointer. general: Complete IMG Descriptions, Delta IMG Description and IMG
Pointer.
4.1.1 Complete Description 3.1.1 Complete IMG Description
A Complete Description provides a complete syntax and semantics to A Complete IMG Description provides a complete syntax and semantics
describe a set of metadata, which does not need any additional to describe a set of metadata, which does not need any additional
information from other IMG entity. information from any other IMG element.
Note, this is not to be confused with "complete IMG metadata", which, Note, this is not to be confused with "complete IMG metadata", which,
although vaguely defined here, represents the complete database of a although vaguely defined here, represents the complete IMG metadata
sender (or related group of senders -- potentially the complete database of an IMG sender (or related group of IMG senders --
Internet IMG knowledge). A sender will generally deliver only subsets potentially the complete Internet IMG knowledge). An IMG sender will
of metadata from its complete database of metadata in a particular generally deliver only subsets of metadata from its complete database
data exchange. in a particular IMG transport session.
4.1.2 Delta Description 3.1.2 Delta IMG Description
A Delta Description provides only part of a Complete Description, A Delta IMG Description provides only part of a Complete IMG
defining the difference from a previous version of the Complete Description, defining the difference from a previous version of the
Description in question. This descriptor may be used to reduce Complete IMG Description in question. Delta transfers may be used to
network resource usage (it may be more bandwidth and congestion reduce network resource usage (it may be more bandwidth and
friendly), for instance, data consistency is essential and, small and congestion friendly), for instance when data consistency is essential
frequent changes occur to the Complete Description. Thus, this and small and frequent changes occur to IMG elements. Thus, this
descriptor itself cannot represent complete metadata set until it is description 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 3.1.3 IMG Pointer
A pointer provided a simple identifier or locator, such as a URL, An IMG Pointer provides a simple identifier or locator, such as a
that the receiver is able to reference (or reference and locate) URI, that the IMG receiver is able to reference (or reference and
specific metadata with. This may be used to separately obtain locate) specific metadata with. This may be used to separately obtain
metadata (complete or delta descriptions) or perform another IMG metadata (Complete or Delta IMG Descriptions) or perform another IMG
management function such as data expire (and erasure). The pointer management function such as data expire (and erasure). The IMG
may be used to reference IMG metadata elements within the IMG Pointer may be used to reference IMG metadata elements within the IMG
transport session and across IMG transport sessions. The pointer does transport session and across IMG transport sessions. This pointer
not include metadata par se (although it may also appear as a data type does not include metadata per se (although it may also appear as
field in complete or delta descriptors). a data field in Complete or Delta IMG descriptors).
4.2 Operation Set for IMG Delivery 3.2 Operation Set for IMG Delivery
A finite set of operations both meets the IMG requirements [2] and A finite set of operations both meets the IMG requirements [1] 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 3.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 IMG metadata delivery. In this case, an IMG sender can prior to IMG metadata delivery. In this case, an IMG sender can
initiate unsolicited distribution for IMG metadata and an IMG sender initiate unsolicited distribution for IMG metadata and an IMG sender
is the only entity which can maintain the distribution (this includes is the only entity which can maintain the distribution (this includes
scenarios with multiple and co-operative senders). This operation is scenarios with multiple and co-operative IMG senders). This operation
useful when there are considerably large number IMG receivers or IMG is useful when there are considerably large number IMG receivers or
receiver(s) do not have a guaranteed uplink connection to the IMG 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 IMG sender may also include authentication data in the
announce operation so that receivers may check the authenticity of announce operation so that IMG receivers may check the authenticity
the metadata. This operation is able to carry any of the IMG data- of 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 IMG receivers to
IMG ANNOUNCE operation. the IMG ANNOUNCE operation.
3.2.2 IMG QUERY
4.2.2 IMG QUERY
If an IMG receiver needs to obtain IMG metadata, an IMG receiver can If an IMG receiver needs to obtain IMG metadata, an IMG receiver can
send an IMG QUERY message and initiate a receiver-driven IMG delivery send an IMG QUERY message and initiate a receiver-driven IMG
session. The IMG receiver expects a synchronous response to the transport session. The IMG receiver expects a synchronous response to
subsequent request from the IMG sender. This operation can be used the subsequent request from the IMG sender. This operation can be
where a bi-directional transport network is available between the IMG used where a bi-directional transport network is available between
sender and receiver. Some IMG receivers may want to obtain IMG the IMG sender and receiver. Some IMG receivers may want to obtain
metadata when a resource is available or just to avoid caching IMG 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 complete IMG metadata may be In some cases requesting an IMG sender's complete IMG metadata may be
feasible, in others it may not. feasible, in others it may not.
4.2.3 IMG RESOLVE 3.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 is available to the IMG
subset, the IMG sender can resolve this, otherwise it should indicate sender, the IMG sender can resolve query; otherwise, it should
that it is not able to resolve the query. The IMG sender may indicate 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 IMG receivers may check the
of the metadata. This operation may carry any of the IMG data types. authenticity of the metadata. This operation may carry any of the IMG
data types.
4.2.4 IMG SUBSCRIBE 3.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 the IMG metadata it
receiver holds is stale, the IMG receiver can start the IMG SUBSCRIBE holds is stale, the IMG receiver can use the IMG SUBSCRIBE operation
operation prior in order to solicit notify messages. Since the IMG in advance in order to solicit notify messages from an IMG sender.
receiver doesn't know when metadata will be updated and the notify Since the IMG receiver doesn't know when metadata will be updated and
message will arrive, this operations does not synchronize with the the notify message will arrive, this operation does not synchronize
notify message. The IMG receiver may wait for the notify message for with the notify messages. The IMG receiver may wait for notify
a long time. The IMG sender may authenticate the IMG receiver to messages for a long time. The IMG sender may authenticate the IMG
investigate whether an IMG SUBSCRIBE operation is from an authorized receiver to investigate whether an IMG SUBSCRIBE operation is from an
receiver. authorized IMG receiver.
4.2.5 IMG NOTIFY 3.2.5 IMG NOTIFY
An IMG receiver needs the response to an earlier IMG SUBSCRIBE and An IMG NOTIFY is used in response to an earlier IMG SUBSCRIBE. An
the IMG NOTIFY indicates that updated IMG metadata is available or IMG NOTIFY generates a notify message indicating that updated IMG
part of the existing IMG metadata is stale. An IMG NOTIFY may be metadata is available or part of the existing IMG metadata is stale.
delivered more than once during the time an IMG SUBSCRIBE is active. An IMG NOTIFY may be delivered more than once during the time an IMG
This operation may carry any of the IMG data types. The sender may SUBSCRIBE is active. This operation may carry any of the IMG data
also include authentication data in the notify operation so that types. The IMG sender may also include authentication data in the IMG
receivers may check the authenticity of the messages. NOTIFY operation so that IMG receivers may check the authenticity of
the messages.
4.3 IMG Entities 3.2.6 Binding Between IMG Operations and Data Types
There is a need to provide a binding between the various IMG
operations and IMG data types to allow management of each discrete
set of IMG metadata transferred using an IMG operation. This binding
must be independent of any particular metadata syntax used to
represent a set of IMG metadata, as well as be compatible with any
IMG transport protocol. The binding must uniquely identify the set of
IMG metadata delivered within an IMG transfer, regardless of the
metadata syntax used. The uniqueness may only be needed within the
domains the metadata is used but this must enable globally unique
identification to support Internet usage. Scope/domain specific
identifications should not 'leak' outside of the scope, and always
using globally unique identification (e.g. based on URIs) should
avoid this error.
The binding must provide versioning to the transferred IMG metadata
so that changes can be easily handled and stale data identified, and
give temporal validity of the transferred IMG metadata. It must
expire the IMG metadata by indicating an expiry time, and may
optionally provide a time (presumably in the future) from when the
IMG metadata becomes valid. Temporal validity of IMG metadata may be
changeable for an IMG transfer, and even for specific versions of the
IMG transfer. Furthermore, the binding must be independent of the
metadata syntax(es) used for the IMG metadata, in the sense that no
useful syntax should be excluded.
3.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
IMG Resolver : receive IMG QUERY then send IMG RESOLVE IMG Resolver : receive IMG QUERY then send IMG RESOLVE
IMG Subscriber: send IMG SUBSCRIBE then receive IMG NOTIFY IMG Subscriber: send IMG SUBSCRIBE then receive IMG NOTIFY
IMG Notifier : receive IMG SUBSCRIBE then send IMG NOTIFY IMG Notifier : receive IMG SUBSCRIBE then send IMG NOTIFY
Finally, the figure 1 shows a relationship between IMG entities and Finally, figure 1 shows a relationship between IMG entities and the
the IMG sender and receiver. IMG sender and receiver.
+--------------------------------------------------------+ +--------------------------------------------------------+
| IMG Sender | | IMG Sender |
+------------------+------------------+------------------+ +------------------+------------------+------------------+
| IMG Announcer | IMG Notifier | IMG Resolver | | IMG Announcer | IMG Notifier | IMG Resolver |
+------------------+------------------+------------------+ +------------------+------------------+------------------+
| ^ ^ | ^ ^
message | | | message | | |
direction v v v direction v v v
+------------------+------------------+------------------+ +------------------+------------------+------------------+
| 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 3.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).
4 Deployment Scenarios for IMG Entities
This section provides some basic deployment scenarios for IMG
entities that illustrate common threads from protocols to use cases.
For the purposes of clarity, this document presents the simple
dataflow from an IMG sender to an IMG receiver, as shown in figure 3.
+--------------------------------------------------+ +--------------------------------------------------+
IMG | | IMG | |
Data types | Complete Desc., Delta Desc., Pointer | Data types | Complete Desc., Delta Desc., Pointer |
| | | |
+-------------------+----------------+-------------+ +-------------------+----------------+-------------+
IMG | IMG ANNOUNCE | IMG SUBSCRIBE | IMG QUERY | IMG | IMG ANNOUNCE | IMG SUBSCRIBE | IMG QUERY |
Operations | | IMG NOTIFY | IMG RESOLVE | Operations | | IMG NOTIFY | IMG RESOLVE |
+--------------+----+----------------+-------------+ +--------------+----+----------------+-------------+
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
This section provides some basic deployment scenarios for IMG
entities that illustrate common threads from protocols to use cases.
For the purposes of clarity, this document presents the simple
dataflow from sender to receiver as shown in figure 3
+-------------+ +---------------+ +-------------+ +---------------+
| IMG Sender | | IMG Receiver | | IMG Sender | | IMG Receiver |
| |--------------->| | | |--------------->| |
+-------------+ +---------------+ +-------------+ +---------------+
Figure 3: A Simple IMG Sender to IMG Receiver Relationship Figure 3: A Simple IMG Sender to IMG Receiver Relationship
5.1 Intermediary Cases 4.1 Intermediary Cases
Some IMG metadata may be distributed to a large number of receivers. Some IMG metadata may be distributed to a large number of IMG
If, for example, some IMG metadata is public information and the receivers. If, for example, some IMG metadata is public information
sender provides the same information for all receivers. This kind of and the IMG sender provides the same information for all IMG
IMG metadata may be distributed from one sender to multiple receivers receivers. This kind of IMG metadata may be distributed from one IMG
(Figure 4) and/or or may be relayed across a set of IMG transceivers sender to multiple IMG receivers (Figure 4) and/or or may be relayed
that receive the IMG metadata, possibly filter or modify its content, across a set of IMG transceivers that receive the IMG metadata,
and then forward it. The relayed network architecture is similar to possibly filter or modify its content, and then forward it. The
content distribution network architecture [3] (CDNs). Existing CDNs relayed network architecture is similar to content distribution
may carry IMG metadata. Satellite and peer-to-peer networks may also network architecture [3] (CDNs). Existing CDNs may carry IMG
carry IMG metadata. 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
IMG senders and receivers are logical functions and it is possible IMG senders and receivers are logical functions and it is possible
for some or all hosts in a system to perform both roles, as, for for some or all hosts in a system to perform both roles, as, for
instance, in many-to-many communications or where a transceiver is instance, in many-to-many communications or where a transceiver is
used to combine or aggregate IMG metadata for some receivers. An IMG used to combine or aggregate IMG metadata for some IMG receivers. An
receiver may be allowed to receive IMG metadata from any number of IMG receiver may be allowed to receive IMG metadata from any number
senders. of IMG senders.
The IMG metadata is used to find, obtain, manage and play content. IMG metadata is used to find, obtain, manage and play content. IMG
The IMG metadata distribution may be modified as they are metadata distributions may be modified as they are distributed. For
distributed. For example, a server may use IMGs to retrieve media example, a server may use IMGs to retrieve media content via unicast
content via unicast and then make it available at scheduled times via and then make it available at scheduled times via multicast, thus
multicast, thus requiring a change of the corresponding metadata. IMG requiring a change of the corresponding metadata. IMG transceivers
transceivers may add or delete information or aggregate IMG metadata may add or delete information or aggregate IMG metadata from
from different senders. For example, a rating service may add its own different IMG senders. For example, a rating service may add its own
content ratings or recommendations to existing meta-data. An content ratings or recommendations to existing meta-data. An
implication of changing (or aggregating) IMG metadata from one or implication of changing (or aggregating) IMG metadata from one or
more senders is that the original authenticity is lost. Thus for more IMG senders is that the original authenticity is lost. Thus for
deployments requiring these kind of features, the original metadata deployments requiring these kind of features, the original metadata
should be reasonably fragmented already (allowing the intermediary to should be reasonably fragmented already (allowing the intermediary to
replace a small fragment without changing the authenticity of the replace a small fragment without changing the authenticity of the
remainder). It may be beneficial to use smaller fragments for more remainder). It may be beneficial to use smaller fragments for more
volatile parts, and larger one for more stable parts. volatile parts, and larger one for more stable parts.
5.2 One-to-many Unidirectional Multicast 4.2 One-to-many Unidirectional Multicast
This case implies many receivers and one or more senders implementing This case implies many IMG receivers and one or more IMG senders
IMG ANNOUNCER and IMG LISTENER operations as shown in figure 5. implementing 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.3 One-to-one Bi-directional Unicast 4.3 One-to-one Bi-directional Unicast
+----------+ +----------+ +----------+ +----------+
| 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 Both query/resolve (figure 6) and subscribe/notify (figure 7) message
exchange operations are feasible. exchange operations are feasible.
4.4 Combined Operations with Common Metadata
As shown in figure 8, a common data model for multiple protocol
operations allows a diverse range of IMG senders and receivers to
provide consistent and interoperable sets of IMG metadata.
+----------+ +------------+ +----------+ +------------+
| |<-------(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.4 Combined Operations with Common Metadata
As shown in figure 8, a common data model for multiple protocol
operations allows a diverse range of senders and receivers to provide
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 |
skipping to change at page 17, line 5 skipping to change at page 13, line 35
+-------------+ | \ | 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 5 Applicability of Existing Protocols to the Proposed Framework Model
6.1 Summary of Limitations of Existing Protocols 5.1 Summary of Limitations of Existing Protocols
SDP [4] 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
another multimedia session descriptors. reference properties of a multimedia session from the description of
another session.
These are mostly overcome by the XML-based SDPng [5] , 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 [6] 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 [7] 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 events and so on.
HTTP [8] 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 [9] is an announcement protocol that distributes session SAP [9] is an announcement protocol that distributes session
descriptions via multicast. It does not support fine-grained meta descriptions via multicast. It does not support fine-grained metadata
data selection and update notifications, as it always sends the whole selection and update notifications, as it always sends the whole
meta data. Given the lack of a wide-area multicast infrastructure, it meta data. Given the lack of a wide-area multicast infrastructure, it
is likely only deployable within a local area network. is likely only deployable within a local area network.
SIP [10] and SIP-specific event notification [11] can be used to SIP [10] and SIP-specific event notification [11] can be used to
notify subscribers of the update of IMG metadata for bi-directional notify subscribers of the update of IMG metadata for bi-directional
transport. It is necessary for SIP Event to define an event package transport. It is necessary for SIP Event to define an event package
for each specific application such as [12]. for each specific application such as [12].
6.2 Existing Protocol Fit to the IMG Framework Model 5.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 IMG Descriptions. Although there are
points in SDP allowing the format to be extended, there are extension points in SDP allowing the format to be extended, there are
limitations in the flexibility of this extension mechanism. However, limitations in the flexibility of this extension mechanism. However,
SDP syntax can not provide with Partial Descriptors and Pointers SDP syntax cannot provide Deleta IMG Descriptions and IMG 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 metadata information conveyed by SDP is just a small subset of IMG metadata
the use of SDP for other than session-level IMG parameters may not be the use of SDP for other than session-level IMG 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.
skipping to change at page 18, line 43 skipping to change at page 15, line 36
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 protocol 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 protocol is not recommended. use of SAP as an IMG transport protocol is not recommended.
SIP: The SIP-specific event mechanism described in [11] provides a SIP: The SIP-specific event mechanism described in RFC 3265 [11]
way to implement IMG SUBSCRIBE and IMG NOTIFY operations via a bi- provides a way to implement IMG SUBSCRIBE and IMG NOTIFY operations
directional unicast connection. However, there are scalability via a bi-directional unicast connection. However, there are
problems with this approach, as RFC 3265 currently does not consider scalability problems with this approach, as RFC 3265 currently does
multicast. not consider multicast.
6.3 Outstanding IMG Mechanism Needs 5.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 5.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 metadata. As discussed, it unidirectional/multicast delivery of IMG metadata. As discussed, it
fails to meet the IMG requirements in many ways and, since it is not fails to meet the IMG requirements in many ways and, since it is not
designed to be extensible, we recognize that a new multicast designed to be extensible, we recognize that a new multicast
transport protocol for announcements needs to be specified to meet transport protocol for announcements needs to be specified to meet
IMG needs. This protocol will be essential to IMG delivery for IMG needs. This protocol will be essential to IMG delivery for
unidirectional and multicast deployments. unidirectional and multicast deployments.
The Asynchronous Layered Coding (ALC) [13] protocol from the IETF The Asynchronous Layered Coding (ALC) [13] protocol from the IETF
skipping to change at page 20, line 15 skipping to change at page 17, line 14
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.
In particular, any announcement protocol must feature sufficient In particular, any announcement protocol must feature sufficient
scalability, flexibility and reliability to meet IMG needs. Also, the scalability, flexibility and reliability to meet IMG needs. Also, the
ANNOUNCE operation must be supported and also NOTIFY capability could ANNOUNCE operation must be supported and NOTIFY capability could be
be investigated for both hybrid unicast-multicast and unidirectional investigated for both hybrid unicast-multicast and unidirectional
unicast systems. unicast systems.
6.3.2 Usage of Unicast Transport Protocols 5.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 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 [10], SIP events [11], HTTP [8], etc.) In
SUBSCRIBE-NOTIFY and QUERY-RESOLVE operation pairs must be enabled. particular, both SUBSCRIBE-NOTIFY and QUERY-RESOLVE operation pairs
We anticipate that the FETCH operation will be a trivial usage of must be enabled. We anticipate that the FETCH operation will be a
HTTP, although other transport options may be beneficial to consider trivial usage of HTTP, although other transport options may be
too. beneficial to consider too.
6.3.3 The Metadata Envelope
To be able to handle multiple metadata syntaxes, a common minimal set
of information is needed to handle discrete blocks of metadata. The
IMG framework model data types defined in this document. This minimal
set of information field will be named a `metadata envelope' and
must:
1. Uniquely identify the block of metadata, regardless of
metadata syntax used. The uniqueness may only be needed
within the domains the metadata is used but this must
enable globally unique identification to support Internet
usage. Scope/domain specific identifications should not
`leak' outside of the scope, and always using globally
unique identification (e.g. based on URIs) should avoid
this error.
2. Version the block so that changes can be easily handled and
stale data identified.
3. Give the temporal validity of the block. It must expire the
block (expiry time), and may optionally provide a time
(presumably in the future) from when the block becomes
valid. Temporal validity may be changeable for a block, and
even a specific version of a block.
4. Be independent of the metadata syntax(es) used for the 5.3.3 IMG Transfer Envelope
metadata block, in the sense that no useful syntax should
be excluded.
For blocks with multiple descriptors, it is assumed that any Section 3.2.6 of this document discussed the need for binding between
descriptors inherit the parameters of the (super)blocks. Thus the IMG Operations and Data Types. Such a binding can be realized by
above information will implicitly describe the individual defining a common minimal set of information needed needed to manage
descriptors. IMG metadata transfers, and by including this information with any
set of IMG metadata delivered to IMG receiver(s).
Four options for metadata envelope transport are feasible: Four options for IMG transfer envelope delivery are feasible:
1. Embedding in a transport protocol header. This can be done 1. Embedding in a transport protocol header. This can be done
with either header extensions of existing protocols, or with either header extensions of existing protocols, or
newly defined header fields of a new (or new version of a) newly defined header fields of a new (or new version of a)
transport protocol. However, multiple methods for the transport protocol. However, multiple methods for the
variety of transport protocols may hinder interoperability. variety of transport protocols may hinder interoperability.
2. A separate envelope object (a form of metadata itself) 2. A separate envelope object (a form of metadata itself)
delivered in-band with the metadata. This would complicate delivered in-band with the metadata. This would complicate
delivery as the envelope and `service' metadata objects delivery as the envelope and `service' metadata objects
skipping to change at page 21, line 45 skipping to change at page 18, line 17
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
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, When there are superset/subset relations between IMG descriptions, it
metadata syntaxes is not sufficient. Whereas the transport protocol is assumed that the IMG descriptions of the subset inherit the
should not restrict the metadata format, the metadata envelope may parameters of the superset. Thus, an IMG transfer envelope carrying
influence the choice metadata. However, metadata in binary format the IMG descriptions of a superset may implicitly define parameters
should not be prevented, in addition to the more abundant text and of IMG descriptors belonging to its subset. The relations between IMG
XML syntaxes currently available. descriptions may span from one IMG transfer envelope to another.
In most cases the actual content of metadata will be application, or 5.3.4 Baseline (Meta)Data Model Specification
service domain, specific. For instance, digital cinema distribution
and television channels will have many different requirements. The
task of specifying the bulk of the world's metadata is well beyond
the scope of this document: a framework for the delivery of IMG
metadata. We do anticipate that existing and future metadata
specifications, including those of several working groups and
standardization bodies, shall be able to use the services of the IMG
framework. However, it is not essential to the current IMG work to
specify standards with application-specific metadata.
It is essential that the three IMG data types are enabled, but it may A minimal IMG data model may be useful to any implementer/deployment
not be necessary to achieve this for every metadata syntax available, of IMGs. The purpose would be to ensure that multiple metadata
nor may it be important to the IETF to cover every possibility for syntaxes (SDP, MPEG-7, etc) can be related within the same body of
this. Generally, Complete Descriptions will be correct for existing IMG knowledge, regardless of any specific metadata and data models
syntaxes (e.g. for XML may be validated according to existing provided by the metadata syntaxes.
schema). Pointer data types may be served by a new syntax (extremely
minimal), although it is feasible that the proposed metadata envelope
specification will contain enough information to implement the
Pointer data type. Partial Descriptions may need new or modified
syntaxes and semantics (e.g. XML schema) as mandatory fields for a
Complete Description may be redundant for a Partial Description.
During and following the specification of the metadata envelope,
enabling the delivery of Partial Descriptions should be considered.
To gain implementation experience, it is essential to agree the basic Further work may be needed to meet application-specific requirements
of some metadata in interoperability tests and subsequently in at defining metadata and data models for the successful deployment of
widespread deployments. So we anticipate that a minimal IMG data IMGs in various environments. Existing (and future) work on these
model would be useful to the Internet community. would need to be mapped to the IMG data types and use of the IMG
transfer envelope concept as described above.
6.4 IMG Needs Fitting the IETF's Scope This document is a framework for the delivery of IMG Metadata and
thus further discussion on the definition data models for IMGs is
beyond its scope.
5.4 IMG Needs Fitting the IETF's Scope
A Multicast Transport Protocol is essential to IMG delivery for A Multicast Transport Protocol is essential to IMG delivery for
unidirectional and multicast deployments and no alternative exists unidirectional and multicast deployments and no alternative exists
which fulfils the IMG requirements. We recommend that the which fulfils the IMG requirements. We recommend that the
specification of this be taken on as an official work item in the specification of this be taken on as an official work item in the
IETF. IETF.
Specification of the usage of unicast transport protocols is Specification of the usage of unicast transport protocols is
essential for IMG delivery and control involving unicast essential for IMG delivery and control involving unicast
communications, and will relate to existing IETF standard transport communications, and will relate to existing IETF standard transport
protocols. Thus, we recommend that the specification of this be taken protocols. Thus, we recommend that the specification of this be taken
on as an official work item in the IETF. on as an official work item in the IETF.
The metadata envelope functionality is essential for the IMG delivery The IMG transfer envelope functionality is essential for the IMG
fulfilling the IMG requirements. It is a required feature for IMG delivery fulfilling the IMG requirements. It is a required feature
metadata transport and maintenance. Thus, we recommend that the for IMG metadata transport and maintenance. Thus, we recommend that
metadata envelope specification be taken on as an official work item the IMG transfer envelope specification be taken on as an official
in the IETF. work item in the IETF.
(Meta)data model specification and application specific metadata do (Meta)data model specification and application specific metadata do
not easily fit into the IETF scope and several other standardization not easily fit into the IETF scope and several other standardization
bodies are well placed to do this work. We recommend that aspect bodies are well placed to do this work. We recommend that aspect
shall not be an official IETF work item. shall not be an official IETF work item.
Note, we acknowledge the need to exchange and agree on a baseline Note, we acknowledge the need to exchange and agree on a baseline
metadata model and application specific metadata for the purposes of metadata model and application specific metadata for the purposes of
interoperability testing between different implementations of IMG interoperability testing between different implementations of IMG
related IETF protocols. However, we feel that the IETF standards related IETF protocols. However, we feel that the IETF standards
process is not required for this. process is not required for this.
7 Security Considerations 6 Security Considerations
The IMG framework is developed from the IMG Requirements document [2] The IMG framework is developed from the IMG Requirements document [1]
and so the selection of specific protocols and mechanism for use with and so the selection of specific protocols and mechanism for use with
the IMG framework must also take into account the security the IMG framework must also take into account the security
considerations of the IMG Requirements document. This framework considerations of the IMG Requirements document. This framework
document does not mandate the use of specific protocols. However, an document does not mandate the use of specific protocols. However, an
IMG specification would inherit the security considerations of IMG specification would inherit the security considerations of
specific protocols used, although this is outside the scope of this specific protocols used, although this is outside the scope of this
document. document.
Protocol instantiations which are used to provide IMG operations will Protocol instantiations which are used to provide IMG operations will
have very different security considerations depending on their scope have very different security considerations depending on their scope
and purpose. However, there are several general issues which are and purpose. However, there are several general issues which are
valuable to consider and, in some cases, provide technical solutions valuable to consider and, in some cases, provide technical solutions
to deal with. These are described below. to deal with. These are described below.
Individual and Group Privacy: Customized IMG metadata may reveal Individual and Group Privacy: Customized IMG metadata may reveal
information about the habits and preferences of a user and may thus information about the habits and preferences of a user and may thus
deserve confidentiality protection, even though the information deserve confidentiality protection, even if the original information
itself is public. Capturing and protecting this IMG metadata requires were public. Snooping and protecting this IMG metadata requires the
the same actions and measures as for other point-to-point and same actions and measures as for other point-to-point and multicast
multicast Internet communications. Naturally, the risk depends on the Internet communications. Naturally, the risk of snooping depends on
amount of individual or group personalization the snooped sessions the amount of individual or group personalization the snooped IMG
contain. Further consideration is valuable at both transport and metadata contains. Further consideration is valuable at both
metadata levels. transport and metadata levels.
IMG Authenticity: In some cases, the receiver needs to be assured of IMG Authenticity: In some cases, the IMG receiver needs to be assured
the origin of IMG metadata or its modification history. This can of the origin of IMG metadata or its modification history. This can
prevent denial of service or hijacking attempts which give an IMG prevent denial of service or hijacking attempts which give an IMG
receiver incorrect information in or about the metadata, thus receiver incorrect information in or about the metadata, thus
preventing successful access of the media or directing the IMG preventing successful access of the media or directing the IMG
receiver to the incorrect media possibly with tasteless material. receiver to the incorrect media possibly with tasteless material.
Action upon detection of unauthorized data insertion is out of scope Action upon detection of unauthorized data insertion is out of scope
of this document. of this document.
Receiver Authorization: Some or all of any IMG sender's metadata may IMG Receiver Authorization: Some or all of any IMG sender's metadata
be private or valuable enough to allow access to only certain may be private or valuable enough to allow access to only certain IMG
receivers and thus make it worth authenticating users. Encrypting the receivers and thus make it worth authenticating users. Encrypting the
data is also a reasonable step, especially where group communications data is also a reasonable step, especially where group communications
methods results in unavoidable snooping opportunities for methods results in unavoidable snooping opportunities for
unauthorized nodes. Encryption and the required security parameters unauthorized nodes. 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
skipping to change at page 24, line 50 skipping to change at page 21, line 8
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 7 Normative References
[1] S. Bradner, "Key words for use in RFCs to indicate requirement
levels," RFC 2119, Internet Engineering Task Force, Mar. 1997.
[2] Y. Nomura et al., "Protocol requirements for Internet media [1] Y. Nomura, "Protocol requirements for Internet media guides,"
guides," Internet Draft draft-ietf-mmusic-img-req-00, Internet Internet Draft draft-ietf-mmusic-img-req-02, Internet Engineering
Engineering Task Force, Sept. 2003. Work in progress. Task Force, Dec. 2003. Work in progress.
[2] S. Bradner, "Key words for use in RFCs to indicate requirement
levels," RFC 2119, Internet Engineering Task Force, Mar. 1997.
[3] M. Day, B. Cain, G. Tomlinson, and P. Rzewski, "A model for [3] 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.
[4] 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.
[5] 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 draft-ietf-mmusic-sdpng-07, capability negotiation," Internet Draft draft-ietf-mmusic-sdpng-07,
skipping to change at page 25, line 49 skipping to change at page 22, line 9
initiation protocol," RFC 3261, Internet Engineering Task Force, June initiation protocol," RFC 3261, Internet Engineering Task Force, June
2002. 2002.
[11] 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.
[13] 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 Informative References 8 Informative References
[12] J. Rosenberg, "A presence event package for the session [12] 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.
[14] T. Paila, "FLUTE - file delivery over unidirectional transport," [14] T. Paila, "FLUTE - file delivery over unidirectional transport,"
Internet Draft draft-ietf-rmt-flute-06, Internet Engineering Task Internet Draft draft-ietf-rmt-flute-07, Internet Engineering Task
Force, Nov. 2003. Work in progress. Force, Dec. 2003. Work in progress.
10 Acknowledgements 9 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 10 Authors' Addresses
Yuji Nomura Yuji Nomura
Fujitsu Laboratories Ltd. Fujitsu Laboratories Ltd.
4-1-1 Kamikodanaka, Nakahara-ku, Kawasaki 211-8588 4-1-1 Kamikodanaka, Nakahara-ku, Kawasaki 211-8588
Japan Japan
Email: nom@flab.fujitsu.co.jp Email: nom@flab.fujitsu.co.jp
Rod Walsh Rod Walsh
Nokia Corporation Nokia Corporation
Nokia Research Center Nokia Research Center
skipping to change at line 1197 skipping to change at page 23, line 18
France France
Email: Hitoshi.Asaeda@sophia.inria.fr Email: Hitoshi.Asaeda@sophia.inria.fr
Henning Schulzrinne Henning Schulzrinne
Dept. of Computer Science Dept. of Computer Science
Columbia University Columbia University
1214 Amsterdam Avenue 1214 Amsterdam Avenue
New York, NY 10027 New York, NY 10027
USA USA
Email: schulzrinne@cs.columbia.edu Email: schulzrinne@cs.columbia.edu
Full Copyright Statement
Copyright (c) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 

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