Internet Engineering Task Force MMUSIC WG
Internet Draft Y. Nomura
Fujitsu Labs.
R. Walsh
J-P. Luoma
Nokia
J. Ott
Universitaet Bremen
H. Schulzrinne
Columbia University
draft-ietf-mmusic-img-req-01.txt
December 2, 2003
Expires: March 2004
Protocol Requirements for Internet Media Guides
STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Abstract
This memo specifies requirements for a protocol for accessing and
updating Internet Media Guide (IMG) information for media-on-demand
and multicast applications. These requirements are designed to guide
development of an IMG protocol for efficient and scalable delivery.
Y. Nomura et. al. [Page 1]
Internet Draft IMG Requirements December 2, 2003
Table of Contents
1 Introduction ........................................ 2
1.1 Background and Motivation ........................... 2
1.2 Scope of this Document .............................. 4
2 Terminology ......................................... 4
3 Problem Statement ................................... 5
4 Requirements ........................................ 6
4.1 General Requirements ................................ 6
4.1.1 Independence of IMG Operations from IMG Metadata .... 6
4.1.2 Multiple IMG Senders ................................ 6
4.1.3 Modularity .......................................... 6
4.2 Delivery Properties ................................. 7
4.2.1 Scalability ......................................... 7
4.2.2 Support for Intermittent Connectivity ............... 7
4.2.3 Congestion Control .................................. 8
4.2.4 Sender and Receiver Driven Delivery ................. 8
4.3 Customized IMGs ..................................... 8
4.4 Reliability ......................................... 9
4.4.1 Managing consistency ................................ 9
4.4.2 Reliable Message Exchange ........................... 10
4.5 IMG Descriptions .................................... 10
5 Security Considerations ............................. 11
5.1 IMG Authentication and Integrity .................... 12
5.2 Privacy ............................................. 13
5.3 Access Control for IMGs ............................. 13
5.4 Denial-of-Service attacks ........................... 14
5.5 Replay Attacks ...................................... 14
6 Acknowledgements .................................... 14
7 Normative References ................................ 14
8 Informative References .............................. 15
9 Authors' Addresses .................................. 15
1 Introduction
1.1 Background and Motivation
For some ten years, multicast-based (multimedia) conferences
(including IETF WG sessions) as well as broadcasts of
lectures/seminars, concerts, and other events have been used in the
Internet, more precisely, on the MBONE. Schedules and descriptions
for such multimedia sessions as well as the transport addresses,
codecs, and their parameters have been described using SDP [1] as a
rudimentary (but as of then largely sufficient) means. Dissemination
of the descriptions has been performed using the Session Announcement
Protocol (SAP) [2] and tools such as SD [3] or SDR [4]; descriptions
have also been put up on web pages, sent by electronic mail, etc.
Y. Nomura et. al. [Page 2]
Internet Draft IMG Requirements December 2, 2003
Recently, interest has grown to expand -- or better: to generalize --
the applicability of these kinds of session descriptions.
Descriptions are becoming more elaborate in terms of included
metadata; more generic regarding the types of media sessions; and
possibly also support other transports than just IP (e.g. legacy TV
channel addresses). This peers well with the DVB Organization's
increased activities towards IP-based communications over satellite,
cable, and terrestrial radio networks, also considering IP as the
basis for TV broadcasts and further services. The program/content
descriptions are referred to as Internet Media Guides (IMGs) and can
be viewed as a generalization of Electronic Program Guides (EPGs) and
multimedia session descriptions.
An Internet Media Guide (IMG) is a structured collection of
multimedia session descriptions expressed using SDP, SDPng or some
similar session description format. It is used to describe a set of
multimedia sessions (e.g. television program schedules, content
delivery schedules etc.) but may also refer to other networked
resources including web pages. An IMG provides an envelope for
metadata formats and session descriptions defined elsewhere with the
aim of facilitating structuring, versioning, referencing,
distributing, and maintaining (caching, updating) such information.
The IMG metadata must be delivered to a potentially large audience,
who use it to join a subset of the sessions described, and who may
need to be notified of changes to the IMG. Hence, a framework for
distributing IMG metadata in various different ways is needed to
accommodate the needs of different audiences: For traditional
broadcast-style scenarios, multicast-based (push) distribution of IMG
metadata needs to be supported. Where no multicast is available,
unicast-based push is required, too. Furthermore, IMG metadata may
need to be retrieved interactively, similar to web pages (e.g. after
rebooting a system or when a user is browsing after network
connectivity has been re-established). Finally, IMG metadata may be
updated as time elapses because content described in the guide may be
changed: for example, the airtime of an event such as a concert or
sports event may change, possibly affecting the airtime of subsequent
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 sender of
content and thus an IMG. Some of the content sources and sinks may
only be connected to the Internet sporadically. Also, a single human
user may use many different devices to access metadata. Thus, we
envision that IMG metadata can be sent and received by, among others,
by cellular phones, PDA (Personal Digital Assistant), personal
computer, streaming video server, set-top box, video camera, and PVR
(Personal Video Recorder) and that they be carried across arbitrary
Y. Nomura et. al. [Page 3]
Internet Draft IMG Requirements December 2, 2003
types of link layers, including bandwidth-constrained mobile
networks.
Finally, with many potential senders and sinks, different types of
networks, and presumably numerous service providers, IMG metadata may
need to be combined, split, filtered, augmented, modified, etc. on
their way from the sender(s) to the receiver(s) to provide the
ultimate user with a suitable selection of multimedia programs
according to her preferences, subscriptions, location, context (e.g.
devices, access networks), etc.
1.2 Scope of this Document
This document defines requirements that Internet Media Guide (IMG)
mechanisms must satisfy in order to deliver IMG to a potentially
large audience. Since the IMG can describe many kinds of multimedia
content, IMG methods are generally applicable to several scenarios.
In considering wide applicability, this document provides the problem
statement and existing mechanisms in this area. Then gives general
requirements that are independent of any transport layer mechanism
and application, such as delivery properties, reliability and IMG
descriptions.
This document reflects investigating work on delivery mechanisms for
IMGs and generalizing work on session announcement and initiation
protocols, especially in the field of the MMUSIC working group (SAP,
SIP [5], SDP).
2 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [6].
Internet Media Guide (IMG): IMG is a generic term to describe
the formation, delivery and use of IMG metadata. The
definition of the IMG is intentionally left imprecise.
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
terms of large scale and atomic data transfers.
Y. Nomura et. al. [Page 4]
Internet Draft IMG Requirements December 2, 2003
IMG Sender: An IMG sender is a logical entity that sends IMGs to
one or more IMG receivers.
IMG Receiver: An IMG receiver is a logical entity that receives
IMGs from an IMG sender.
IMG Transceiver: An IMG transceiver combines an IMG receiver and
sender. It may modify original IMGs or merge several IMGs
from a different IMG sender.
IMG Operation: An atomic process for the IMG transport protocol
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
The MMUSIC working group has long been investigating content, media
and service information delivery mechanisms and protocols, and has
itself produces Session Announcement Protocol (SAP), Session
Description Protocol (SDP), and the Session Initiation Protocol
(SIP). SDP is capable of describing multimedia sessions (i.e.
content in a wider sense) by means of limited descriptive information
intended for human perception plus transport, scheduling information,
and codecs and addresses for setting up media sessions. SIP and SAP
are protocols to distribute these session descriptions.
HTTP is a well known data retrieval protocol using bi-directional
transport and widely used to deliver content descriptions to many
hosts.
However, we perceive a lack of standard solution for scalable IMG
delivery mechanism in the number of receivers with consistency of IMG
metadata between an IMG sender and IMG receiver for both bi-
directional and unidirectional transport. With increased service
dynamics and complexity, there is an increased requirement for
updates to these content descriptions.
Whenever an HTTP client requires updated content descriptions, the
client has to reload those using the same URL. For mass media, the
large number of users polling a server causes scalability and
congestion concerns and so the technique is feasible only if the
period between reloading is long and the amount of content
descriptions or the number of users is small. A well-behaved
implementation limits the timeliness of receiver-side updates for
mass audiences.
Y. Nomura et. al. [Page 5]
Internet Draft IMG Requirements December 2, 2003
The unicast equivalent of this is to maintain a unicast
connection/session between sender and receiver for the whole time a
receiver is interested in a service. This may be feasible in many
wire line systems for servers with only a few receivers, but both of
these become less attractive for both wireless links and large
numbers of sender-receiver connections, especially as both of these
share a resource (the radio bandwidth or the server resources) and
thus limit the number of receivers that can be served, without
additional infrastructure investment.
We also perceive a lack of standard solution for flexible content
descriptions to support a multitude of application-specific data
models with differing amount of detail and different target
audiences.
4 Requirements
4.1 General Requirements
4.1.1 Independence of IMG Operations from IMG Metadata
REQ GEN-1: Carrying different kinds of IMG metadata format 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 delivery protocol
suited to various scenarios.
4.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 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
Y. Nomura et. al. [Page 6]
Internet Draft IMG Requirements December 2, 2003
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
assumption that the range of IMG usage shall be important. However,
it may be noted that requirements of 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.
4.2.1 Scalability
REQ DEL-1: The system MUST be scalable in that it does not fail to
deliver 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 verbose IMG metadata that have been stored or deleted in IMG
receivers. Note, 'verbose' data is unneeded or unused detail or
repetitions.
REQ DEL-3: The protocol MUST be scalable to very large audience sizes
requiring IMG delivery.
4.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, allows hosts to wake up for short
periods of time and still be kept up-to-date. This can be beneficial
for receivers with sporadic connects to the fixed Internet, but is
critical in the battery-powered wireless Internet.
Y. Nomura et. al. [Page 7]
Internet Draft IMG Requirements December 2, 2003
4.2.3 Congestion Control
REQ DEL-5: Internet-friendly congestion control MUST be provided for
use on the public Internet.
For instance, notifications of updates (containing only minimal
change related data) can reduce congestion, especially for very large
groups, while allowing individual "congestion free" parts of the
Internet to do things "their way". Where some hosts are on
unidirectional links, and other have bi-directional links (or both),
this is sensible "diversity".
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 mechanism can reduce notifications of updates from the IMG
sender to receiver to invalidate the item. It may be beneficial for
congestion control.
4.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. This avoids keeping track of a
delivery state of every receiver.
In contrast, the receiver-driven delivery provides on-demand delivery
for IMG receivers. Since a 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 receiver).
4.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
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.
Y. Nomura et. al. [Page 8]
Internet Draft IMG Requirements December 2, 2003
This mechanism can reduce the amount of IMG metadata delivered from
the sender to receiver, and consequently it can save the resource
consumption on the IMG entities and networks. It is typically useful
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.
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 its joined channels). 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.
Customized metadata might be achieved by changing the IMG descriptors
sent and receivers and/or changing the delivery properties (channels
used).
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.
4.4 Reliability
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
(unsynchronized) or IMG sender and receiver can interact to keep
their copies of the IMG metadata synchronized.
In the unsynchronized model, the sender does not know whether a
particular receiver has an up-to-date copy of the IMG metadata.
In the synchronized model, updating 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
Y. Nomura et. al. [Page 9]
Internet Draft IMG Requirements December 2, 2003
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.
Depending on the size of the guide, the interested party may want to
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
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 a content and media is
more important immediately prior to and during the media's
session(s). Hosts which forward (or otherwise resend) metadata may be
less tolerant to inconsistencies as delivering out of date data is
both misleading and bandwidth inefficient.
By contrast, intermittent connectivity make immediate distribution of
changes infeasible and so managing data consistency should be focused
on the timely delivery of data.
4.4.2 Reliable Message Exchange
REQ REL-3: An IMG transport protocol MUST support reliable message
exchange.
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.
4.5 IMG Descriptions
REQ DES-1: IMG metadata MUST be interoperable over any IMG delivery
protocol, 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).
Y. Nomura et. al. [Page 10]
Internet Draft IMG Requirements December 2, 2003
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
different application-specific IMG metadata formats, is needed. The
payload of this transfer envelope would be some application-specific
metadata.
REQ DES-4: IMG metadata MUST be structured such that it is possible
to deliver only part of a sender's (and the global) complete IMG
metadata knowledge.
REQ DES-5: A 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 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
Y. Nomura et. al. [Page 11]
Internet Draft IMG Requirements December 2, 2003
Internet Media Guides are used to convey information about multimedia
resources from one or more senders across one or intermediaries to
one or more receivers. IMG metadata may be pushed to the receivers or
interactively retrieved by them. IMGs provide metadata as well as
scheduling and rendezvous information about multimedia resources,
etc. 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 forging information,
misdirecting users, spoofing senders, etc. and to protect user
privacy.
The remainder of section addresses the security requirements for
IMGs.
5.1 IMG Authentication and Integrity
IMG metadata and its parts need to be protected against unauthorized
altering/adding/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 had 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
Y. Nomura et. al. [Page 12]
Internet Draft IMG Requirements December 2, 2003
contents of an IMG operation (e.g. the subscription or inquiry
information).
5.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.
5.3 Access Control for IMGs
Some IMG metadata may be freely available, while access to other may
be restricted to closed user groups (e.g. paying subscribers). Also,
different parts of IMG metadata may be protected at different levels:
e.g. 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 sender.
REQ ACC-6: It SHOULD be possible for IMG transceiver to impose
different authorization requirements.
Y. Nomura et. al. [Page 13]
Internet Draft IMG Requirements December 2, 2003
REQ ACC-7: It MAY be possible for IMG senders to require certain
authorization that cannot be overridden by intermediaries.
5.4 Denial-of-Service attacks
Retrieving or distributing IMG metadata may require state in the
senders, transceivers, and/or receivers for the respective IMG
delivery 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 prevent 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.
5.5 Replay Attacks
IMG metadata disseminated by the sender or a transceiver may be
updated, 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 needs also be
prevented.
REQ REP-1: IMG metadata MUST be protected against partial or full
replacement of newer ("current") versions by older ones.
REQ REP-2: Mechanisms MUST be provided to mitigate replay attacks on
the IMG operations.
6 Acknowledgements
The authors would like to thank Hitoshi Asaeda, Petri Koskelainen,
Toni Paila and Dirk Kutscher for their comments and ideas on this
work.
7 Normative References
[1] M. Handley and V. Jacobson, ``SDP: session description protocol,''
RFC 2327, Internet Engineering Task Force, Apr. 1998.
[2] M. Handley, C. E. Perkins, and E. Whelan, ``Session announcement
Y. Nomura et. al. [Page 14]
Internet Draft IMG Requirements December 2, 2003
protocol,'' RFC 2974, Internet Engineering Task Force, Oct. 2000.
[5] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J.
Peterson, R. Sparks, M. Handley, and E. Schooler, ``SIP: session
initiation protocol,'' RFC 3261, Internet Engineering Task Force, June
2002.
[6] S. Bradner, ``Key words for use in RFCs to indicate requirement
levels,'' RFC 2119, Internet Engineering Task Force, Mar. 1997.
8 Informative References
[3] Session Directory, ftp://ftp.ee.lbl.gov/conferencing/sd/
[4] Session Directory Tool, http://www-
mice.cs.ucl.ac.uk/multimedia/software/sdr/
9 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
Universitaet Bremen
MZH 5180
Bibliothekstr. 1
D-28359 Bremen
Y. Nomura et. al. [Page 15]
Internet Draft IMG Requirements December 2, 2003
Germany
Email: jo@tzi.uni-bremen.de
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 (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.
Y. Nomura et. al. [Page 16]
