idnits 2.17.1 draft-ietf-mmusic-img-req-02.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 are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 22, 2003) is 7429 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: '7' is mentioned on line 371, but not defined ** Obsolete normative reference: RFC 2327 (ref. '1') (Obsoleted by RFC 4566) ** Downref: Normative reference to an Experimental RFC: RFC 2974 (ref. '2') Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 2 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 J. Ott 9 Universitaet Bremen 10 H. Schulzrinne 11 Columbia University 12 draft-ietf-mmusic-img-req-02.txt 13 December 22, 2003 14 Expires: June 2004 16 Protocol Requirements for 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 memo specifies requirements for a protocol for accessing and 42 updating Internet Media Guide (IMG) information for media-on-demand 43 and multicast applications. These requirements are designed to guide 44 development of an IMG protocol for efficient and scalable delivery. 46 Table of Contents 48 1 Introduction ........................................ 2 49 1.1 Background and Motivation ........................... 3 50 1.2 Scope of This Document .............................. 4 51 2 Terminology ......................................... 4 52 3 Problem Statement ................................... 5 53 4 Use Cases Requiring IMGs ............................ 6 54 4.1 Connectivity-based Use Cases ........................ 6 55 4.1.1 IP Datacast to a Wireless Receiver .................. 7 56 4.1.2 Regular Fixed Dial-up Internet Connection ........... 8 57 4.1.3 Broadband Always-on Fixed Internet Connection ....... 8 58 4.2 Content-orientated Use Cases ........................ 8 59 4.2.1 File Distribution ................................... 9 60 4.2.2 TV and Radio Program Delivery ....................... 9 61 4.2.3 Media Coverage of a Live Event ...................... 10 62 4.2.4 Distance Learning ................................... 10 63 4.2.5 Multiplayer Gaming .................................. 10 64 5 Requirements ........................................ 10 65 5.1 General Requirements ................................ 10 66 5.1.1 Independence of IMG Operations from IMG Metadata 67 5.1.2 Multiple IMG Senders ................................ 11 68 5.1.3 Modularity .......................................... 11 69 5.2 Delivery Properties ................................. 11 70 5.2.1 Scalability ......................................... 11 71 5.2.2 Support for Intermittent Connectivity ............... 12 72 5.2.3 Congestion Control .................................. 12 73 5.2.4 Sender and Receiver Driven Delivery ................. 12 74 5.3 Customized IMGs ..................................... 13 75 5.4 Reliability ......................................... 13 76 5.4.1 Managing consistency ................................ 14 77 5.4.2 Reliable Message Exchange ........................... 14 78 5.5 IMG Descriptions .................................... 15 79 6 Security Considerations ............................. 16 80 6.1 IMG Authentication and Integrity .................... 16 81 6.2 Privacy ............................................. 17 82 6.3 Access Control for IMGs ............................. 17 83 6.4 Denial-of-Service attacks ........................... 18 84 6.5 Replay Attacks ...................................... 18 85 7 Acknowledgements .................................... 19 86 8 Normative References ................................ 19 87 9 Informative References .............................. 19 89 1 Introduction 91 1.1 Background and Motivation 92 For some ten years, multicast-based (multimedia) conferences 93 (including IETF WG sessions) as well as broadcasts of 94 lectures/seminars, concerts, and other events have been used in the 95 Internet, more precisely, on the MBONE. Schedules and descriptions 96 for such multimedia sessions as well as the transport addresses, 97 codecs, and their parameters have been described using SDP [1] as a 98 rudimentary (but as of then largely sufficient) means. Dissemination 99 of the descriptions has been performed using the Session Announcement 100 Protocol (SAP) [2] and tools such as SD [3] or SDR [4]; descriptions 101 have also been put up on web pages, sent by electronic mail, etc. 103 Recently, interest has grown to expand -- or better: to generalize -- 104 the applicability of these kinds of session descriptions. 105 Descriptions are becoming more elaborate in terms of included 106 metadata; more generic regarding the types of media sessions; and 107 possibly also support other transports than just IP (e.g. legacy TV 108 channel addresses). This peers well with the DVB Organization's 109 increased activities towards IP-based communications over satellite, 110 cable, and terrestrial radio networks, also considering IP as the 111 basis for TV broadcasts and further services. The program/content 112 descriptions are referred to as Internet Media Guides (IMGs) and can 113 be viewed as a generalization of Electronic Program Guides (EPGs) and 114 multimedia session descriptions. 116 An Internet Media Guide (IMG) is a structured collection of 117 multimedia session descriptions expressed using SDP, SDPng or some 118 similar session description format. It is used to describe a set of 119 multimedia sessions (e.g. television program schedules, content 120 delivery schedules etc.) but may also refer to other networked 121 resources including web pages. An IMG provides an envelope for 122 metadata formats and session descriptions defined elsewhere with the 123 aim of facilitating structuring, versioning, referencing, 124 distributing, and maintaining (caching, updating) such information. 126 The IMG metadata must be delivered to a potentially large audience, 127 who use it to join a subset of the sessions described, and who may 128 need to be notified of changes to the IMG. Hence, a framework for 129 distributing IMG metadata in various different ways is needed to 130 accommodate the needs of different audiences: For traditional 131 broadcast-style scenarios, multicast-based (push) distribution of IMG 132 metadata needs to be supported. Where no multicast is available, 133 unicast-based push is required, too. Furthermore, IMG metadata may 134 need to be retrieved interactively, similar to web pages (e.g. after 135 rebooting a system or when a user is browsing after network 136 connectivity has been re-established). Finally, IMG metadata may be 137 updated as time elapses because content described in the guide may be 138 changed: for example, the airtime of an event such as a concert or 139 sports event may change, possibly affecting the airtime of subsequent 140 media. This may be done by polling the IMG as well as asynchronous 141 change notifications. 143 Furthermore, we assume that any Internet host can be a sender of 144 content and thus an IMG. Some of the content sources and sinks may 145 only be connected to the Internet sporadically. Also, a single human 146 user may use many different devices to access metadata. Thus, we 147 envision that IMG metadata can be sent and received by, among others, 148 by cellular phones, PDA (Personal Digital Assistant), personal 149 computer, streaming video server, set-top box, video camera, and PVR 150 (Personal Video Recorder) and that they be carried across arbitrary 151 types of link layers, including bandwidth-constrained mobile 152 networks. 154 Finally, with many potential senders and sinks, different types of 155 networks, and presumably numerous service providers, IMG metadata may 156 need to be combined, split, filtered, augmented, modified, etc. on 157 their way from the sender(s) to the receiver(s) to provide the 158 ultimate user with a suitable selection of multimedia programs 159 according to her preferences, subscriptions, location, context (e.g. 160 devices, access networks), etc. 162 1.2 Scope of This Document 164 This document defines requirements that Internet Media Guide (IMG) 165 mechanisms must satisfy in order to deliver IMG to a potentially 166 large audience. Since the IMG can describe many kinds of multimedia 167 content, IMG methods are generally applicable to several scenarios. 169 In considering wide applicability, this document provides the problem 170 statement and existing mechanisms in this area. Then several use case 171 scenarios for IMGs are explained including descriptions of how IMG 172 metadata and IMG delivery mechanisms contribute to these scenarios. 173 Following this, this document provides general requirements that are 174 independent of any transport layer mechanism and application, such as 175 delivery properties, reliability and IMG descriptions. 177 This document reflects investigating work on delivery mechanisms for 178 IMGs and generalizing work on session announcement and initiation 179 protocols, especially in the field of the MMUSIC working group (SAP, 180 SIP [5], SDP). 182 2 Terminology 184 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 185 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 186 document are to be interpreted as described in RFC 2119 [6]. 188 Internet Media Guide (IMG): IMG is a generic term to describe 189 the formation, delivery and use of IMG metadata. The 190 definition of the IMG is intentionally left imprecise. 192 IMG Element: The smallest atomic element of metadata that can be 193 transmitted separately by IMG operations and referenced 194 individually from other IMG elements. 196 IMG Metadata: A set of metadata consisting of one or more IMG 197 elements. IMG metadata describes the features of multimedia 198 content used to enable selection of and access to media 199 sessions containing content. For example, metadata may 200 consist of the URI, title, airtime, bandwidth needed, file 201 size, text summary, genre and access restrictions. 203 IMG Delivery: The process of exchanging IMG metadata both in 204 terms of large scale and atomic data transfers. 206 IMG Sender: An IMG sender is a logical entity that sends IMG 207 metadata to one or more IMG receivers. 209 IMG Receiver: An IMG receiver is a logical entity that receives 210 IMG metadata from an IMG sender. 212 IMG Transceiver: An IMG transceiver combines an IMG receiver and 213 sender. It may modify received IMG metadata or merge IMG 214 metadata received from a several different IMG senders. 216 IMG Operation: An atomic operation of an IMG transport protocol, 217 used between IMG sender(s) and IMG receiver(s) for the 218 delivery of IMG metadata and for the control of IMG 219 sender(s)/receiver(s). 221 IMG Transport Protocol: A protocol that transports IMG metadata 222 from an IMG sender to IMG receiver(s). 224 IMG Transport Session: An association between an IMG sender and 225 one or more IMG receivers within the scope of an IMG 226 transport protocol. An IMG transport session involves a 227 series of IMG transport protocol interactions that provide 228 delivery of IMG metadata from the IMG sender to the IMG 229 receiver(s). 231 3 Problem Statement 233 The MMUSIC working group has long been investigating content, media 234 and service information delivery mechanisms and protocols, and has 235 itself produces Session Announcement Protocol (SAP), Session 236 Description Protocol (SDP), and the Session Initiation Protocol 237 (SIP). SDP is capable of describing multimedia sessions (i.e. 238 content in a wider sense) by means of limited descriptive information 239 intended for human perception plus transport, scheduling information, 240 and codecs and addresses for setting up media sessions. SIP and SAP 241 are protocols to distribute these session descriptions. 243 HTTP is a well known data retrieval protocol using bi-directional 244 transport and widely used to deliver content descriptions to many 245 hosts. 247 However, we perceive a lack of standard solution for scalable IMG 248 delivery mechanism in the number of receivers with consistency of IMG 249 metadata between an IMG sender and IMG receiver for both bi- 250 directional and unidirectional transport. With increased service 251 dynamics and complexity, there is an increased requirement for 252 updates to these content descriptions. 254 Whenever an HTTP client requires updated content descriptions, the 255 client has to reload those using the same URL. For mass media, the 256 large number of users polling a server causes scalability and 257 congestion concerns and so the technique is feasible only if the 258 period between reloading is long and the amount of content 259 descriptions or the number of users is small. A well-behaved 260 implementation limits the timeliness of receiver-side updates for 261 mass audiences. 263 The unicast equivalent of this is to maintain a unicast 264 connection/session between sender and receiver for the whole time a 265 receiver is interested in a service. This may be feasible in many 266 wire line systems for servers with only a few receivers, but both of 267 these become less attractive for both wireless links and large 268 numbers of sender-receiver connections, especially as both of these 269 share a resource (the radio bandwidth or the server resources) and 270 thus limit the number of receivers that can be served, without 271 additional infrastructure investment. 273 We also perceive a lack of standard solution for flexible content 274 descriptions to support a multitude of application-specific data 275 models with differing amount of detail and different target 276 audiences. 278 4 Use Cases Requiring IMGs 280 4.1 Connectivity-based Use Cases 282 4.1.1 IP Datacast to a Wireless Receiver 283 IP Datacast is the delivery of IP-based services over broadcast 284 radio. Internet content delivery is therefore unidirectional in this 285 case. However, there can be significant benefits from being able to 286 provide rich media one-to-many services to such receivers. 288 There are two main classes of receiver in this use case: fixed 289 mains-powered; and mobile battery-powered. Both of these are affected 290 by radio phenomena and so robust, or error-resilient, delivery is 291 important. Carouselled metadata transfer provides a base level of 292 robustness for an IP datacast based announcement system, although the 293 design of carouselled transfer should enable battery-powered 294 receivers to go through periods of sleep to extend their operational 295 time between charges. Insertion of Forward Error Correction (FEC) 296 data into metadata announcements improves error resilience, and 297 reordering (interleaving) data blocks further increases tolerance to 298 burst errors. 300 To enable receivers to more accurately specify the metadata they are 301 interested in, the unidirectional delivery is distributed between 302 several logical channels. This is so that a receiver need only access 303 the channels of interest and thus can reduce the amount of time, 304 storage and CPU resources needed for processing the IP data. Also, 305 hierarchical channels enable receivers to subscribe to a root, 306 possibly well known, multicast channel/group and progressively access 307 only those additional channels based on metadata in parent channels. 309 In some cases the receiver may be multi-access, such that it is 310 capable of bi-directional communications. This enables a multitude of 311 options, but most importantly it enables NACK based reliability and 312 the individual retrieval of missed or not-multicasted sets of 313 metadata. 315 Thus, essential IMG features in this case include: robust 316 unidirectional delivery (with optional levels of reliability 317 including "plug-in FEC") which implies easily identifiable 318 segmentation of delivery data to enable FEC, carousel, interleaving 319 and other schemes possible; effective identification of metadata sets 320 (probably uniquely) to enable more efficient use of multicast and 321 unicast retrieval over multiple access systems regardless of the 322 parts of metadata and application specific extensions in use; 323 prioritization of metadata, which can (for instance) be achieved by 324 spreading it between channels and allocating/distributing bandwidth 325 accordingly. 327 Furthermore, some cases require IMG metadata authentication and some 328 group security/encryption and supporting security message exchanges 329 (out of band from the IMG multicast sessions). 331 4.1.2 Regular Fixed Dial-up Internet Connection 333 Dial-up connections tend to be reasonably slow (<56kbps in any case) 334 and thus large data transfers are less feasible, especially during an 335 active application session (such as a file transfer described by IMG 336 metadata). They can also be intermittent, especially if a user is 337 paying for the connected time, or connected through a less reliable 338 exchange. Thus this favors locally stored IMG metadata over web-based 339 browsing, especially where parts of the metadata change infrequently. 340 There may be no service provider preference over unicast and 341 multicast transport for small and medium numbers of users as the 342 last-mile dial-up connection limits per-user congestion, and a user 343 may prefer the more reliable option (unicast unless reliable 344 multicast is provided). 346 4.1.3 Broadband Always-on Fixed Internet Connection 348 Typically bandwidth is less of an issue to a broadband user and 349 unicast transport, such as using IMG QUERY, may be typical for a PC 350 user. If a system were only used in this context, with content 351 providers, ISPs and users having no other requirements, then web- 352 based browsing may be equally suitable. However, broadband users 353 sharing a local area network, especially wireless, may benefit more 354 from local storage features than on-line browsing, especially if they 355 have intermittent Internet access. 357 Broadband enables rich media services, which are increasingly 358 bandwidth hungry. Thus backbone operators may prefer multicast 359 communications to reduce overall congestion, if they have the 360 equipment and configuration to support this. Thus, broadband users 361 may be forced to retrieve IMG metadata over multicast if the 362 respective operators require this to keep system-wide bandwidth usage 363 feasible. 365 4.2 Content-orientated Use Cases 367 IMGs will be able to support a very wide range of use cases for 368 content/media delivery. The following few sections just touch the 369 surface of what is possible and are intended to provide an 370 understanding of the scope and type of IMG usage. Many more examples 371 may be relevant, for instance those detailed in [7]. There are 372 several unique features of IMGs that set them apart from related 373 application areas such as SLP based service location discovery, LDAP 374 based indexing services and search engines such as Google. Features 375 unique to IMGs include: 377 o IMG metadata is generally time-related 378 o There are timeliness requirements in the delivery of IMG 379 metadata 381 o IMG metadata may be updated as time elapses or when an event 382 arises 384 4.2.1 File Distribution 386 IMGs support the communication of file delivery session properties, 387 enabling the scheduled delivery or synchronization of files between a 388 number of hosts. The received IMG metadata could be subsequently used 389 by any application (also outside the scope of IMGs), for example to 390 download a file with a software update. IMG metadata can provide a 391 description to each file in a file delivery session, assisting users 392 or receiving software in selecting individual files for reception. 394 For example, when a content provider wants to distribute a large 395 amount of data in file format to thousands clients, the content 396 provider can use IMG metadata to schedule the delivery effectively. 397 Since IMG metadata can describe time-related data for each receiver, 398 the content provider can schedule delivery time for each receiver. 399 This can save network bandwidth and delivery capacity of senders. In 400 addition, IMG metadata can be used to synchronize a set of files 401 between a sender host and receiver host, when those files change as 402 time elapses. 404 4.2.2 TV and Radio Program Delivery 406 A sender of audio/video streaming content can use the IMG metadata to 407 describe the scheduling and other properties of audio/video sessions 408 and events within those sessions, such as individual TV and radio 409 programs and segments within those programs. IMG metadata describing 410 audio/video streaming content could be represented in a format 411 similar to that of a TV guide in newspapers, or an Electronic Program 412 Guide available on digital TV receivers. 414 Similarly to file reception, TV and radio programs can be selected 415 for reception either manually by the end-user or automatically based 416 on the content descriptions and the preferences of the user. The 417 received TV and radio content can be either presented in real time or 418 recorded for consuming later. There may be changes in the scheduling 419 of a TV or a radio program, possibly affecting the transmission times 420 of subsequent programs. IMG metadata can be used to notify receivers 421 of such changes, enabling users to be prompted or recording times to 422 be adjusted. 424 4.2.3 Media Coverage of a Live Event 425 The media coverage of a live event such as a rock concert or a sports 426 event is a special case of regular TV/radio programming. There may be 427 unexpected changes in the scheduling of live event, or the event may 428 be unscheduled to start with (such as breaking news). In addition to 429 audio/video streams, textual information relevant to the event (e.g. 430 statistics of the players during a football match) may be sent to 431 user terminals. Different transport modes or even different access 432 technologies can be used for the different media: for example, a 433 unidirectional datacast transport could be used for the audio/video 434 streams and an interactive cellular connection for the textual data. 435 IMG metadata should enable terminals to discover the availability of 436 different media used to cover a live event. 438 4.2.4 Distance Learning 440 IMG metadata could describe compound sessions or services enabling 441 several alternative interaction modes between the participants. For 442 example, the combination of one-to-many media streaming, unicast 443 messaging and download of presentation material could be useful for 444 distance learning. 446 4.2.5 Multiplayer Gaming 448 Multiplayer games are an example of real-time multiparty 449 communication sessions that could be advertised using IMGs. A gaming 450 session could be advertised either by a dedicated server, or by the 451 terminals of individual users. A user could use IMGs to learn of 452 active multiplayer gaming sessions, or advertise the users interest 453 in establishing such a session. 455 5 Requirements 457 5.1 General Requirements 459 5.1.1 Independence of IMG Operations from IMG Metadata 461 REQ GEN-1: Carrying different kinds of IMG metadata format in the IMG 462 message body MUST be allowed. 464 REQ GEN-2: Delivery mechanisms SHOULD support many different 465 applications specific metadata formats to keep the system 466 interoperable with existing applications. 468 This provides flexibility in selecting/designing IMG transport 469 protocol suited to various scenarios. 471 5.1.2 Multiple IMG Senders 472 REQ GEN-3: IMG receivers MUST be allowed to communicate with any 473 number of IMG senders simultaneously. 475 This might lead to receiving redundant IMG metadata describing the 476 same items, however it enables the IMG receiver access to more IMG 477 metadata than may be available from a single IMG sender. This also 478 provides flexibility for the IMG transport protocols and does not 479 preclude a mechanism to solve inconsistency among IMG metadata due to 480 multiple IMG senders. This document assumes a typical IMG environment 481 will involve many more IMG receivers than IMG senders and that IMG 482 senders are continually connected for the duration of interest 483 (rather than intermittently connected). 485 5.1.3 Modularity 487 REQ GEN-4: The IMG delivery mechanisms MUST allow the combination of 488 several IMG Operations. 490 This is for the purpose of extending functionality (e.g. several or 491 one protocol(s) to provide all the needed operations). Applications 492 can select an appropriate operation set to fulfill their purpose. 494 5.2 Delivery Properties 496 This section describes general performance requirements based on the 497 assumption that the range of IMG usage shall be important. However, 498 it may be noted that requirements of delivery properties may vary 499 based on the usage scenario, and thus some limited use 500 implementations place less importance on some requirements. 502 For example, it is clear that a multicast transport may provide more 503 scalable delivery than a unicast transport, however scalability 504 requirements do not preclude the unicast transport mechanisms. In 505 this sense, scalability is always important for the protocols 506 irrespective of transport mechanisms. 508 5.2.1 Scalability 510 REQ DEL-1: The system MUST be scalable in that it does not fail to 511 deliver up-to-date information under huge numbers of transactions and 512 massive quantities of IMG metadata. 514 REQ DEL-2: IMGs SHOULD provide a method to prevent an IMG sender from 515 sending verbose IMG metadata that have been stored or deleted in IMG 516 receivers. Note, 'verbose' data is unneeded or unused detail or 517 repetitions. 519 REQ DEL-3: The protocol MUST be scalable to very large audience sizes 520 requiring IMG delivery. 522 5.2.2 Support for Intermittent Connectivity 524 REQ DEL-4: The system MUST enable IMG receivers with intermittent 525 access to network resources (connectivity) to receive and adequately 526 maintain sufficient IMG metadata. 528 This allows intermittent access to save power where there is no need 529 to keep communications links powered-up while they are sitting idle. 530 For instance, in this situation periodic bursts of notifies, or a 531 fast cycling update carousel, allows hosts to wake up for short 532 periods of time and still be kept up-to-date. This can be beneficial 533 for IMG receivers with sporadic connects to the fixed Internet, but 534 is critical in the battery-powered wireless Internet. 536 5.2.3 Congestion Control 538 REQ DEL-5: Internet-friendly congestion control MUST be provided for 539 use on the public Internet. 541 For instance, notifications of updates (containing only minimal 542 change related data) can reduce congestion, especially for very large 543 groups, while allowing individual "congestion free" parts of the 544 Internet to do things "their way". Where some hosts are on 545 unidirectional links, and other have bi-directional links (or both), 546 this is sensible "diversity". 548 REQ DEL-6: An IMG entity SHOULD invalidate the IMG metadata item when 549 an IMG metadata item has lifetime information and its lifetime is 550 over. 552 This mechanism can reduce notifications of updates from the IMG 553 sender to the IMG receiver to invalidate the item. It may be 554 beneficial for congestion control. 556 5.2.4 Sender and Receiver Driven Delivery 558 REQ DEL-7: The system MUST be flexible in choosing sender-driven, 559 receiver-driven or both delivery schemes. 561 Sender-driven delivery achieves high scalability without interaction 562 between the IMG sender and receiver. This avoids keeping track of a 563 delivery state of every IMG receiver. 565 In contrast, the receiver-driven delivery provides on-demand delivery 566 for IMG receivers. Since an IMG sender's complete IMG metadata may be 567 a very large amount of data, the IMG receiver needs to be able to 568 access the guide when convenient (e.g., when sufficient network 569 bandwidth is available to the IMG receiver). 571 5.3 Customized IMGs 573 REQ CUS-1: The system MUST allow delivery of customized IMG metadata. 575 The IMG receiver may require a subset of all the IMG metadata 576 available according to their preferences (type of content, media 577 description, appropriate age group, etc.) and configuration. 579 The IMG receiver might send its preferences in the IMG operations 580 which can specify user specific IMG metadata to be delivered. These 581 preferences could consist of filtering rules. When receiving these 582 messages, the IMG sender might respond appropriate messages carrying 583 a subset of IMG metadata which matches the IMG receiver's 584 preferences. 586 This mechanism can reduce the amount of IMG metadata delivered from 587 the IMG sender to IMG receiver, and consequently it can save the 588 resource consumption on the IMG entities and networks. It is 589 typically useful in unicast case and also beneficial in multicast 590 case where IMG sender distributes the same IMG metadata to interested 591 IMG receivers at the same time. 593 For multicast and unicast cases where the IMG sender does not provide 594 customized IMG metadata, the IMG receiver could receive all IMG 595 metadata transmitted (on its joined channels). However, it may select 596 and filter the IMG metadata to get customized IMG metadata by its 597 preferences, and thus drop unwanted metadata immediately upon 598 reception. 600 Customized metadata might be achieved by changing the IMG 601 descriptions sent and IMG receivers and/or changing the delivery 602 properties (channels used). 604 Note, customization and scalability are only somewhat exclusive. 605 Systems providing an IMG receiver to an IMG sender request-based 606 customization, will be generally less scalable to massive IMG 607 receiver populations than those without this return signaling 608 technique. Thus, customization, as with any feature which affects 609 scalability, should be carefully designed for the intended 610 application, and it may not be possible that a one-size-fits-all 611 solution for customization would meet the scalability requirements 612 for all applications and deployment cases. 614 5.4 Reliability 615 5.4.1 Managing consistency 617 IMG metadata tends to change as time elapses, as new content is 618 added, the old IMG metadata stored in the IMG receiver becomes 619 unavailable and the parameters of the existing IMG metadata are 620 changed. 622 REQ REL-1: The system MUST manage IMG metadata consistency. 624 The IMG sender can either simply make updates available 625 (unsynchronized) or IMG sender and receiver can interact to keep 626 their copies of the IMG metadata synchronized. 628 In the unsynchronized model, the IMG sender does not know whether a 629 particular IMG receiver has an up-to-date copy of the IMG metadata. 631 In the synchronized model, updating cached copy of the IMG metadata 632 is necessary to control consistency when the IMG sender or receiver 633 could not communicate for a while. In this case, the IMG sender or 634 receiver may need to confirm its consistency by IMG operations. 636 REQ REL-2: Since IMG metadata can change at any time, IMG receivers 637 SHOULD be notified of such changes. 639 Depending on the size of the guide, the interested party may want to 640 defer retrieving the actual information. The change notification 641 should be addressed to a logical user (or user group), not a host, 642 since users may change devices. 644 Note that depending on the deployment environment and application 645 specifics, the level of acceptable inconsistency varies. Thus, this 646 document does not define inconsistency as specific time and state 647 differences between IMG metadata stored in an IMG sender and IMG 648 metadata stored in an IMG receiver. 650 In general, the consistency of metadata for a content and media is 651 more important immediately prior to and during the media's 652 session(s). Hosts which forward (or otherwise resend) metadata may be 653 less tolerant to inconsistencies as delivering out of date data is 654 both misleading and bandwidth inefficient. 656 By contrast, intermittent connectivity make immediate distribution of 657 changes infeasible and so managing data consistency should be focused 658 on the timely delivery of data. 660 5.4.2 Reliable Message Exchange 662 REQ REL-3: An IMG transport protocol MUST support reliable message 663 exchange. 665 The extent to which this could result in 100% error free delivery to 666 100% of IMG receivers is a statistical characteristic of the 667 protocols used. Usage of reliable IMG delivery mechanisms is expected 668 to depend on the extent to which underlying networks provide 669 reliability and, conversely, introduce errors. Note, some deployments 670 of IMG transport protocols may not aim to provide perfect reception 671 to all IMG receivers in all possible cases. 673 5.5 IMG Descriptions 675 REQ DES-1: IMG metadata MUST be interoperable over any IMG transport 676 protocol, such that an application receiving the same metadata over 677 any one (or more) of several network connections and/or IMG transport 678 protocols will interpret the metadata in exactly the same way. (This 679 also relates to the 'Independence of IMG Operations from IMG 680 Metadata' requirement). 682 REQ DES-2: IMG delivery MUST enable the carriage of any format of 683 application-specific metadata. 685 Thus, the system will support the description of many kinds of 686 multimedia content, without the need for a single homogenous metadata 687 syntax for all uses (which would be infeasible anyway). This is 688 essential for environments using IMG systems to support many kinds of 689 multimedia content and to achieve wide applicability. 691 REQ DES-3: Whereas specific applications relying on IMGs will need to 692 select one or more specific application-specific metadata formats 693 (standard, syntax, etc.), the IMG system MUST be independent of this 694 (it may be aware, but it will operate in the same way for all). 696 Thus, a transfer envelope format, that is uniform across all 697 different application-specific IMG metadata formats, is needed. The 698 payload of this transfer envelope would be some application-specific 699 metadata. 701 REQ DES-4: IMG metadata MUST be structured such that it is possible 702 to deliver only part of an IMG sender's (and the global) complete IMG 703 metadata knowledge. 705 REQ DES-5: A transfer envelope MUST be defined to include essential 706 parameters. 708 Examples of essential parameters are those that allow the metadata in 709 question to be uniquely identified and updated by new versions of the 710 same metadata. 712 REQ DES-6: It SHALL be possible to deduce the metadata format from 713 the transfer envelope. 715 REQ DES-7: IMG senders SHALL use the transfer envelope for each IMG 716 metadata transfer. 718 Thus, it will even be possible to describe relationships between 719 syntactically dissimilar application-specific formats within the same 720 body of IMG metadata knowledge. 722 REQ DES-8: IMG metadata SHOULD support to describe differences 723 between update version and old version of IMG metadata when IMG 724 delivery mechanism carries updated IMG metadata and those differences 725 are considerably little. (This also relates the delivery property 726 requirements for congestion control in Section 5.2.3). 728 6 Security Considerations 730 Internet Media Guides are used to convey information about multimedia 731 resources from one or more IMG senders across one or intermediaries 732 to one or more IMG receivers. IMG metadata may be pushed to the IMG 733 receivers or interactively retrieved by them. IMGs provide metadata 734 as well as scheduling and rendezvous information about multimedia 735 resources, etc. and requests for IMG metadata may contain information 736 about the requesting users. 738 The information contained in IMG metadata as well as the operations 739 related to IMGs should be secured to avoid forging information, 740 misdirecting users, spoofing IMG senders, etc. and to protect user 741 privacy. 743 The remainder of section addresses the security requirements for 744 IMGs. 746 6.1 IMG Authentication and Integrity 748 IMG metadata and its parts need to be protected against unauthorized 749 altering/adding/deletion on the way. Their originator needs to be 750 authenticated. 752 REQ AUT-1: It MUST be possible to authenticate the originator of a 753 set of IMG metadata. 755 REQ AUT-2: It MUST be possible to authenticate the originator of a 756 subpart of IMG metadata (e.g. a delta or a subset of the 757 information). 759 REQ AUT-3: It MUST be possible to validate the integrity of IMG 760 metadata. 762 REQ AUT-4: It MUST be possible to validate the integrity of a subpart 763 of IMG metadata (e.g. a delta or a subset of the information). 765 REQ AUT-5: It MUST be possible to separate or combine individually 766 authenticated pieces of IMG metadata (e.g. in an IMG transceiver) 767 without invalidating the authentication. 769 REQ AUT-6: It MUST be possible to validate the integrity of an 770 individually authenticated piece of IMG metadata even after this 771 piece had been separated from other pieces of IMG metadata and 772 combined with other pieces to form new IMG metadata. 774 REQ AUT-7: It MUST be possible to authenticate the originator of an 775 IMG operation. 777 REQ AUT-8: It MUST be possible to validate the integrity of any 778 contents of an IMG operation (e.g. the subscription or inquiry 779 information). 781 6.2 Privacy 783 Customized IMG metadata and IMG metadata delivered by notification to 784 individual users may reveal information about the habits and 785 preferences of a user and may thus deserve confidentiality 786 protection, even though the information itself is public. 788 REQ PRI-1: It MUST be possible to keep user requests to subscribe to 789 or retrieve certain (parts of) IMG metadata confidential. 791 REQ PRI-2: It MUST be possible to keep IMG metadata, pieces of IMG 792 metadata, or pointers to IMG metadata delivered to individual users 793 or groups of users confidential. 795 REQ PRI-3: It SHOULD be possible to ensure this confidentiality end- 796 to-end, that is, to prevent intermediaries (such as IMG transceivers) 797 from accessing the contained information. 799 6.3 Access Control for IMGs 801 Some IMG metadata may be freely available, while access to other may 802 be restricted to closed user groups (e.g. paying subscribers). Also, 803 different parts of IMG metadata may be protected at different levels: 804 e.g. metadata describing a media session may be freely accessible 805 while rendezvous information to actually access the media session may 806 require authorization. 808 REQ ACC-1: It MUST be possible to authorize user access to IMG 809 metadata. 811 REQ ACC-2: It MUST be possible to authorize access of users to pieces 812 of IMG metadata (delta information, subparts, pointers). 814 REQ ACC-3: It MUST be possible to require different authorization for 815 different parts of the same IMG metadata. 817 REQ ACC-4: It MUST be possible to access selected IMG metadata 818 anonymously. 820 REQ ACC-5: It MUST be possible for an IMG receiver to choose not to 821 receive (parts of) IMG metadata in order to avoid being identified by 822 the IMG sender. 824 REQ ACC-6: It SHOULD be possible for IMG transceiver to impose 825 different authorization requirements. 827 REQ ACC-7: It MAY be possible for IMG senders to require certain 828 authorization that cannot be overridden by intermediaries. 830 6.4 Denial-of-Service attacks 832 Retrieving or distributing IMG metadata may require state in the IMG 833 senders, transceivers, and/or receivers for the respective IMG 834 transport sessions. Attackers may create large numbers of sessions 835 with any of the above IMG entities to disrupt regular operation. 837 REQ DOS-1: IMG operations SHOULD be authenticated. 839 REQ DOS-2: It SHOULD be possible to prevent DoS attacks that build up 840 session state in IMG entities to exhaust their resources. 842 REQ DOS-3: It SHOULD be possible to avoid DoS attacks that exhaust 843 resources of IMG entities by flooding them with IMG metadata. 845 6.5 Replay Attacks 847 IMG metadata disseminated by an IMG sender or an IMG transceiver may 848 be updated, deleted, or lose validity over time for some other 849 reasons. Replaying outdated IMG metadata needs to be prevented. 851 Furthermore, replay attacks may also apply to IMG operations (rather 852 than just their payload). Replaying operations needs also be 853 prevented. 855 REQ REP-1: IMG metadata MUST be protected against partial or full 856 replacement of newer ("current") versions by older ones. 858 REQ REP-2: Mechanisms MUST be provided to mitigate replay attacks on 859 the IMG operations. 861 7 Acknowledgements 863 The authors would like to thank Hitoshi Asaeda, Petri Koskelainen, 864 Toni Paila and Dirk Kutscher for their comments and ideas on this 865 work. 867 8 Normative References 869 [1] M. Handley and V. Jacobson, ``SDP: session description protocol,'' 870 RFC 2327, Internet Engineering Task Force, Apr. 1998. 872 [2] M. Handley, C. E. Perkins, and E. Whelan, ``Session announcement 873 protocol,'' RFC 2974, Internet Engineering Task Force, Oct. 2000. 875 [5] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J. 876 Peterson, R. Sparks, M. Handley, and E. Schooler, ``SIP: session 877 initiation protocol,'' RFC 3261, Internet Engineering Task Force, June 878 2002. 880 [6] S. Bradner, ``Key words for use in RFCs to indicate requirement 881 levels,'' RFC 2119, Internet Engineering Task Force, Mar. 1997. 883 9 Informative References 885 [3] Session Directory, ftp://ftp.ee.lbl.gov/conferencing/sd/ 887 [4] Session Directory Tool, http://www- 888 mice.cs.ucl.ac.uk/multimedia/software/sdr/ 890 10 Authors' Addresses 892 Yuji Nomura 893 Fujitsu Laboratories Ltd. 894 4-1-1 Kamikodanaka, Nakahara-ku, Kawasaki 211-8588 895 Japan 896 Email: nom@flab.fujitsu.co.jp 898 Rod Walsh 899 Nokia Research Center 900 P.O. Box 100, FIN-33721 Tampere 901 Finland 902 Email: rod.walsh@nokia.com 904 Juha-Pekka Luoma 905 Nokia Research Center 906 P.O. Box 100, FIN-33721 Tampere 907 Finland 908 Email: juha-pekka.luoma@nokia.com 910 Joerg Ott 911 Universitaet Bremen 912 MZH 5180 913 Bibliothekstr. 1 914 D-28359 Bremen 915 Germany 916 Email: jo@tzi.uni-bremen.de 918 Henning Schulzrinne 919 Dept. of Computer Science 920 Columbia University 921 1214 Amsterdam Avenue 922 New York, NY 10027 923 USA 924 Email: schulzrinne@cs.columbia.edu 926 Full Copyright Statement 928 Copyright (c) The Internet Society (2003). All Rights Reserved. 930 This document and translations of it may be copied and furnished to 931 others, and derivative works that comment on or otherwise explain it 932 or assist in its implementation may be prepared, copied, published 933 and distributed, in whole or in part, without restriction of any 934 kind, provided that the above copyright notice and this paragraph are 935 included on all such copies and derivative works. However, this 936 document itself may not be modified in any way, such as by removing 937 the copyright notice or references to the Internet Society or other 938 Internet organizations, except as needed for the purpose of 939 developing Internet standards in which case the procedures for 940 copyrights defined in the Internet Standards process must be 941 followed, or as required to translate it into languages other than 942 English. 944 The limited permissions granted above are perpetual and will not be 945 revoked by the Internet Society or its successors or assigns. 947 This document and the information contained herein is provided on an 948 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 949 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 950 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 951 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 952 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.