draft-ietf-mmusic-img-req-00.txt   draft-ietf-mmusic-img-req-01.txt 
Internet Engineering Task Force 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
Nokia Nokia
J. Ott J. Ott
Universitaet Bremen Universitaet Bremen
H. Schulzrinne H. Schulzrinne
Columbia University Columbia University
draft-ietf-mmusic-img-req-00.txt draft-ietf-mmusic-img-req-01.txt
September 10, 2003 December 2, 2003
Expires: March 2004 Expires: March 2004
Protocol Requirements for Internet Media Guides Protocol Requirements for 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
skipping to change at page 2, line 6 skipping to change at page 2, line 6
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This memo specifies requirements for a protocol for accessing and This memo specifies requirements for a protocol for accessing and
updating Internet Media Guide (IMG) information for media-on-demand updating Internet Media Guide (IMG) information for media-on-demand
and multicast applications. These requirements are designed to guide and multicast applications. These requirements are designed to guide
development of an IMG protocol for efficient and scalable delivery. development of an IMG protocol for efficient and scalable delivery.
Table of Contents Table of Contents
1 Introduction ........................................ 2 1 Introduction ........................................ 2
1.1 Background and Motivation ........................... 2 1.1 Background and Motivation ........................... 2
1.2 Scope of this Document .............................. 4 1.2 Scope of this Document .............................. 4
2 Terminology ......................................... 4 2 Terminology ......................................... 4
3 Problem Statement ................................... 5 3 Problem Statement ................................... 5
4 Requirements ........................................ 6 4 Requirements ........................................ 6
4.1 Independence of IMG Operations from IMG Metadata .... 6 4.1 General Requirements ................................ 6
4.2 Multiple IMG Senders ................................ 6 4.1.1 Independence of IMG Operations from IMG Metadata .... 6
4.3 Modularity .......................................... 6 4.1.2 Multiple IMG Senders ................................ 6
4.4 Delivery Properties ................................. 6 4.1.3 Modularity .......................................... 6
4.4.1 Scalability ......................................... 7 4.2 Delivery Properties ................................. 7
4.4.2 Support for Intermittent Connectivity ............... 7 4.2.1 Scalability ......................................... 7
4.4.3 Congestion Control .................................. 7 4.2.2 Support for Intermittent Connectivity ............... 7
4.5 Flexibility ......................................... 8 4.2.3 Congestion Control .................................. 8
4.5.1 Customized IMGs ..................................... 8 4.2.4 Sender and Receiver Driven Delivery ................. 8
4.5.2 Many Kinds of Multimedia Content .................... 8 4.3 Customized IMGs ..................................... 8
4.5.3 Sender and Receiver Driven .......................... 8 4.4 Reliability ......................................... 9
4.6 Reliability ......................................... 9 4.4.1 Managing consistency ................................ 9
4.6.1 Managing consistency ................................ 9 4.4.2 Reliable Message Exchange ........................... 10
4.6.2 Reliable Message Exchange ........................... 10 4.5 IMG Descriptions .................................... 10
4.7 IMG Descriptions .................................... 10 5 Security Considerations ............................. 11
5 Security Considerations ............................. 10 5.1 IMG Authentication and Integrity .................... 12
5.1 IMG Authentication and Integrity .................... 11 5.2 Privacy ............................................. 13
5.2 Privacy ............................................. 11 5.3 Access Control for IMGs ............................. 13
5.3 Access Control for IMG .............................. 12 5.4 Denial-of-Service attacks ........................... 14
5.4 Denial-of-Service attacks ........................... 12 5.5 Replay Attacks ...................................... 14
5.5 Replay Attacks ...................................... 13 6 Acknowledgements .................................... 14
6 Acknowledgements .................................... 13 7 Normative References ................................ 14
7 Normative References ................................ 13 8 Informative References .............................. 15
8 Informative References .............................. 13 9 Authors' Addresses .................................. 15
9 Authors' Addresses .................................. 14
1 Introduction 1 Introduction
1.1 Background and Motivation 1.1 Background and Motivation
For some ten years, multicast-based (multimedia) conferences For some ten years, multicast-based (multimedia) conferences
(including IETF WG sessions) as well as broadcasts of (including IETF WG sessions) as well as broadcasts of
lectures/seminars, concerts, and other events have been used in the lectures/seminars, concerts, and other events have been used in the
Internet, more precisely, on the MBONE. Schedules and descriptions Internet, more precisely, on the MBONE. Schedules and descriptions
for such multimedia sessions as well as the transport addresses, for such multimedia sessions as well as the transport addresses,
skipping to change at page 3, line 30 skipping to change at page 3, line 28
An Internet Media Guide (IMG) is a structured collection of An Internet Media Guide (IMG) is a structured collection of
multimedia session descriptions expressed using SDP, SDPng or some multimedia session descriptions expressed using SDP, SDPng or some
similar session description format. It is used to describe a set of similar session description format. It is used to describe a set of
multimedia sessions (e.g. television program schedules, content multimedia sessions (e.g. television program schedules, content
delivery schedules etc.) but may also refer to other networked delivery schedules etc.) but may also refer to other networked
resources including web pages. An IMG provides an envelope for resources including web pages. An IMG provides an envelope for
metadata formats and session descriptions defined elsewhere with the metadata formats and session descriptions defined elsewhere with the
aim of facilitating structuring, versioning, referencing, aim of facilitating structuring, versioning, referencing,
distributing, and maintaining (caching, updating) such information. distributing, and maintaining (caching, updating) such information.
The IMG must be delivered to a potentially large audience, who use it The IMG metadata must be delivered to a potentially large audience,
to join a subset of the sessions described, and who may need to be who use it to join a subset of the sessions described, and who may
notified of changes to the IMG. Hence, a framework for distributing need to be notified of changes to the IMG. Hence, a framework for
IMGs in various different ways is needed to accommodate the needs of distributing IMG metadata in various different ways is needed to
different audiences: For traditional broadcast-style scenarios, accommodate the needs of different audiences: For traditional
multicast-based (push) distribution of IMGs needs to be supported. broadcast-style scenarios, multicast-based (push) distribution of IMG
Where no multicast is available, unicast-based push is required, too. metadata needs to be supported. Where no multicast is available,
Furthermore, IMGs may need to be retrieved interactively, similar to unicast-based push is required, too. Furthermore, IMG metadata may
web pages (e.g. after rebooting a system or when a user is browsing need to be retrieved interactively, similar to web pages (e.g. after
after network connectivity has been re-established). Finally, IMG rebooting a system or when a user is browsing after network
data may be updated as time elapses because content described in the connectivity has been re-established). Finally, IMG metadata may be
guide may be changed: for example, the airtime of an event such as a updated as time elapses because content described in the guide may be
concert or sports event may change, possibly affecting the airtime of changed: for example, the airtime of an event such as a concert or
subsequent media. This may be done by polling the IMG as well as sports event may change, possibly affecting the airtime of subsequent
asynchronous change notifications. media. This may be done by polling the IMG as well as asynchronous
change notifications.
Furthermore, we assume that any Internet host can be a source of Furthermore, we assume that any Internet host can be a sender of
content and thus an IMG. Some of the content sources and sinks may content and thus an IMG. Some of the content sources and sinks may
only be connected to the Internet sporadically. Also, a single human only be connected to the Internet sporadically. Also, a single human
user may use many different devices to access metadata. Thus, we user may use many different devices to access metadata. Thus, we
envision that IMGs can be sent and received by, among others, by envision that IMG metadata can be sent and received by, among others,
cellular phones, PDA (Personal Digital Assistant), personal computer, by cellular phones, PDA (Personal Digital Assistant), personal
streaming video server, set-top box, video camera, and PVR (Personal computer, streaming video server, set-top box, video camera, and PVR
Video Recorder) and that they be carried across arbitrary types of (Personal Video Recorder) and that they be carried across arbitrary
link layers, including bandwidth-constrained mobile networks. types of link layers, including bandwidth-constrained mobile
networks.
Finally, with many potential sources and sinks, different types of Finally, with many potential senders and sinks, different types of
networks, and presumably numerous service providers, IMGs may need to networks, and presumably numerous service providers, IMG metadata may
be combined, split, filtered, augmented, modified, etc. on their way need to be combined, split, filtered, augmented, modified, etc. on
from the sender(s) to the receiver(s) to provide the ultimate user their way from the sender(s) to the receiver(s) to provide the
with a suitable selection of multimedia programs according to her ultimate user with a suitable selection of multimedia programs
preferences, subscriptions, location, context (e.g. devices, access according to her preferences, subscriptions, location, context (e.g.
networks), etc. devices, access networks), etc.
1.2 Scope of this Document 1.2 Scope of this Document
This document defines requirements that Internet Media Guide (IMG) This document defines requirements that Internet Media Guide (IMG)
mechanisms must satisfy in order to deliver IMG to a potentially mechanisms must satisfy in order to deliver IMG to a potentially
large audience. Since the IMG can describe many kinds of multimedia large audience. Since the IMG can describe many kinds of multimedia
content, IMG methods are generally applicable to several scenarios. content, IMG methods are generally applicable to several scenarios.
In considering wide applicability, this document provides an analysis In considering wide applicability, this document provides the problem
of the problem space and existing mechanisms in this area. Then gives statement and existing mechanisms in this area. Then gives general
general requirements that are independent of any transport layer requirements that are independent of any transport layer mechanism
mechanism, existing protocol and application, such as performance, and application, such as delivery properties, reliability and IMG
flexibility and reliability. descriptions.
This document reflects investigating work on delivery mechanisms for This document reflects investigating work on delivery mechanisms for
IMGs and generalizing work on session announcement and initiation IMGs and generalizing work on session announcement and initiation
protocols, especially in the field of the MMUSIC working group (SAP, protocols, especially in the field of the MMUSIC working group (SAP,
SIP[5], SDP). SIP[5], SDP).
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 [6]. document are to be interpreted as described in RFC 2119 [6].
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 Problem Statement 3 Problem Statement
The MMUSIC working group has long been investigating content, media The MMUSIC working group has long been investigating content, media
and service information delivery mechanisms and protocols, and has and service information delivery mechanisms and protocols, and has
itself produces Session Announcement Protocol (SAP), Session itself produces Session Announcement Protocol (SAP), Session
Description Protocol (SDP), and the Session Initiation Protocol Description Protocol (SDP), and the Session Initiation Protocol
(SIP). SDP is capable of describing multimedia sessions (i.e. (SIP). SDP is capable of describing multimedia sessions (i.e.
content in a wider sence) by means of limited descriptive information content in a wider sense) by means of limited descriptive information
intended for human perception plus transport, scheduling information, intended for human perception plus transport, scheduling information,
and codecs and addresses for setting up media sessions. SIP and SAP and codecs and addresses for setting up media sessions. SIP and SAP
are protocols to distribute these session descriptions. are protocols to distribute these session descriptions.
Also in the IETF, HTTP is a well known information retrieval protocol HTTP is a well known data retrieval protocol using bi-directional
using bi-directional transport and widely used to deliver content transport and widely used to deliver content descriptions to many
descriptions to many hosts. hosts.
However, we perceive a lack of standard solution for scalable IMG However, we perceive a lack of standard solution for scalable IMG
delivery mechanism in the number of receivers with consistency of IMG delivery mechanism in the number of receivers with consistency of IMG
between an IMG sender and IMG receiver for both bi- and metadata between an IMG sender and IMG receiver for both bi-
unidirectional transport. With increased service dynamics and directional and unidirectional transport. With increased service
complexity, there is an increased requirement for updates to these dynamics and complexity, there is an increased requirement for
content descriptions. updates to these content descriptions.
Whenever an HTTP client requires updated content descriptions, the Whenever an HTTP client requires updated content descriptions, the
client has to reload those using the same URL. For mass media, the client has to reload those using the same URL. For mass media, the
large number of users polling a server causes scalability and large number of users polling a server causes scalability and
congestion concerns and so the technique is feasible only if the congestion concerns and so the technique is feasible only if the
period between reloading is long and the amount of content period between reloading is long and the amount of content
descriptions or the number of users is small. A well-behaved descriptions or the number of users is small. A well-behaved
implementation limits the timeliness of receiver-side updates for implementation limits the timeliness of receiver-side updates for
mass audiences. mass audiences.
The unicast equivalent of this is to maintain a unicast The unicast equivalent of this is to maintain a unicast
connection/session between sender and receiver for the whole time a connection/session between sender and receiver for the whole time a
receiver is interested in a service. This may be feasible in many receiver is interested in a service. This may be feasible in many
wireline systems for servers with only a few receivers, but both of wireline systems for servers with only a few receivers, but both of
these become less attractive for both wireless links and large these become less attractive for both wireless links and large
numbers of sender-receiver connections, especially as both of these numbers of sender-receiver connections, especially as both of these
share a resource (the radio bandwidth or the server resources) and share a resource (the radio bandwidth or the server resources) and
thus limit the number of receivers that can be served, without thus limit the number of receivers that can be served, without
additional infrastructure investment. additional infrastructure investment.
We also preceive a lack of standard solution for flexible content We also perceive a lack of standard solution for flexible content
descriptions to support a multitude of application-specific data descriptions to support a multitude of application-specific data
models with differing amount of detail and different target models with differing amount of detail and different target
audiences. audiences.
4 Requirements 4 Requirements
4.1 Independence of IMG Operations from IMG Metadata 4.1 General Requirements
Carrying different kinds of IMG metadata format in the IMG message 4.1.1 Independence of IMG Operations from IMG Metadata
body MUST be allowed. Delivery mechanisms SHOULD be agnostic to
applications specific metadata to keep the system interoperable with
existing applications. This provides flexibility in
selecting/designing delivery protocol suited to various scenarios.
4.2 Multiple IMG Senders REQ GEN-1: Carrying different kinds of IMG metadata format in the IMG
message body MUST be allowed.
IMG receivers MUST be allowed to communicate with any number of IMG REQ GEN-2: Delivery mechanisms SHOULD support many different
senders simultaneously. This might lead to receiving redundant IMG applications specific metadata formats to keep the system
metadata describing the same items, however it enables receiver interoperable with existing applications.
access to more IMG metadata than may be available from a single IMG
sender. This also provides flexibility for the delivery protocols
and does not Preclude a mechanism to solve inconsistency among IMG
metadata due to multiple IMG senders.
4.3 Modularity This provides flexibility in selecting/designing delivery protocol
suited to various scenarios.
The IMG delivery mechanisms MUST allow the combination of several IMG 4.1.2 Multiple IMG Senders
operations for the purpose of extending functionality (e.g. several
or one protocol(s) to provide all the needed operations).
Applications may select an appropriate operation set to fulfill their
purpose.
4.4 Delivery Properties REQ GEN-3: IMG receivers MUST be allowed to communicate with any
number of IMG senders simultaneously.
This might lead to receiving redundant IMG metadata describing the
same items, however it enables receiver access to more IMG metadata
than may be available from a single IMG sender. This also provides
flexibility for the delivery protocols and does not preclude a
mechanism to solve inconsistency among IMG metadata due to multiple
IMG senders. This document assumes a typical IMG environment will
involve many more receivers than senders and that senders are
continually connected for the duration of interest (rather than
intermittently connected).
4.1.3 Modularity
REQ GEN-4: The IMG delivery mechanisms MUST allow the combination of
several IMG Operations.
This is for the purpose of extending functionality (e.g. several or
one protocol(s) to provide all the needed operations). Applications
can select an appropriate operation set to fulfill their purpose.
4.2 Delivery Properties
This section describes general performance requirements based on the This section describes general performance requirements based on the
assumption that the range of IMG usage shall be important. However, assumption that the range of IMG usage shall be important. However,
it may be noted that requirements of delivery properties may vary it may be noted that requirements of delivery properties may vary
based on the usage scenario, and thus some limited use based on the usage scenario, and thus some limited use
implementations place less importance on some requirements. implementations place less importance on some requirements.
Example: It is clear that a multicast transport may provide more For example, it is clear that a multicast transport may provide more
scalable delivery than a unicast transport, however scalability scalable delivery than a unicast transport, however scalability
requirements do not preclude the unicast transport mechanisms. In requirements do not preclude the unicast transport mechanisms. In
this sense, scalability is always important for the protocols this sense, scalability is always important for the protocols
irrespective of transport mechanisms. irrespective of transport mechanisms.
4.4.1 Scalability 4.2.1 Scalability
The system MUST be scalable in that it does not fail to deliver up- REQ DEL-1: The system MUST be scalable in that it does not fail to
to-date information under huge numbers of transactions and massive deliver up-to-date information under huge numbers of transactions and
quantities of IMG Metadata. massive quantities of IMG metadata.
An IMG system SHOULD provide a method to prevent an IMG sender from REQ DEL-2: IMGs SHOULD provide a method to prevent an IMG sender from
sending verbose IMGs that have been stored or deleted in IMG sending verbose IMG metadata that have been stored or deleted in IMG
receivers. Note, 'verbose' data is unneeded or unused detail or receivers. Note, 'verbose' data is unneeded or unused detail or
repetitions. repetitions.
The protocol MUST be scalable to very large audience sizes requiring REQ DEL-3: The protocol MUST be scalable to very large audience sizes
IMG delivery. requiring IMG delivery.
4.4.2 Support for Intermittent Connectivity 4.2.2 Support for Intermittent Connectivity
The system MUST enable IMG receivers with intermittent access to REQ DEL-4: The system MUST enable IMG receivers with intermittent
network resources (connectivity) to receive and adequately maintain access to network resources (connectivity) to receive and adequately
sufficient IMG metadata. maintain sufficient IMG metadata.
This allows intermittent access to save power where there is no need This allows intermittent access to save power where there is no need
to keep communications links powered-up while they are sitting idle. to keep communications links powered-up while they are sitting idle.
For instance, in this situation periodic bursts of notifies, or a For instance, in this situation periodic bursts of notifies, or a
fast cycling update carousel, allows hosts to wake up for short fast cycling update carousel, allows hosts to wake up for short
periods of time and still be kept up-to-date. This may be beneficial periods of time and still be kept up-to-date. This can be beneficial
in the fixed-Internet, but is critical in the battery-powered for receivers with sporadic connects to the fixed Internet, but is
wireless Internet. critical in the battery-powered wireless Internet.
In addition, some of the IMG senders and receivers may only be 4.2.3 Congestion Control
connected to the Internet sporadically. As an example, consider a
storage device requires the up-to-date video file from an IP-
reachable video camera but the camera is connected manually within a
limited period. When the camera is connected on the network and has a
new video object, the storage device must be notified of the
availability of the video file immediately.
4.4.3 Congestion Control REQ DEL-5: Internet-friendly congestion control MUST be provided for
use on the public Internet.
Internet-friendly congestion control MUST be provided. For instance, For instance, notifications of updates (containing only minimal
notifications of updates (containing only minimal change related change related data) can reduce congestion, especially for very large
data) can reduce congestion, especially for very large groups, while groups, while allowing individual "congestion free" parts of the
allowing individual "congestion free" parts of the Internet to do Internet to do things "their way". Where some hosts are on
things "their way". Where some hosts are on unidirectional links, and unidirectional links, and other have bi-directional links (or both),
other have bi-directional links (or both), this is sensible this is sensible "diversity".
"diversity".
When an IMG item has lifetime information, the IMG entity SHOULD REQ DEL-6: An IMG entity SHOULD invalidate the IMG metadata item when
invalidate the IMG item when its lifetime is over without any IMG an IMG metadata item has lifetime information and its lifetime is
operations. This mechanism can reduce notifications of updates from over.
the IMG sender to receiver to invalidate the item. It may be
beneficial for congestion control.
4.5 Flexibility This mechanism can reduce notifications of updates from the IMG
sender to receiver to invalidate the item. It may be beneficial for
congestion control.
4.5.1 Customized IMGs 4.2.4 Sender and Receiver Driven Delivery
The system MUST allow delivery of customized IMG metadata. The IMG REQ DEL-7: The system MUST be flexible in choosing sender-driven,
receiver may require a subset of the IMG according to their receiver-driven or both delivery schemes.
preferences (type of content, media description, appropriate age
group, etc.) and configuration.
The IMG receiver may send its preferences in the IMG operations which Sender-driven delivery achieves high scalability without interaction
can specify user specific IMGs to be delivered. The preferences might between the IMG sender and receiver. This avoids keeping track of a
consist of filtering rules. When receiving these messages, the IMG delivery state of every receiver.
sender may respond appropriate messages carrying a subset of IMGs
which matches the receiver's preferences.
This mechanism can reduce the amount of IMGs delivered from the In contrast, the receiver-driven delivery provides on-demand delivery
sender to receiver, and consequently it can save the resource for IMG receivers. Since a sender's complete IMG metadata may be a
consumption on the IMG entities and IMG networks. It is typically very large amount of data, the IMG receiver needs to be able to
useful in unicast case and also beneficial in multicast case where access the guide when convenient (e.g., when sufficient network
IMG sender distributes the same IMGs to interested IMG receivers at bandwidth is available to the receiver).
the same time.
In multicast case or unicast case where the IMG sender does not 4.3 Customized IMGs
provide customized IMGs, the IMG receiver may receive all IMG data
transmitted (on its joined channels). However, it may select and
filter the IMGs to get customized IMGs by its preferences, and thus
drop unwanted metadata immediately upon reception.
4.5.2 Many Kinds of Multimedia Content REQ CUS-1: The system MUST allow delivery of customized IMG metadata.
The system MUST be able to deliver a variety of media descriptions, The IMG receiver may require a subset of all the IMG metadata
which represents multimedia items available (e.g. by download, available according to their preferences (type of content, media
streaming or multicast distribution.) This is essential for the description, appropriate age group, etc.) and configuration.
system to support many kinds of multimedia content and to achieve
wide applicability.
4.5.3 Sender and Receiver Driven The IMG receiver might send its preferences in the IMG operations
which can specify user specific IMG metadata to be delivered. These
preferences could consist of filtering rules. When receiving these
messages, the IMG sender might respond appropriate messages carrying
a subset of IMG metadata which matches the receiver's preferences.
The system MUST be flexible in choosing sender-driven, receiver- This mechanism can reduce the amount of IMG metadata delivered from
driven or both delivery schemes. Sender-driven delivery achieves high the sender to receiver, and consequently it can save the resource
scalability without interaction between the IMG sender and receiver. consumption on the IMG entities and networks. It is typically useful
This avoids keeping track of a delivery state of every receiver. in unicast case and also beneficial in multicast case where IMG
sender distributes the same IMG metadata to interested IMG receivers
at the same time.
In contrast, the receiver-driven delivery provides on-demand delivery For multicast and unicast cases where the IMG sender does not provide
for IMG receivers. Since an IMG may contain a large amount of data, customized IMG metadata, the IMG receiver could receive all IMG
the IMG receiver needs to be able to access the guide when convenient metadata transmitted (on its joined channels). However, it may select
(e.g., when sufficient network bandwidth is available to the and filter the IMG metadata to get customized IMG metadata by its
receiver). preferences, and thus drop unwanted metadata immediately upon
reception.
4.6 Reliability Customized metadata might be achieved by changing the IMG descriptors
sent and receivers and/or changing the delivery properties (channels
used).
4.6.1 Managing consistency Note, customization and scalability are only somewhat exclusive.
Systems providing receiver to sender request-based customization,
will be generally less scalable to massive receiver populations than
those without this return signaling technique. Thus, customization,
as with any feature which effects scalability, should be carefully
designed for the intended application, and it may not be possible
that a one-size-fits-all solution for customization would meet the
scalability requirements for all applications and deployment cases.
IMGs tend to change as time elapses, as new content is added, the old 4.4 Reliability
IMG stored in the IMG receiver becomes unavailable and the parameters
of the existing IMG are changed. 4.4.1 Managing consistency
IMG metadata tends to change as time elapses, as new content is
added, the old IMG metadata stored in the IMG receiver becomes
unavailable and the parameters of the existing IMG metadata are
changed.
REQ REL-1: The system MUST manage IMG metadata consistency.
The IMG sender can either simply make updates available The IMG sender can either simply make updates available
(unsynchronized) or IMG sender and receiver can interact to keep (unsynchronized) or IMG sender and receiver can interact to keep
their copies of the IMG synchronized. their copies of the IMG metadata synchronized.
In the unsynchronized model, the source does not know whether a In the unsynchronized model, the sender does not know whether a
particular receiver has an up-to-date copy of the IMG. particular receiver has an up-to-date copy of the IMG metadata.
In the synchronized model, updating cached copy of the IMG is In the synchronized model, updating cached copy of the IMG metadata
necessary to control consistency when the IMG sender or receiver is necessary to control consistency when the IMG sender or receiver
could not communicate for a while. In this case, the IMG sender or could not communicate for a while. In this case, the IMG sender or
receiver may need to confirm its consistency by IMG operations. receiver may need to confirm its consistency by IMG operations.
Since IMGs can change at any time, IMG receivers SHOULD be notified REQ REL-2: Since IMG metadata can change at any time, IMG receivers
of such changes. Depending on the size of the guide, the interested SHOULD be notified of such changes.
party may want to defer retrieving the actual information. The
change notification should be addressed to a logical user (or user Depending on the size of the guide, the interested party may want to
group), not a host, since users may change devices. defer retrieving the actual information. The change notification
should be addressed to a logical user (or user group), not a host,
since users may change devices.
Note that depending on the deployment environment and application Note that depending on the deployment environment and application
specifics, the level of acceptable inconsistency varies. Thus, this specifics, the level of acceptable inconsistency varies. Thus, this
document does not define inconsistency as specific time and state document does not define inconsistency as specific time and state
differences between two IMG metadata stored in the IMG receiver and differences between IMG metadata stored in an IMG sender and IMG
IMG sender. metadata stored in an IMG receiver.
In general, the consistency of metadata is more important immediately In general, the consistency of metadata for a content and media is
prior to and during the media session(s) duration (in time). Hosts more important immediately prior to and during the media's
which forward (or otherwise resend) metadata may be less tolerant to session(s). Hosts which forward (or otherwise resend) metadata may be
inconsistencies as delivering out of date data is both misleading and less tolerant to inconsistencies as delivering out of date data is
is bandwidth inefficient. both misleading and bandwidth inefficient.
By contrast, intermittent connectivity make immediate distribution of By contrast, intermittent connectivity make immediate distribution of
changes infeasible and so managing data consistency should be focused changes infeasible and so managing data consistency should be focused
on the timely delivery of data. on the timely delivery of data.
4.6.2 Reliable Message Exchange 4.4.2 Reliable Message Exchange
IMG transport MUST support reliable message exchange. The extent to REQ REL-3: An IMG transport protocol MUST support reliable message
which this will result in 100 statistical characteristic of the exchange.
protocols used. Usage of reliable IMG delivery mechanisms is expected
to depend on the extent to which underlying networks provide
reliability and, conversely, introduce errors.
4.7 IMG Descriptions The extent to which this could result in 100% error free delivery to
100% of receivers is a statistical characteristic of the protocols
used. Usage of reliable IMG delivery mechanisms is expected to depend
on the extent to which underlying networks provide reliability and,
conversely, introduce errors. Note, some deployments of IMG transport
protocols may not aim to provide perfect reception to all receivers
in all possible cases.
IMG metadata MUST be interoperable over any IMG delivery protocol, 4.5 IMG Descriptions
such that an application receiving the same metadata over any one (or
more) of several network connections and/or delivery protocols will
interpret the metadata in exactly the same way. (This also relates to
the 'Independence of IMG Operations from IMG Metadata' requirement).
IMG delivery MUST enable the carriage of any format of application- REQ DES-1: IMG metadata MUST be interoperable over any IMG delivery
specific metadata. Whereas specific applications relying on IMG shall protocol, such that an application receiving the same metadata over
need to select one or more specific application-specific metadata any one (or more) of several network connections and/or delivery
formats (standard, syntax, etc.), the IMG system shall be agnostic to protocols will interpret the metadata in exactly the same way. (This
this (it may be aware, but it will operate in the same way for all). also relates to the 'Independence of IMG Operations from IMG
Metadata' requirement).
REQ DES-2: IMG delivery MUST enable the carriage of any format of
application-specific metadata.
Thus, the system will support the description of many kinds of
multimedia content, without the need for a single homogenous metadata
syntax for all uses (which would be infeasible anyway). This is
essential for environments using IMG systems to support many kinds of
multimedia content and to achieve wide applicability.
REQ DES-3: Whereas specific applications relying on IMGs will need to
select one or more specific application-specific metadata formats
(standard, syntax, etc.), the IMG system MUST be independent of this
(it may be aware, but it will operate in the same way for all).
Thus, a transfer envelope format, that is uniform across all Thus, a transfer envelope format, that is uniform across all
different application-specific IMG metadata formats, is needed. The different application-specific IMG metadata formats, is needed. The
payload of this transfer envelope would be some application-specific payload of this transfer envelope would be some application-specific
metadata. metadata.
IMG metadata MUST be structured such that it is possible to deliver REQ DES-4: IMG metadata MUST be structured such that it is possible
only part of a sender's (and the global) complete IMG knowledge MUST to deliver only part of a sender's (and the global) complete IMG
be defined to include parameters, from the data model, that allow its metadata knowledge.
payload to be uniquely identified and updated by new versions of the
same payload. It SHALL be possible to deduce the payload format from
the transfer envelope. IMG senders SHALL use the transfer envelope
for each IMG Metadata transfer. Thus, it will even be possible to
describe relationships between syntactically dissimilar application-
specific formats within the same body of IMG metadata knowledge.
IMG metadata SHOULD support to describe differences between update REQ DES-5: A transfer envelope MUST be defined to include essential
version and old version of IMG metadata when IMG delivery mechanism parameters.
carries updated IMG metadata and those differences are considerably
little. This also relates the delivery property requirements for
"Congestion Control".
5 Security Considerations Examples of essential parameters are those that allow the metadata in
question to be uniquely identified and updated by new versions of the
same metadata.
REQ DES-6: It SHALL be possible to deduce the metadata format from
the transfer envelope.
REQ DES-7: IMG senders SHALL use the transfer envelope for each IMG
metadata transfer.
Thus, it will even be possible to describe relationships between
syntactically dissimilar application-specific formats within the same
body of IMG metadata knowledge.
REQ DES-8: IMG metadata SHOULD support to describe differences
between update version and old version of IMG metadata when IMG
delivery mechanism carries updated IMG metadata and those differences
are considerably little. (This also relates the delivery property
requirements for congestion control in Section 4.2.3).
5 Security Considerations
Internet Media Guides are used to convey information about multimedia Internet Media Guides are used to convey information about multimedia
resources from one or more senders across one or intermediaries to resources from one or more senders across one or intermediaries to
one or more receivers. IMGs may be pushed to the receivers or one or more receivers. IMG metadata may be pushed to the receivers or
interactively retrieved by them. IMGs contain metadata as well as interactively retrieved by them. IMGs provide metadata as well as
scheduling and rendezvous information about multimedia resources, scheduling and rendezvous information about multimedia resources,
etc. and requests for IMGs may contain information about the etc. and requests for IMG metadata may contain information about the
requesting users. requesting users.
The information contained in IMGs as well as the operations related The information contained in IMG metadata as well as the operations
to IMGs should be secured to avoid forging information, misdirecting related to IMGs should be secured to avoid forging information,
users, spoofing sneders, etc. and to protect user privacy. misdirecting users, spoofing senders, etc. and to protect user
privacy.
This section addresses the security requirements for IMGs. The remainder of section addresses the security requirements for
IMGs.
5.1 IMG Authentication and Integrity 5.1 IMG Authentication and Integrity
IMGs and their constituents need to be protected against unauthorized IMG metadata and its parts need to be protected against unauthorized
altering/adding/deletion on the way. Their originator needs to be altering/adding/deletion on the way. Their originator needs to be
authenticated. authenticated.
R: It MUST be possible to authenticate the originator of an IMG. REQ AUT-1: It MUST be possible to authenticate the originator of a
set of IMG metadata.
R: It MUST be possible to authenticate the originator of a subpart of REQ AUT-2: It MUST be possible to authenticate the originator of a
an IMG (e.g. a delta or a subset of the information). subpart of IMG metadata (e.g. a delta or a subset of the
information).
R: It MUST be possible to validate the integrity of an IMG. REQ AUT-3: It MUST be possible to validate the integrity of IMG
metadata.
R: It MUST be possible to validate the integrity of a subpart of an REQ AUT-4: It MUST be possible to validate the integrity of a subpart
IMG (e.g. a delta or a subset of the information). of IMG metadata (e.g. a delta or a subset of the information).
R: It SHOULD be possible to separate or combine individually REQ AUT-5: It MUST be possible to separate or combine individually
authenticated pieces of an IMG (e.g. in an IMG transceiver) without authenticated pieces of IMG metadata (e.g. in an IMG transceiver)
invalidating the authentication. without invalidating the authentication.
R: It SHOULD be possible to validate the integrity of a piece of an REQ AUT-6: It MUST be possible to validate the integrity of an
IMG even after this piece had been separated from other pieces of an individually authenticated piece of IMG metadata even after this
IMG and combined with other pieces to form a new IMG. piece had been separated from other pieces of IMG metadata and
combined with other pieces to form new IMG metadata.
R: It MUST be possible to authenticate the originator of an IMG REQ AUT-7: It MUST be possible to authenticate the originator of an
related primitive. IMG operation.
R: It MUST be possible to validate the integrity of any contents of REQ AUT-8: It MUST be possible to validate the integrity of any
an IMG related primitive (e.g. the subscription or inquiry contents of an IMG operation (e.g. the subscription or inquiry
information). information).
5.2 Privacy 5.2 Privacy
Customized IMGs and IMGs delivered by notification to individual Customized IMG metadata and IMG metadata delivered by notification to
users may reveal information about the habits and preferences of a individual users may reveal information about the habits and
user and may thus deserve confidentiality protection, even though the preferences of a user and may thus deserve confidentiality
information itself is public. protection, even though the information itself is public.
R: It MUST be possible to keep user requests to subscribe to or REQ PRI-1: It MUST be possible to keep user requests to subscribe to
retrieve certain (parts of) IMGs confidential. or retrieve certain (parts of) IMG metadata confidential.
R: It MUST be possible to keep IMGs, pieces of IMGs, or pointers to REQ PRI-2: It MUST be possible to keep IMG metadata, pieces of IMG
IMGs delivered to individual users or groups of users confidential. metadata, or pointers to IMG metadata delivered to individual users
or groups of users confidential.
R: It SHOULD be possible to ensure this confidentiality end-to-end, REQ PRI-3: It SHOULD be possible to ensure this confidentiality end-
that is, to prevent intermediaries (such as IMG transceivers) from to-end, that is, to prevent intermediaries (such as IMG transceivers)
accessing the contained information. from accessing the contained information.
5.3 Access Control for IMG 5.3 Access Control for IMGs
Some IMGs may be freely available, while access to other may be Some IMG metadata may be freely available, while access to other may
restricted to closed user groups (e.g. paying subscribers). Also, be restricted to closed user groups (e.g. paying subscribers). Also,
different parts of an IMG may be protected at different levels: e.g. different parts of IMG metadata may be protected at different levels:
metadata describing a media session may be freely accessible while e.g. metadata describing a media session may be freely accessible
rendezvous information to actually access the media session may while rendezvous information to actually access the media session may
require authorization. require authorization.
R: It MUST be possible to authorize user access to IMGs. REQ ACC-1: It MUST be possible to authorize user access to IMG
metadata.
R: It MUST be possible to authorize access of users to pieces of IMGs REQ ACC-2: It MUST be possible to authorize access of users to pieces
(delta information, subparts, pointers). of IMG metadata (delta information, subparts, pointers).
R: It MUST be possible to require different authorization for REQ ACC-3: It MUST be possible to require different authorization for
different parts of the same IMG. different parts of the same IMG metadata.
R: It MUST be possible to access selected IMGs anonymously. REQ ACC-4: It MUST be possible to access selected IMG metadata
anonymously.
R: It MUST be possbile for an IMG receiver to choose not to receive REQ ACC-5: It MUST be possible for an IMG receiver to choose not to
(parts of) an IMG in order to avoid authentication by the source. receive (parts of) IMG metadata in order to avoid being identified by
the sender.
R: It SHOULD be possible for IMG transceiver to impose different REQ ACC-6: It SHOULD be possible for IMG transceiver to impose
authorization requirements. different authorization requirements.
R: It MAY be possible for IMG originators to require certain REQ ACC-7: It MAY be possible for IMG senders to require certain
authorization that cannot be overridden by intermediaries. authorization that cannot be overridden by intermediaries.
5.4 Denial-of-Service attacks 5.4 Denial-of-Service attacks
Retrieving or distributing IMGs may require state in the senders, Retrieving or distributing IMG metadata may require state in the
transceivers, and/or receivers for the respective IMG delivery senders, transceivers, and/or receivers for the respective IMG
sessions. Attackers may create large numbers of sessions with any of delivery sessions. Attackers may create large numbers of sessions
the above IMG entities to disrupt regular operation. with any of the above IMG entities to disrupt regular operation.
R: IMG operations SHOULD be authenticated. REQ DOS-1: IMG operations SHOULD be authenticated.
R: It SHOULD be possible to prevent DoS attacks that build up session REQ DOS-2: It SHOULD be possible to prevent DoS attacks that build up
state in IMG components to exhaust their resources. session state in IMG entities to exhaust their resources.
R: It SHOULD be possible to avoid DoS attachs that exhaust resources REQ DOS-3: It SHOULD be possible to avoid DoS attacks that exhaust
of IMG components by flooding them with IMG content. resources of IMG entities by flooding them with IMG metadata.
5.5 Replay Attacks 5.5 Replay Attacks
IMGs dissiminated by the source or a transceiver may be updated, IMG metadata disseminated by the sender or a transceiver may be
deleted, or lose validity over time for some other reasons. updated, deleted, or lose validity over time for some other reasons.
Replaying outdated IMGs needs to be prevented. Replaying outdated IMG metadata needs to be prevented.
Furthermore, replay attacks may also apply to IMG operations (rather Furthermore, replay attacks may also apply to IMG operations (rather
than just their payload). Replaying operations needs also be than just their payload). Replaying operations needs also be
prevented. prevented.
R: IMGs MUST be protected against partial or full replacement of REQ REP-1: IMG metadata MUST be protected against partial or full
newer ("current") versions by older ones. replacement of newer ("current") versions by older ones.
R: Mechanisms MUST be provided to mitigate replay attacks on the IMG REQ REP-2: Mechanisms MUST be provided to mitigate replay attacks on
operations. the IMG operations.
6 Acknowledgements 6 Acknowledgements
The authors would like to thank Hitoshi Asaeda, Juka-Pekka Luoma , The authors would like to thank Hitoshi Asaeda, Petri Koskelainen,
Petri Koskelainen, Toni Paila and Dirk Kutscher for thier comments on Toni Paila and Dirk Kutscher for their comments and ideas on this
the draft. work.
7 Normative References 7 Normative References
[1] M. Handley and V. Jacobson, ``SDP: session description protocol,'' [1] 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.
[2] M. Handley, C. E. Perkins, and E. Whelan, ``Session announcement [2] 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.
[5] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J. [5] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J.
skipping to change at page 14, line 18 skipping to change at page 15, line 30
9 Authors' Addresses 9 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 Research Center Nokia Research Center
P.O. Box 100, FIN-33721 Tampere P.O. Box 100, FIN-33721 Tampere
Finland Finland
Email: rod,walsh@nokia.com Email: rod.walsh@nokia.com
Joerg Ott <jo@tzi.org> Juha-Pekka Luoma
Nokia Research Center
P.O. Box 100, FIN-33721 Tampere
Finland
Email: juha-pekka.luoma@nokia.com
Joerg Ott
Universitaet Bremen Universitaet Bremen
MZH 5180 MZH 5180
Bibliothekstr. 1 Bibliothekstr. 1
D-28359 Bremen D-28359 Bremen
Germany Germany
tel:+49-421-201-7028 Email: jo@tzi.uni-bremen.de
sip:jo@tzi.org
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 Full Copyright Statement
 End of changes. 

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