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-02.txt December 22,draft-ietf-mmusic-img-req-03.txt February 16, 2003 Expires: JuneJuly 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 ........................................ 23 1.1 Background and Motivation ........................... 3 1.2 Scope of This Document .............................. 4 2 Terminology ......................................... 45 3 Problem Statement ................................... 56 4 Use Cases Requiring IMGs ............................ 67 4.1 Connectivity-based Use Cases ........................ 67 4.1.1 IP Datacast to a Wireless Receiver .................. 7 4.1.2 Regular Fixed Dial-up Internet Connection ........... 8 4.1.3 Broadband Always-on Fixed Internet Connection ....... 8 4.2 Content-orientated Use Cases ........................ 8 4.2.1 File Distribution ...................................9 220.127.116.11.1 TV and Radio Program Delivery ....................... 9 18.104.22.168.2 Media Coverage of a Live Event ...................... 10 4.2.49 4.2.3 Distance Learning ................................... 10 22.214.171.124.4 Multiplayer Gaming .................................. 10 4.2.5 File Distribution ................................... 10 4.2.6 Coming-release and Pre-released Content ............. 11 5 Requirements ........................................ 1011 5.1 General Requirements ................................ 1011 5.1.1 Independence of IMG Operations from IMG Metadata 5.1.2 Multiple IMG Senders ................................ 11 5.1.3 Modularity .......................................... 11 5.2 Delivery Properties ................................. 1112 5.2.1 Scalability ......................................... 1112 5.2.2 Support for Intermittent Connectivity ............... 12 5.2.3 Congestion Control .................................. 1213 5.2.4 Sender and Receiver Driven Delivery ................. 1213 5.3 Customized IMGs ..................................... 13 5.4 Reliability ......................................... 1314 5.4.1 Managing consistency ................................ 14 5.4.2 Reliable Message Exchange ........................... 1415 5.5 IMG Descriptions .................................... 15 6 Security Considerations ............................. 16 6.1 IMG Authentication and Integrity .................... 1617 6.2 Privacy ............................................. 1718 6.3 Access Control for IMGs ............................. 1718 6.4 Denial-of-Service attacks ........................... 1819 6.5 Replay Attacks ...................................... 1819 7 Acknowledgements ....................................IANA Considerations ................................. 19 8 Normative References ................................ 19 9 Informative References .............................. 1920 10 Acknowledgements .................................... 20 11 Authors' Addresses .................................. 20 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  as a rudimentary (but as of then largely sufficient) means. Dissemination of the descriptions has been performed using the Session Announcement Protocol (SAP)  and tools such as SD  or SDR ;; 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) ishas a structured collection of multimedia session descriptions expressed using SDP, SDPng or some similar session description format. ItThis 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 anIMGs provide the 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.this information. 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 sender as well as by asynchronous change notifications. Furthermore, we assume thatany Internet host can be a sender of content and thus an IMG.IMG sender. 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 (PersonalDVR (Digital Video Recorder) and that they be carried across arbitrary types of link layers, including bandwidth-constrained mobile networks. However, generally we expect IMG Senders to be well connected hosts. Finally, with many potential senders and sinks,receivers, 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 metadata to a potentially large audience. Since the IMGIMGs 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 several use case scenarios for IMGs are explained including descriptions of how IMG metadata and IMG delivery mechanisms contribute to these scenarios. Following this, this document provides 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 ,, 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 .. 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 Element: The smallest atomic element of metadata that can be transmitted separately by IMG operations and referenced individually from other IMG elements. IMG Metadata: A set of metadata consisting of one or more IMG elements. IMG metadata describes 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. IMG Sender: An IMG sender is a logical entity that sends IMG metadata to one or more IMG receivers. IMG Receiver: An IMG receiver is a logical entity that receives IMG metadata from an IMG sender. IMG Transceiver: An IMG transceiver combines an IMG receiver and sender. It may modify received IMG metadata or merge IMG metadata received from a several different IMG senders. IMG Operation: An atomic operation of an IMG transport protocol, used between IMG sender(s) and IMG receiver(s) for the delivery of IMG metadata and for the control of IMG sender(s)/receiver(s). IMG Transport Protocol: A protocol that transports IMG metadata from an IMG sender to IMG receiver(s). IMG Transport Session: An association between an IMG sender and one or more IMG receivers within the scope of an IMG transport protocol. An IMG transport session involves a series of IMG transport protocol interactions that provide delivery of IMG metadata from the IMG sender to the IMG receiver(s). 3 Problem Statement As we enumerate the requirements for an IMG, it will become clear that they are not fully addressed by the existing protocols. The Framework for the Usage of Internet Media Guides  talks about these issues in more detail. 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 anHTTP client requires updated is a well known information retrieval protocol using bi- directional transport and widely used to deliver web-based content descriptions, the client hasdescriptions to reload those using the same URL. For mass media,many hosts. However, it has well recognized limitations of scalability in the largenumber of usersHTTP clients since it relies on the polling amechanism to keep information consistent between the server causes scalability and congestion concernsand so the technique is feasible only if the period between reloadingclient. SAP  is longan announcement protocol that distributes session descriptions via multicast. It does not support fine-grained metadata selection and update notifications, as it always sends the amount of content descriptions orwhole metadata. Given the numberlack 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 maintaina unicast connection/session between sender and receiver for the whole time a receiverwide-area multicast infrastructure, it is interested in a service. This may be feasible in many wire line systems for servers withlikely only deployable within a few receivers, but both of these become less attractive for both wireless linkslocal area network. SIP  and large numbers of sender-receiver connections, especially as bothSIP-specific event notification  can be used to notify subscribers of these share a resource (the radio bandwidth or the server resources) and thus limitthe numberupdate of receivers that can be served, without additional infrastructure investment.IMG metadata for bi-directional transport. However, it is necessary for SIP Event to define an event package as a standard protocol for each specific application including IMGs. 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. SDP  has a text-encoded syntax to specify multimedia sessions for announcements and invitations. Although SDP is extensible, it has limitations such as structured extensibility and capability to reference properties of a multimedia session from the description of another session. These are mostly overcome by the XML-based SDPng , which is intended for both two-way negotiation and also unidirectional delivery. Since SDPng addresses multiparty multimedia conferences, it is necessary to extend the XML schema in order to describe general multimedia content. 4 Use Cases Requiring IMGs 4.1 Connectivity-based Use Cases 4.1.1 IP Datacast to a Wireless Receiver IP Datacast is the delivery of IP-based services over broadcast radio. Internet content delivery is therefore unidirectional in this case. However, there can be significant benefits from being able to provide rich media one-to-many services to such receivers. There are two main classes of receiver in this use case: fixed mains-powered; and mobile battery-powered. Both of these are affected by radio phenomena and so robust, or error-resilient, delivery is important. Carouselled metadata transfer provides a base level of robustness for an IP datacast based announcement system, although the design of carouselled transfer should enable battery-powered receivers to go through periods of sleep to extend their operational time between charges. Insertion of Forward Error Correction (FEC) data into metadata announcements improves error resilience, and reordering (interleaving) data blocks further increases tolerance to burst errors. To enable receivers to more accurately specify the metadata they are interested in, the unidirectional delivery is distributed between several logical channels. This is so that a receiver need only access the channels of interest and thus can reduce the amount of time, storage and CPU resources needed for processing the IP data. Also, hierarchical channels enable receivers to subscribe to a root, possibly well known, multicast channel/group and progressively access only those additional channels based on metadata in parent channels. In some cases the receiver may be multi-access, such that it is capable of bi-directional communications. This enables a multitude of options, but most importantly it enables NACK based reliability and the individual retrieval of missed or not-multicasted sets of metadata. Thus, essential IMG features in this case include: robust unidirectional delivery (with optional levels of reliability including "plug-in FEC") which implies easily identifiable segmentation of delivery data to enable FEC, carousel, interleaving and other schemes possible; effective identification of metadata sets (probably uniquely) to enable more efficient use of multicast and unicast retrieval over multiple access systems regardless of the parts of metadata and application specific extensions in use; prioritization of metadata, which can (for instance) be achieved by spreading it between channels and allocating/distributing bandwidth accordingly. Furthermore, some cases require IMG metadata authentication and some group security/encryption and supporting security message exchanges (out of band from the IMG multicast sessions). 4.1.2 Regular Fixed Dial-up Internet Connection Dial-up connections tend to be reasonably slow (<56kbps in any case) and thus large data transfers are less feasible, especially during an active application session (such as a file transfer described by IMG metadata). They can also be intermittent, especially if a user is paying for the connected time, or connected through a less reliable exchange. Thus this favors locally stored IMG metadata over web-based browsing, especially where parts of the metadata change infrequently. There may be no service provider preference over unicast and multicast transport for small and medium numbers of users as the last-mile dial-up connection limits per-user congestion, and a user may prefer the more reliable option (unicast unless reliable multicast is provided). 4.1.3 Broadband Always-on Fixed Internet Connection Typically bandwidth is less of an issue to a broadband user and unicast transport, such as using IMG QUERY, may be typical for a PC user. If a system were only used in this context, with content providers, ISPs and users having no other requirements, then web- based browsing may be equally suitable. However, broadband users sharing a local area network, especially wireless, may benefit more from local storage features than on-line browsing, especially if they have intermittent Internet access. Broadband enables rich media services, which are increasingly bandwidth hungry. Thus backbone operators may prefer multicast communications to reduce overall congestion, if they have the equipment and configuration to support this. Thus, broadband users may be forced to retrieve IMG metadata over multicast if the respective operators require this to keep system-wide bandwidth usage feasible. 4.2 Content-orientated Use Cases IMGs will be able to support a very wide range of use cases for content/media delivery. The following few sections just touch the surface of what is possible and are intended to provide an understanding of the scope and type of IMG usage. Many more examples may be relevant, for instance those detailed in .. There are several unique features of IMGs that set them apart from related application areas such as SLP based service location discovery, LDAP based indexing services and search engines such as Google. Features unique to IMGs include: o IMG metadata is generally time-related o There are timeliness requirements in the delivery of IMG metadata o IMG metadata may be updated as time elapses or when an event arises 4.2.1 File Distribution IMGs support the communicationTV and Radio Program Delivery A sender of file delivery session properties, enablingaudio/video streaming content can use the scheduled delivery or synchronization of files between a numberIMG metadata to describe the scheduling and other properties of hosts. The receivedaudio/video sessions and events within those sessions, such as individual TV and radio programs and segments within those programs. IMG metadata could be subsequently used by any application (also outside the scope of IMGs), for example to download a file with a software update. IMG metadata can provide a description to each file in a file delivery session, assisting users or receiving software in selecting individual files for reception. For example, when a content provider wants to distribute a large amount of data in file format to thousands clients, the content provider can use IMG metadata to schedule the delivery effectively. Since IMG metadata can describe time-related data for each receiver, the content provider can schedule delivery time for each receiver. This can save network bandwidth and delivery capacity of senders. In addition, IMG metadata can be used to synchronize a set of files between a sender host and receiver host, when those files change as time elapses. 4.2.2 TV and Radio Program Delivery A sender of audio/video streaming content can use the IMG metadata to describe the scheduling and other properties of audio/video sessions and events within those sessions, such as individual TV and radio programs and segments within those programs. IMG metadata describing audio/video streaming contentdescribing audio/video streaming content could be represented in a format similar to that of a TV guide in newspapers, or an Electronic Program Guide available on digital TV receivers. Similarly to file reception, TV and radio programs can be selected for reception either manually by the end-user or automatically based on the content descriptions and the preferences of the user. The received TV and radio content can be either presented in real time or recorded for consuming later. There may be changes in the scheduling of a TV or a radio program, possibly affecting the transmission times of subsequent programs. IMG metadata can be used to notify receivers of such changes, enabling users to be prompted or recording times to be adjusted. 126.96.36.199.2 Media Coverage of a Live Event The media coverage of a live event such as a rock concert or a sports event is a special case of regular TV/radio programming. There may be unexpected changes in the scheduling of live event, or the event may be unscheduled to start with (such as breaking news). In addition to audio/video streams, textual information relevant to the event (e.g. statistics of the players during a football match) may be sent to user terminals. Different transport modes or even different access technologies can be used for the different media: for example, a unidirectional datacast transport could be used for the audio/video streams and an interactive cellular connection for the textual data. IMG metadata should enable terminals to discover the availability of different media used to cover a live event. 188.8.131.52.3 Distance Learning IMG metadata could describe compound sessions or services enabling several alternative interaction modes between the participants. For example, the combination of one-to-many media streaming, unicast messaging and download of presentation material could be useful for distance learning. 184.108.40.206.4 Multiplayer Gaming Multiplayer games are an example of real-time multiparty communication sessions that could be advertised using IMGs. A gaming session could be advertised either by a dedicated server, or by the terminals of individual users. A user could use IMGs to learn of active multiplayer gaming sessions, or advertise the users interest in establishing such a session. 5 Requirements 5.1 General Requirements 5.1.1 Independence4.2.5 File Distribution IMGs support the communication of IMG Operations from IMG Metadata REQ GEN-1: Carrying different kindsfile delivery session properties, enabling the scheduled delivery or synchronization of files between a number of hosts. The received IMG metadata format in the IMG message body MUSTcould be allowed. REQ GEN-2: Delivery mechanisms SHOULD support many different applications specific metadata formats to keepsubsequently used by any application (also outside the system interoperable withscope of IMGs), for example to download a file with a software update. IMG metadata can provide a description to each file in a file delivery session, assisting users or receiving software in selecting individual files for reception. For example, when a content provider wants to distribute a large amount of data in file format to thousands clients, the content provider can use IMG metadata to schedule the delivery effectively. Since IMG metadata can describe time-related data for each receiver, the content provider can schedule delivery time for each receiver. This can save network bandwidth and delivery capacity of senders. In addition, IMG metadata can be used to synchronize a set of files between a sender host and receiver host, when those files change as time elapses. 4.2.6 Coming-release and Pre-released Content IMG metadata can be used to describe items of content before the details of their final release are known. A user may be interested in coming content (a new movie or software title where some aspects of the content description are known in advance) and so subscribe to an information service which notifies the user of changes to metadata describing that content. Thus, as the coming release, or pre-releases (such as movie trailers or software demos), become available the IMG metadata changes and the user is notified of this change. For example, the user could see an announcement of a movie that will be released sometime in the next few months, and configure the user's terminal to receive and record any trailers or promotional material as they become available. 5 Requirements 5.1 General Requirements 5.1.1 Independence of IMG Operations from IMG Metadata REQ GEN-1: Carrying different kinds of IMG metadata format 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 IMG transport protocol suited to various scenarios. 5.1.2 Multiple IMG Senders REQ GEN-3: IMG receivers MUST be allowed to communicate with any number of IMG senders simultaneously. This might lead to receiving redundant IMG metadata describing the same items, however it enables the IMG receiver access to more IMG metadata than may be available from a single IMG sender. This also provides flexibility for the IMG transport protocols and does not preclude a mechanism to solve inconsistency among IMG metadata due to multiple IMG senders. This document assumes a typical IMG environment will involve many more IMG receivers than IMG senders and that IMG senders are continually connected for the duration of interest (rather than intermittently connected). 5.1.3 Modularity REQ GEN-4: The IMG delivery mechanisms MUST allow the combination of several IMG Operations. This is for the purpose of extending functionality (e.g. several or one protocol(s) to provide all the needed operations). Applications can select an appropriate operation set to fulfill their purpose. 5.2 Delivery Properties This section describes general performance requirements based on the assumption that the range of IMG usage shall be important. However, 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. 5.2.1 Scalability REQ DEL-1: The system MUST be scalable into large numbers of messages, so 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 verboseunnecessary 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. 5.2.2 Support for Intermittent Connectivity REQ DEL-4: The system MUST enable IMG receivers with intermittent access to network resources (connectivity) to receive and adequately maintain sufficient IMG metadata. This allows intermittent access to save power where there is no need to keep communications links powered-up while they are sitting idle. For instance, in this situation periodic bursts of notifies, or a fast cycling update carousel, allows hosts to wake up for short periods of time and still be kept up-to-date. This can be beneficial for IMG receivers with sporadic connects to the fixed Internet, but is critical in the battery-powered wireless Internet. 5.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 reducewill lessen the need for notifications of updates from the IMG sender to the IMG receiver to invalidate the item. Ititem and may be beneficial for congestion control.enable lesser congestion. 5.2.4 Sender and Receiver Driven Delivery REQ DEL-7: The system MUST be flexible in choosing sender-driven, receiver-driven or both delivery schemes. Sender-driven delivery achieves high scalability without interaction between the IMG sender and receiver. This avoids keeping track of a delivery state of every IMG receiver. In contrast, the receiver-driven delivery provides on-demand delivery for IMG receivers. Since an IMG sender's complete IMG metadata may be a very large amount of data, the IMG receiver needs to be able to access the guide when convenient (e.g., when sufficient network bandwidth is available to the IMG receiver). 5.3 Customized IMGs REQ CUS-1: The system MUST allow delivery of customized IMG metadata. The IMG receiver may require a subset of all the IMG metadata available according to their preferences (type of content, media description, appropriate age group, etc.) and configuration. The IMG receiver might send its preferences in the IMG operations 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 IMG receiver's preferences. This mechanism can reduce the amount of IMG metadata delivered from the IMG sender to IMG receiver, and consequently it can save the resource consumption on the IMG entities and networks. It is typically useful in unicast 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 descriptions sent and IMG receivers and/or changing the delivery properties (channels used). Note, customization and scalability are only somewhat exclusive. Systems providing an IMG receiver to an IMG sender request-based customization, will be generally less scalable to massive IMG receiver populations than those without this return signaling technique. Thus, customization, as with any feature which affects scalability, should be carefully designed for the intended application, and it may not be possible that a one-size-fits-all solution for customization would meet the scalability requirements for all applications and deployment cases. 5.4 Reliability 5.4.1 Managing consistency IMG metadata tends to change as time elapses, as new content is added, the old IMG metadata stored in the IMG receiver becomes unavailable and the parameters of the existing IMG metadata are changed. REQ REL-1: The system MUST manage IMG metadata consistency. 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 IMG sender does not know whether a particular IMG receiver has an up-to-date copy of the IMG metadata. In the synchronized model, updating cached copy of the IMG metadata is necessary to control consistency when the IMG sender or receiver could not communicate for a while. In this case, the IMG sender or receiver may need to confirm its consistency by IMG operations. REQ REL-2: Since IMG metadata can change at any time, IMG receivers SHOULD be notified of such changes. 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. 5.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 IMG receivers is a statistical characteristic of the protocols used. Usage of reliable IMG delivery mechanisms is expected to depend on the extent to which underlying networks provide reliability and, conversely, introduce errors. Note, some deployments of IMG transport protocols may not aim to provide perfect reception to all IMG receivers in all possible cases. 5.5 IMG Descriptions REQ DES-1: IMG metadata MUST be interoperable over any IMG transport protocol, such that an application receiving the same metadata over any one (or more) of several network connections and/or IMG transport protocols will interpret the metadata in exactly the same way. (This also relates to the 'Independence of IMG Operations from IMG Metadata' requirement). REQ DES-2: IMG delivery MUST enable the carriage of any format of application-specific metadata. Thus, the system will support the description of many kinds of multimedia content, without the need for a single homogenous metadata syntax for all uses (which would be infeasible anyway). This is essential for environments using IMG systems to support many kinds of multimedia content and to achieve wide applicability. REQ DES-3: Whereas specific applications relying on IMGs will need to select one or more specific application-specific metadata formats (standard, syntax, etc.), the IMG system MUST be independent of this (it may be aware, but it will operate in the same way for all). Thus, a transfer envelope format, that is uniform across all different application-specific IMG metadata formats, is needed. The payload of this transfer envelope would be some application-specific metadata.metadata, and the envelope would support the maintenance of the application-specific metadata including the metadata relationships determined by the data model(s) used. The transfer envelope would not need to be aware of the data model(s) in use. REQ DES-4: IMG metadata MUST be structured such that it is possible to deliver only part of an IMG 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 5.2.3). 6 Security Considerations Internet Media Guides are used to convey information about multimedia resources from one or more IMG senders across one or intermediaries to one or more IMG receivers. IMG metadata may be pushed to the IMG receivers or interactively retrieved by them. IMGs provide metadata as well as scheduling and rendezvous information about multimedia resources, 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 IMG senders, etc. and to protect user privacy. The remainder of section addresses the security requirements for IMGs. 6.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 contents of an IMG operation (e.g. the subscription or inquiry information). 6.2 Privacy Customized IMG metadata and IMG metadata delivered by notification to individual users may reveal information about the habits and preferences of a user and may thus deserve confidentiality protection, even though the information itself is public. REQ PRI-1: It MUST be possible to keep user requests to subscribe to or retrieve certain (parts of) IMG metadata confidential. REQ PRI-2: It MUST be possible to keep IMG metadata, pieces of IMG metadata, or pointers to IMG metadata delivered to individual users or groups of users confidential. REQ PRI-3: It SHOULD be possible to ensure this confidentiality end- to-end, that is, to prevent intermediaries (such as IMG transceivers) from accessing the contained information. 6.3 Access Control for IMGs Some IMG metadata may be freely available, while access to other 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 IMG sender. REQ ACC-6: It SHOULD be possible for IMG transceiver to impose different authorization requirements. REQ ACC-7: It MAY be possible for IMG senders to require certain authorization that cannot be overridden by intermediaries. 6.4 Denial-of-Service attacks Retrieving or distributing IMG metadata may require state in the IMG senders, transceivers, and/or receivers for the respective IMG transport sessions. Attackers may create large numbers of sessions with any of the above IMG entities to disrupt regular operation. REQ DOS-1: IMG operations SHOULD be authenticated. REQ DOS-2: It SHOULD be possible to 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. 6.5 Replay Attacks IMG metadata disseminated by an IMG sender or an IMG 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. 7 Acknowledgements The authors would like to thank HitoshiIANA Considerations There are no IANA considerations within this document. 8 Normative References  Y. Nomura, R. Walsh, J-P. Luoma, H. Asaeda, Petri Koskelainen, Toni Pailaand Dirk KutscherH. Schulzrinne, "A framework for the usage of Internet media guides," Internet Draft draft-ietf-mmusic-img-framework-02, Internet Engineering Task Force, Dec. 2003. Work in progress.  S. Bradner, "Key words for their comments and ideas on this work. 8 Normativeuse in RFCs to indicate requirement levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. 9 Informative References  M. Handley and V. Jacobson, ``SDP:"SDP: session description protocol,''protocol," RFC 2327, Internet Engineering Task Force, Apr. 1998.  M. Handley, C. E. Perkins, and E. Whelan, ``Session"Session announcement protocol,''protocol," RFC 2974, Internet Engineering Task Force, Oct. 2000.  Session Directory, ftp://ftp.ee.lbl.gov/conferencing/sd/  Session Directory Tool, http://www- mice.cs.ucl.ac.uk/multimedia/software/sdr/  J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler, ``SIP:"SIP: session initiation protocol,''protocol," RFC 3261, Internet Engineering Task Force, June 2002.  S. Bradner, ``Key words for use in RFCs to indicate requirement levels,'' R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, and T. Berners- Lee, "Hypertext transfer protocol -- HTTP/1.1," RFC 2119,2068, Internet Engineering Task Force, Mar.Jan. 1997. 9 Informative References  Session Directory, ftp://ftp.ee.lbl.gov/conferencing/sd/  Session Directory Tool, http://www- mice.cs.ucl.ac.uk/multimedia/software/sdr/ A. B. Roach, "Session initiation protocol (sip)-specific event notification," RFC 3265, Internet Engineering Task Force, June 2002.  D. Kutscher, J. Ott, and C. Bormann, "Session description and capability negotiation," Internet Draft draft-ietf-mmusic-sdpng-07, Internet Engineering Task Force, Oct. 2003. Work in progress.  B. Quinn and K. Almeroth, "IP multicast applications: Challenges and solutions," RFC 3170, Internet Engineering Task Force, Sept. 2001. 10 Acknowledgements The authors would like to thank Colin Perkins, Jean-Pierre Evain, Hitoshi Asaeda, Petri Koskelainen, Toni Paila and Dirk Kutscher for their comments and ideas on this work. 11 Authors' Addresses Yuji Nomura Fujitsu Laboratories Ltd. 4-1-1 Kamikodanaka, Nakahara-ku, Kawasaki 211-8588 Japan Email: firstname.lastname@example.org Rod Walsh Nokia Research Center P.O. Box 100, FIN-33721 Tampere Finland Email: email@example.com Juha-Pekka Luoma Nokia Research Center P.O. Box 100, FIN-33721 Tampere Finland Email: firstname.lastname@example.org Joerg Ott Universitaet Bremen MZH 5180 Bibliothekstr. 1 D-28359 Bremen Germany Email: email@example.com Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA Email: firstname.lastname@example.org The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (c) The Internet Society (2003).(2004). 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.