Internet Engineering Task Force
Internet Draft Y. Nomura
Fujitsu Labs.
R. Walsh
Nokia
J. Ott
Universitaet Bremen
H. Schulzrinne
Columbia University
draft-ietf-mmusic-img-req-00.txt
September 10, 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 September 10, 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 Independence of IMG Operations from IMG Metadata .... 6
4.2 Multiple IMG Senders ................................ 6
4.3 Modularity .......................................... 6
4.4 Delivery Properties ................................. 6
4.4.1 Scalability ......................................... 7
4.4.2 Support for Intermittent Connectivity ............... 7
4.4.3 Congestion Control .................................. 7
4.5 Flexibility ......................................... 8
4.5.1 Customized IMGs ..................................... 8
4.5.2 Many Kinds of Multimedia Content .................... 8
4.5.3 Sender and Receiver Driven .......................... 8
4.6 Reliability ......................................... 9
4.6.1 Managing consistency ................................ 9
4.6.2 Reliable Message Exchange ........................... 10
4.7 IMG Descriptions .................................... 10
5 Security Considerations ............................. 10
5.1 IMG Authentication and Integrity .................... 11
5.2 Privacy ............................................. 11
5.3 Access Control for IMG .............................. 12
5.4 Denial-of-Service attacks ........................... 12
5.5 Replay Attacks ...................................... 13
6 Acknowledgements .................................... 13
7 Normative References ................................ 13
8 Informative References .............................. 13
9 Authors' Addresses .................................. 14
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
Y. Nomura et. al. [Page 2]
Internet Draft IMG Requirements September 10, 2003
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.
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 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
IMGs in various different ways is needed to accommodate the needs of
different audiences: For traditional broadcast-style scenarios,
multicast-based (push) distribution of IMGs needs to be supported.
Where no multicast is available, unicast-based push is required, too.
Furthermore, IMGs 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
data 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 source 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 IMGs can be sent and received by, among others, by
cellular phones, PDA (Personal Digital Assistant), personal computer,
Y. Nomura et. al. [Page 3]
Internet Draft IMG Requirements September 10, 2003
streaming video server, set-top box, video camera, and PVR (Personal
Video Recorder) and that they be carried across arbitrary types of
link layers, including bandwidth-constrained mobile networks.
Finally, with many potential sources and sinks, different types of
networks, and presumably numerous service providers, IMGs 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 an analysis
of the problem space and existing mechanisms in this area. Then gives
general requirements that are independent of any transport layer
mechanism, existing protocol and application, such as performance,
flexibility and reliability.
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): An IMG is a set of meta-data
describing the features of multimedia content. For example,
meta-data may consist of the URI, title, air time,
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.
IMG Sender: An IMG sender is a logical entity that sends IMGs to
one or more IMG receivers.
Y. Nomura et. al. [Page 4]
Internet Draft IMG Requirements September 10, 2003
IMG Receiver: An IMG receiver is a logical entity that receives
IMGs from an IMG source.
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 Operations: An atomic process for the IMG protocol to
deliver IMG or control the IMG sender or IMG receiver.
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 sence) 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.
Also in the IETF, HTTP is a well known information 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
between an IMG sender and IMG receiver for both bi- 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.
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
wireline 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
Y. Nomura et. al. [Page 5]
Internet Draft IMG Requirements September 10, 2003
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 preceive 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 Independence of IMG Operations from IMG Metadata
Carrying different kinds of IMG metadata format in the IMG message
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
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.
4.3 Modularity
The IMG delivery mechanisms MUST allow the combination of several IMG
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
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.
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
Y. Nomura et. al. [Page 6]
Internet Draft IMG Requirements September 10, 2003
this sense, scalability is always important for the protocols
irrespective of transport mechanisms.
4.4.1 Scalability
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.
An IMG system SHOULD provide a method to prevent an IMG sender from
sending verbose IMGs that have been stored or deleted in IMG
receivers. Note, 'verbose' data is unneeded or unused detail or
repetitions.
The protocol MUST be scalable to very large audience sizes requiring
IMG delivery.
4.4.2 Support for Intermittent Connectivity
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 may be beneficial
in the fixed-Internet, but is critical in the battery-powered
wireless Internet.
In addition, some of the IMG senders and receivers may only be
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
Internet-friendly congestion control MUST be provided. 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".
Y. Nomura et. al. [Page 7]
Internet Draft IMG Requirements September 10, 2003
When an IMG item has lifetime information, the IMG entity SHOULD
invalidate the IMG item when its lifetime is over without any IMG
operations. 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 Flexibility
4.5.1 Customized IMGs
The system MUST allow delivery of customized IMG metadata. The IMG
receiver may require a subset of the IMG according to their
preferences (type of content, media description, appropriate age
group, etc.) and configuration.
The IMG receiver may send its preferences in the IMG operations which
can specify user specific IMGs to be delivered. The preferences might
consist of filtering rules. When receiving these messages, the IMG
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
sender to receiver, and consequently it can save the resource
consumption on the IMG entities and IMG networks. It is typically
useful in unicast case and also beneficial in multicast case where
IMG sender distributes the same IMGs to interested IMG receivers at
the same time.
In multicast case or unicast case where the IMG sender does not
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
The system MUST be able to deliver a variety of media descriptions,
which represents multimedia items available (e.g. by download,
streaming or multicast distribution.) This is essential for the
system to support many kinds of multimedia content and to achieve
wide applicability.
4.5.3 Sender and Receiver Driven
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.
Y. Nomura et. al. [Page 8]
Internet Draft IMG Requirements September 10, 2003
In contrast, the receiver-driven delivery provides on-demand delivery
for IMG receivers. Since an IMG may contain a 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.6 Reliability
4.6.1 Managing consistency
IMGs tend to change as time elapses, as new content is added, the old
IMG stored in the IMG receiver becomes unavailable and the parameters
of the existing IMG are changed.
The IMG sender can either simply make updates available
(unsynchronized) or IMG sender and receiver can interact to keep
their copies of the IMG synchronized.
In the unsynchronized model, the source does not know whether a
particular receiver has an up-to-date copy of the IMG.
In the synchronized model, updating cached copy of the IMG 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.
Since IMGs 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 two IMG metadata stored in the IMG receiver and
IMG sender.
In general, the consistency of metadata is more important immediately
prior to and during the media session(s) duration (in time). Hosts
which forward (or otherwise resend) metadata may be less tolerant to
inconsistencies as delivering out of date data is both misleading and
is 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.
Y. Nomura et. al. [Page 9]
Internet Draft IMG Requirements September 10, 2003
4.6.2 Reliable Message Exchange
IMG transport MUST support reliable message exchange. The extent to
which this will result in 100 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.
4.7 IMG Descriptions
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).
IMG delivery MUST enable the carriage of any format of application-
specific metadata. Whereas specific applications relying on IMG shall
need to select one or more specific application-specific metadata
formats (standard, syntax, etc.), the IMG system shall be agnostic to
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.
IMG metadata MUST be structured such that it is possible to deliver
only part of a sender's (and the global) complete IMG knowledge MUST
be defined to include parameters, from the data model, that allow its
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
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".
5 Security Considerations
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. IMGs may be pushed to the receivers or
Y. Nomura et. al. [Page 10]
Internet Draft IMG Requirements September 10, 2003
interactively retrieved by them. IMGs contain metadata as well as
scheduling and rendezvous information about multimedia resources,
etc. and requests for IMGs may contain information about the
requesting users.
The information contained in IMGs as well as the operations related
to IMGs should be secured to avoid forging information, misdirecting
users, spoofing sneders, etc. and to protect user privacy.
This section addresses the security requirements for IMGs.
5.1 IMG Authentication and Integrity
IMGs and their constituents need to be protected against unauthorized
altering/adding/deletion on the way. Their originator needs to be
authenticated.
R: It MUST be possible to authenticate the originator of an IMG.
R: It MUST be possible to authenticate the originator of a subpart of
an IMG (e.g. a delta or a subset of the information).
R: It MUST be possible to validate the integrity of an IMG.
R: It MUST be possible to validate the integrity of a subpart of an
IMG (e.g. a delta or a subset of the information).
R: It SHOULD be possible to separate or combine individually
authenticated pieces of an IMG (e.g. in an IMG transceiver) without
invalidating the authentication.
R: It SHOULD be possible to validate the integrity of a piece of an
IMG even after this piece had been separated from other pieces of an
IMG and combined with other pieces to form a new IMG.
R: It MUST be possible to authenticate the originator of an IMG
related primitive.
R: It MUST be possible to validate the integrity of any contents of
an IMG related primitive (e.g. the subscription or inquiry
information).
5.2 Privacy
Customized IMGs and IMGs 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.
Y. Nomura et. al. [Page 11]
Internet Draft IMG Requirements September 10, 2003
R: It MUST be possible to keep user requests to subscribe to or
retrieve certain (parts of) IMGs confidential.
R: It MUST be possible to keep IMGs, pieces of IMGs, or pointers to
IMGs delivered to individual users or groups of users confidential.
R: 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 IMG
Some IMGs may be freely available, while access to other may be
restricted to closed user groups (e.g. paying subscribers). Also,
different parts of an IMG 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.
R: It MUST be possible to authorize user access to IMGs.
R: It MUST be possible to authorize access of users to pieces of IMGs
(delta information, subparts, pointers).
R: It MUST be possible to require different authorization for
different parts of the same IMG.
R: It MUST be possible to access selected IMGs anonymously.
R: It MUST be possbile for an IMG receiver to choose not to receive
(parts of) an IMG in order to avoid authentication by the source.
R: It SHOULD be possible for IMG transceiver to impose different
authorization requirements.
R: It MAY be possible for IMG originators to require certain
authorization that cannot be overridden by intermediaries.
5.4 Denial-of-Service attacks
Retrieving or distributing IMGs 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.
R: IMG operations SHOULD be authenticated.
R: It SHOULD be possible to prevent DoS attacks that build up session
Y. Nomura et. al. [Page 12]
Internet Draft IMG Requirements September 10, 2003
state in IMG components to exhaust their resources.
R: It SHOULD be possible to avoid DoS attachs that exhaust resources
of IMG components by flooding them with IMG content.
5.5 Replay Attacks
IMGs dissiminated by the source or a transceiver may be updated,
deleted, or lose validity over time for some other reasons.
Replaying outdated IMGs needs to be prevented.
Furthermore, replay attacks may also apply to IMG operations (rather
than just their payload). Replaying operations needs also be
prevented.
R: IMGs MUST be protected against partial or full replacement of
newer ("current") versions by older ones.
R: Mechanisms MUST be provided to mitigate replay attacks on the IMG
operations.
6 Acknowledgements
The authors would like to thank Hitoshi Asaeda, Juka-Pekka Luoma ,
Petri Koskelainen, Toni Paila and Dirk Kutscher for thier comments on
the draft.
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
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
Y. Nomura et. al. [Page 13]
Internet Draft IMG Requirements September 10, 2003
[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 Corporation
Nokia Research Center
P.O. Box 100, FIN-33721 Tampere
Finland
Email: rod,walsh@nokia.com
Joerg Ott <jo@tzi.org>
Universitaet Bremen
MZH 5180
Bibliothekstr. 1
D-28359 Bremen
Germany
tel:+49-421-201-7028
sip:jo@tzi.org
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
Y. Nomura et. al. [Page 14]
Internet Draft IMG Requirements September 10, 2003
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 15]
