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-00.txt
September 10,
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.

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.2
   4.1.2      Multiple IMG Senders ................................    6
   4.3
   4.1.3      Modularity ..........................................    6
   4.4
   4.2        Delivery Properties .................................    6
   4.4.1    7
   4.2.1      Scalability .........................................    7
   4.4.2
   4.2.2      Support for Intermittent Connectivity ...............    7
   4.4.3
   4.2.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
   4.2.4      Sender and Receiver Driven .......................... Delivery .................    8
   4.3        Customized IMGs .....................................    8
   4.6
   4.4        Reliability .........................................    9
   4.6.1
   4.4.1      Managing consistency ................................    9
   4.6.2
   4.4.2      Reliable Message Exchange ...........................   10
   4.7
   4.5        IMG Descriptions ....................................   10
   5          Security Considerations .............................   10   11
   5.1        IMG Authentication and Integrity ....................   11   12
   5.2        Privacy .............................................   11   13
   5.3        Access Control for IMG ..............................   12 IMGs .............................   13
   5.4        Denial-of-Service attacks ...........................   12   14
   5.5        Replay Attacks ......................................   13   14
   6          Acknowledgements ....................................   13   14
   7          Normative References ................................   13   14
   8          Informative References ..............................   13   15
   9          Authors' Addresses ..................................   14   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] 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] (SAP) [2] and tools such as SD[3] 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 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
   IMGs 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 IMGs IMG
   metadata needs to be supported. Where no multicast is available,
   unicast-based push is required, too.  Furthermore, IMGs 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
   data 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 source 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 IMGs 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
   types of link layers, including bandwidth-constrained mobile
   networks.

   Finally, with many potential sources senders and sinks, different types of
   networks, and presumably numerous service providers, IMGs 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 an analysis
   of the problem space
   statement and existing mechanisms in this area. Then gives general
   requirements that are independent of any transport layer
   mechanism, existing protocol mechanism
   and application, such as performance,
   flexibility delivery properties, reliability and reliability. 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],
   SIP [5], SDP).

2 Terminology

   The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, "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 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 meta-data metadata describing the features
             of multimedia content used to enable selection of and
             access to media sessions containing content. For example,
             meta-data
             metadata may consist of the URI, title, air time, 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.

        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 source. 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 Operations: Operation: An atomic process for the IMG transport protocol
             to deliver IMG metadata or control the IMG sender sender(s) or IMG receiver.
             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 sence) 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.

   Also in the IETF,

   HTTP is a well known information 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.

   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
   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 preceive 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 be agnostic to 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.2

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 preclude a
   mechanism to solve inconsistency among IMG metadata due to multiple
   IMG senders.

4.3 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 Operations.

   This is for the purpose of extending functionality (e.g. several or
   one protocol(s) to provide all the needed operations).  Applications may
   can select an appropriate operation set to fulfill their purpose.

4.4

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.

   Example: It

   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.4.1

4.2.1 Scalability

   REQ DEL-1: The system MUST be scalable in that it does not fail to
   deliver up-
   to-date up-to-date information under huge numbers of transactions and
   massive quantities of IMG Metadata.

   An IMG system metadata.

   REQ DEL-2: IMGs SHOULD provide a method to prevent an IMG sender from
   sending verbose IMGs 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.4.2

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 may can be beneficial
   in
   for receivers with sporadic connects to the fixed-Internet, fixed Internet, but is
   critical in the battery-powered wireless Internet.

   In addition, some of the IMG senders and receivers may only

4.2.3 Congestion Control

   REQ DEL-5: Internet-friendly congestion control MUST 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 provided for
   use on 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. 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".

   When an IMG item has lifetime information, the

   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 without any IMG
   operations.
   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.5 Flexibility

4.5.1

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 may might send its preferences in the IMG operations
   which can specify user specific IMGs IMG metadata to be delivered. The These
   preferences might could consist of filtering rules. When receiving these
   messages, the IMG sender may might respond appropriate messages carrying
   a subset of IMGs IMG metadata which matches the receiver's preferences.

   This mechanism can reduce the amount of IMGs IMG metadata 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 IMG metadata to interested IMG receivers
   at the same time.

   In

   For multicast case or and unicast case cases where the IMG sender does not provide
   customized IMGs, IMG metadata, the IMG receiver may could receive all IMG data
   metadata transmitted (on its joined channels). However, it may select
   and filter the IMGs IMG metadata to get customized IMGs IMG metadata by its
   preferences, and thus drop unwanted metadata immediately upon
   reception.

4.5.2 Many Kinds of Multimedia Content

   The system MUST

   Customized metadata might be able to deliver a variety of media descriptions,
   which represents multimedia items available (e.g. achieved 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 changing the IMG sender descriptors
   sent and receiver.
   This avoids keeping track of a delivery state of every receiver.

   In contrast, receivers and/or changing the receiver-driven delivery provides on-demand delivery
   for IMG receivers. Since an IMG may contain a large amount of data,
   the IMG properties (channels
   used).

   Note, customization and scalability are only somewhat exclusive.
   Systems providing receiver needs to sender request-based customization,
   will be able generally less scalable to access 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 guide when convenient
   (e.g., when sufficient network bandwidth is available to intended application, and it may not be possible
   that a one-size-fits-all solution for customization would meet the
   receiver).

4.6
   scalability requirements for all applications and deployment cases.

4.4 Reliability

4.6.1

4.4.1 Managing consistency

   IMGs tend

   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 source sender does not know whether a
   particular receiver has an up-to-date copy of the IMG. 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
   receiver may need to confirm its consistency by IMG operations.

   REQ REL-2: Since IMGs 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 two IMG metadata stored in the an IMG receiver sender and IMG sender.
   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 session(s) duration (in time). 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
   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.

4.6.2

4.4.2 Reliable Message Exchange

   REQ REL-3: An IMG transport protocol MUST support reliable message
   exchange.

   The extent to which this will could result in 100 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.

4.7 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).

   REQ DES-2: IMG delivery MUST enable the carriage of any format of application-
   specific
   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 IMG shall IMGs will need to
   select one or more specific application-specific metadata formats
   (standard, syntax, etc.), the IMG system shall MUST be agnostic to 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 knowledge
   metadata knowledge.

   REQ DES-5: A transfer envelope MUST be defined to include parameters, from the data model, essential
   parameters.

   Examples of essential parameters are those that allow its
   payload the metadata in
   question to be uniquely identified and updated by new versions of the
   same payload. metadata.

   REQ DES-6: It SHALL be possible to deduce the payload metadata format from
   the transfer envelope.

   REQ DES-7: IMG senders SHALL use the transfer envelope for each IMG Metadata
   metadata transfer.

   Thus, it will even be possible to describe relationships between
   syntactically dissimilar application-
   specific 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 (This also relates the delivery property
   requirements for
   "Congestion Control". congestion control in Section 4.2.3).

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 IMG metadata may be pushed to the receivers or
   interactively retrieved by them. IMGs contain provide metadata as well as
   scheduling and rendezvous information about multimedia resources,
   etc. and requests for IMGs IMG metadata may contain information about the
   requesting users.

   The information contained in IMGs IMG metadata as well as the operations
   related to IMGs should be secured to avoid forging information,
   misdirecting users, spoofing sneders, senders, etc. and to protect user
   privacy.

   This

   The remainder of section addresses the security requirements for
   IMGs.

5.1 IMG Authentication and Integrity

   IMGs

   IMG metadata and their constituents its parts need to be protected against unauthorized
   altering/adding/deletion on the way. Their originator needs to be
   authenticated.

   R:

   REQ AUT-1: It MUST be possible to authenticate the originator of an IMG.

   R: a
   set of IMG metadata.

   REQ AUT-2: It MUST be possible to authenticate the originator of a
   subpart of
   an IMG metadata (e.g. a delta or a subset of the
   information).

   R:

   REQ AUT-3: It MUST be possible to validate the integrity of an IMG.

   R: IMG
   metadata.

   REQ AUT-4: It MUST be possible to validate the integrity of a subpart
   of an IMG metadata (e.g. a delta or a subset of the information).

   R:

   REQ AUT-5: It SHOULD MUST be possible to separate or combine individually
   authenticated pieces of an IMG metadata (e.g. in an IMG transceiver)
   without invalidating the authentication.

   R:

   REQ AUT-6: It SHOULD MUST be possible to validate the integrity of a an
   individually authenticated piece of an IMG metadata even after this
   piece had been separated from other pieces of an IMG metadata and
   combined with other pieces to form a new IMG.

   R: IMG metadata.

   REQ AUT-7: It MUST be possible to authenticate the originator of an
   IMG
   related primitive.

   R: operation.

   REQ AUT-8: It MUST be possible to validate the integrity of any
   contents of an IMG related primitive operation (e.g. the subscription or inquiry
   information).

5.2 Privacy

   Customized IMGs IMG metadata and IMGs 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.

   R:

   REQ PRI-1: It MUST be possible to keep user requests to subscribe to
   or retrieve certain (parts of) IMGs IMG metadata confidential.

   R:

   REQ PRI-2: It MUST be possible to keep IMGs, IMG metadata, pieces of IMGs, IMG
   metadata, or pointers to
   IMGs IMG metadata delivered to individual users
   or groups of users confidential.

   R:

   REQ PRI-3: It SHOULD be possible to ensure this confidentiality end-to-end, 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

   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 an 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.

   R:

   REQ ACC-1: It MUST be possible to authorize user access to IMGs.

   R: IMG
   metadata.

   REQ ACC-2: It MUST be possible to authorize access of users to pieces
   of IMGs IMG metadata (delta information, subparts, pointers).

   R:

   REQ ACC-3: It MUST be possible to require different authorization for
   different parts of the same IMG.

   R: IMG metadata.

   REQ ACC-4: It MUST be possible to access selected IMGs IMG metadata
   anonymously.

   R:

   REQ ACC-5: It MUST be possbile possible for an IMG receiver to choose not to
   receive (parts of) an IMG metadata in order to avoid authentication being identified by
   the source.

   R: sender.

   REQ ACC-6: It SHOULD be possible for IMG transceiver to impose
   different authorization requirements.

   R:

   REQ ACC-7: It MAY be possible for IMG originators senders to require certain
   authorization that cannot be overridden by intermediaries.

5.4 Denial-of-Service attacks

   Retrieving or distributing IMGs 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.

   R:

   REQ DOS-1: IMG operations SHOULD be authenticated.

   R:

   REQ DOS-2: It SHOULD be possible to prevent DoS attacks that build up
   session state in IMG components entities to exhaust their resources.

   R:

   REQ DOS-3: It SHOULD be possible to avoid DoS attachs attacks that exhaust
   resources of IMG components entities by flooding them with IMG content. metadata.

5.5 Replay Attacks

   IMGs dissiminated

   IMG metadata disseminated by the source sender or a transceiver may be
   updated, deleted, or lose validity over time for some other reasons.
   Replaying outdated IMGs 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.

   R: IMGs

   REQ REP-1: IMG metadata MUST be protected against partial or full
   replacement of newer ("current") versions by older ones.

   R:

   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, Juka-Pekka Luoma , Petri Koskelainen,
   Toni Paila and Dirk Kutscher for thier their comments and ideas on
   the draft. 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
   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 Corporation 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: rod,walsh@nokia.com juha-pekka.luoma@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
   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.