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