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 delivery capacity of senders. In
addition, IMG metadata can be used to consistency check, and thus
synchronize, a set of files between a sender host and receiver host,
when those files change as time elapses.
4.2.6. Coming-release and Pre-released Content
IMG metadata can be used to describe items of content before the
details of their final release are known. A user may be interested
in coming content (a new movie or software title where some aspects
of the content description are known in advance) and so subscribe to
an information service that notifies the user of changes to metadata
describing that content. Thus, as the coming release (or pre-
releases, e.g., as movie trailers or software demos) become
available, the IMG metadata changes and the user is notified of this
change. For example, the user could see an announcement of a movie
that will be released sometime in the next few months, and configure
the user’s terminal to receive and record any trailers or promotional
material as they become available.
5. Requirements
5.1. General Requirements
5.1.1. Independence of IMG Operations from IMG Metadata
REQ GEN-1: Carrying different kinds of IMG metadata format and
different IMG metadata formats in the IMG message body MUST be
allowed.
REQ GEN-2: Delivery mechanisms SHOULD support many different
applications’ specific metadata formats to keep the system
interoperable with existing applications.
This provides flexibility in selecting/designing an IMG transport
protocol suited to various scenarios.
5.1.2. Multiple IMG Senders
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 the IMG receiver access to more IMG
metadata than may be available from a single IMG sender. This also
provides flexibility for the IMG transport protocols and does not
preclude a mechanism to solve inconsistency among IMG metadata due to
multiple IMG senders. This document assumes that a typical IMG
environment will involve many more IMG receivers than IMG senders and
that IMG senders are continually connected for the duration of
interest (rather than intermittently connected).
5.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.
5.2. Delivery Properties
This section describes general performance requirements based on the
assumption that the range of IMG usage shall be important. However,
note that requirements for delivery properties may vary based on the
usage scenario, and thus some limited-use implementations place less
importance on some requirements.
For example, it is clear that a multicast transport may provide more
scalable delivery than a unicast transport; however, scalability
requirements do not preclude the unicast transport mechanisms. In
this sense, scalability is always important for the protocols
irrespective of transport mechanisms.
5.2.1. Scalability
REQ DEL-1: The IMG system MUST be scalable to large numbers of
messages, so as to allow design and use of delivery mechanisms that
will not fail in delivering up-to-date information under huge numbers
of transactions and massive quantities of IMG metadata.
REQ DEL-2: IMGs SHOULD provide a method to prevent an IMG sender from
sending unnecessary IMG metadata that have been stored or deleted in
IMG receivers.
REQ DEL-3: The protocol MUST be scalable to very large audience sizes
requiring IMG delivery.
5.2.2. Support for Intermittent Connectivity
REQ DEL-4: The system MUST enable IMG receivers with intermittent
access to network resources (connectivity) to receive and adequately
maintain sufficient IMG metadata.
This allows intermittent access to save power where there is no need
to keep communications links powered up while they are sitting idle.
For instance, in this situation, periodic bursts of notifies or a
fast cycling update carousel allow hosts to wake up for short periods
of time and still be kept up-to-date. This can be beneficial for IMG
receivers with sporadic connections to the fixed Internet, but is
critical in the battery-powered wireless Internet.
The implication of intermittent connectivity is that immediate
distribution of changes becomes infeasible and so managing data
consistency should be focused on the timely delivery of data.
5.2.3. Congestion Control
REQ DEL-5: Internet-friendly congestion control MUST be provided for
use on the public Internet.
REQ DEL-6: An IMG entity SHOULD invalidate the IMG metadata item when
an IMG metadata item has lifetime information and its lifetime is
over. This will lessen the need for notifications of updates from
the IMG sender to the IMG receiver to invalidate the item and may
help in reducing load.
5.2.4. Sender- and Receiver-Driven Delivery
REQ DEL-7: The system MUST be flexible in choosing sender-driven,
receiver-driven, or both delivery schemes.
Sender-driven delivery achieves high scalability without interaction
between the IMG sender and receiver.
In contrast, receiver-driven delivery provides on-demand delivery for
IMG receivers. Since an IMG sender’s complete IMG metadata may be a
very large amount of data, the IMG receiver needs to be able to
access the guide when convenient (e.g., when sufficient network
bandwidth is available to the IMG receiver).
5.3. Customized IMGs
REQ CUS-1: The system MUST allow delivery of customized IMG metadata.
The IMG receiver may require a subset of all the IMG metadata
available according to their preferences (type of content, media
description, appropriate age group, etc.) and configuration.
The IMG receiver might send its preferences in the IMG operations
that 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 with appropriate messages
carrying a subset of IMG metadata that matches the IMG receiver’s
preferences.
This mechanism can reduce the amount of IMG metadata delivered from
the IMG sender to IMG receiver, and consequently it can save the
resource consumption on the IMG entities and networks. It is
typically useful in unicast cases and also beneficial in multicast
cases where an IMG sender distributes the same IMG metadata to
interested IMG receivers at the same time.
For multicast and unicast cases where the IMG sender does not provide
customized IMG metadata, the IMG receiver could receive all IMG
metadata transmitted on the channels that the IMG receiver has
joined. However, it may select and filter the IMG metadata to get
customized IMG metadata by its preferences, and thus drop unwanted
metadata immediately upon reception.
Customizing metadata might be achieved by changing the IMG
descriptions sent and IMG receivers and/or changing the delivery
properties (channels used).
Note that customization and scalability are only somewhat exclusive.
Systems providing an IMG receiver to an IMG sender request-based
customization will be generally less scalable to massive IMG receiver
populations than those without this return signaling technique.
Thus, customization, as with any feature that affects 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.
5.4. Reliability
5.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.
Either the IMG sender can simply make updates available
(unsynchronized), or the IMG sender and receiver can interact to keep
their copies of the IMG metadata synchronized.
In the unsynchronized model, the IMG sender does not know whether a
particular IMG receiver has an up-to-date copy of the IMG metadata.
In the synchronized model, updating a cached copy of the IMG metadata
is necessary to control consistency when the IMG sender or receiver
could not communicate for a while. In this case, the IMG sender or
receiver may need to confirm its consistency by IMG operations.
REQ REL-2: Since IMG metadata can change at any time, IMG receivers
SHOULD be notified of such changes.
Fulfilling this requirement needs to be compatible with the
scalability requirements for the number of IMG receivers and the
consistency of metadata.
Depending on the size of the IMG metadata, the interested party may
want to defer retrieving the actual information. The change
notification should be addressed to a logical user (or user group),
rather than a host, since users may change devices.
Note that depending on the deployment environment and application
specifics, the level of acceptable inconsistency varies. Thus, this
document does not define inconsistency as specific time and state
differences between IMG metadata stored in an IMG sender and IMG
metadata stored in an IMG receiver.
In general, the consistency of metadata for content and media is more
important immediately prior to and during the media’s session(s).
Hosts that forward (or otherwise resend) metadata may not tolerate
inconsistencies because delivering out-of-date data is both
misleading and bandwidth inefficient.
5.4.2. Reliable Message Exchange
REQ REL-4: An IMG transport protocol MUST support reliable message
exchange.
The extent to which this could result in 100% error-free delivery to
100% of IMG 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 that some
deployments of IMG transport protocols may not aim to provide perfect
reception to all IMG receivers in all possible cases.
5.5. IMG Descriptions
REQ DES-1: IMG metadata MUST be interoperable over any IMG transport
protocol, such that an application receiving the same metadata over
any one (or more) of several network connections and/or IMG transport
protocols will interpret the metadata in exactly the same way. (This
also relates to the ’Independence of IMG Operations from IMG
Metadata’ requirements.)
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 homogeneous
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 metadata transfer envelope format that is uniform across all
different application-specific IMG metadata formats is needed. The
envelope would reference (point to) or carry (as payload) some
application-specific metadata, and the envelope would support the
maintenance of the application-specific metadata, which may also
serve the metadata relationships determined by the data model(s)
used. The envelope would not need to be aware of the data model(s)
in use.
REQ DES-4: IMG metadata MUST be structured to enable fragmentation
for efficient delivery.
This is intended to ensure that an IMG sender with more than a
trivial knowledge of metadata is able to deliver only part of its
(and the global) complete IMG metadata knowledge. (For instance, a
trivial quantity of knowledge could be a single SDP description.) In
general, the resolution of this fragmentation will be very much
dependent on the optimal delivery of a deployment, although some
metadata syntaxes will inherently affect the sensible lower limit for
a single element/fragment.
REQ DES-5: A metadata transfer envelope MUST be defined to include
essential parameters.
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 via the
metadata transfer envelope.
REQ DES-7: IMG senders SHALL use a metadata 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. (For instance, a data model could be
instantiated using both SDP and SDPng.)
REQ DES-8: IMG metadata SHOULD support the description of differences
between an updated version and an old version of IMG metadata when
the IMG delivery mechanism carries updated IMG metadata and those
differences are considerably little (e.g., by providing a ’delta’ of
the two versions; this also relates the delivery property
requirements for congestion control in Section 5.2.3).
6. Security Considerations
Internet Media Guides are used to convey information about multimedia
resources from one or more IMG senders across one or more
intermediaries to one or more IMG receivers. IMG metadata may be
pushed to the IMG receivers or interactively retrieved by them. IMGs
provide metadata as well as scheduling and rendezvous information
about multimedia resources, and so on, and requests for IMG metadata
may contain information about the requesting users.
The information contained in IMG metadata as well as the operations
related to IMGs should be secured to avoid forged information,
misdirected users, and spoofed IMG senders, for example, and to
protect user privacy.
The remainder of this section addresses the security requirements for
IMGs.
6.1. IMG Authentication and Integrity
IMG metadata and its parts need to be protected against unauthorized
alteration/addition/deletion on the way. Their originator needs to
be authenticated.
REQ AUT-1: It MUST be possible to authenticate the originator of a
set of IMG metadata.
REQ AUT-2: It MUST be possible to authenticate the originator of a
subpart of IMG metadata (e.g., a delta or a subset of the
information).
REQ AUT-3: It MUST be possible to validate the integrity of IMG
metadata.
REQ AUT-4: It MUST be possible to validate the integrity of a subpart
of IMG metadata (e.g., a delta or a subset of the information).
REQ AUT-5: It MUST be possible to separate or combine individually
authenticated pieces of IMG metadata (e.g., in an IMG transceiver)
without invalidating the authentication.
REQ AUT-6: It MUST be possible to validate the integrity of an
individually authenticated piece of IMG metadata even after this
piece has been separated from other pieces of IMG metadata and
combined with other pieces to form new IMG metadata.
REQ AUT-7: It MUST be possible to authenticate the originator of an
IMG operation.
REQ AUT-8: It MUST be possible to validate the integrity of any
contents of an IMG operation (e.g., the subscription or inquiry
information).
6.2. Privacy
Customized IMG metadata and IMG metadata delivered by notification to
individual users may reveal information about the habits and
preferences of a user and may thus deserve confidentiality
protection, even though the information itself is public.
REQ PRI-1: It MUST be possible to keep user requests to subscribe to
or retrieve certain (parts of) IMG metadata confidential.
REQ PRI-2: It MUST be possible to keep IMG metadata, pieces of IMG
metadata, or pointers to IMG metadata delivered to individual users
or groups of users confidential.
REQ PRI-3: It SHOULD be possible to ensure this confidentiality end-
to-end, that is, to prevent intermediaries (such as IMG transceivers)
from accessing the contained information.
6.3. Access Control for IMGs
Some IMG metadata may be freely available, while access to other IMG
metadata may be restricted to closed user groups (e.g., paying
subscribers). Also, different parts of IMG metadata may be protected
at different levels: for example, metadata describing a media session
may be freely accessible, while rendezvous information to actually
access the media session may require authorization.
REQ ACC-1: It MUST be possible to authorize user access to IMG
metadata.
REQ ACC-2: It MUST be possible to authorize access of users to pieces
of IMG metadata (delta information, subparts, pointers).
REQ ACC-3: It MUST be possible to require different authorization for
different parts of the same IMG metadata.
REQ ACC-4: It MUST be possible to access selected IMG metadata
anonymously.
REQ ACC-5: It MUST be possible for an IMG receiver to choose not to
receive (parts of) IMG metadata in order to avoid being identified by
the IMG sender.
REQ ACC-6: It SHOULD be possible for an IMG transceiver to select
suitable authorization methods that are compatible between both IMG
senders and IMG receivers it interacts with.
REQ ACC-7: It MAY be possible for IMG senders to require certain
authorization that cannot be modified by intermediaries.
6.4. Denial-of-Service (DOS) Attacks
Retrieving or distributing IMG metadata may require state in the IMG
senders, transceivers, and/or receivers for the respective IMG
transport sessions. Attackers may create large numbers of sessions
with any of the above IMG entities to disrupt regular operation.
REQ DOS-1: IMG operations SHOULD be authenticated.
REQ DOS-2: It SHOULD be possible to avoid DoS attacks that build up
session state in IMG entities to exhaust their resources.
REQ DOS-3: It SHOULD be possible to avoid DoS attacks that exhaust
resources of IMG entities by flooding them with IMG metadata.
As an example, two potential solutions that may be considered are
running an IMG entity in stateless mode or identification and
discarding of malicious packets by an IMG entity.
6.5. Replay Attacks
IMG metadata disseminated by an IMG sender or an IMG transceiver may
be updated, be deleted, or lose validity over time for some other
reasons. Replaying outdated IMG metadata needs to be prevented.
Furthermore, replay attacks may also apply to IMG operations (rather
than just their payload). Replaying operations also needs to be
prevented.
REQ REP-1: IMG metadata MUST be protected against partial or full
replacement of newer ("current") versions by older ones.
In a system with multiple senders, it may not be feasible to prevent
some senders from delivering older versions of metadata than others -
as a result of imperfect sender-sender data consistency. Thus,
replay attacks and delivery of inconsistent data require that an IMG
receiver verifies that the IMG metadata is valid and reliable by
using some security mechanism(s) (e.g., authorization,
authentication, or integrity).
REQ REP-2: Mechanisms MUST be provided to mitigate replay attacks on
the IMG operations.
The level of threat from replay attacks varies very much depending on
system scale and how well defined or open it is. Thus, mitigating
replay attacks may lead to different solutions for different systems,
independent of the basic delivery method and metadata definitions. A
system with multiple senders presents a more challenging scenario for
handling replay attacks. As an example, bundling metadata with a
security mechanism is one potential solution.
7. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
8. Informative References
[2] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[3] Handley, M., Perkins, C., and E. Whelan, "Session Announcement
Protocol", RFC 2974, October 2000.
[4] Session Directory, ftp://ftp.ee.lbl.gov/conferencing/sd/
[5] Session Directory Tool, http://www-
mice.cs.ucl.ac.uk/multimedia/software/sdr/
[6] Digital Video Broadcasting Project, http://www.dvb.org/
[7] Kutscher, D., Ott, J., and C. Bormann, "Session description and
capability negotiation", Work in Progress, February 2005.
[8] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[9] Nomura, Y., Walsh, R., Luoma, J-P., Asaeda, H., and H.
Schulzrinne, "Framework for the Usage of Internet Media Guides
(IMG)", RFC 4435, April 2006.
[10] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[11] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[12] Quinn, B. and K. Almeroth, "IP Multicast Applications:
Challenges and Solutions", RFC 3170, September 2001.
9. Acknowledgements
The authors would like to thank Hitoshi Asaeda, Gonzalo Camarillo,
Jean-Pierre Evain, Dirk Kutscher, Petri Koskelainen, Colin Perkins,
Toni Paila, and Magnus Westerlund for their excellent comments and
ideas on this work.
Authors’ Addresses
Yuji Nomura
Fujitsu Laboratories Ltd.
4-1-1 Kamikodanaka, Nakahara-ku, Kawasaki 211-8588
Japan
EMail: nom@flab.fujitsu.co.jp
Rod Walsh
Nokia Research Center
P.O. Box 100, FIN-33721 Tampere
Finland
EMail: rod.walsh@nokia.com
Juha-Pekka Luoma
Nokia Research Center
P.O. Box 100, FIN-33721 Tampere
Finland
EMail: juha-pekka.luoma@nokia.com
Joerg Ott
Helsinki University of Technology
Networking Laboratory
PO Box 3000
FIN-02015 TKK
Finland
EMail: jo@netlab.tkk.fi
Henning Schulzrinne
Dept. of Computer Science
Columbia University
1214 Amsterdam Avenue
New York, NY 10027
USA
EMail: schulzrinne@cs.columbia.edu
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).