idnits 2.17.1 draft-ietf-mmusic-img-framework-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 554 has weird spacing: '...rection v ...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 2, 2003) is 7450 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-08) exists of draft-ietf-mmusic-img-req-00 ** Downref: Normative reference to an Informational draft: draft-ietf-mmusic-img-req (ref. '2') ** Obsolete normative reference: RFC 3466 (ref. '3') (Obsoleted by RFC 7336) ** Obsolete normative reference: RFC 2327 (ref. '4') (Obsoleted by RFC 4566) == Outdated reference: A later version (-08) exists of draft-ietf-mmusic-sdpng-07 -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' ** Obsolete normative reference: RFC 2068 (ref. '8') (Obsoleted by RFC 2616) ** Downref: Normative reference to an Experimental RFC: RFC 2974 (ref. '9') ** Obsolete normative reference: RFC 3265 (ref. '11') (Obsoleted by RFC 6665) ** Obsolete normative reference: RFC 3450 (ref. '13') (Obsoleted by RFC 5775) == Outdated reference: A later version (-08) exists of draft-ietf-rmt-flute-06 Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force MMUSIC WG 3 Internet Draft Y. Nomura 4 Fujitsu Labs. 5 R. Walsh 6 J-P. Luoma 7 Nokia 8 H. Asaeda 9 INRIA 10 H. Schulzrinne 11 Columbia University 12 draft-ietf-mmusic-img-framework-01.txt 13 December 2, 2003 14 Expires: March 2004 16 A Framework for the Usage of Internet Media Guides 18 STATUS OF THIS MEMO 20 This document is an Internet-Draft and is in full conformance with 21 all provisions of Section 10 of RFC2026. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress". 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 To view the list Internet-Draft Shadow Directories, see 37 http://www.ietf.org/shadow.html. 39 Abstract 41 This document defines a framework for the delivery of Internet Media 42 Guides (IMGs). An IMG is a structured collection of multimedia 43 session descriptions expressed using SDP, SDPng or some similar 44 session description format. This document describes several use case 45 scenarios requirering the IMG framework, a generalized model for IMG 46 delivery mechanisms, and the use of existing protocol to create an 47 IMG delivery infrastructure. 49 Table of Contents 50 1 Introduction ........................................ 3 51 1.1 Background and Motivation ........................... 3 52 1.2 Scope of this Document .............................. 4 53 2 Terminology ......................................... 4 54 3 Use Cases Requiring IMG Framework ................... 5 55 3.1 Connectivity-based Use Cases ........................ 5 56 3.1.1 IP Datacast to a Wireless Receiver .................. 5 57 3.1.2 Regular Fixed Dial-up Internet Connection ........... 6 58 3.1.3 Broadband Always-on Fixed Internet Connection ....... 6 59 3.2 Content-orientated Use Cases ........................ 6 60 3.2.1 File Distribution ................................... 7 61 3.2.2 TV and Radio Program Delivery ....................... 7 62 3.2.3 Media Coverage of a Live Event ...................... 8 63 3.2.4 Distance Learning ................................... 8 64 3.2.5 Multiplayer Gaming .................................. 8 65 4 IMG Common Framework Model .......................... 8 66 4.1 IMG Data Types ...................................... 9 67 4.1.1 Complete Description ................................ 9 68 4.1.2 Delta Description ................................... 9 69 4.1.3 Pointer ............................................. 10 70 4.2 Operation Set for IMG Delivery ...................... 10 71 4.2.1 IMG ANNOUNCE ........................................ 10 72 4.2.2 IMG QUERY ........................................... 10 73 4.2.3 IMG RESOLVE ......................................... 11 74 4.2.4 IMG SUBSCRIBE ....................................... 11 75 4.2.5 IMG NOTIFY .......................................... 11 76 4.3 IMG Entities ........................................ 12 77 4.4 Overview of Protocol Operations ..................... 12 78 5 Deployment Scenarios for IMG Entities ............... 13 79 5.1 Intermediary Cases .................................. 13 80 5.2 One-to-many Unidirectional Multicast ................ 15 81 5.3 One-to-one Bi-directional Unicast ................... 15 82 5.4 Combined Operations with Common Metadata ............ 16 83 6 Applicability of Existing Protocols to the 84 Proposed Framework Model ....................................... 17 85 6.1 Summary of Limitations of Existing Protocols ........ 17 86 6.2 Existing Protocol Fit to the IMG Framework Model 87 6.3 Outstanding IMG Mechanism Needs ..................... 19 88 6.3.1 A Multicast Transport Protocol ...................... 19 89 6.3.2 Usage of Unicast Transport Protocols ................ 20 90 6.3.3 The Metadata Envelope ............................... 20 91 6.3.4 Baseline (Meta)Data Model Specification ............. 21 92 6.4 IMG Needs Fitting the IETF's Scope .................. 22 93 7 Security Considerations ............................. 23 94 8 Normative References ................................ 24 95 9 Informative References .............................. 25 96 10 Acknowledgements .................................... 26 97 11 Authors' Addresses .................................. 26 99 1 Introduction 101 1.1 Background and Motivation 103 Internet Media Guide (IMG) provide structured collections of 104 multimedia descriptions expressed using SDP, SDPng or some similar 105 description format. It is used to describe sets of multimedia 106 sessions (e.g. television program schedules, content delivery 107 schedules etc.) and refer to other networked resources including web 108 pages. IMGs provide an envelope for metadata formats and session 109 descriptions defined elsewhere with the aim of facilitating 110 structuring, versioning, referencing, distributing, and maintaining 111 (caching, updating) such information. 113 Firstly, this document explains several use case scenarios requiring 114 the IMG framework. IMGs are inherently required to be independent of 115 any particular access network, and link in general. Therefore, they 116 are suitable in many Internet access scenarios including fixed and 117 mobile devices, wired and satellite and terrestrial radio, always-on 118 Internet and intermittent connectivity, and so on. Furthermore, IMGs 119 provides essential functions that facilitate better distribution of 120 content. Section 3 describes how IMGs and IMG delivery mechanisms 121 contribute for the scenarios. 123 Then, this document defines a generalized model for IMG delivery 124 mechanisms and their deployment in network entities regarding the use 125 case scenarios. IMG metadata must be delivered to a potentially large 126 audience, who use it to join a subset of the sessions described, and 127 who may need to be notified of changes to the IMG metadata. Hence, a 128 framework for distributing IMG metadata in various different ways is 129 needed to accommodate the needs of different audiences: For 130 traditional broadcast-style scenarios, multicast-based (push) 131 distribution of IMG metadata needs to be supported. Where no 132 multicast is available, unicast-based push is required, too. 134 Finally, this document outlines the use of existing protocols to 135 create an IMG delivery infrastructure. It aims to organize existing 136 protocols into common model and show their capabilities and 137 limitations from the view point of IMG delivery functions. One of the 138 multicast-enabling IMG requirements is scaling well to a large number 139 of hosts and IMG senders in a network. Another issue is the need for 140 flexibility and diversity in delivery methods, whereas existing 141 protocols tend to be bound to a specific application. 143 1.2 Scope of this Document 145 This document defines a common framework model for the delivery of 146 Internet Media Guide (IMG) metadata. The framework describes existing 147 mechanisms and the level to which they support and enable the 148 framework. The requirements for IMG delivery mechanisms and 149 descriptions can be found in [1]. 151 A brief run through the usage and use cases of media guide is 152 provided to illustrate the relevance of IMGs before the framework 153 model is presented. The framework model defines the data types, 154 operations and entities which are needed. These are then shown in a 155 number of simplified deployment scenarios. 157 Existing protocols are organized and referenced against the framework 158 model to show the degree to which they fulfill IMG framework and 159 requirements. This also makes it straightforward to identify gaps so 160 that new protocols needs are made apparent. 162 2 Terminology 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 166 document are to be interpreted as described in RFC 2119 [1]. 168 Internet Media Guide (IMG): IMG is a generic term to describe 169 the formation, delivery and use of IMG metadata. The 170 definition of the IMG is intentionally left imprecise. 172 IMG Metadata: This is a set of metadata describing the features 173 of multimedia content used to enable selection of and 174 access to media sessions containing content. For example, 175 metadata may consist of the URI, title, airtime, bandwidth 176 needed, file size, text summary, genre, and access 177 restrictions. 179 IMG Delivery: The process of exchanging IMG metadata both in 180 terms of large scale and atomic data transfers. 182 IMG Sender: An IMG sender is a logical entity that sends IMGs to 183 one or more IMG receivers. 185 IMG Receiver: An IMG receiver is a logical entity that receives 186 IMGs from an IMG sender. 188 IMG Transceiver: An IMG transceiver combines an IMG receiver and 189 sender. It may modify original IMGs or merge several IMGs 190 from a different IMG sender. 192 IMG Operation: An atomic process for the IMG transport protocol 193 to deliver IMG metadata or control IMG sender(s) or IMG 194 receiver(s). 196 IMG Transport Protocol: A protocol that transports IMG metadata 197 from IMG sender to IMG receiver(s) 199 3 Use Cases Requiring IMG Framework 201 3.1 Connectivity-based Use Cases 203 3.1.1 IP Datacast to a Wireless Receiver 205 IP Datacast is the delivery of IP-based services over broadcast 206 radio. Internet content delivery is therefore unidirectional in this 207 case. However, there can be significant benefits from being able to 208 provide rich media one-to-many services to such receivers. 210 There are two main classes of receiver in this use case: fixed 211 mains-powered; and mobile battery-powered. Both of these are affected 212 by radio phenomena and so robust, or error-resilient, delivery is 213 important. Carouselled metadata transfer provides a base level of 214 robustness for an IP datacast based announcement system, although the 215 design of carouselled transfer should enable battery-powered 216 receivers to go through periods of sleep to extend their operational 217 time between charges. Insertion of Forward Error Correction (FEC) 218 data into metadata announcements improves error resilience, and 219 reordering (interleaving) data blocks further increases tolerance to 220 burst errors. 222 To enable receivers to more accurately specify the metadata they are 223 interested in, the unidirectional delivery is distributed between 224 several logical channels. This is so that a receiver need only access 225 the channels of interest and thus can reduce the amount of time and 226 processing of IP data (and storage). Also, hierarchical channels 227 enable receivers to subscribe to a root, possibly well known, 228 multicast channel/group and progressively access only those 229 additional channels based on metadata in parent channels. 231 In some cases the receiver may be multi-access, such that it is 232 capable of bi-directional communications. This enables a multitude of 233 options, but most importantly it enables NACK based reliability and 234 the individual retrieval of missed or not-multicasted sets of 235 metadata. 237 Thus, essential IMG features in this case include: robust 238 unidirectional delivery (with optional levels of reliability 239 including "plug-in FEC") which implies easily identifiable 240 segmentation of delivery data to enable FEC, carousel, interleaving 241 and other schemes possible; effective identification of metadata sets 242 (probably uniquely) to enable more efficient use of multicast and 243 unicast retrieval over multiple access systems regardless of the 244 parts of metadata and application specific extensions in use; 245 prioritization of metadata, which can (for instance) be achieved by 246 spreading it between channels and allocating/distributing bandwidth 247 accordingly. 249 Furthermore, some cases require IMG metadata authentication and some 250 group security/encryption and supporting security message exchanges 251 (out of band from the IMG multicast sessions). 253 3.1.2 Regular Fixed Dial-up Internet Connection 255 Dial-up connections tend to be reasonably slow (<56kbps in any case) 256 and thus large data transfers are less feasible, especially during an 257 active application session (such as a file transfer described by IMG 258 metadata). They can also be intermittent, especially if a user is 259 paying for the connected time, or connected through a less reliable 260 exchange. Thus this favors locally stored IMG metadata over web-based 261 browsing, especially where parts of the metadata change infrequently. 262 There may be no service provider preference over unicast and 263 multicast transport for small and medium numbers of users as the 264 last-mile dial-up connection limits per-user congestion, and a user 265 may prefer the more reliable option (unicast unless reliable 266 multicast is provided). 268 3.1.3 Broadband Always-on Fixed Internet Connection 270 Typically bandwidth is less of an issue to a broadband user and 271 unicast transport, such as using IMG QUERY, may be typical for a PC 272 user. If a system were only used in this context, with content 273 providers, ISPs and users having no other requirements, then web- 274 based browsing may be equally suitable. However, broadband users 275 sharing a local area network, especially wireless, may benefit more 276 from local storage features than on-line browsing, especially if they 277 have intermittent Internet access. 279 Broadband enables rich media services, which are increasingly 280 bandwidth hungry. Thus backbone operators may prefer multicast 281 communications to reduce overall congestion, if they have the 282 equipment and configuration to support this. Thus, broadband users 283 may be forced to retrieve IMG metadata over multicast if the 284 respective operators require this to keep system-wide bandwidth usage 285 feasible. 287 3.2 Content-orientated Use Cases 288 IMGs will be able to support a very wide range of use cases for 289 content/media delivery. The following few sections just touch the 290 surface of what is possible and are intended to provide an 291 understanding of the scope and type of IMG usage. Many more examples 292 may be relevant, for instance those detailed in[3]. There are 293 several unique features of IMGs that set them apart from related 294 application areas such as SLP based service location discovery, LDAP 295 based indexing services and search engines such as Google. Features 296 unique to IMGs include: 298 o IMG metadata is generally time-related 300 o There are timeliness requirements in the delivery of IMG 301 metadata 303 o IMG metadata may be updated as time elapses or when an event 304 arises 306 3.2.1 File Distribution 308 IMGs support the communication of file delivery session properties, 309 enabling the scheduled delivery or synchronization of files between a 310 number of hosts. For example, the metadata that IMGs provide could be 311 subsequently used by a different application (outside the scope of 312 IMGs) to download a file with a software update. An IMG metadata can 313 provide a description to each file in a file delivery session, 314 assisting users or receiving software in selecting individual files 315 for reception. 317 For example, when a content provider wants to distribute a large 318 amount of data in file format to thousands clients, the content 319 provider can use IMG metadata to schedule the delivery effectively. 320 Since IMG metadata can describe time-related data for each receiver, 321 the content provider can schedule delivery time for each receiver. 322 This can save network bandwidth and capacity of delivery senders. In 323 addition, IMG metadata can be used to synchronize a set of files 324 between a sender host and receiver host, when those files change as 325 time elapses. 327 3.2.2 TV and Radio Program Delivery 329 A sender of audio/video streaming content can use the IMG metadata to 330 describe the scheduling and other properties of audio/video sessions 331 and events within those sessions, such as individual TV and radio 332 programs and segments within those programs. IMG metadata describing 333 audio/video streaming content could be represented in a format 334 similar to that of a TV guide in newspapers, or an Electronic Program 335 Guide available on digital TV receivers. 337 Similarly to file reception, TV and radio programs can be selected 338 for reception either manually by the end-user or automatically based 339 on the content descriptions and the preferences of the user. The 340 received TV and radio content can be either presented in real time or 341 recorded for consuming later. There may be changes in the scheduling 342 of a TV or a radio program, possibly affecting the transmission times 343 of subsequent programs. IMG metadata can be used to notify receivers 344 of such changes, enabling users to be prompted or recording times to 345 be adjusted. 347 3.2.3 Media Coverage of a Live Event 349 The media coverage of a live event such as a rock concert or a sports 350 event is a special case of regular TV/radio programming. There may be 351 unexpected changes in the scheduling of live event, or the event may 352 be unscheduled to start with (such as breaking news). In addition to 353 audio/video streams, textual information relevant to the event (e.g. 354 statistics of the players during a football match) may be sent to 355 user terminals. Different transport modes or even different access 356 technologies could be used for the different media: for example, a 357 unidirectional datacast transport could be used for the audio/video 358 streams and an interactive cellular connection for the textual data. 359 IMG metadata should enable terminals to discover the availability of 360 different media used to cover a live event. 362 3.2.4 Distance Learning 364 IMG metadata could describe compound sessions or services enabling 365 several alternative interaction modes between the participants. For 366 example, the combination of one-to-many media streaming, unicast 367 messaging and download of presentation material could be useful for 368 distance learning. 370 3.2.5 Multiplayer Gaming 372 Multiplayer games are an example of real-time multiparty 373 communication sessions that could be advertised using IMGs. A gaming 374 session could be advertised either by a dedicated server, or by the 375 terminals of individual users. A user could use IMGs to learn of 376 active multiplayer gaming sessions, or advertise the users interest 377 in establishing such a session. 379 4 IMG Common Framework Model 381 Two common elements are found in all of existing IMG candidate cases: 382 the need to describe the services; the need to deliver the 383 descriptions. In some cases, the descriptions are multicast enablers 384 (such as the session parameters of SDP) and are thus intrinsically 385 part of the delivery aspects, and in other cases descriptions are 386 application-specific (both machine and human readable). Thus, the 387 technologies can be roughly divided into three areas: 389 o Application-specific Metadata -- data describing the services' 390 content and media which are both specific to certain 391 applications and generally human readable. 393 o Delivery Descriptors -- the descriptors (metadata) that are 394 essential to enable (e.g. multicast) delivery. These include 395 framing (headers) for application-specific metadata, the 396 metadata element identification and structure, fundamental 397 session descriptors. 399 o Delivery Protocols -- the methods and protocols to exchange 400 descriptions between the senders and the receivers. An IMG 401 delivery protocol consists of two functions: carrying IMG 402 metadata from an IMG sender to an IMG receiver and controlling 403 an IMG transport protocol. These functions are not always 404 exclusive, therefore some messages may combine control 405 messages and metadata carriage functions metadata to reduce 406 the amount of the messaging. 408 4.1 IMG Data Types 410 A data model is needed to precisely define the terminology and 411 relationships between sets, supersets and subsets of metadata. A 412 precise data model is essential for the implementation of IMGs 413 although it is not within the scope of this framework and requires a 414 separate specification. However there are three IMG data types in 415 general: Complete description, delta description and pointer. 417 4.1.1 Complete Description 419 A Complete Description provides a complete syntax and semantics to 420 describe a set of metadata, which does not need any additional 421 information from other IMG entity. 423 Note, this is not to be confused with "complete IMG metadata", which, 424 although vaguely defined here, represents the complete database of a 425 sender (or related group of senders -- potentially the complete 426 Internet IMG knowledge). A sender will generally deliver only subsets 427 of metadata from its complete database of metadata in a particular 428 data exchange. 430 4.1.2 Delta Description 432 A Delta Description provides only part of a Complete Description, 433 defining the difference from a previous version of the Complete 434 Description in question. This descriptor may be used to reduce 435 network resource usage (it may be more bandwidth and congestion 436 friendly), for instance, data consistency is essential and, small and 437 frequent changes occur to the Complete Description. Thus, this 438 descriptor itself cannot represent complete metadata set until it is 439 combined with existing, or future, description knowledge. 441 4.1.3 Pointer 443 A pointer provided a simple identifier or locator, such as a URL, 444 that the receiver is able to reference (or reference and locate) 445 specific metadata with. This may be used to separately obtain 446 metadata (complete or delta descriptions) or perform another IMG 447 management function such as data expire (and erasure). The pointer 448 may be used to reference IMG metadata elements within the IMG 449 transport session and across IMG transport sessions. The pointer does 450 not include metadata par se (although it may also appear as a data 451 field in complete or delta descriptors). 453 4.2 Operation Set for IMG Delivery 455 A finite set of operations both meets the IMG requirements [2] and 456 fits the roles of existing protocols. These are crystallized in the 457 next few sections. 459 4.2.1 IMG ANNOUNCE 461 When an IMG receiver participates in unidirectional communications 462 (e.g. over satellite, terrestrial radio and wired multicast networks) 463 an IMG receiver may not need to send any message to an IMG sender 464 prior to IMG metadata delivery. In this case, an IMG sender can 465 initiate unsolicited distribution for IMG metadata and an IMG sender 466 is the only entity which can maintain the distribution (this includes 467 scenarios with multiple and co-operative senders). This operation is 468 useful when there are considerably large number IMG receivers or IMG 469 receiver(s) do not have a guaranteed uplink connection to the IMG 470 sender(s). The sender may also include authentication data in the 471 announce operation so that receivers may check the authenticity of 472 the metadata. This operation is able to carry any of the IMG data- 473 types. 475 Note, there is no restriction to prevent IMG ANNOUNCE from being used 476 in an asynchronous solicited manner, where a separate operation 477 (possibly out of band) is able to subscribe/register receivers to the 478 IMG ANNOUNCE operation. 480 4.2.2 IMG QUERY 481 If an IMG receiver needs to obtain IMG metadata, an IMG receiver can 482 send an IMG QUERY message and initiate a receiver-driven IMG delivery 483 session. The IMG receiver expects a synchronous response to the 484 subsequent request from the IMG sender. This operation can be used 485 where a bi-directional transport network is available between the IMG 486 sender and receiver. Some IMG receivers may want to obtain IMG 487 metadata when a resource is available or just to avoid caching 488 unsolicited IMG metadata. The IMG receiver must indicate the extent 489 and data type of metadata wanted in some message in the operation 490 (Extent indicates the number and grouping of metadata descriptions). 491 In some cases requesting a sender's complete IMG metadata may be 492 feasible, in others it may not. 494 4.2.3 IMG RESOLVE 496 An IMG sender synchronously responds and sends IMG metadata to an IMG 497 QUERY which has been sent by an IMG receiver. This operation can be 498 used where a bi-directional transport network is available between 499 the IMG sender and receiver. If the IMG QUERY specifies a subset of 500 IMG metadata (extent and data type) that the IMG sender has the 501 subset, the IMG sender can resolve this, otherwise it should indicate 502 that it is not able to resolve the query. The IMG sender may 503 authenticate the IMG receiver to investigate the IMG QUERY operation 504 in order to determine whether the IMG receiver is authorized to be 505 sent that metadata. The sender may also include authentication data 506 in the resolve operation so that receivers may check the authenticity 507 of the metadata. This operation may carry any of the IMG data types. 509 4.2.4 IMG SUBSCRIBE 511 If an IMG receiver wants to be notified when metadata which the IMG 512 receiver holds is stale, the IMG receiver can start the IMG SUBSCRIBE 513 operation prior in order to solicit notify messages. Since the IMG 514 receiver doesn't know when metadata will be updated and the notify 515 message will arrive, this operations does not synchronize with the 516 notify message. The IMG receiver may wait for the notify message for 517 a long time. The IMG sender may authenticate the IMG receiver to 518 investigate whether an IMG SUBSCRIBE operation is from an authorized 519 receiver. 521 4.2.5 IMG NOTIFY 523 An IMG receiver needs the response to an earlier IMG SUBSCRIBE and 524 the IMG NOTIFY indicates that updated IMG metadata is available or 525 part of the existing IMG metadata is stale. An IMG NOTIFY may be 526 delivered more than once during the time an IMG SUBSCRIBE is active. 527 This operation may carry any of the IMG data types. The sender may 528 also include authentication data in the notify operation so that 529 receivers may check the authenticity of the messages. 531 4.3 IMG Entities 533 There are several fundamental IMG entities that indicate the 534 capability to perform certain roles. An Internet host involved in IMG 535 operations may adopt one or more of these roles: 537 IMG Announcer : send IMG ANNOUNCE 538 IMG Listener : receive IMG ANNOUNCE 539 IMG Querier : send IMG QUERY to receive IMG RESOLVE 540 IMG Resolver : receive IMG QUERY then send IMG RESOLVE 541 IMG Subscriber: send IMG SUBSCRIBE then receive IMG NOTIFY 542 IMG Notifier : receive IMG SUBSCRIBE then send IMG NOTIFY 544 Finally, the figure 1 shows a relationship between IMG entities and 545 the IMG sender and receiver. 547 +--------------------------------------------------------+ 548 | IMG Sender | 549 +------------------+------------------+------------------+ 550 | IMG Announcer | IMG Notifier | IMG Resolver | 551 +------------------+------------------+------------------+ 552 | ^ ^ 553 message | | | 554 direction v v v 555 +------------------+------------------+------------------+ 556 | IMG Listener | IMG Subscriber | IMG Querier | 557 +------------------+------------------+------------------+ 558 | IMG Receiver | 559 +------------------+------------------+------------------+ 561 Figure 1: Relationship with IMG Entities 563 4.4 Overview of Protocol Operations 565 The figure 2 gives an overview of the relationship between transport 566 cases, IMG Operations and IMG data types (note, it is not a protocol 567 stack). 569 +--------------------------------------------------+ 570 IMG | | 571 Data types | Complete Desc., Delta Desc., Pointer | 572 | | 573 +-------------------+----------------+-------------+ 574 IMG | IMG ANNOUNCE | IMG SUBSCRIBE | IMG QUERY | 575 Operations | | IMG NOTIFY | IMG RESOLVE | 576 +--------------+----+----------------+-------------+ 577 IMG | | | 578 Transport | P-to-M | P-to-P | 579 | | | 580 +--------------+-----------------------------------+ 582 Figure 2: IMG Operations and IMG Data type 584 5 Deployment Scenarios for IMG Entities 586 This section provides some basic deployment scenarios for IMG 587 entities that illustrate common threads from protocols to use cases. 588 For the purposes of clarity, this document presents the simple 589 dataflow from sender to receiver as shown in figure 3 591 +-------------+ +---------------+ 592 | IMG Sender | | IMG Receiver | 593 | |--------------->| | 594 +-------------+ +---------------+ 596 Figure 3: A Simple IMG Sender to IMG Receiver Relationship 598 5.1 Intermediary Cases 600 Some IMG metadata may be distributed to a large number of receivers. 601 If, for example, some IMG metadata is public information and the 602 sender provides the same information for all receivers. This kind of 603 IMG metadata may be distributed from one sender to multiple receivers 604 (Figure 4) and/or or may be relayed across a set of IMG transceivers 605 that receive the IMG metadata, possibly filter or modify its content, 606 and then forward it. The relayed network architecture is similar to 607 content distribution network architecture [3] (CDNs). Existing CDNs 608 may carry IMG metadata. Satellite and peer-to-peer networks may also 609 carry IMG metadata. 611 +----------+ +----------+ 612 | IMG | | IMG | 613 | Sender |---- ---->| Receiver | 614 +----------+ \ / +----------+ 615 \ / 616 . \ +-----------+ / . 617 . -->|IMG |----- . 618 . -->|Transceiver| \ . 619 / +-----------+ \ 620 +----------+ / \ +----------+ 621 | IMG | / ---->| IMG | 622 | Sender |---- | Receiver | 623 +----------+ +----------+ 625 Figure 4: A Relay Network with an IMG Transceiver 627 IMG senders and receivers are logical functions and it is possible 628 for some or all hosts in a system to perform both roles, as, for 629 instance, in many-to-many communications or where a transceiver is 630 used to combine or aggregate IMG metadata for some receivers. An IMG 631 receiver may be allowed to receive IMG metadata from any number of 632 senders. 634 The IMG metadata is used to find, obtain, manage and play content. 635 The IMG metadata distribution may be modified as they are 636 distributed. For example, a server may use IMGs to retrieve media 637 content via unicast and then make it available at scheduled times via 638 multicast, thus requiring a change of the corresponding metadata. IMG 639 transceivers may add or delete information or aggregate IMG metadata 640 from different senders. For example, a rating service may add its own 641 content ratings or recommendations to existing meta-data. An 642 implication of changing (or aggregating) IMG metadata from one or 643 more senders is that the original authenticity is lost. Thus for 644 deployments requiring these kind of features, the original metadata 645 should be reasonably fragmented already (allowing the intermediary to 646 replace a small fragment without changing the authenticity of the 647 remainder). It may be beneficial to use smaller fragments for more 648 volatile parts, and larger one for more stable parts. 650 5.2 One-to-many Unidirectional Multicast 652 This case implies many receivers and one or more senders implementing 653 IMG ANNOUNCER and IMG LISTENER operations as shown in figure 5. 655 Unidirectional +----------+ 656 ---------------> | IMG | 657 downlink | Listener | 658 ------------->| 1 | 659 / +----------+ 660 +-----------+ / . 661 | IMG |-------- . 662 | Announcer | \ . 663 +-----------+ \ +----------+ 664 ------------->| IMG | 665 | Listener | 666 | # | 667 +----------+ 669 Figure 5: IMG Unidirectional Multicast Distribution Example 671 5.3 One-to-one Bi-directional Unicast 673 +----------+ +----------+ 674 | IMG |<------(1)------| IMG | 675 | Resolver |-------(2)----->| Querier | 676 +----------+ +----------+ 678 Figure 6: Query/Resolve Deployment Example 680 Both query/resolve (figure 6) and subscribe/notify (figure 7) message 681 exchange operations are feasible. 683 +----------+ +------------+ 684 | |<-------(1)--------| | 685 | IMG |--------(2)------->| IMG | 686 | Notifier | (time passes) | Subscriber | 687 | |--------(3)------->| | 688 +----------+ +------------+ 690 Figure 7: Subscribe/Notify Deployment Example 692 5.4 Combined Operations with Common Metadata 694 As shown in figure 8, a common data model for multiple protocol 695 operations allows a diverse range of senders and receivers to provide 696 consistent and interoperable IMGs. 698 IMG Metadata IMG Senders IMG Receivers 700 +--------------+ 701 +-----------+ ---->| IMG Listener | 702 | IMG | / +--------------+ 703 /| Announcer |----- 704 +-------------+ / +-----------+ \ +--------------+ 705 | IMG |-+ / ---->| IMG Listener | 706 | Description | |-+ / | - - - - - - -| 707 | metadata 1 | | | / +-----------+ /--->| IMG Querier | 708 +-------------+ | | -----| IMG |<----/ +--------------+ 709 +-------------+ | \ | Resolver | 710 +-------------+ \ +-----------+<----\ +--------------+ 711 \ \--->| IMG Querier | 712 \ +-----------+ | - - - - - - -| 713 \| IMG |<--------->| IMG | 714 | Notifier | | Subscriber | 715 +-----------+ +--------------+ 717 Figure 8: Combined System with Common Metadata 719 6 Applicability of Existing Protocols to the Proposed Framework Model 721 6.1 Summary of Limitations of Existing Protocols 723 SDP [4] has a text-encoded syntax to specify multimedia sessions for 724 announcements and invitations. Although SDP is extensible, it has 725 limitations such as structured extensibility and capability to carry 726 another multimedia session descriptors. 728 These are mostly overcome by the XML-based SDPng [5] , which is 729 intended for both two-way negotiation and also unidirectional 730 delivery. Since SDPng addresses multiparty multimedia conferences, it 731 is necessary to extend the XML schema in order to describe general 732 multimedia content. 734 MPEG-7 [6] is a collection of XML-based description tools for general 735 multimedia content including structured multimedia sessions. TV- 736 Anytime Forum [7] provides descriptions based on MPEG-7 for TV 737 specific program guides. These are likely to be limited to describe 738 pictures, music and movies, thus it may be necessary to extend these 739 descriptions in order to define a variety of documents, game 740 programs, binary files, live event and so on. 742 HTTP [8] is a well known information retrieval protocol using bi- 743 directional transport and widely used to deliver web-based content 744 descriptions to many hosts. However, it has well recognized 745 limitations of scalability in the number of HTTP clients since it 746 relies on the polling mechanism to keep information consistent 747 between the server and client. 749 SAP [9] is an announcement protocol that distributes session 750 descriptions via multicast. It does not support fine-grained meta 751 data selection and update notifications, as it always sends the whole 752 meta data. Given the lack of a wide-area multicast infrastructure, it 753 is likely only deployable within a local area network. 755 SIP [10] and SIP-specific event notification [11] can be used to 756 notify subscribers of the update of IMG metadata for bi-directional 757 transport. It is necessary for SIP Event to define an event package 758 for each specific application such as [12]. 760 6.2 Existing Protocol Fit to the IMG Framework Model 762 SDP: The SDP format could be used to describe session-level 763 parameters (e.g. scheduling, addressing and the use of media codecs) 764 to be included in Complete Descriptors. Although there are extension 765 points in SDP allowing the format to be extended, there are 766 limitations in the flexibility of this extension mechanism. However, 767 SDP syntax can not provide with Partial Descriptors and Pointers 768 without significant unused overhead. Because it is expected that the 769 information conveyed by SDP is just a small subset of IMG metadata 770 the use of SDP for other than session-level IMG parameters may not be 771 reasonable. 773 SDPng: Similar to SDP, this format could also be used for 774 representing session-level parameters of IMG metadata. Compared to 775 SDP, the XML-based format of SDPng is much more flexible with regards 776 to extensions and combining with other description formats. 778 MPEG-7: Descriptions based on the MPEG-7 standard could provide 779 application-specific metadata describing the properties of multimedia 780 content beyond parameters carried in SDP or SDPng descriptions. 781 MPEG-7 provides a machine-readable format of representing content 782 categories and attributes, helping end-users or receiving software in 783 choosing content for reception: this is well in line with the IMG 784 usage scenarios of IMGs introduced in 3.2. Because MPEG-7 is based on 785 XML, it is well suited for combining with other XML-based formats 786 such as SDPng. 788 HTTP: The HTTP protocol can be used as a bi-directional/unicast IMG 789 transport protocol. Being a request-reply oriented protocol, HTTP is 790 well suited for implementing synchronous operations such as QUERY, 791 RESOLVE and even SUBSCRIBE. However, HTTP does not provide 792 asynchronous operations such as ANNOUNCE and NOTIFY and to implement 793 asynchronous operations using HTTP, IMG receivers should poll the IMG 794 sender periodically. So alone, HTTP is not sufficient to fulfill IMG 795 requirements in a unicast deployment. 797 SAP: The announcement mechanism provided by SAP provides 798 unidirectional delivery of session discovery information. Although 799 SDP is the default payload format of SAP, the use of a MIME type 800 identifier for the payload allows arbitrary payload formats to be 801 used in SAP messages. Thus, SAP could be used to implement the 802 (multicast and unicast) IMG ANNOUNCE and IMG NOTIFY operations. 803 However, the limitations of SAP as a generic IMG transport protocol 804 include: 806 - Lack of reliability (through forward error correction / retransmissions) 807 - Lack of payload segmentation 808 - Limited payload size 809 - Only one description allowed per SAP message 810 - Lack of congestion control 811 - Lack of Internet standard authentication / encryption mechanisms 812 - It is an Experimental RFC with no support for progressing further 813 In principle, the current SAP protocol could be extended to get 814 around its limitations (e.g. the use of a multipart MIME type in the 815 SAP payload has been proposed, enabling multiple descriptions to be 816 carried in a single SAP message). However, the amount of changes 817 needed in SAP to address all of the above limitations would 818 effectively result in a new protocol. Due to these limitations, the 819 use of SAP as an IMG transport protocol is not recommended. 821 SIP: The SIP-specific event mechanism described in [11] provides a 822 way to implement IMG SUBSCRIBE and IMG NOTIFY operations via a bi- 823 directional unicast connection. However, there are scalability 824 problems with this approach, as RFC 3265 currently does not consider 825 multicast. 827 6.3 Outstanding IMG Mechanism Needs 829 Several outstanding needs result from the IMG requirements, framework 830 model and existing relevant mechanisms as already shown in this 831 document. Four specific groupings of work are readily apparent which 832 are: (a) specification of an adequate multicast and unidirectional 833 capable announcement protocol; (b) specification of the use of 834 existing unicast protocols to enable unicast subscribe and 835 announcement/notification functionality; (c) specification of the 836 metadata envelope which is common to, and independent of, the 837 application metadata syntax(es) used; agreement on basic metadata 838 models to enable interoperability testing of the above. The following 839 sections describe each of these. 841 6.3.1 A Multicast Transport Protocol 843 SAP is currently the only open standard protocol suited to the 844 unidirectional/multicast delivery of IMG metadata. As discussed, it 845 fails to meet the IMG requirements in many ways and, since it is not 846 designed to be extensible, we recognize that a new multicast 847 transport protocol for announcements needs to be specified to meet 848 IMG needs. This protocol will be essential to IMG delivery for 849 unidirectional and multicast deployments. 851 The Asynchronous Layered Coding (ALC) [13] protocol from the IETF 852 Reliable Multicast Transport (RMT) working group is very interesting 853 as it fulfils many of the requirements, is extensible and has the 854 ability to `plug-in' both FEC (Forward Error Correction -- for 855 reliability) and CC (Congestion Control) functional blocks -- it is 856 specifically designed for unidirectional multicast object transport. 857 ALC is not fully specified, although RMT has a work-in-progress fully 858 specified protocol using ALC called FLUTE (File Delivery over 859 Unidirectional Transport) [14]. FLUTE seems to be the only fully 860 specified transport and open specification on which a new IMG 861 announcement protocol could be designed. Thus we recommend that ALC 862 and FLUTE be the starting points for this protocol's design. 864 Developing a new protocol from scratch, or attempting to improve SAP, 865 is also feasible, although it would involve repeating many of the 866 design processes and decisions already made by the IETF for ALC. 867 Thus, we recommend only to attempt this if ALC-based protocols are 868 later found to be insufficient. 870 In particular, any announcement protocol must feature sufficient 871 scalability, flexibility and reliability to meet IMG needs. Also, the 872 ANNOUNCE operation must be supported and also NOTIFY capability could 873 be investigated for both hybrid unicast-multicast and unidirectional 874 unicast systems. 876 6.3.2 Usage of Unicast Transport Protocols 878 A thorough description of the use of existing unicast protocols is 879 essential for the use of IMGs in a unicast and point-to-point 880 environment. Such a specification does not currently exist, although 881 several usable unicast transport protocols and specifications can be 882 harnessed for this (SIP, SIP events, HTTP, etc). In particular, both 883 SUBSCRIBE-NOTIFY and QUERY-RESOLVE operation pairs must be enabled. 884 We anticipate that the FETCH operation will be a trivial usage of 885 HTTP, although other transport options may be beneficial to consider 886 too. 888 6.3.3 The Metadata Envelope 890 To be able to handle multiple metadata syntaxes, a common minimal set 891 of information is needed to handle discrete blocks of metadata. The 892 IMG framework model data types defined in this document. This minimal 893 set of information field will be named a `metadata envelope' and 894 must: 896 1. Uniquely identify the block of metadata, regardless of 897 metadata syntax used. The uniqueness may only be needed 898 within the domains the metadata is used but this must 899 enable globally unique identification to support Internet 900 usage. Scope/domain specific identifications should not 901 `leak' outside of the scope, and always using globally 902 unique identification (e.g. based on URIs) should avoid 903 this error. 905 2. Version the block so that changes can be easily handled and 906 stale data identified. 908 3. Give the temporal validity of the block. It must expire the 909 block (expiry time), and may optionally provide a time 910 (presumably in the future) from when the block becomes 911 valid. Temporal validity may be changeable for a block, and 912 even a specific version of a block. 914 4. Be independent of the metadata syntax(es) used for the 915 metadata block, in the sense that no useful syntax should 916 be excluded. 918 For blocks with multiple descriptors, it is assumed that any 919 descriptors inherit the parameters of the (super)blocks. Thus the 920 above information will implicitly describe the individual 921 descriptors. 923 Four options for metadata envelope transport are feasible: 925 1. Embedding in a transport protocol header. This can be done 926 with either header extensions of existing protocols, or 927 newly defined header fields of a new (or new version of a) 928 transport protocol. However, multiple methods for the 929 variety of transport protocols may hinder interoperability. 931 2. A separate envelope object (a form of metadata itself) 932 delivered in-band with the metadata. This would complicate 933 delivery as the envelope and `service' metadata objects 934 would have to be bound, e.g. by pairing some kind of 935 transport object numbers (analogous to port number pairs 936 sometimes used for RTP and RTSP). 938 3. A metadata wrapper which points to and/or embeds the 939 service metadata into its `super-syntax'. For example, XML 940 enables referencing (pointing to) other resources as well 941 as embedding generic text objects. 943 4. Embedding in the metadata itself. However, this requires 944 new field in many metadata syntaxes and would not be 945 feasible if a useful syntax were not capable of 946 extensibility in this way. It also introduces a larger 947 'implementation interpretation' variety which would hinder 948 interoperability. Thus this option is not recommended. 950 6.3.4 Baseline (Meta)Data Model Specification 952 It is likely that more than one of these options will fulfill the 953 needs of IMGs so the selection, and possibly optimization, is left 954 for subsequent specification and feedback from implementation 955 experience. Such a specification is essential for IMG delivery and so 956 should be an official IETF work item. 958 Relevant work-in-progress ensures that support of one, or very few, 959 metadata syntaxes is not sufficient. Whereas the transport protocol 960 should not restrict the metadata format, the metadata envelope may 961 influence the choice metadata. However, metadata in binary format 962 should not be prevented, in addition to the more abundant text and 963 XML syntaxes currently available. 965 In most cases the actual content of metadata will be application, or 966 service domain, specific. For instance, digital cinema distribution 967 and television channels will have many different requirements. The 968 task of specifying the bulk of the world's metadata is well beyond 969 the scope of this document: a framework for the delivery of IMG 970 metadata. We do anticipate that existing and future metadata 971 specifications, including those of several working groups and 972 standardization bodies, shall be able to use the services of the IMG 973 framework. However, it is not essential to the current IMG work to 974 specify standards with application-specific metadata. 976 It is essential that the three IMG data types are enabled, but it may 977 not be necessary to achieve this for every metadata syntax available, 978 nor may it be important to the IETF to cover every possibility for 979 this. Generally, Complete Descriptions will be correct for existing 980 syntaxes (e.g. for XML may be validated according to existing 981 schema). Pointer data types may be served by a new syntax (extremely 982 minimal), although it is feasible that the proposed metadata envelope 983 specification will contain enough information to implement the 984 Pointer data type. Partial Descriptions may need new or modified 985 syntaxes and semantics (e.g. XML schema) as mandatory fields for a 986 Complete Description may be redundant for a Partial Description. 987 During and following the specification of the metadata envelope, 988 enabling the delivery of Partial Descriptions should be considered. 990 To gain implementation experience, it is essential to agree the basic 991 of some metadata in interoperability tests and subsequently in 992 widespread deployments. So we anticipate that a minimal IMG data 993 model would be useful to the Internet community. 995 6.4 IMG Needs Fitting the IETF's Scope 997 A Multicast Transport Protocol is essential to IMG delivery for 998 unidirectional and multicast deployments and no alternative exists 999 which fulfils the IMG requirements. We recommend that the 1000 specification of this be taken on as an official work item in the 1001 IETF. 1003 Specification of the usage of unicast transport protocols is 1004 essential for IMG delivery and control involving unicast 1005 communications, and will relate to existing IETF standard transport 1006 protocols. Thus, we recommend that the specification of this be taken 1007 on as an official work item in the IETF. 1009 The metadata envelope functionality is essential for the IMG delivery 1010 fulfilling the IMG requirements. It is a required feature for IMG 1011 metadata transport and maintenance. Thus, we recommend that the 1012 metadata envelope specification be taken on as an official work item 1013 in the IETF. 1015 (Meta)data model specification and application specific metadata do 1016 not easily fit into the IETF scope and several other standardization 1017 bodies are well placed to do this work. We recommend that aspect 1018 shall not be an official IETF work item. 1020 Note, we acknowledge the need to exchange and agree on a baseline 1021 metadata model and application specific metadata for the purposes of 1022 interoperability testing between different implementations of IMG 1023 related IETF protocols. However, we feel that the IETF standards 1024 process is not required for this. 1026 7 Security Considerations 1028 The IMG framework is developed from the IMG Requirements document [2] 1029 and so the selection of specific protocols and mechanism for use with 1030 the IMG framework must also take into account the security 1031 considerations of the IMG Requirements document. This framework 1032 document does not mandate the use of specific protocols. However, an 1033 IMG specification would inherit the security considerations of 1034 specific protocols used, although this is outside the scope of this 1035 document. 1037 Protocol instantiations which are used to provide IMG operations will 1038 have very different security considerations depending on their scope 1039 and purpose. However, there are several general issues which are 1040 valuable to consider and, in some cases, provide technical solutions 1041 to deal with. These are described below. 1043 Individual and Group Privacy: Customized IMG metadata may reveal 1044 information about the habits and preferences of a user and may thus 1045 deserve confidentiality protection, even though the information 1046 itself is public. Capturing and protecting this IMG metadata requires 1047 the same actions and measures as for other point-to-point and 1048 multicast Internet communications. Naturally, the risk depends on the 1049 amount of individual or group personalization the snooped sessions 1050 contain. Further consideration is valuable at both transport and 1051 metadata levels. 1053 IMG Authenticity: In some cases, the receiver needs to be assured of 1054 the origin of IMG metadata or its modification history. This can 1055 prevent denial of service or hijacking attempts which give an IMG 1056 receiver incorrect information in or about the metadata, thus 1057 preventing successful access of the media or directing the IMG 1058 receiver to the incorrect media possibly with tasteless material. 1059 Action upon detection of unauthorized data insertion is out of scope 1060 of this document. 1062 Receiver Authorization: Some or all of any IMG sender's metadata may 1063 be private or valuable enough to allow access to only certain 1064 receivers and thus make it worth authenticating users. Encrypting the 1065 data is also a reasonable step, especially where group communications 1066 methods results in unavoidable snooping opportunities for 1067 unauthorized nodes. Encryption and the required security parameters 1068 exchange are outside the scope of this document. 1070 Unidirectional Specifics: A difficulty that is faced by 1071 unidirectional delivery operations is that many protocols providing 1072 application-level security are based on bi-directional 1073 communications. The application of these security protocols in case 1074 of strictly unidirectional links is not considered in the present 1075 document. 1077 Malicious Code: Currently, IMGs are not envisaged to deliver 1078 executable code at any stage. However, as some IMG transport 1079 protocols may be capable of delivering arbitrary files, it is 1080 RECOMMENDED that the FLUTE delivery service does not have write 1081 access to the system or any other critical areas. 1083 Protocol Specific Attacks: It is recommended that developers of any 1084 IMG protocol take account of the above risks in addition to any 1085 protocol design and deployment environment risks that may be 1086 reasonably identified. Currently this framework document does not 1087 recommend or mandate the use of any specific protocols, however the 1088 deployment of IMGs using specific protocol instantiations will 1089 naturally be subject to the security considerations of those 1090 protocols. 1092 Security Improvement Opportunity: The security properties of one 1093 channel and protocol can be improved through the use of another 1094 channel and protocol. For example, a secure unicast channel can be 1095 used to deliver the keys and initialization vectors for an encryption 1096 algorithm used on a multicast channel. The exploitation of this 1097 opportunity is specific to the protocols used and is outside the 1098 scope of this document. 1100 8 Normative References 1102 [1] S. Bradner, "Key words for use in RFCs to indicate requirement 1103 levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. 1105 [2] Y. Nomura et al., "Protocol requirements for Internet media 1106 guides," Internet Draft draft-ietf-mmusic-img-req-00, Internet 1107 Engineering Task Force, Sept. 2003. Work in progress. 1109 [3] M. Day, B. Cain, G. Tomlinson, and P. Rzewski, "A model for 1110 content internetworking (CDI)," RFC 3466, Internet Engineering Task 1111 Force, Feb. 2003. 1113 [4] M. Handley and V. Jacobson, "SDP: session description protocol," 1114 RFC 2327, Internet Engineering Task Force, Apr. 1998. 1116 [5] D. Kutscher, J. Ott, and C. Bormann, "Session description and 1117 capability negotiation," Internet Draft draft-ietf-mmusic-sdpng-07, 1118 Internet Engineering Task Force, Oct. 2003. Work in progress. 1120 [6] ISO (International Organization for Standardization), "Overview 1121 of the MPEG-7 standard," ISO Standard ISO/IEC JTC1/SC29/WG11 N4509, 1122 International Organization for Standardization, Geneva, Switzerland, 1123 Dec. 2001. 1125 [7] T.-A. Forum, "Metadata specification S-3," TV-Anytime Forum 1126 Specification SP003v1.2 Part A, TV, TV-Anytime Forum, June 2002. 1128 [8] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, and T. Berners- 1129 Lee, "Hypertext transfer protocol -- HTTP/1.1," RFC 2068, Internet 1130 Engineering Task Force, Jan. 1997. 1132 [9] M. Handley, C. E. Perkins, and E. Whelan, "Session announcement 1133 protocol," RFC 2974, Internet Engineering Task Force, Oct. 2000. 1135 [10] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J. 1136 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session 1137 initiation protocol," RFC 3261, Internet Engineering Task Force, June 1138 2002. 1140 [11] A. B. Roach, "Session initiation protocol (sip)-specific event 1141 notification," RFC 3265, Internet Engineering Task Force, June 2002. 1143 [13] M. Luby, J. Gemmell, L. Vicisano, L. Rizzo, and J. Crowcroft, 1144 "Asynchronous layered coding (ALC) protocol instantiation," RFC 3450, 1145 Internet Engineering Task Force, Dec. 2002. 1147 9 Informative References 1149 [12] J. Rosenberg, "A presence event package for the session 1150 initiation protocol (SIP)," internet draft, Internet Engineering Task 1151 Force, Jan. 2003. Work in progress. 1153 [14] T. Paila, "FLUTE - file delivery over unidirectional transport," 1154 Internet Draft draft-ietf-rmt-flute-06, Internet Engineering Task 1155 Force, Nov. 2003. Work in progress. 1157 10 Acknowledgements 1159 The authors would like to thank Joerg Ott, Colin Perkins, Toni Paila 1160 and Petri Koskelainen on for their ideas and input to this document. 1162 11 Authors' Addresses 1164 Yuji Nomura 1165 Fujitsu Laboratories Ltd. 1166 4-1-1 Kamikodanaka, Nakahara-ku, Kawasaki 211-8588 1167 Japan 1168 Email: nom@flab.fujitsu.co.jp 1170 Rod Walsh 1171 Nokia Corporation 1172 Nokia Research Center 1173 P.O. Box 100, FIN-33721 Tampere 1174 Finland 1175 Email: rod,walsh@nokia.com 1177 Juha-Pekka Luoma 1178 Nokia Corporation 1179 Nokia Research Center 1180 P.O. Box 100, FIN-33721 Tampere 1181 Finland 1182 Email: juha-pekka.luoma@nokia.com 1184 Hitoshi Asaeda 1185 INRIA 1186 Project PLANETE 1187 2004, Route des Lucioles, BP93, 1188 06902 Sophia Antipolis, 1189 France 1190 Email: Hitoshi.Asaeda@sophia.inria.fr 1192 Henning Schulzrinne 1193 Dept. of Computer Science 1194 Columbia University 1195 1214 Amsterdam Avenue 1196 New York, NY 10027 1197 USA 1198 Email: schulzrinne@cs.columbia.edu