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-07.txt June 21,draft-ietf-mmusic-img-framework-08.txt July 19, 2004 Expires: December 2004January 2005 A Framework for the Usage of Internet Media Guides STATUS OF THIS MEMO By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668." 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 a "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at 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 a generalized model for IMG delivery mechanisms, the use of existing protocols and the need for additional work to create an IMG delivery infrastructure. Table of Contents 1 Introduction ........................................ 2 2 Terminology ......................................... 3 3 IMG Common Framework Model .......................... 5 3.1 IMG Data Types ...................................... 5 3.1.1 Complete IMG Description ............................ 5 3.1.2 Delta IMG Description ............................... 6 3.1.3 IMG Pointer ......................................... 6 3.2 Operation Set for IMG Delivery ...................... 6 3.2.1 IMG ANNOUNCE ........................................ 6 3.2.2 IMG QUERY ........................................... 7 3.2.3 IMG RESOLVE ......................................... 7 3.2.4 IMG SUBSCRIBE ....................................... 7 3.2.5 IMG NOTIFY .......................................... 8 3.2.6 Binding Between IMG Operations and Data Types ....... 8 3.3 IMG Entities ........................................ 9 3.4 Overview of Protocol Operations ..................... 10 4 Deployment Scenarios for IMG Entities ............... 10 4.1 Intermediary Cases .................................. 11 4.2 One-to-many Unidirectional Multicast ................ 12 4.3 One-to-one Bi-directional Unicast ................... 13 4.4 Combined Operations with Common Metadata ............ 14 5 Applicability of Existing Protocols to the Proposed Framework Model ............................ 14 5.1 Existing Standard Fit to the IMG Framework Model .... 14 5.2 Outstanding IMG Mechanism Needs ..................... 16 5.2.1 A Multicast Transport Protocol ...................... 16 5.2.2 Usage of Unicast Transport Protocols ................ 17 5.2.3 IMG Envelope ........................................ 17 5.2.4 Baseline (Meta)Data Model Specification ............. 18 5.3 IMG Needs Fitting the IETF's Scope .................. 196 Security Considerations ............................. 19 7 IANA Considerations ................................. 2120 8 Normative References ................................ 2120 9 Informative References .............................. 21 10 Acknowledgements .................................... 2221 11 Authors' Addresses .................................. 22 12 Full Copyright Statement ............................ 23 1 Introduction Internet Media Guides (IMGs) provide and deliver structured collections of multimedia descriptions expressed using SDP , SDPng  or other description formats. They are used to describe sets of multimedia services (e.g. television program schedules, content delivery schedules) 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. IMG metadata may 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 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. 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 guidelines for efficient delivery and description of IMG metadata. The data types give generalized means to deliver and manage the consistency of 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, a host involved in IMG operations performs one or more of the 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 the IMG requirements document . Then, this document outlines the use of existing protocols to create an IMG delivery infrastructure. It aims to organize existing protocols into a common model and show their capabilities and limitations from the viewpoint 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. 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 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 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 time bound series of IMG transport protocol interactions that provide delivery of IMG metadata from the IMG sender to the IMG receiver(s).  IMG Transfer: A transfer of IMG metadata consisting of Complete 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 Descriptions -- the descriptions (metadata) that are essential to enable (e.g. multicast) delivery. These include framing (headers) for application-specific metadata, the metadata element identification and structure, and fundamental session data. o Delivery Protocols -- the methods and protocols to exchange descriptions between the senders and the receivers. An IMG transport 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 to reduce the amount of the messaging. 3.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 IMG Descriptions, Delta IMG Descriptions and IMG Pointers. 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 element. Note, this is not to be confused with "complete IMG metadata", which, although vaguely defined here, represents the complete IMG metadata database of an IMG sender (or related group of IMG senders -- potentially the complete Internet IMG knowledge). An IMG sender will generally deliver only subsets of metadata from its complete database in a particular IMG 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. Delta transfers may be used to reduce network resource usage (it may be more bandwidth and congestion friendly), for instance when data consistency is essential and small and frequent changes occur to IMG elements. Thus, this description itself cannot represent a complete metadata set until it is combined with existing, or future, description knowledge. 3.1.3 IMG Pointer An IMG Pointer provides a simple identifier or locator, such as a 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 or Delta IMG Descriptions) or perform another IMG management function such as data expiry (and erasure). The IMG Pointer may be used to reference IMG metadata elements within the IMG transport session and across IMG transport sessions. This pointer type does not include IMG metadata per se (although it may also appear as a data field in Complete or Delta IMG descriptors). 3.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. 3.2.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 IMG 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 numbers of IMG receivers or the 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 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) enables IMG receivers to subscribe/register to the IMG ANNOUNCE operation. 3.2.2 IMG QUERY If an IMG receiver needs to obtain IMG metadata, an IMG receiver can use an IMG QUERY operation and initiate a receiver-driven IMG transport 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 an IMG sender's complete IMG metadata may be feasible, in others it may not. 3.2.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, the IMG sender can resolve the query; 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. 3.2.4 IMG SUBSCRIBE If an IMG receiver wants to be notified when the IMG metadata it holds is stale, the IMG receiver can use the IMG SUBSCRIBE operation in advance in order to solicit notify messages from an IMG sender. This operation may provide the IMG sender with specific details of which metadata or notification services it is interested in (in the case where the IMG sender offers more than the simplest "all data" service). This operation implicitly provides the functionality of unsubscribing to inform an IMG sender that an IMG receiver wishes to stop getting certain (or all) notifications. It should be noted that unsubscription may be provided implicitly by the expiry (timeout) of a subscription before it is renewed. However, these details belong to a messaging protocol instantiation of this operation are beyond the scope of this document. Since the IMG receiver does not know when metadata will be updated and the notify message will arrive, this operation does not synchronize with the notify messages. The IMG receiver may wait for notify messages for a long time. The IMG 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 asynchronously in response to an earlier IMG SUBSCRIBE. An IMG NOTIFY operation 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 the transferred IMG metadata so that changes can be easily handled and stale data identified, and give temporal validity of the transferred IMG metadata. It must expire the IMG metadata by indicating an expiry time, and may optionally provide a time (presumably in the future) from when the IMG metadata becomes valid. Temporal validity of IMG metadata may be changeable for an IMG transfer, and even for specific versions of the IMG transfer. Furthermore, the binding must be independent of the metadata 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 Figure 1 shows the 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 between IMG Entities, Senders and Receivers 3.4 Overview of Protocol Operations Figure 2 gives an overview of the relationship between transport cases, IMG Operations and IMG data types (note, it is not a protocol stack). Generalized multicast point-to-multipoint (P-to-M) and unicast point-to-point (P-to-P) transports are shown. +--------------------------------------------------+ 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 Transport, IMG Operations and IMG Data types 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 Sender | | IMG Receiver | | |--------------->| | +-------------+ +---------------+ Figure 3: A Simple IMG Sender to IMG Receiver Relationship 4.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. +----------+ +----------+ | 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. IMG metadata is used to find, obtain, manage and play content. IMG metadata distributions 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 metadata. 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 ones for more stable parts. 4.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 4.3 One-to-one Bi-directional Unicast Both query/resolve (Figure 6) and subscribe/notify (Figure 7) message exchange operations are feasible. The "time passes" activities of Figure 7 are purely for example. +----------+ +----------+ | IMG | | IMG | | Resolver | | Querier | +----------+ +----------+ | | |<----------IMG QUERY -----------| | | |----------IMG RESOLVE---------->| | | Figure 6: Query/Resolve Sequence Example +----------+ +------------+ | IMG | | IMG | | Notifier | | Subscriber | +----------+ +------------+ | | |<---------IMG SUBSCRIBE---------| : : (time passes) : : |-----------IMG NOTIFY---------->| : : (time passes) : : |-----------IMG NOTIFY---------->| | | Figure 7: Subscribe/Notify Sequence Example 4.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 sets of IMG metadata. 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 5 Applicability of Existing Protocols to the Proposed Framework Model 5.1 Existing Standard 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 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 cannot provide IMG Descriptions and IMG Pointers without significant unused overhead. It is expected that the information conveyed by SDP is just a small subset of IMG metadata, thus the use of SDP for other than session 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 should be 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. MPEG-7 is based on XML so it is well suited for combining with other XML-based formats such as SDPng. TV-Anytime Forum: The TV-Anytime Forum  provides descriptions based on XML schema for TV-specific program guides. TV-Anytime uses the MPEG-7 User description profile to a limited extent (for user preferences and usage history) and also a TV-Anytime-specific data model for other schema - which are optimised to describe broadcast schedules, on-demand program guides and program events. 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 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-directional unicast connection. However, there are scalability problems with this approach, as RFC 3265 currently does not consider multicast. RTSP: The RTSP protocol defines a retrieval and update notification mechanism, named DESCRIBE and ANNOUNCE, for the description of a presentation or media object in order to initialize a streaming session. These methods are subset of the entire streaming control operations in RTSP, thus these could not be available for individual mechanisms. However, the DESCRIBE method in RTSP could be use to instantiate IMG QUERY, IMG RESOLVE and IMG SUBSCRIBE, and the RTSP ANNOUNCE could be use to instantiate an IMG NOTIFY for a streaming session controlled by RTSP. 5.2 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; (d) agreement on basic metadata models to enable interoperability testing of the above. The following sections describe each of these. 5.2.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 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 IMG ANNOUNCE operation must be supported and IMG NOTIFY capability could be investigated for both hybrid unicast-multicast and unidirectional unicast systems. 5.2.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 point-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 IMG SUBSCRIBE-NOTIFY and IMG QUERY-RESOLVE operation pairs must be enabled. We anticipate that the IMG QUERY-RESOLVE operation will be a trivial usage of HTTP, although other transport protocol options may be beneficial to consider too. 5.2.3 IMG Envelope Section 3.2.6 of this document discussed the need for binding between IMG Operations and Data Types. Such a binding can be realized by defining a common minimal set of information needed to manage IMG metadata transfers, and by including this information with any set of IMG metadata delivered to IMG receiver(s). Four options for IMG metadata transfer envelope delivery 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 would hinder interoperability and transport protocol independence. 2. A separate envelope object, which points to the IMG metadata 'object', delivered in-band with the metadata transport protocol session. This might 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 RTCP ). This would also enable schemes which deliver enveope and metadata 'objects' on by different media, also using more than a single transport protocol. 3. A metadata wrapper which points to and/or embeds the service metadata into its 'super-syntax'. For example, an XML would enable 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. It 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. When there are superset/subset relations between IMG descriptions, it is assumed that the IMG descriptions of the subset inherit the parameters of the superset. Thus, an IMG metadata transfer envelope carrying the IMG descriptions of a superset may implicitly define parameters of IMG descriptors belonging to its subset. The relations between IMG descriptions may span from one envelope to another according to a data model definition. 5.2.4 Baseline (Meta)Data Model Specification A minimal IMG data model may be useful to any implementer/deployment of IMGs. The purpose would be to ensure that multiple metadata syntaxes (SDP, MPEG-7, etc.) can be related within the same body of IMG knowledge, regardless of any specific metadata and data models provided by the metadata syntaxes. Further work may be needed to meet application-specific requirements at defining metadata and data models for the successful deployment of IMGs in various environments. Existing (and future) work on these would need to be mapped to the IMG data types and use of the IMG transfer envelope concept as described above. This document is a framework for the delivery of IMG metadata and thus further discussion on the definition data models for IMGs is beyond its scope. 5.3 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 IMG metadata 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 IMG 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. This aspect need 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 may not be required for this.6 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 if the original information were public. Snooping 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 IMG metadata contains. Further consideration is valuable at network, 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 IMG transport methods do 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 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. 7 IANA Considerations There are no IANA considerations within this document. 8 Normative References  S. Bradner, "Key words for use in RFCs to indicate requirement levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. 9 Informative References  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.  Y. Nomura, R. Walsh, J-P. Luoma, J. Ott, and H. Schulzrinne, "Requirements for Internet Media Guides," Internet Draft draft-ietf-mmusic-img-req-07, Internet Engineering Task Force, June 2004. Work in progress.  TV-Anytime Forum, "Broadcast and On-line Services: Search, select, and rightful use of content on personal storage systems ("TV-Anytime Phase 1"); Part 2: System description," ETSI-TS 102 822-2: System Description, V1.1.1, October 2003.  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.  T. Paila, M. Luby, R. Lehtonen, V. Roca, R. Walsh, "FLUTE - file delivery over unidirectional transport," Internet Draft draft-ietf-rmt-flute-08, Internet Engineering Task Force, June 2004. Work in progress.  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.  R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, L. Masinter, P. Leach and T. Berners-Lee, "Hypertext transfer protocol -- HTTP/1.1," RFC 2616, Internet Engineering Task Force, June 1999.  H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: a transport protocol for real-time applications," RFC 3550, Internet Engineering Task Force, July 2003. 10 Acknowledgements The authors would like to thank Joerg Ott, Colin Perkins, Toni Paila, Jean-Pierre Evain, Magnus Westerlund and Petri Koskelainen for their excellent ideas and input to this document. 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 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: email@example.com 12 Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- firstname.lastname@example.org.