idnits 2.17.1 draft-ietf-mmusic-img-req-03.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 : ---------------------------------------------------------------------------- No issues found here. 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 (February 16, 2003) is 7740 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-09) exists of draft-ietf-mmusic-img-framework-02 ** Downref: Normative reference to an Informational draft: draft-ietf-mmusic-img-framework (ref. '1') -- Obsolete informational reference (is this intentional?): RFC 2327 (ref. '3') (Obsoleted by RFC 4566) -- Obsolete informational reference (is this intentional?): RFC 2068 (ref. '8') (Obsoleted by RFC 2616) -- Obsolete informational reference (is this intentional?): RFC 3265 (ref. '9') (Obsoleted by RFC 6665) == Outdated reference: A later version (-08) exists of draft-ietf-mmusic-sdpng-07 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 5 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-03.txt 13 February 16, 2003 14 Expires: July 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 ........................................ 3 49 1.1 Background and Motivation ........................... 3 50 1.2 Scope of This Document .............................. 4 51 2 Terminology ......................................... 5 52 3 Problem Statement ................................... 6 53 4 Use Cases Requiring IMGs ............................ 7 54 4.1 Connectivity-based Use Cases ........................ 7 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 ........................ 9 59 4.2.1 TV and Radio Program Delivery ....................... 9 60 4.2.2 Media Coverage of a Live Event ...................... 9 61 4.2.3 Distance Learning ................................... 10 62 4.2.4 Multiplayer Gaming .................................. 10 63 4.2.5 File Distribution ................................... 10 64 4.2.6 Coming-release and Pre-released Content ............. 11 65 5 Requirements ........................................ 11 66 5.1 General Requirements ................................ 11 67 5.1.1 Independence of IMG Operations from IMG Metadata 68 5.1.2 Multiple IMG Senders ................................ 11 69 5.1.3 Modularity .......................................... 11 70 5.2 Delivery Properties ................................. 12 71 5.2.1 Scalability ......................................... 12 72 5.2.2 Support for Intermittent Connectivity ............... 12 73 5.2.3 Congestion Control .................................. 13 74 5.2.4 Sender and Receiver Driven Delivery ................. 13 75 5.3 Customized IMGs ..................................... 13 76 5.4 Reliability ......................................... 14 77 5.4.1 Managing consistency ................................ 14 78 5.4.2 Reliable Message Exchange ........................... 15 79 5.5 IMG Descriptions .................................... 15 80 6 Security Considerations ............................. 16 81 6.1 IMG Authentication and Integrity .................... 17 82 6.2 Privacy ............................................. 18 83 6.3 Access Control for IMGs ............................. 18 84 6.4 Denial-of-Service attacks ........................... 19 85 6.5 Replay Attacks ...................................... 19 86 7 IANA Considerations ................................. 19 87 8 Normative References ................................ 19 88 9 Informative References .............................. 20 89 10 Acknowledgements .................................... 20 90 11 Authors' Addresses .................................. 20 92 1 Introduction 94 1.1 Background and Motivation 96 For some ten years, multicast-based (multimedia) conferences 97 (including IETF WG sessions) as well as broadcasts of 98 lectures/seminars, concerts, and other events have been used in the 99 Internet, more precisely, on the MBONE. Schedules and descriptions 100 for such multimedia sessions as well as the transport addresses, 101 codecs, and their parameters have been described using SDP [3] as a 102 rudimentary (but as of then largely sufficient) means. Dissemination 103 of the descriptions has been performed using the Session Announcement 104 Protocol (SAP) [4] and tools such as SD [5] or SDR [6]; descriptions 105 have also been put up on web pages, sent by electronic mail, etc. 107 Recently, interest has grown to expand -- or better: to generalize -- 108 the applicability of these kinds of session descriptions. 109 Descriptions are becoming more elaborate in terms of included 110 metadata; more generic regarding the types of media sessions; and 111 possibly also support other transports than just IP (e.g. legacy TV 112 channel addresses). This peers well with the DVB Organization's 113 increased activities towards IP-based communications over satellite, 114 cable, and terrestrial radio networks, also considering IP as the 115 basis for TV broadcasts and further services. The program/content 116 descriptions are referred to as Internet Media Guides (IMGs) and can 117 be viewed as a generalization of Electronic Program Guides (EPGs) and 118 multimedia session descriptions. 120 An Internet Media Guide (IMG) has a structured collection of 121 multimedia session descriptions expressed using SDP, SDPng or some 122 similar session description format. This is used to describe a set of 123 multimedia sessions (e.g. television program schedules, content 124 delivery schedules etc.) but may also refer to other networked 125 resources including web pages. IMGs provide the envelope for metadata 126 formats and session descriptions defined elsewhere with the aim of 127 facilitating structuring, versioning, referencing, distributing, and 128 maintaining (caching, updating) such information. 130 The IMG metadata must be delivered to a potentially large audience, 131 who use it to join a subset of the sessions described, and who may 132 need to be notified of changes to this information. Hence, a 133 framework for distributing IMG metadata in various different ways is 134 needed to accommodate the needs of different audiences: For 135 traditional broadcast-style scenarios, multicast-based (push) 136 distribution of IMG metadata needs to be supported. Where no 137 multicast is available, unicast-based push is required, too. 138 Furthermore, IMG metadata may need to be retrieved interactively, 139 similar to web pages (e.g. after rebooting a system or when a user is 140 browsing after network connectivity has been re-established). 141 Finally, IMG metadata may be updated as time elapses because content 142 described in the guide may be changed: for example, the airtime of an 143 event such as a concert or sports event may change, possibly 144 affecting the airtime of subsequent media. This may be done by 145 polling the IMG sender as well as by asynchronous change 146 notifications. 148 Furthermore, any Internet host can be a sender of content and thus an 149 IMG sender. Some of the content sources and sinks may only be 150 connected to the Internet sporadically. Also, a single human user may 151 use many different devices to access metadata. Thus, we envision that 152 IMG metadata can be sent and received by, among others, by cellular 153 phones, PDA (Personal Digital Assistant), personal computer, 154 streaming video server, set-top box, video camera, and DVR (Digital 155 Video Recorder) and that they be carried across arbitrary types of 156 link layers, including bandwidth-constrained mobile networks. 157 However, generally we expect IMG Senders to be well connected hosts. 159 Finally, with many potential senders and receivers, different types 160 of networks, and presumably numerous service providers, IMG metadata 161 may need to be combined, split, filtered, augmented, modified, etc. 162 on their way from the sender(s) to the receiver(s) to provide the 163 ultimate user with a suitable selection of multimedia programs 164 according to her preferences, subscriptions, location, context (e.g. 165 devices, access networks), etc. 167 1.2 Scope of This Document 169 This document defines requirements that Internet Media Guide (IMG) 170 mechanisms must satisfy in order to deliver IMG metadata to a 171 potentially large audience. Since IMGs can describe many kinds of 172 multimedia content, IMG methods are generally applicable to several 173 scenarios. 175 In considering wide applicability, this document provides the problem 176 statement and existing mechanisms in this area. Then several use case 177 scenarios for IMGs are explained including descriptions of how IMG 178 metadata and IMG delivery mechanisms contribute to these scenarios. 179 Following this, this document provides general requirements that are 180 independent of any transport layer mechanism and application, such as 181 delivery properties, reliability and IMG descriptions. 183 This document reflects investigating work on delivery mechanisms for 184 IMGs and generalizing work on session announcement and initiation 185 protocols, especially in the field of the MMUSIC working group (SAP, 186 SIP [7], SDP). 188 2 Terminology 190 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 191 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 192 document are to be interpreted as described in RFC 2119 [2]. 194 Internet Media Guide (IMG): IMG is a generic term to describe 195 the formation, delivery and use of IMG metadata. The 196 definition of the IMG is intentionally left imprecise. 198 IMG Element: The smallest atomic element of metadata that can be 199 transmitted separately by IMG operations and referenced 200 individually from other IMG elements. 202 IMG Metadata: A set of metadata consisting of one or more IMG 203 elements. IMG metadata describes the features of multimedia 204 content used to enable selection of and access to media 205 sessions containing content. For example, metadata may 206 consist of the URI, title, airtime, bandwidth needed, file 207 size, text summary, genre and access restrictions. 209 IMG Delivery: The process of exchanging IMG metadata both in 210 terms of large scale and atomic data transfers. 212 IMG Sender: An IMG sender is a logical entity that sends IMG 213 metadata to one or more IMG receivers. 215 IMG Receiver: An IMG receiver is a logical entity that receives 216 IMG metadata from an IMG sender. 218 IMG Transceiver: An IMG transceiver combines an IMG receiver and 219 sender. It may modify received IMG metadata or merge IMG 220 metadata received from a several different IMG senders. 222 IMG Operation: An atomic operation of an IMG transport protocol, 223 used between IMG sender(s) and IMG receiver(s) for the 224 delivery of IMG metadata and for the control of IMG 225 sender(s)/receiver(s). 227 IMG Transport Protocol: A protocol that transports IMG metadata 228 from an IMG sender to IMG receiver(s). 230 IMG Transport Session: An association between an IMG sender and 231 one or more IMG receivers within the scope of an IMG 232 transport protocol. An IMG transport session involves a 233 series of IMG transport protocol interactions that provide 234 delivery of IMG metadata from the IMG sender to the IMG 235 receiver(s). 237 3 Problem Statement 239 As we enumerate the requirements for an IMG, it will become clear 240 that they are not fully addressed by the existing protocols. The 241 Framework for the Usage of Internet Media Guides [1] talks about 242 these issues in more detail. 244 The MMUSIC working group has long been investigating content, media 245 and service information delivery mechanisms and protocols, and has 246 itself produces Session Announcement Protocol (SAP), Session 247 Description Protocol (SDP), and the Session Initiation Protocol 248 (SIP). SDP is capable of describing multimedia sessions (i.e. 249 content in a wider sense) by means of limited descriptive information 250 intended for human perception plus transport, scheduling information, 251 and codecs and addresses for setting up media sessions. SIP and SAP 252 are protocols to distribute these session descriptions. 254 However, we perceive a lack of standard solution for scalable IMG 255 delivery mechanism in the number of receivers with consistency of IMG 256 metadata between an IMG sender and IMG receiver for both bi- 257 directional and unidirectional transport. With increased service 258 dynamics and complexity, there is an increased requirement for 259 updates to these content descriptions. 261 HTTP [8] is a well known information retrieval protocol using bi- 262 directional transport and widely used to deliver web-based content 263 descriptions to many hosts. However, it has well recognized 264 limitations of scalability in the number of HTTP clients since it 265 relies on the polling mechanism to keep information consistent 266 between the server and client. 268 SAP [4] is an announcement protocol that distributes session 269 descriptions via multicast. It does not support fine-grained metadata 270 selection and update notifications, as it always sends the whole 271 metadata. Given the lack of a wide-area multicast infrastructure, it 272 is likely only deployable within a local area network. 274 SIP [7] and SIP-specific event notification [9] can be used to notify 275 subscribers of the update of IMG metadata for bi-directional 276 transport. However, it is necessary for SIP Event to define an event 277 package as a standard protocol for each specific application 278 including IMGs. 280 We also perceive a lack of standard solution for flexible content 281 descriptions to support a multitude of application-specific data 282 models with differing amount of detail and different target 283 audiences. 285 SDP [3] has a text-encoded syntax to specify multimedia sessions for 286 announcements and invitations. Although SDP is extensible, it has 287 limitations such as structured extensibility and capability to 288 reference properties of a multimedia session from the description of 289 another session. 291 These are mostly overcome by the XML-based SDPng [10], which is 292 intended for both two-way negotiation and also unidirectional 293 delivery. Since SDPng addresses multiparty multimedia conferences, it 294 is necessary to extend the XML schema in order to describe general 295 multimedia content. 297 4 Use Cases Requiring IMGs 299 4.1 Connectivity-based Use Cases 301 4.1.1 IP Datacast to a Wireless Receiver 303 IP Datacast is the delivery of IP-based services over broadcast 304 radio. Internet content delivery is therefore unidirectional in this 305 case. However, there can be significant benefits from being able to 306 provide rich media one-to-many services to such receivers. 308 There are two main classes of receiver in this use case: fixed 309 mains-powered; and mobile battery-powered. Both of these are affected 310 by radio phenomena and so robust, or error-resilient, delivery is 311 important. Carouselled metadata transfer provides a base level of 312 robustness for an IP datacast based announcement system, although the 313 design of carouselled transfer should enable battery-powered 314 receivers to go through periods of sleep to extend their operational 315 time between charges. Insertion of Forward Error Correction (FEC) 316 data into metadata announcements improves error resilience, and 317 reordering (interleaving) data blocks further increases tolerance to 318 burst errors. 320 To enable receivers to more accurately specify the metadata they are 321 interested in, the unidirectional delivery is distributed between 322 several logical channels. This is so that a receiver need only access 323 the channels of interest and thus can reduce the amount of time, 324 storage and CPU resources needed for processing the IP data. Also, 325 hierarchical channels enable receivers to subscribe to a root, 326 possibly well known, multicast channel/group and progressively access 327 only those additional channels based on metadata in parent channels. 329 In some cases the receiver may be multi-access, such that it is 330 capable of bi-directional communications. This enables a multitude of 331 options, but most importantly it enables NACK based reliability and 332 the individual retrieval of missed or not-multicasted sets of 333 metadata. 335 Thus, essential IMG features in this case include: robust 336 unidirectional delivery (with optional levels of reliability 337 including "plug-in FEC") which implies easily identifiable 338 segmentation of delivery data to enable FEC, carousel, interleaving 339 and other schemes possible; effective identification of metadata sets 340 (probably uniquely) to enable more efficient use of multicast and 341 unicast retrieval over multiple access systems regardless of the 342 parts of metadata and application specific extensions in use; 343 prioritization of metadata, which can (for instance) be achieved by 344 spreading it between channels and allocating/distributing bandwidth 345 accordingly. 347 Furthermore, some cases require IMG metadata authentication and some 348 group security/encryption and supporting security message exchanges 349 (out of band from the IMG multicast sessions). 351 4.1.2 Regular Fixed Dial-up Internet Connection 353 Dial-up connections tend to be reasonably slow (<56kbps in any case) 354 and thus large data transfers are less feasible, especially during an 355 active application session (such as a file transfer described by IMG 356 metadata). They can also be intermittent, especially if a user is 357 paying for the connected time, or connected through a less reliable 358 exchange. Thus this favors locally stored IMG metadata over web-based 359 browsing, especially where parts of the metadata change infrequently. 360 There may be no service provider preference over unicast and 361 multicast transport for small and medium numbers of users as the 362 last-mile dial-up connection limits per-user congestion, and a user 363 may prefer the more reliable option (unicast unless reliable 364 multicast is provided). 366 4.1.3 Broadband Always-on Fixed Internet Connection 368 Typically bandwidth is less of an issue to a broadband user and 369 unicast transport, such as using IMG QUERY, may be typical for a PC 370 user. If a system were only used in this context, with content 371 providers, ISPs and users having no other requirements, then web- 372 based browsing may be equally suitable. However, broadband users 373 sharing a local area network, especially wireless, may benefit more 374 from local storage features than on-line browsing, especially if they 375 have intermittent Internet access. 377 Broadband enables rich media services, which are increasingly 378 bandwidth hungry. Thus backbone operators may prefer multicast 379 communications to reduce overall congestion, if they have the 380 equipment and configuration to support this. Thus, broadband users 381 may be forced to retrieve IMG metadata over multicast if the 382 respective operators require this to keep system-wide bandwidth usage 383 feasible. 385 4.2 Content-orientated Use Cases 387 IMGs will be able to support a very wide range of use cases for 388 content/media delivery. The following few sections just touch the 389 surface of what is possible and are intended to provide an 390 understanding of the scope and type of IMG usage. Many more examples 391 may be relevant, for instance those detailed in [11]. There are 392 several unique features of IMGs that set them apart from related 393 application areas such as SLP based service location discovery, LDAP 394 based indexing services and search engines such as Google. Features 395 unique to IMGs include: 397 o IMG metadata is generally time-related 399 o There are timeliness requirements in the delivery of IMG 400 metadata 402 o IMG metadata may be updated as time elapses or when an event 403 arises 405 4.2.1 TV and Radio Program Delivery 407 A sender of audio/video streaming content can use the IMG metadata to 408 describe the scheduling and other properties of audio/video sessions 409 and events within those sessions, such as individual TV and radio 410 programs and segments within those programs. IMG metadata describing 411 audio/video streaming content could be represented in a format 412 similar to that of a TV guide in newspapers, or an Electronic Program 413 Guide available on digital TV receivers. 415 Similarly to file reception, TV and radio programs can be selected 416 for reception either manually by the end-user or automatically based 417 on the content descriptions and the preferences of the user. The 418 received TV and radio content can be either presented in real time or 419 recorded for consuming later. There may be changes in the scheduling 420 of a TV or a radio program, possibly affecting the transmission times 421 of subsequent programs. IMG metadata can be used to notify receivers 422 of such changes, enabling users to be prompted or recording times to 423 be adjusted. 425 4.2.2 Media Coverage of a Live Event 427 The media coverage of a live event such as a rock concert or a sports 428 event is a special case of regular TV/radio programming. There may be 429 unexpected changes in the scheduling of live event, or the event may 430 be unscheduled to start with (such as breaking news). In addition to 431 audio/video streams, textual information relevant to the event (e.g. 432 statistics of the players during a football match) may be sent to 433 user terminals. Different transport modes or even different access 434 technologies can be used for the different media: for example, a 435 unidirectional datacast transport could be used for the audio/video 436 streams and an interactive cellular connection for the textual data. 437 IMG metadata should enable terminals to discover the availability of 438 different media used to cover a live event. 440 4.2.3 Distance Learning 442 IMG metadata could describe compound sessions or services enabling 443 several alternative interaction modes between the participants. For 444 example, the combination of one-to-many media streaming, unicast 445 messaging and download of presentation material could be useful for 446 distance learning. 448 4.2.4 Multiplayer Gaming 450 Multiplayer games are an example of real-time multiparty 451 communication sessions that could be advertised using IMGs. A gaming 452 session could be advertised either by a dedicated server, or by the 453 terminals of individual users. A user could use IMGs to learn of 454 active multiplayer gaming sessions, or advertise the users interest 455 in establishing such a session. 457 4.2.5 File Distribution 459 IMGs support the communication of file delivery session properties, 460 enabling the scheduled delivery or synchronization of files between a 461 number of hosts. The received IMG metadata could be subsequently used 462 by any application (also outside the scope of IMGs), for example to 463 download a file with a software update. IMG metadata can provide a 464 description to each file in a file delivery session, assisting users 465 or receiving software in selecting individual files for reception. 467 For example, when a content provider wants to distribute a large 468 amount of data in file format to thousands clients, the content 469 provider can use IMG metadata to schedule the delivery effectively. 470 Since IMG metadata can describe time-related data for each receiver, 471 the content provider can schedule delivery time for each receiver. 472 This can save network bandwidth and delivery capacity of senders. In 473 addition, IMG metadata can be used to synchronize a set of files 474 between a sender host and receiver host, when those files change as 475 time elapses. 477 4.2.6 Coming-release and Pre-released Content 479 IMG metadata can be used to describe items of content before the 480 details of their final release are known. A user may be interested in 481 coming content (a new movie or software title where some aspects of 482 the content description are known in advance) and so subscribe to an 483 information service which notifies the user of changes to metadata 484 describing that content. Thus, as the coming release, or pre-releases 485 (such as movie trailers or software demos), become available the IMG 486 metadata changes and the user is notified of this change. For 487 example, the user could see an announcement of a movie that will be 488 released sometime in the next few months, and configure the user's 489 terminal to receive and record any trailers or promotional material 490 as they become available. 492 5 Requirements 494 5.1 General Requirements 496 5.1.1 Independence of IMG Operations from IMG Metadata 498 REQ GEN-1: Carrying different kinds of IMG metadata format in the IMG 499 message body MUST be allowed. 501 REQ GEN-2: Delivery mechanisms SHOULD support many different 502 applications specific metadata formats to keep the system 503 interoperable with existing applications. 505 This provides flexibility in selecting/designing IMG transport 506 protocol suited to various scenarios. 508 5.1.2 Multiple IMG Senders 510 REQ GEN-3: IMG receivers MUST be allowed to communicate with any 511 number of IMG senders simultaneously. 513 This might lead to receiving redundant IMG metadata describing the 514 same items, however it enables the IMG receiver access to more IMG 515 metadata than may be available from a single IMG sender. This also 516 provides flexibility for the IMG transport protocols and does not 517 preclude a mechanism to solve inconsistency among IMG metadata due to 518 multiple IMG senders. This document assumes a typical IMG environment 519 will involve many more IMG receivers than IMG senders and that IMG 520 senders are continually connected for the duration of interest 521 (rather than intermittently connected). 523 5.1.3 Modularity 524 REQ GEN-4: The IMG delivery mechanisms MUST allow the combination of 525 several IMG Operations. 527 This is for the purpose of extending functionality (e.g. several or 528 one protocol(s) to provide all the needed operations). Applications 529 can select an appropriate operation set to fulfill their purpose. 531 5.2 Delivery Properties 533 This section describes general performance requirements based on the 534 assumption that the range of IMG usage shall be important. However, 535 it may be noted that requirements of delivery properties may vary 536 based on the usage scenario, and thus some limited use 537 implementations place less importance on some requirements. 539 For example, it is clear that a multicast transport may provide more 540 scalable delivery than a unicast transport, however scalability 541 requirements do not preclude the unicast transport mechanisms. In 542 this sense, scalability is always important for the protocols 543 irrespective of transport mechanisms. 545 5.2.1 Scalability 547 REQ DEL-1: The system MUST be scalable to large numbers of messages, 548 so that it does not fail to deliver up-to-date information under huge 549 numbers of transactions and massive quantities of IMG metadata. 551 REQ DEL-2: IMGs SHOULD provide a method to prevent an IMG sender from 552 sending unnecessary IMG metadata that have been stored or deleted in 553 IMG receivers. 555 REQ DEL-3: The protocol MUST be scalable to very large audience sizes 556 requiring IMG delivery. 558 5.2.2 Support for Intermittent Connectivity 560 REQ DEL-4: The system MUST enable IMG receivers with intermittent 561 access to network resources (connectivity) to receive and adequately 562 maintain sufficient IMG metadata. 564 This allows intermittent access to save power where there is no need 565 to keep communications links powered-up while they are sitting idle. 566 For instance, in this situation periodic bursts of notifies, or a 567 fast cycling update carousel, allows hosts to wake up for short 568 periods of time and still be kept up-to-date. This can be beneficial 569 for IMG receivers with sporadic connects to the fixed Internet, but 570 is critical in the battery-powered wireless Internet. 572 5.2.3 Congestion Control 574 REQ DEL-5: Internet-friendly congestion control MUST be provided for 575 use on the public Internet. 577 REQ DEL-6: An IMG entity SHOULD invalidate the IMG metadata item when 578 an IMG metadata item has lifetime information and its lifetime is 579 over. This will lessen the need for notifications of updates from the 580 IMG sender to the IMG receiver to invalidate the item and may enable 581 lesser congestion. 583 5.2.4 Sender and Receiver Driven Delivery 585 REQ DEL-7: The system MUST be flexible in choosing sender-driven, 586 receiver-driven or both delivery schemes. 588 Sender-driven delivery achieves high scalability without interaction 589 between the IMG sender and receiver. This avoids keeping track of a 590 delivery state of every IMG receiver. 592 In contrast, the receiver-driven delivery provides on-demand delivery 593 for IMG receivers. Since an IMG sender's complete IMG metadata may be 594 a very large amount of data, the IMG receiver needs to be able to 595 access the guide when convenient (e.g., when sufficient network 596 bandwidth is available to the IMG receiver). 598 5.3 Customized IMGs 600 REQ CUS-1: The system MUST allow delivery of customized IMG metadata. 602 The IMG receiver may require a subset of all the IMG metadata 603 available according to their preferences (type of content, media 604 description, appropriate age group, etc.) and configuration. 606 The IMG receiver might send its preferences in the IMG operations 607 which can specify user specific IMG metadata to be delivered. These 608 preferences could consist of filtering rules. When receiving these 609 messages, the IMG sender might respond appropriate messages carrying 610 a subset of IMG metadata which matches the IMG receiver's 611 preferences. 613 This mechanism can reduce the amount of IMG metadata delivered from 614 the IMG sender to IMG receiver, and consequently it can save the 615 resource consumption on the IMG entities and networks. It is 616 typically useful in unicast case and also beneficial in multicast 617 case where IMG sender distributes the same IMG metadata to interested 618 IMG receivers at the same time. 620 For multicast and unicast cases where the IMG sender does not provide 621 customized IMG metadata, the IMG receiver could receive all IMG 622 metadata transmitted (on its joined channels). However, it may select 623 and filter the IMG metadata to get customized IMG metadata by its 624 preferences, and thus drop unwanted metadata immediately upon 625 reception. 627 Customized metadata might be achieved by changing the IMG 628 descriptions sent and IMG receivers and/or changing the delivery 629 properties (channels used). 631 Note, customization and scalability are only somewhat exclusive. 632 Systems providing an IMG receiver to an IMG sender request-based 633 customization, will be generally less scalable to massive IMG 634 receiver populations than those without this return signaling 635 technique. Thus, customization, as with any feature which affects 636 scalability, should be carefully designed for the intended 637 application, and it may not be possible that a one-size-fits-all 638 solution for customization would meet the scalability requirements 639 for all applications and deployment cases. 641 5.4 Reliability 643 5.4.1 Managing consistency 645 IMG metadata tends to change as time elapses, as new content is 646 added, the old IMG metadata stored in the IMG receiver becomes 647 unavailable and the parameters of the existing IMG metadata are 648 changed. 650 REQ REL-1: The system MUST manage IMG metadata consistency. 652 The IMG sender can either simply make updates available 653 (unsynchronized) or IMG sender and receiver can interact to keep 654 their copies of the IMG metadata synchronized. 656 In the unsynchronized model, the IMG sender does not know whether a 657 particular IMG receiver has an up-to-date copy of the IMG metadata. 659 In the synchronized model, updating cached copy of the IMG metadata 660 is necessary to control consistency when the IMG sender or receiver 661 could not communicate for a while. In this case, the IMG sender or 662 receiver may need to confirm its consistency by IMG operations. 664 REQ REL-2: Since IMG metadata can change at any time, IMG receivers 665 SHOULD be notified of such changes. 667 Depending on the size of the guide, the interested party may want to 668 defer retrieving the actual information. The change notification 669 should be addressed to a logical user (or user group), not a host, 670 since users may change devices. 672 Note that depending on the deployment environment and application 673 specifics, the level of acceptable inconsistency varies. Thus, this 674 document does not define inconsistency as specific time and state 675 differences between IMG metadata stored in an IMG sender and IMG 676 metadata stored in an IMG receiver. 678 In general, the consistency of metadata for a content and media is 679 more important immediately prior to and during the media's 680 session(s). Hosts which forward (or otherwise resend) metadata may be 681 less tolerant to inconsistencies as delivering out of date data is 682 both misleading and bandwidth inefficient. 684 By contrast, intermittent connectivity make immediate distribution of 685 changes infeasible and so managing data consistency should be focused 686 on the timely delivery of data. 688 5.4.2 Reliable Message Exchange 690 REQ REL-3: An IMG transport protocol MUST support reliable message 691 exchange. 693 The extent to which this could result in 100% error free delivery to 694 100% of IMG receivers is a statistical characteristic of the 695 protocols used. Usage of reliable IMG delivery mechanisms is expected 696 to depend on the extent to which underlying networks provide 697 reliability and, conversely, introduce errors. Note, some deployments 698 of IMG transport protocols may not aim to provide perfect reception 699 to all IMG receivers in all possible cases. 701 5.5 IMG Descriptions 703 REQ DES-1: IMG metadata MUST be interoperable over any IMG transport 704 protocol, such that an application receiving the same metadata over 705 any one (or more) of several network connections and/or IMG transport 706 protocols will interpret the metadata in exactly the same way. (This 707 also relates to the 'Independence of IMG Operations from IMG 708 Metadata' requirement). 710 REQ DES-2: IMG delivery MUST enable the carriage of any format of 711 application-specific metadata. 713 Thus, the system will support the description of many kinds of 714 multimedia content, without the need for a single homogenous metadata 715 syntax for all uses (which would be infeasible anyway). This is 716 essential for environments using IMG systems to support many kinds of 717 multimedia content and to achieve wide applicability. 719 REQ DES-3: Whereas specific applications relying on IMGs will need to 720 select one or more specific application-specific metadata formats 721 (standard, syntax, etc.), the IMG system MUST be independent of this 722 (it may be aware, but it will operate in the same way for all). 724 Thus, a transfer envelope format, that is uniform across all 725 different application-specific IMG metadata formats, is needed. The 726 payload of this transfer envelope would be some application-specific 727 metadata, and the envelope would support the maintenance of the 728 application-specific metadata including the metadata relationships 729 determined by the data model(s) used. The transfer envelope would not 730 need to be aware of the data model(s) in use. 732 REQ DES-4: IMG metadata MUST be structured such that it is possible 733 to deliver only part of an IMG sender's (and the global) complete IMG 734 metadata knowledge. 736 REQ DES-5: A transfer envelope MUST be defined to include essential 737 parameters. 739 Examples of essential parameters are those that allow the metadata in 740 question to be uniquely identified and updated by new versions of the 741 same metadata. 743 REQ DES-6: It SHALL be possible to deduce the metadata format from 744 the transfer envelope. 746 REQ DES-7: IMG senders SHALL use the transfer envelope for each IMG 747 metadata transfer. 749 Thus, it will even be possible to describe relationships between 750 syntactically dissimilar application-specific formats within the same 751 body of IMG metadata knowledge. 753 REQ DES-8: IMG metadata SHOULD support to describe differences 754 between update version and old version of IMG metadata when IMG 755 delivery mechanism carries updated IMG metadata and those differences 756 are considerably little. (This also relates the delivery property 757 requirements for congestion control in Section 5.2.3). 759 6 Security Considerations 761 Internet Media Guides are used to convey information about multimedia 762 resources from one or more IMG senders across one or intermediaries 763 to one or more IMG receivers. IMG metadata may be pushed to the IMG 764 receivers or interactively retrieved by them. IMGs provide metadata 765 as well as scheduling and rendezvous information about multimedia 766 resources, etc. and requests for IMG metadata may contain information 767 about the requesting users. 769 The information contained in IMG metadata as well as the operations 770 related to IMGs should be secured to avoid forging information, 771 misdirecting users, spoofing IMG senders, etc. and to protect user 772 privacy. 774 The remainder of section addresses the security requirements for 775 IMGs. 777 6.1 IMG Authentication and Integrity 779 IMG metadata and its parts need to be protected against unauthorized 780 altering/adding/deletion on the way. Their originator needs to be 781 authenticated. 783 REQ AUT-1: It MUST be possible to authenticate the originator of a 784 set of IMG metadata. 786 REQ AUT-2: It MUST be possible to authenticate the originator of a 787 subpart of IMG metadata (e.g. a delta or a subset of the 788 information). 790 REQ AUT-3: It MUST be possible to validate the integrity of IMG 791 metadata. 793 REQ AUT-4: It MUST be possible to validate the integrity of a subpart 794 of IMG metadata (e.g. a delta or a subset of the information). 796 REQ AUT-5: It MUST be possible to separate or combine individually 797 authenticated pieces of IMG metadata (e.g. in an IMG transceiver) 798 without invalidating the authentication. 800 REQ AUT-6: It MUST be possible to validate the integrity of an 801 individually authenticated piece of IMG metadata even after this 802 piece had been separated from other pieces of IMG metadata and 803 combined with other pieces to form new IMG metadata. 805 REQ AUT-7: It MUST be possible to authenticate the originator of an 806 IMG operation. 808 REQ AUT-8: It MUST be possible to validate the integrity of any 809 contents of an IMG operation (e.g. the subscription or inquiry 810 information). 812 6.2 Privacy 814 Customized IMG metadata and IMG metadata delivered by notification to 815 individual users may reveal information about the habits and 816 preferences of a user and may thus deserve confidentiality 817 protection, even though the information itself is public. 819 REQ PRI-1: It MUST be possible to keep user requests to subscribe to 820 or retrieve certain (parts of) IMG metadata confidential. 822 REQ PRI-2: It MUST be possible to keep IMG metadata, pieces of IMG 823 metadata, or pointers to IMG metadata delivered to individual users 824 or groups of users confidential. 826 REQ PRI-3: It SHOULD be possible to ensure this confidentiality end- 827 to-end, that is, to prevent intermediaries (such as IMG transceivers) 828 from accessing the contained information. 830 6.3 Access Control for IMGs 832 Some IMG metadata may be freely available, while access to other may 833 be restricted to closed user groups (e.g. paying subscribers). Also, 834 different parts of IMG metadata may be protected at different levels: 835 e.g. metadata describing a media session may be freely accessible 836 while rendezvous information to actually access the media session may 837 require authorization. 839 REQ ACC-1: It MUST be possible to authorize user access to IMG 840 metadata. 842 REQ ACC-2: It MUST be possible to authorize access of users to pieces 843 of IMG metadata (delta information, subparts, pointers). 845 REQ ACC-3: It MUST be possible to require different authorization for 846 different parts of the same IMG metadata. 848 REQ ACC-4: It MUST be possible to access selected IMG metadata 849 anonymously. 851 REQ ACC-5: It MUST be possible for an IMG receiver to choose not to 852 receive (parts of) IMG metadata in order to avoid being identified by 853 the IMG sender. 855 REQ ACC-6: It SHOULD be possible for IMG transceiver to impose 856 different authorization requirements. 858 REQ ACC-7: It MAY be possible for IMG senders to require certain 859 authorization that cannot be overridden by intermediaries. 861 6.4 Denial-of-Service attacks 863 Retrieving or distributing IMG metadata may require state in the IMG 864 senders, transceivers, and/or receivers for the respective IMG 865 transport sessions. Attackers may create large numbers of sessions 866 with any of the above IMG entities to disrupt regular operation. 868 REQ DOS-1: IMG operations SHOULD be authenticated. 870 REQ DOS-2: It SHOULD be possible to prevent DoS attacks that build up 871 session state in IMG entities to exhaust their resources. 873 REQ DOS-3: It SHOULD be possible to avoid DoS attacks that exhaust 874 resources of IMG entities by flooding them with IMG metadata. 876 6.5 Replay Attacks 878 IMG metadata disseminated by an IMG sender or an IMG transceiver may 879 be updated, deleted, or lose validity over time for some other 880 reasons. Replaying outdated IMG metadata needs to be prevented. 882 Furthermore, replay attacks may also apply to IMG operations (rather 883 than just their payload). Replaying operations needs also be 884 prevented. 886 REQ REP-1: IMG metadata MUST be protected against partial or full 887 replacement of newer ("current") versions by older ones. 889 REQ REP-2: Mechanisms MUST be provided to mitigate replay attacks on 890 the IMG operations. 892 7 IANA Considerations 894 There are no IANA considerations within this document. 896 8 Normative References 898 [1] Y. Nomura, R. Walsh, J-P. Luoma, H. Asaeda, and H. Schulzrinne, 899 "A framework for the usage of Internet media guides," Internet Draft 900 draft-ietf-mmusic-img-framework-02, Internet Engineering Task Force, 901 Dec. 2003. Work in progress. 903 [2] S. Bradner, "Key words for use in RFCs to indicate requirement 904 levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. 906 9 Informative References 908 [3] M. Handley and V. Jacobson, "SDP: session description protocol," 909 RFC 2327, Internet Engineering Task Force, Apr. 1998. 911 [4] M. Handley, C. E. Perkins, and E. Whelan, "Session announcement 912 protocol," RFC 2974, Internet Engineering Task Force, Oct. 2000. 914 [5] Session Directory, ftp://ftp.ee.lbl.gov/conferencing/sd/ 916 [6] Session Directory Tool, http://www- 917 mice.cs.ucl.ac.uk/multimedia/software/sdr/ 919 [7] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J. 920 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session 921 initiation protocol," RFC 3261, Internet Engineering Task Force, June 922 2002. 924 [8] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, and T. Berners- 925 Lee, "Hypertext transfer protocol -- HTTP/1.1," RFC 2068, Internet 926 Engineering Task Force, Jan. 1997. 928 [9] A. B. Roach, "Session initiation protocol (sip)-specific event 929 notification," RFC 3265, Internet Engineering Task Force, June 2002. 931 [10] D. Kutscher, J. Ott, and C. Bormann, "Session description and 932 capability negotiation," Internet Draft draft-ietf-mmusic-sdpng-07, 933 Internet Engineering Task Force, Oct. 2003. Work in progress. 935 [11] B. Quinn and K. Almeroth, "IP multicast applications: Challenges 936 and solutions," RFC 3170, Internet Engineering Task Force, Sept. 937 2001. 939 10 Acknowledgements 941 The authors would like to thank Colin Perkins, Jean-Pierre Evain, 942 Hitoshi Asaeda, Petri Koskelainen, Toni Paila and Dirk Kutscher for 943 their comments and ideas on this work. 945 11 Authors' Addresses 947 Yuji Nomura 948 Fujitsu Laboratories Ltd. 949 4-1-1 Kamikodanaka, Nakahara-ku, Kawasaki 211-8588 950 Japan 951 Email: nom@flab.fujitsu.co.jp 953 Rod Walsh 954 Nokia Research Center 955 P.O. Box 100, FIN-33721 Tampere 956 Finland 957 Email: rod.walsh@nokia.com 959 Juha-Pekka Luoma 960 Nokia Research Center 961 P.O. Box 100, FIN-33721 Tampere 962 Finland 963 Email: juha-pekka.luoma@nokia.com 965 Joerg Ott 966 Universitaet Bremen 967 MZH 5180 968 Bibliothekstr. 1 969 D-28359 Bremen 970 Germany 971 Email: jo@tzi.uni-bremen.de 973 Henning Schulzrinne 974 Dept. of Computer Science 975 Columbia University 976 1214 Amsterdam Avenue 977 New York, NY 10027 978 USA 979 Email: schulzrinne@cs.columbia.edu 981 The IETF takes no position regarding the validity or scope of any 982 intellectual property or other rights that might be claimed to 983 pertain to the implementation or use of the technology described in 984 this document or the extent to which any license under such rights 985 might or might not be available; neither does it represent that it 986 has made any effort to identify any such rights. Information on the 987 IETF's procedures with respect to rights in standards-track and 988 standards-related documentation can be found in BCP-11. Copies of 989 claims of rights made available for publication and any assurances of 990 licenses to be made available, or the result of an attempt made to 991 obtain a general license or permission for the use of such 992 proprietary rights by implementors or users of this specification can 993 be obtained from the IETF Secretariat. The IETF invites any 994 interested party to bring to its attention any copyrights, patents or 995 patent applications, or other proprietary rights which may cover 996 technology that may be required to practice this standard. Please 997 address the information to the IETF Executive Director. 999 Full Copyright Statement 1001 Copyright (c) The Internet Society (2004). All Rights Reserved. 1003 This document and translations of it may be copied and furnished to 1004 others, and derivative works that comment on or otherwise explain it 1005 or assist in its implementation may be prepared, copied, published 1006 and distributed, in whole or in part, without restriction of any 1007 kind, provided that the above copyright notice and this paragraph are 1008 included on all such copies and derivative works. However, this 1009 document itself may not be modified in any way, such as by removing 1010 the copyright notice or references to the Internet Society or other 1011 Internet organizations, except as needed for the purpose of 1012 developing Internet standards in which case the procedures for 1013 copyrights defined in the Internet Standards process must be 1014 followed, or as required to translate it into languages other than 1015 English. 1017 The limited permissions granted above are perpetual and will not be 1018 revoked by the Internet Society or its successors or assigns. 1020 This document and the information contained herein is provided on an 1021 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1022 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1023 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1024 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1025 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.