Internet Engineering Task Force MMUSIC WG Internet Draft Y. Nomura Fujitsu Labs. R. Walsh J-P. Luoma Nokia H. Asaeda INRIA H. Schulzrinne Columbia University
draft-ietf-mmusic-img-framework-01.txtdraft-ietf-mmusic-img-framework-02.txt December 2,22, 2003 Expires: MarchJune 2004 A Framework for the Usage of 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 document defines a framework for the delivery of Internet Media Guides (IMGs). An IMG is a structured collection of multimedia session descriptions expressed using SDP, SDPng or some similar session description format. This document describes several use case scenarios requirering the IMG framework,a generalized model for IMG delivery mechanisms, and the use of existing protocol to create an IMG delivery infrastructure. Table of Contents 1 Introduction ........................................ 3 1.1 Background and Motivation ........................... 3 1.2 Scope of this Document .............................. 42 2 Terminology ......................................... 43 Use Cases Requiring IMG Framework ................... 5 3.1 Connectivity-based Use Cases ........................ 5 3.1.1 IP Datacast to a Wireless Receiver .................. 5 3.1.2 Regular Fixed Dial-up Internet Connection ........... 6 3.1.3 Broadband Always-on Fixed Internet Connection ....... 6 3.2 Content-orientated Use Cases ........................ 6 3.2.1 File Distribution ................................... 7 3.2.2 TV and Radio Program Delivery ....................... 7 3.2.3 Media Coverage of a Live Event ...................... 8 3.2.4 Distance Learning ................................... 8 3.2.5 Multiplayer Gaming .................................. 8 43 IMG Common Framework Model .......................... 8 4.15 3.1 IMG Data Types ...................................... 9 4.1.15 3.1.1 Complete IMG Description ................................ 9 4.1.2............................ 5 3.1.2 Delta IMG Description ................................... 9 4.1.3............................... 6 3.1.3 IMG Pointer ............................................. 10 4.2......................................... 6 3.2 Operation Set for IMG Delivery ...................... 10 4.2.16 3.2.1 IMG ANNOUNCE ........................................ 10 4.2.26 3.2.2 IMG QUERY ........................................... 10 4.2.37 3.2.3 IMG RESOLVE ......................................... 11 4.2.47 3.2.4 IMG SUBSCRIBE ....................................... 11 4.2.57 3.2.5 IMG NOTIFY .......................................... 11 4.38 3.2.6 Binding Between IMG Operations and Data Types ....... 8 3.3 IMG Entities ........................................ 12 4.48 3.4 Overview of Protocol Operations ..................... 12 59 4 Deployment Scenarios for IMG Entities ............... 13 5.19 4.1 Intermediary Cases .................................. 13 5.210 4.2 One-to-many Unidirectional Multicast ................ 15 5.311 4.3 One-to-one Bi-directional Unicast ................... 15 5.412 4.4 Combined Operations with Common Metadata ............ 16 612 5 Applicability of Existing Protocols to the Proposed Framework Model ....................................... 17 6.113 5.1 Summary of Limitations of Existing Protocols ........ 17 6.213 5.2 Existing Protocol Fit to the IMG Framework Model 6.35.3 Outstanding IMG Mechanism Needs ..................... 19 6.3.116 5.3.1 A Multicast Transport Protocol ...................... 19 6.3.216 5.3.2 Usage of Unicast Transport Protocols ................ 20 6.3.3 The Metadata17 5.3.3 IMG Transfer Envelope ............................... 20 6.3.417 5.3.4 Baseline (Meta)Data Model Specification ............. 21 6.418 5.4 IMG Needs Fitting the IETF's Scope .................. 22 718 6 Security Considerations ............................. 23 819 7 Normative References ................................ 24 921 8 Informative References .............................. 25 1022 9 Acknowledgements .................................... 26 1122 10 Authors' Addresses .................................. 2622 1 Introduction 1.1 Background and MotivationInternet Media Guide (IMG)Guides (IMGs) provide and deliver structured collections of multimedia descriptions expressed using SDP, SDPng or some similar description format. It isThey are used to describe sets of multimedia sessions (e.g. television program schedules, content delivery schedules etc.) and refer to other networked resources including web pages. IMGs provide 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. Firstly, this document explains several use case scenarios requiring theIMG framework. IMGs are inherently required tometadata must be independentdelivered to a potentially large audience, who use it to join a subset of any particular access network, and link in general. Therefore, they are suitable in many Internet access scenarios including fixed and mobile devices, wired and satellite and terrestrial radio, always-on Internet and intermittent connectivity,the sessions described, and so on. Furthermore, IMGs provides essential functions that facilitate better distributionwho may need to be notified of content. Section 3 describes how IMGs and IMG delivery mechanisms contribute for the scenarios. Then, this document defines a generalized model for IMG delivery mechanisms and their deployment in network entities regarding the use case scenarios. 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 thechanges to the IMG metadata. 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. Finally,This document defines a common framework model for IMG delivery mechanisms and their deployment in network entities. There are three fundamental components in IMG framework model: data types, operation sets and entities. These components specify a set of framework guideline for IMG delivery to efficiently deliver and describe IMG metadata. The data types give common base descriptions on top of an application-specific IMG metadata. IMG operations cover traditional broadcast-style scenarios, multicast-based distributions, unicast- based push and interactive retrievals similar to web pages. Since we envision that any Internet host can be a sender and receiver of IMG metadata, an host involved in IMG operations perform one or more of roles defined as the entities in IMG framework model. These are then shown in a number of simplified deployment scenarios. The requirements for IMG delivery mechanisms and descriptions can be found in . Then, this document outlines the use of existing protocols to create an IMG delivery infrastructure. It aims to organize existing protocols into common model and show their capabilities and limitations from the view pointviewpoint of IMG delivery functions. One of the multicast-enabling IMG requirements is scaling well to a large number of hosts and IMG senders in a network. Another issue is the need for flexibility and diversity in delivery methods, whereas existing protocols tend to be bound to a specific application. 1.2 Scope of2 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this Document Thisdocument defines a common framework model for the delivery ofare to be interpreted as described in RFC 2119 . Internet Media Guide (IMG) metadata. The framework describes existing mechanisms and the level(IMG): IMG is a generic term to which they support and enabledescribe the framework. The requirements for IMG delivery mechanisms and descriptions can be found in . A brief run through the usage and use cases of media guide is provided to illustrate the relevance of IMGs before the framework model is presented. The framework model defines the data types, operations and entities which are needed. These are then shown in a number of simplified deployment scenarios. Existing protocols are organized and referenced against the framework model to show the degree to which they fulfill IMG framework and requirements. This also makes it straightforward to identify gaps so that new protocols needs are made apparent. 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,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: This is aA set of metadata describingconsisting 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,genre and access restrictions. IMG Description: A collection of IMG metadata which has a relationship to other IMG metadata. There are three data types to describe the relationship: Complete IMG Descriptions, Delta IMG Description and IMG pointer. 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 IMGsIMG metadata to one or more IMG receivers. IMG Receiver: An IMG receiver is a logical entity that receives IMGsIMG metadata from an IMG sender. IMG Transceiver: An IMG transceiver combines an IMG receiver and sender. It may modify original IMGsreceived IMG metadata or merge several IMGsIMG metadata received from a several different IMG sender.senders. IMG Operation: An atomic process for theoperation of an IMG transport protocol to deliverprotocol, used between IMG sender(s) and IMG receiver(s) for the delivery of IMG metadata orand for the control of IMG sender(s) or IMG receiver(s).sender(s)/receiver(s). IMG Transport Protocol: A protocol that transports IMG metadata from an IMG sender to IMG receiver(s) 3 Use Cases Requiringreceiver(s). IMG Framework 3.1 Connectivity-based Use Cases 3.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 and processing of IP data (and storage). 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). 3.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). 3.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. 3.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 3.2.1 File Distribution IMGs support the communication of file delivery session properties, enabling the scheduled delivery or synchronization of files between a number of hosts. For example, the metadata that IMGs provide could be subsequently used by a different application (outside the scope of IMGs) to download a file with a software update.Transport Session: An 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 capacity of delivery senders. In addition, IMG metadata can be used to synchronize a set of filesassociation between a sender host and receiver host, when those files change as time elapses. 3.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 content could be represented in a format similar to that of a TV guide in newspapers, oran 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. 3.2.3 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,sender and one or more IMG receivers within 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. statisticsscope of the players during a football match) may be sent to user terminals. Differentan IMG transport modes or even different access technologies could be used for the different media: for example, a unidirectional datacastprotocol. An IMG transport could be used for the audio/video streams and an interactive cellular connection for the textual data.session involves a series of IMG metadata should enable terminals to discover the availabilitytransport protocol interactions that provide delivery of different media used to cover a live event. 3.2.4 Distance LearningIMG metadata could describe compound sessions or services enabling several alternative interaction modes betweenfrom the participants. For example,IMG sender to the combination of one-to-many media streaming, unicast messaging and download of presentation material could be useful for distance learning. 3.2.5 Multiplayer Gaming Multiplayer games are an example of real-time multiparty communication sessions that could be advertised using IMGs.IMG receiver(s). IMG Transfer: A gaming session could be advertised either by a dedicated server, or by the terminalstransfer of individual users. A user could use IMGs to learnIMG metadata consisting of active multiplayer gaming sessions, or advertise the users interest in establishing such a session. 4Complete IMG Descriptions, Delta IMG Descriptions and/or IMG Pointers. 3 IMG Common Framework Model Two common elements are found in all of existing IMG candidate cases: the need to describe the services; the need to deliver the descriptions. In some cases, the descriptions are multicast enablers (such as the session parameters of SDP) and are thus intrinsically part of the delivery aspects, and in other cases descriptions are application-specific (both machine and human readable). Thus, the technologies can be roughly divided into three areas: o Application-specific Metadata -- data describing the services' content and media which are both specific to certain applications and generally human readable. o Delivery DescriptorsDescriptions -- the descriptorsdescriptions (metadata) that are essential to enable (e.g. multicast) delivery. These include framing (headers) for application-specific metadata, the metadata element identification and structure, fundamental session descriptors.descriptions. o Delivery Protocols -- the methods and protocols to exchange descriptions between the senders and the receivers. An IMG deliverytransport protocol consists of two functions: carrying IMG metadata from an IMG sender to an IMG receiver and controlling an IMG transport protocol. These functions are not always exclusive, therefore some messages may combine control messages and metadata carriage functions metadata to reduce the amount of the messaging. 4.13.1 IMG Data Types A data model is needed to precisely define the terminology and relationships between sets, supersets and subsets of metadata. A precise data model is essential for the implementation of IMGs although it is not within the scope of this framework and requires a separate specification. However there are three IMG data types in general: Complete description, delta descriptionIMG Descriptions, Delta IMG Description and pointer. 4.1.1IMG Pointer. 3.1.1 Complete IMG Description A Complete IMG Description provides a complete syntax and semantics to describe a set of metadata, which does not need any additional information from any other IMG entity.element. Note, this is not to be confused with "complete IMG metadata", which, although vaguely defined here, represents the complete IMG metadata database of aan IMG sender (or related group of IMG senders -- potentially the complete Internet IMG knowledge). AAn IMG sender will generally deliver only subsets of metadata from its complete database of metadatain a particular data exchange. 4.1.2IMG transport session. 3.1.2 Delta IMG Description A Delta IMG Description provides only part of a Complete IMG Description, defining the difference from a previous version of the Complete IMG Description in question. This descriptorDelta transfers may be used to reduce network resource usage (it may be more bandwidth and congestion friendly), for instance,instance when data consistency is essential and,and small and frequent changes occur to the Complete Description.IMG elements. Thus, this descriptordescription itself cannot represent complete metadata set until it is combined with existing, or future, description knowledge. 126.96.36.199.3 IMG Pointer A pointer providedAn IMG Pointer provides a simple identifier or locator, such as a URL,URI, that the IMG receiver is able to reference (or reference and locate) specific metadata with. This may be used to separately obtain metadata (complete(Complete or delta descriptions)Delta IMG Descriptions) or perform another IMG management function such as data expire (and erasure). The pointerIMG Pointer may be used to reference IMG metadata elements within the IMG transport session and across IMG transport sessions. TheThis pointer type does not include metadata parper se (although it may also appear as a data field in completeComplete or deltaDelta IMG descriptors). 4.23.2 Operation Set for IMG Delivery A finite set of operations both meets the IMG requirements  and fits the roles of existing protocols. These are crystallized in the next few sections. 188.8.131.52.1 IMG ANNOUNCE When an IMG receiver participates in unidirectional communications (e.g. over satellite, terrestrial radio and wired multicast networks) an IMG receiver may not need to send any message to an IMG sender prior to IMG metadata delivery. In this case, an IMG sender can initiate unsolicited distribution for IMG metadata and an IMG sender is the only entity which can maintain the distribution (this includes scenarios with multiple and co-operative IMG senders). This operation is useful when there are considerably large number IMG receivers or IMG receiver(s) do not have a guaranteed uplink connection to the IMG sender(s). The IMG sender may also include authentication data in the announce operation so that IMG receivers may check the authenticity of the metadata. This operation is able to carry any of the IMG data-data types. Note, there is no restriction to prevent IMG ANNOUNCE from being used in an asynchronous solicited manner, where a separate operation (possibly out of band) is able to subscribe/register IMG receivers to the IMG ANNOUNCE operation. 184.108.40.206.2 IMG QUERY If an IMG receiver needs to obtain IMG metadata, an IMG receiver can send an IMG QUERY message and initiate a receiver-driven IMG deliverytransport session. The IMG receiver expects a synchronous response to the subsequent request from the IMG sender. This operation can be used where a bi-directional transport network is available between the IMG sender and receiver. Some IMG receivers may want to obtain IMG metadata when a resource is available or just to avoid caching unsolicited IMG metadata. The IMG receiver must indicate the extent and data type of metadata wanted in some message in the operation (Extent indicates the number and grouping of metadata descriptions). In some cases requesting aan IMG sender's complete IMG metadata may be feasible, in others it may not. 220.127.116.11.3 IMG RESOLVE An IMG sender synchronously responds and sends IMG metadata to an IMG QUERY which has been sent by an IMG receiver. This operation can be used where a bi-directional transport network is available between the IMG sender and receiver. If the IMG QUERY specifies a subset of IMG metadata (extent and data type) that is available to the IMG sender has the subset,sender, the IMG sender can resolve this, otherwisequery; otherwise, it should indicate that it is not able to resolve the query. The IMG sender may authenticate the IMG receiver to investigate the IMG QUERY operation in order to determine whether the IMG receiver is authorized to be sent that metadata. The sender may also include authentication data in the resolve operation so that IMG receivers may check the authenticity of the metadata. This operation may carry any of the IMG data types. 18.104.22.168.4 IMG SUBSCRIBE If an IMG receiver wants to be notified when metadata whichthe IMG receivermetadata it holds is stale, the IMG receiver can startuse the IMG SUBSCRIBE operation priorin advance in order to solicit notify messages.messages from an IMG sender. Since the IMG receiver doesn't know when metadata will be updated and the notify message will arrive, this operationsoperation does not synchronize with the notify message.messages. The IMG receiver may wait for thenotify messagemessages for a long time. The IMG sender may authenticate the IMG receiverIMG sender may authenticate the IMG receiver to investigate whether an IMG SUBSCRIBE operation is from an authorized IMG receiver. 3.2.5 IMG NOTIFY An IMG NOTIFY is used in response to an earlier IMG SUBSCRIBE. An IMG NOTIFY generates a notify message indicating that updated IMG metadata is available or part of the existing IMG metadata is stale. An IMG NOTIFY may be delivered more than once during the time an IMG SUBSCRIBE is active. This operation may carry any of the IMG data types. The IMG sender may also include authentication data in the IMG NOTIFY operation so that IMG receivers may check the authenticity of the messages. 3.2.6 Binding Between IMG Operations and Data Types There is a need to provide a binding between the various IMG operations and IMG data types to allow management of each discrete set of IMG metadata transferred using an IMG operation. This binding must be independent of any particular metadata syntax used to represent a set of IMG metadata, as well as be compatible with any IMG transport protocol. The binding must uniquely identify the set of IMG metadata delivered within an IMG transfer, regardless of the metadata syntax used. The uniqueness may only be needed within the domains the metadata is used but this must enable globally unique identification to support Internet usage. Scope/domain specific identifications should not 'leak' outside of the scope, and always using globally unique identification (e.g. based on URIs) should avoid this error. The binding must provide versioning to investigate whether an IMG SUBSCRIBE operation is from an authorized receiver. 4.2.5 IMG NOTIFY An IMG receiver needsthe response to an earliertransferred IMG SUBSCRIBEmetadata so that changes can be easily handled and stale data identified, and give temporal validity of the transferred IMG NOTIFY indicates that updatedmetadata. It must expire the IMG metadata is available or part ofby indicating an expiry time, and may optionally provide a time (presumably in the future) from when the existingIMG metadata is stale. Anbecomes valid. Temporal validity of IMG NOTIFYmetadata may be delivered more than once during the timechangeable for an IMG SUBSCRIBE is active. This operation may carry anytransfer, and even for specific versions of the IMG data types. The sender may also include authentication data in the notify operation so that receivers may checktransfer. Furthermore, the authenticitybinding must be independent of the messages. 4.3metadata syntax(es) used for the IMG metadata, in the sense that no useful syntax should be excluded. 3.3 IMG Entities There are several fundamental IMG entities that indicate the capability to perform certain roles. An Internet host involved in IMG operations may adopt one or more of these roles: IMG Announcer : send IMG ANNOUNCE IMG Listener : receive IMG ANNOUNCE IMG Querier : send IMG QUERY to receive IMG RESOLVE IMG Resolver : receive IMG QUERY then send IMG RESOLVE IMG Subscriber: send IMG SUBSCRIBE then receive IMG NOTIFY IMG Notifier : receive IMG SUBSCRIBE then send IMG NOTIFY Finally, thefigure 1 shows a relationship between IMG entities and the IMG sender and receiver. +--------------------------------------------------------+ | IMG Sender | +------------------+------------------+------------------+ | IMG Announcer | IMG Notifier | IMG Resolver | +------------------+------------------+------------------+ | ^ ^ message | | | direction v v v +------------------+------------------+------------------+ | IMG Listener | IMG Subscriber | IMG Querier | +------------------+------------------+------------------+ | IMG Receiver | +------------------+------------------+------------------+ Figure 1: Relationship with IMG Entities 4.43.4 Overview of Protocol Operations The figure 2 gives an overview of the relationship between transport cases, IMG Operations and IMG data types (note, it is not a protocol stack). 4 Deployment Scenarios for IMG Entities This section provides some basic deployment scenarios for IMG entities that illustrate common threads from protocols to use cases. For the purposes of clarity, this document presents the simple dataflow from an IMG sender to an IMG receiver, as shown in figure 3. +--------------------------------------------------+ IMG | | Data types | Complete Desc., Delta Desc., Pointer | | | +-------------------+----------------+-------------+ IMG | IMG ANNOUNCE | IMG SUBSCRIBE | IMG QUERY | Operations | | IMG NOTIFY | IMG RESOLVE | +--------------+----+----------------+-------------+ IMG | | | Transport | P-to-M | P-to-P | | | | +--------------+-----------------------------------+ Figure 2: IMG Operations and IMG Data type 5 Deployment Scenarios for IMG Entities This section provides some basic deployment scenarios for IMG entities that illustrate common threads from protocols to use cases. For the purposes of clarity, this document presents the simple dataflow from sender to receiver as shown in figure 3+-------------+ +---------------+ | IMG Sender | | IMG Receiver | | |--------------->| | +-------------+ +---------------+ Figure 3: A Simple IMG Sender to IMG Receiver Relationship 5.14.1 Intermediary Cases Some IMG metadata may be distributed to a large number of IMG receivers. If, for example, some IMG metadata is public information and the IMG sender provides the same information for all IMG receivers. This kind of IMG metadata may be distributed from one IMG sender to multiple IMG receivers (Figure 4) and/or or may be relayed across a set of IMG transceivers that receive the IMG metadata, possibly filter or modify its content, and then forward it. The relayed network architecture is similar to content distribution network architecture  (CDNs). Existing CDNs may carry IMG metadata. Satellite and peer-to-peer networks may also carry IMG metadata. +----------+ +----------+ | IMG | | IMG | | Sender |---- ---->| Receiver | +----------+ \ / +----------+ \ / . \ +-----------+ / . . -->|IMG |----- . . -->|Transceiver| \ . / +-----------+ \ +----------+ / \ +----------+ | IMG | / ---->| IMG | | Sender |---- | Receiver | +----------+ +----------+ Figure 4: A Relay Network with an IMG Transceiver IMG senders and receivers are logical functions and it is possible for some or all hosts in a system to perform both roles, as, for instance, in many-to-many communications or where a transceiver is used to combine or aggregate IMG metadata for some IMG receivers. An IMG receiver may be allowed to receive IMG metadata from any number of IMG senders. TheIMG metadata is used to find, obtain, manage and play content. TheIMG metadata distributiondistributions may be modified as they are distributed. For example, a server may use IMGs to retrieve media content via unicast and then make it available at scheduled times via multicast, thus requiring a change of the corresponding metadata. IMG transceivers may add or delete information or aggregate IMG metadata from different IMG senders. For example, a rating service may add its own content ratings or recommendations to existing meta-data. An implication of changing (or aggregating) IMG metadata from one or more IMG senders is that the original authenticity is lost. Thus for deployments requiring these kind of features, the original metadata should be reasonably fragmented already (allowing the intermediary to replace a small fragment without changing the authenticity of the remainder). It may be beneficial to use smaller fragments for more volatile parts, and larger one for more stable parts. 5.24.2 One-to-many Unidirectional Multicast This case implies many IMG receivers and one or more IMG senders implementing IMG ANNOUNCER and IMG LISTENER operations as shown in figure 5. Unidirectional +----------+ ---------------> | IMG | downlink | Listener | ------------->| 1 | / +----------+ +-----------+ / . | IMG |-------- . | Announcer | \ . +-----------+ \ +----------+ ------------->| IMG | | Listener | | # | +----------+ Figure 5: IMG Unidirectional Multicast Distribution Example 5.34.3 One-to-one Bi-directional Unicast +----------+ +----------+ | IMG |<------(1)------| IMG | | Resolver |-------(2)----->| Querier | +----------+ +----------+ Figure 6: Query/Resolve Deployment Example Both query/resolve (figure 6) and subscribe/notify (figure 7) message exchange operations are feasible. +----------+ +------------+ | |<-------(1)--------| | | IMG |--------(2)------->| IMG | | Notifier | (time passes) | Subscriber | | |--------(3)------->| | +----------+ +------------+ Figure 7: Subscribe/Notify Deployment Example 5.44.4 Combined Operations with Common Metadata As shown in figure 8, a common data model for multiple protocol operations allows a diverse range of IMG senders and receivers to provide consistent and interoperable IMGs.sets of IMG metadata. +----------+ +------------+ | |<-------(1)--------| | | IMG |--------(2)------->| IMG | | Notifier | (time passes) | Subscriber | | |--------(3)------->| | +----------+ +------------+ Figure 7: Subscribe/Notify Deployment Example IMG Metadata IMG Senders IMG Receivers +--------------+ +-----------+ ---->| IMG Listener | | IMG | / +--------------+ /| Announcer |----- +-------------+ / +-----------+ \ +--------------+ | IMG |-+ / ---->| IMG Listener | | Description | |-+ / | - - - - - - -| | metadata 1 | | | / +-----------+ /--->| IMG Querier | +-------------+ | | -----| IMG |<----/ +--------------+ +-------------+ | \ | Resolver | +-------------+ \ +-----------+<----\ +--------------+ \ \--->| IMG Querier | \ +-----------+ | - - - - - - -| \| IMG |<--------->| IMG | | Notifier | | Subscriber | +-----------+ +--------------+ Figure 8: Combined System with Common Metadata 65 Applicability of Existing Protocols to the Proposed Framework Model 6.15.1 Summary of Limitations of Existing Protocols 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 carry anotherreference properties of a multimedia session descriptors.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. MPEG-7  is a collection of XML-based description tools for general multimedia content including structured multimedia sessions. TV- Anytime Forum  provides descriptions based on MPEG-7 for TV specific program guides. These are likely to be limited to describe pictures, music and movies, thus it may be necessary to extend these descriptions in order to define a variety of documents, game programs, binary files, live eventevents and so on. HTTP  is a well known information retrieval protocol using bi- directional transport and widely used to deliver web-based content descriptions to many hosts. However, it has well recognized limitations of scalability in the number of HTTP clients since it relies on the polling mechanism to keep information consistent between the server and client. SAP  is an announcement protocol that distributes session descriptions via multicast. It does not support fine-grained meta datametadata selection and update notifications, as it always sends the whole meta data.metadata. Given the lack of a wide-area multicast infrastructure, it is likely only deployable within a local area network. SIP  and SIP-specific event notification  can be used to notify subscribers of the update of IMG metadata for bi-directional transport. It is necessary for SIP Event to define an event package for each specific application such as . 6.25.2 Existing Protocol Fit to the IMG Framework Model SDP: The SDP format could be used to describe session-level parameters (e.g. scheduling, addressing and the use of media codecs) to be included in Complete Descriptors.IMG Descriptions. Although there are extension points in SDP allowing the format to be extended, there are limitations in the flexibility of this extension mechanism. However, SDP syntax can notcannot provide with Partial DescriptorsDeleta IMG Descriptions and IMG Pointers without significant unused overhead. Because it is expected that the information conveyed by SDP is just a small subset of IMG metadata the use of SDP for other than session-level IMG parameters may not be reasonable. SDPng: Similar to SDP, this format could also be used for representing session-level parameters of IMG metadata. Compared to SDP, the XML-based format of SDPng is much more flexible with regards to extensions and combining with other description formats. MPEG-7: Descriptions based on the MPEG-7 standard could provide application-specific metadata describing the properties of multimedia content beyond parameters carried in SDP or SDPng descriptions. MPEG-7 provides a machine-readable format of representing content categories and attributes, helping end-users or receiving software in choosing content for reception: this is well in line with the IMG usage scenarios of IMGs introduced in 3.2. Because MPEG-7 is based on XML, it is well suited for combining with other XML-based formats such as SDPng. HTTP: The HTTP protocol can be used as a bi-directional/unicast IMG transport protocol. Being a request-reply oriented protocol, HTTP is well suited for implementing synchronous operations such as QUERY, RESOLVE and even SUBSCRIBE. However, HTTP does not provide asynchronous operations such as ANNOUNCE and NOTIFY and to implement asynchronous operations using HTTP, IMG receivers should poll the IMG sender periodically. So alone, HTTP is not sufficient to fulfill IMG requirements in a unicast deployment. SAP: The announcement mechanism provided by SAP provides unidirectional delivery of session discovery information. Although SDP is the default payload format of SAP, the use of a MIME type identifier for the payload allows arbitrary payload formats to be used in SAP messages. Thus, SAP could be used to implement the (multicast and unicast) IMG ANNOUNCE and IMG NOTIFY operations. However, the limitations of SAP as a generic IMG transport protocol include: - Lack of reliability (through forward error correction / retransmissions) - Lack of payload segmentation - Limited payload size - Only one description allowed per SAP message - Lack of congestion control - Lack of Internet standard authentication / encryption mechanisms - It is an Experimental RFC with no support for progressing further In principle, the current SAP protocol could be extended to get around its limitations (e.g. the use of a multipart MIME type in the SAP payload has been proposed, enabling multiple descriptions to be carried in a single SAP message). However, the amount of changes needed in SAP to address all of the above limitations would effectively result in a new protocol. Due to these limitations, the use of SAP as an IMG transport protocol is not recommended. SIP: The SIP-specific event mechanism described in RFC 3265  provides a way to implement IMG SUBSCRIBE and IMG NOTIFY operations via a bi- directionalbi-directional unicast connection. However, there are scalability problems with this approach, as RFC 3265 currently does not consider multicast. 6.35.3 Outstanding IMG Mechanism Needs Several outstanding needs result from the IMG requirements, framework model and existing relevant mechanisms as already shown in this document. Four specific groupings of work are readily apparent which are: (a) specification of an adequate multicast and unidirectional capable announcement protocol; (b) specification of the use of existing unicast protocols to enable unicast subscribe and announcement/notification functionality; (c) specification of the metadata envelope which is common to, and independent of, the application metadata syntax(es) used; agreement on basic metadata models to enable interoperability testing of the above. The following sections describe each of these. 22.214.171.124.1 A Multicast Transport Protocol SAP is currently the only open standard protocol suited to the unidirectional/multicast delivery of IMG metadata. As discussed, it fails to meet the IMG requirements in many ways and, since it is not designed to be extensible, we recognize that a new multicast transport protocol for announcements needs to be specified to meet IMG needs. This protocol will be essential to IMG delivery for unidirectional and multicast deployments. The Asynchronous Layered Coding (ALC)  protocol from the IETF Reliable Multicast Transport (RMT) working group is very interesting as it fulfils many of the requirements, is extensible and has the ability to `plug-in' both FEC (Forward Error Correction -- for reliability) and CC (Congestion Control) functional blocks -- it is specifically designed for unidirectional multicast object transport. ALC is not fully specified, although RMT has a work-in-progress fully specified protocol using ALC called FLUTE (File Delivery over Unidirectional Transport) . FLUTE seems to be the only fully specified transport and open specification on which a new IMG announcement protocol could be designed. Thus we recommend that ALC and FLUTE be the starting points for this protocol's design. Developing a new protocol from scratch, or attempting to improve SAP, is also feasible, although it would involve repeating many of the design processes and decisions already made by the IETF for ALC. Thus, we recommend only to attempt this if ALC-based protocols are later found to be insufficient. In particular, any announcement protocol must feature sufficient scalability, flexibility and reliability to meet IMG needs. Also, the ANNOUNCE operation must be supported and alsoNOTIFY capability could be investigated for both hybrid unicast-multicast and unidirectional unicast systems. 126.96.36.199.2 Usage of Unicast Transport Protocols A thorough description of the use of existing unicast protocols is essential for the use of IMGs in a unicast andpoint-to-point environment. Such a specification does not currently exist, although several usable unicast transport protocols and specifications can be harnessed for this (SIP, SIP events, HTTP, etc). In particular, both SUBSCRIBE-NOTIFY and QUERY-RESOLVE operation pairs must be enabled. We anticipate that the FETCH operation will be a trivial usage of HTTP, although other transport options may be beneficial to consider too. 6.3.3 The Metadata Envelope To be able to handle multiple metadata syntaxes, a common minimal set of information is needed to handle discrete blocks of metadata. The IMG framework model data types defined in this document. This minimal set of information field will be named a `metadata envelope' and must: 1. Uniquely identify the block of metadata, regardless of metadata syntax used. The uniqueness may only be needed within the domains the metadata is used but this must enable globally unique identification to support Internet usage. Scope/domain specific identifications should not `leak' outside of the scope, and always using globally unique identification (e.g. based on URIs) should avoid this error. 2. Version the block so that changes can be easily handledthis (SIP , SIP events , HTTP , etc.) In particular, both SUBSCRIBE-NOTIFY and stale data identified. 3. Give the temporal validity of the block. ItQUERY-RESOLVE operation pairs must expirebe enabled. We anticipate that the block (expiry time), and may optionally provideFETCH operation will be a time (presumably in the future) from when the block becomes valid. Temporal validitytrivial usage of HTTP, although other transport options may be changeablebeneficial to consider too. 5.3.3 IMG Transfer Envelope Section 3.2.6 of this document discussed the need for a block,binding between IMG Operations and evenData Types. Such a specific version ofbinding can be realized by defining a block. 4. Be independentcommon minimal set of the metadata syntax(es) used for theinformation needed needed to manage IMG metadata block, in the sense that no useful syntax should be excluded. For blockstransfers, and by including this information with multiple descriptors, it is assumed thatany descriptors inherit the parametersset of the (super)blocks. Thus the above information will implicitly describe the individual descriptors.IMG metadata delivered to IMG receiver(s). Four options for metadataIMG transfer envelope transportdelivery are feasible: 1. Embedding in a transport protocol header. This can be done with either header extensions of existing protocols, or newly defined header fields of a new (or new version of a) transport protocol. However, multiple methods for the variety of transport protocols may hinder interoperability. 2. A separate envelope object (a form of metadata itself) delivered in-band with the metadata. This would complicate delivery as the envelope and `service' metadata objects would have to be bound, e.g. by pairing some kind of transport object numbers (analogous to port number pairs sometimes used for RTP and RTSP). 3. A metadata wrapper which points to and/or embeds the service metadata into its `super-syntax'. For example, XML enables referencing (pointing to) other resources as well as embedding generic text objects. 4. Embedding in the metadata itself. However, this requires new field in many metadata syntaxes and would not be feasible if a useful syntax were not capable of extensibility in this way. It also introduces a larger 'implementation interpretation' variety which would hinder interoperability. Thus this option is not recommended. 6.3.4 Baseline (Meta)Data Model SpecificationIt is likely that more than one of these options will fulfill the needs of IMGs so the selection, and possibly optimization, is left for subsequent specification and feedback from implementation experience. Such a specification is essential for IMG delivery and so should be an official IETF work item. Relevant work-in-progress ensures that support of one, or very few, metadata syntaxes is not sufficient. Whereas the transport protocol should not restrict the metadata format, the metadata envelope may influence the choice metadata. However, metadata in binary format should not be prevented, in addition to the more abundant text and XML syntaxes currently available. In most cases the actual content of metadata will be application, or service domain, specific. For instance, digital cinema distribution and television channels will have many different requirements. The task of specifyingthese options will fulfill the bulkneeds of IMGs so the world's metadataselection, and possibly optimization, is well beyond the scope of this document:left for subsequent specification and feedback from implementation experience. Such a frameworkspecification is essential for theIMG delivery ofand so should be an official IETF work item. When there are superset/subset relations between IMG metadata. We do anticipatedescriptions, it is assumed that existing and future metadata specifications, including thosethe IMG descriptions of several working groups and standardization bodies, shall be able to usethe servicessubset inherit the parameters of the superset. Thus, an IMG framework. However, it is not essential totransfer envelope carrying the currentIMG workdescriptions of a superset may implicitly define parameters of IMG descriptors belonging to specify standards with application-specific metadata. It is essential that the threeits subset. The relations between IMG data types are enabled, but itdescriptions may not be necessaryspan from one IMG transfer envelope to achieve this for every metadata syntax available, noranother. 5.3.4 Baseline (Meta)Data Model Specification A minimal IMG data model may itbe important to the IETFuseful to cover every possibility for this. Generally, Complete Descriptions willany implementer/deployment of IMGs. The purpose would be correct for existingto ensure that multiple metadata syntaxes (e.g. for XML may(SDP, MPEG-7, etc) can be validated according to existing schema). Pointerrelated within the same body of IMG knowledge, regardless of any specific metadata and data types may be servedmodels provided by a new syntax (extremely minimal), although it is feasible thatthe proposedmetadata envelope specification will contain enough information to implement the Pointer data type. Partial Descriptionssyntaxes. Further work may need new or modified syntaxesbe needed to meet application-specific requirements at defining metadata and semantics (e.g. XML schema) as mandatory fieldsdata models for a Complete Description maythe successful deployment of IMGs in various environments. Existing (and future) work on these would need to be redundant for a Partial Description. During and followingmapped to the specificationIMG data types and use of the metadata envelope, enabling the delivery of Partial Descriptions should be considered. To gain implementation experience, itIMG transfer envelope concept as described above. This document is essential to agreea framework for the basicdelivery of some metadata in interoperability tests and subsequently in widespread deployments. So we anticipate that a minimalIMG data model would be useful toMetadata and thus further discussion on the Internet community. 6.4definition data models for IMGs is beyond its scope. 5.4 IMG Needs Fitting the IETF's Scope A Multicast Transport Protocol is essential to IMG delivery for unidirectional and multicast deployments and no alternative exists which fulfils the IMG requirements. We recommend that the specification of this be taken on as an official work item in the IETF. Specification of the usage of unicast transport protocols is essential for IMG delivery and control involving unicast communications, and will relate to existing IETF standard transport protocols. Thus, we recommend that the specification of this be taken on as an official work item in the IETF. The metadataIMG transfer envelope functionality is essential for the IMG delivery fulfilling the IMG requirements. It is a required feature for IMG metadata transport and maintenance. Thus, we recommend that the metadataIMG transfer envelope specification be taken on as an official work item in the IETF. (Meta)data model specification and application specific metadata do not easily fit into the IETF scope and several other standardization bodies are well placed to do this work. We recommend that aspect shall not be an official IETF work item. Note, we acknowledge the need to exchange and agree on a baseline metadata model and application specific metadata for the purposes of interoperability testing between different implementations of IMG related IETF protocols. However, we feel that the IETF standards process is not required for this. 76 Security Considerations The IMG framework is developed from the IMG Requirements document  and so the selection of specific protocols and mechanism for use with the IMG framework must also take into account the security considerations of the IMG Requirements document. This framework document does not mandate the use of specific protocols. However, an IMG specification would inherit the security considerations of specific protocols used, although this is outside the scope of this document. Protocol instantiations which are used to provide IMG operations will have very different security considerations depending on their scope and purpose. However, there are several general issues which are valuable to consider and, in some cases, provide technical solutions to deal with. These are described below. Individual and Group Privacy: Customized IMG metadata may reveal information about the habits and preferences of a user and may thus deserve confidentiality protection, even thoughif the original information itself iswere public. CapturingSnooping and protecting this IMG metadata requires the same actions and measures as for other point-to-point and multicast Internet communications. Naturally, the risk of snooping depends on the amount of individual or group personalization the snooped sessions contain.IMG metadata contains. Further consideration is valuable at both transport and metadata levels. IMG Authenticity: In some cases, the IMG receiver needs to be assured of the origin of IMG metadata or its modification history. This can prevent denial of service or hijacking attempts which give an IMG receiver incorrect information in or about the metadata, thus preventing successful access of the media or directing the IMG receiver to the incorrect media possibly with tasteless material. Action upon detection of unauthorized data insertion is out of scope of this document. IMG Receiver Authorization: Some or all of any IMG sender's metadata may be private or valuable enough to allow access to only certain IMG receivers and thus make it worth authenticating users. Encrypting the data is also a reasonable step, especially where group communications methods results in unavoidable snooping opportunities for unauthorized nodes. Encryption and the required security parameters exchange are outside the scope of this document. Unidirectional Specifics: A difficulty that is faced by unidirectional delivery operations is that many protocols providing application-level security are based on bi-directional communications. The application of these security protocols in case of strictly unidirectional links is not considered in the present document. Malicious Code: Currently, IMGs are not envisaged to deliver executable code at any stage. However, as some IMG transport protocols may be capable of delivering arbitrary files, it is RECOMMENDED that the FLUTE delivery service does not have write access to the system or any other critical areas. Protocol Specific Attacks: It is recommended that developers of any IMG protocol take account of the above risks in addition to any protocol design and deployment environment risks that may be reasonably identified. Currently this framework document does not recommend or mandate the use of any specific protocols, however the deployment of IMGs using specific protocol instantiations will naturally be subject to the security considerations of those protocols. Security Improvement Opportunity: The security properties of one channel and protocol can be improved through the use of another channel and protocol. For example, a secure unicast channel can be used to deliver the keys and initialization vectors for an encryption algorithm used on a multicast channel. The exploitation of this opportunity is specific to the protocols used and is outside the scope of this document. 87 Normative References  Y. Nomura, "Protocol requirements for Internet media guides," Internet Draft draft-ietf-mmusic-img-req-02, Internet Engineering Task Force, Dec. 2003. Work in progress.  S. Bradner, "Key words for use in RFCs to indicate requirement levels," RFC 2119, Internet Engineering Task Force, Mar. 1997.  Y. Nomura et al., "Protocol requirements for Internet media guides," Internet Draft draft-ietf-mmusic-img-req-00, Internet Engineering Task Force, Sept. 2003. Work in progress. M. Day, B. Cain, G. Tomlinson, and P. Rzewski, "A model for content internetworking (CDI)," RFC 3466, Internet Engineering Task Force, Feb. 2003.  M. Handley and V. Jacobson, "SDP: session description protocol," RFC 2327, Internet Engineering Task Force, Apr. 1998.  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.  ISO (International Organization for Standardization), "Overview of the MPEG-7 standard," ISO Standard ISO/IEC JTC1/SC29/WG11 N4509, International Organization for Standardization, Geneva, Switzerland, Dec. 2001.  T.-A. Forum, "Metadata specification S-3," TV-Anytime Forum Specification SP003v1.2 Part A, TV, TV-Anytime Forum, June 2002.  R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, and T. Berners- Lee, "Hypertext transfer protocol -- HTTP/1.1," RFC 2068, Internet Engineering Task Force, Jan. 1997.  M. Handley, C. E. Perkins, and E. Whelan, "Session announcement protocol," RFC 2974, Internet Engineering Task Force, Oct. 2000.  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.  A. B. Roach, "Session initiation protocol (sip)-specific event notification," RFC 3265, Internet Engineering Task Force, June 2002.  M. Luby, J. Gemmell, L. Vicisano, L. Rizzo, and J. Crowcroft, "Asynchronous layered coding (ALC) protocol instantiation," RFC 3450, Internet Engineering Task Force, Dec. 2002. 98 Informative References  J. Rosenberg, "A presence event package for the session initiation protocol (SIP)," internet draft, Internet Engineering Task Force, Jan. 2003. Work in progress.  T. Paila, "FLUTE - file delivery over unidirectional transport," Internet Draft draft-ietf-rmt-flute-06,draft-ietf-rmt-flute-07, Internet Engineering Task Force, Nov.Dec. 2003. Work in progress. 109 Acknowledgements The authors would like to thank Joerg Ott, Colin Perkins, Toni Paila and Petri Koskelainen on for their ideas and input to this document. 1110 Authors' Addresses Yuji Nomura Fujitsu Laboratories Ltd. 4-1-1 Kamikodanaka, Nakahara-ku, Kawasaki 211-8588 Japan Email: email@example.com Rod Walsh Nokia Corporation Nokia Research Center P.O. Box 100, FIN-33721 Tampere Finland Email: rod,firstname.lastname@example.org Juha-Pekka Luoma Nokia Corporation Nokia Research Center P.O. Box 100, FIN-33721 Tampere Finland Email: email@example.com Hitoshi Asaeda INRIA Project PLANETE 2004, Route des Lucioles, BP93, 06902 Sophia Antipolis, France Email: Hitoshi.Asaeda@sophia.inria.fr Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA Email: firstname.lastname@example.org 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.