idnits 2.17.1 draft-ietf-mmusic-img-req-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1034. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1045. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1052. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1058. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (June 21, 2004) is 7249 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) -- Obsolete informational reference (is this intentional?): RFC 2327 (ref. '2') (Obsoleted by RFC 4566) == Outdated reference: A later version (-08) exists of draft-ietf-mmusic-sdpng-07 == Outdated reference: A later version (-09) exists of draft-ietf-mmusic-img-framework-07 -- Obsolete informational reference (is this intentional?): RFC 2616 (ref. '9') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 3265 (ref. '10') (Obsoleted by RFC 6665) Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 9 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-07.txt 13 June 21, 2004 14 Expires: December 2004 16 Requirements for Internet Media Guides 18 STATUS OF THIS MEMO 20 By submitting this Internet-Draft, I certify that any applicable 21 patent or other IPR claims of which I am aware have been disclosed, 22 and any of which I become aware will be disclosed, in accordance 23 with RFC 3668." 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as 28 Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six 31 months and may be updated, replaced, or obsoleted by other 32 documents at any time. It is inappropriate to use Internet-Drafts 33 as reference material or to cite them other than a "work in 34 progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/1id-abstracts.html 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html 42 Abstract 44 This memo specifies requirements for a framework and protocols for 45 accessing and updating Internet Media Guide (IMG) information for 46 media-on-demand and multicast applications. These requirements are 47 designed to guide choice and development of IMG protocols for 48 efficient and scalable delivery. 50 Table of Contents 52 1 Introduction ........................................ 3 53 1.1 Background and Motivation ........................... 3 54 1.2 Scope of This Document .............................. 4 55 2 Terminology ......................................... 5 56 3 Problem Statement ................................... 6 57 4 Use Cases Requiring IMGs ............................ 7 58 4.1 Connectivity-based Use Cases ........................ 7 59 4.1.1 IP Datacast to a Wireless Receiver .................. 7 60 4.1.2 Regular Fixed Dial-up Internet Connection ........... 8 61 4.1.3 Broadband Always-on Fixed Internet Connection ....... 8 62 4.2 Content-orientated Use Cases ........................ 9 63 4.2.1 TV and Radio Program Delivery ....................... 9 64 4.2.2 Media Coverage of a Live Event ...................... 9 65 4.2.3 Distance Learning ................................... 10 66 4.2.4 Multiplayer Gaming .................................. 10 67 4.2.5 File Distribution ................................... 10 68 4.2.6 Coming-release and Pre-released Content ............. 11 69 5 Requirements ........................................ 11 70 5.1 General Requirements ................................ 11 71 5.1.1 Independence of IMG Operations from IMG Metadata .... 11 72 5.1.2 Multiple IMG Senders ................................ 11 73 5.1.3 Modularity .......................................... 12 74 5.2 Delivery Properties ................................. 12 75 5.2.1 Scalability ......................................... 12 76 5.2.2 Support for Intermittent Connectivity ............... 12 77 5.2.3 Congestion Control .................................. 13 78 5.2.4 Sender and Receiver Driven Delivery ................. 13 79 5.3 Customized IMGs ..................................... 13 80 5.4 Reliability ......................................... 14 81 5.4.1 Managing Consistency ................................ 14 82 5.4.2 Reliable Message Exchange ........................... 15 83 5.5 IMG Descriptions .................................... 15 84 6 Security Considerations ............................. 17 85 6.1 IMG Authentication and Integrity .................... 17 86 6.2 Privacy ............................................. 18 87 6.3 Access Control for IMGs ............................. 18 88 6.4 Denial-of-Service attacks ........................... 19 89 6.5 Replay Attacks ...................................... 19 90 7 IANA Considerations ................................. 20 91 8 Normative References ................................ 20 92 9 Informative References .............................. 20 93 10 Acknowledgements .................................... 21 94 11 Authors' Addresses .................................. 21 95 12 Full Copyright Statement ............................ 22 97 1 Introduction 99 1.1 Background and Motivation 101 For some ten years, multicast-based (multimedia) conferences 102 (including IETF WG sessions) as well as broadcasts of 103 lectures/seminars, concerts, and other events have been used in the 104 Internet, more precisely, on the MBONE. Schedules and descriptions 105 for such multimedia sessions as well as the transport addresses, 106 codecs, and their parameters have been described using SDP [2] as a 107 rudimentary (but as of then largely sufficient) means. Dissemination 108 of the descriptions has been performed using the Session Announcement 109 Protocol (SAP) [3] and tools such as SD [4] or SDR [5]; descriptions 110 have also been put up on web pages, sent by electronic mail, etc. 112 Recently, interest has grown to expand -- or better: to generalize -- 113 the applicability of these kinds of session descriptions. 114 Descriptions are becoming more elaborate in terms of included 115 metadata; more generic regarding the types of media sessions; and 116 possibly also support other transports than just IP (e.g. legacy TV 117 channel addresses). This peers well with the DVB Organization's 118 increased activities towards IP-based communications over satellite, 119 cable, and terrestrial radio networks, also considering IP as the 120 basis for TV broadcasts and further services. The program/content 121 descriptions are referred to as Internet Media Guides (IMGs) and can 122 be viewed as a generalization of Electronic Program Guides (EPGs) and 123 multimedia session descriptions. 125 An Internet Media Guide (IMG) has a structured collection of 126 multimedia session descriptions expressed using SDP, SDPng [6] or 127 some similar session description format. This is used to describe a 128 set of multimedia services (e.g. television program schedules, 129 content delivery schedules) but may also refer to other networked 130 resources including web pages. IMGs provide the envelope for metadata 131 formats and session descriptions defined elsewhere with the aim of 132 facilitating structuring, versioning, referencing, distributing, and 133 maintaining (caching, updating) such information. 135 The IMG metadata may be delivered to a potentially large audience, 136 who use it to join a subset of the sessions described, and who may 137 need to be notified of changes to this information. Hence, a 138 framework for distributing IMG metadata in various different ways is 139 needed to accommodate the needs of different audiences: For 140 traditional broadcast-style scenarios, multicast-based (push) 141 distribution of IMG metadata needs to be supported. Where no 142 multicast is available, unicast-based push is required, too. 143 Furthermore, IMG metadata may need to be retrieved interactively, 144 similar to web pages (e.g. after rebooting a system or when a user is 145 browsing after network connectivity has been re-established). 146 Finally, IMG metadata may be updated as time elapses because content 147 described in the guide may be changed: for example, the airtime of an 148 event such as a concert or sports event may change, possibly 149 affecting the airtime of subsequent media. This may be done by 150 polling the IMG sender as well as by asynchronous change 151 notifications. 153 Furthermore, any Internet host can be a sender of content and thus an 154 IMG sender. Some of the content sources and sinks may only be 155 connected to the Internet sporadically. Also, a single human user may 156 use many different devices to access metadata. Thus, we envision that 157 IMG metadata can be sent and received by, among others, by cellular 158 phones, PDA (Personal Digital Assistant), personal computer, 159 streaming video server, set-top box, video camera, and DVR (Digital 160 Video Recorder) and that they be carried across arbitrary types of 161 link layers, including bandwidth-constrained mobile networks. 162 However, generally we expect IMG Senders to be well-connected hosts. 164 Finally, with many potential senders and receivers, different types 165 of networks, and presumably numerous service providers, IMG metadata 166 may need to be combined, split, filtered, augmented, modified, etc., 167 on their way from the sender(s) to the receiver(s) to provide the 168 ultimate user with a suitable selection of multimedia services 169 according to her preferences, subscriptions, location, context (e.g. 170 devices, access networks), etc. 172 1.2 Scope of This Document 174 This document defines requirements that Internet Media Guide 175 mechanisms must satisfy in order to deliver IMG metadata to a 176 potentially large audience. Since IMGs can describe many kinds of 177 multimedia content, IMG methods are generally applicable to several 178 scenarios. 180 In considering wide applicability, this document provides the problem 181 statement and existing mechanisms in this area. Then several use case 182 scenarios for IMGs are explained including descriptions of how IMG 183 metadata and IMG delivery mechanisms contribute to these scenarios. 184 Following this, this document provides general requirements that are 185 independent of any transport layer mechanism and application, such as 186 delivery properties, reliability and IMG descriptions. 188 This document reflects investigating work on delivery mechanisms for 189 IMGs and generalizing work on session announcement and initiation 190 protocols, especially in the field of the MMUSIC working group (SAP, 191 SIP [7], SDP). 193 2 Terminology 195 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 196 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 197 document are to be interpreted as described in RFC 2119 [1]. 199 Internet Media Guide (IMG): IMG is a generic term to describe 200 the formation, delivery and use of IMG metadata. The 201 definition of the IMG is intentionally left imprecise. 203 IMG Element: The smallest atomic element of metadata that can be 204 transmitted separately by IMG operations and referenced 205 individually from other IMG elements. 207 IMG Metadata: A set of metadata consisting of one or more IMG 208 elements. IMG metadata describes the features of multimedia 209 content used to enable selection of and access to media 210 sessions containing content. For example, metadata may 211 consist of the URI, title, airtime, bandwidth needed, file 212 size, text summary, genre and access restrictions. 214 IMG Delivery: The process of exchanging IMG metadata both in 215 terms of large scale and atomic data transfers. 217 IMG Sender: An IMG sender is a logical entity that sends IMG 218 metadata to one or more IMG receivers. 220 IMG Receiver: An IMG receiver is a logical entity that receives 221 IMG metadata from an IMG sender. 223 IMG Transceiver: An IMG transceiver combines an IMG receiver and 224 sender. It may modify received IMG metadata or merge IMG 225 metadata received from a several different IMG senders. 227 IMG Operation: An atomic operation of an IMG transport protocol, 228 used between IMG sender(s) and IMG receiver(s) for the 229 delivery of IMG metadata and for the control of IMG 230 sender(s)/receiver(s). 232 IMG Transport Protocol: A protocol that transports IMG metadata 233 from an IMG sender to IMG receiver(s). 235 IMG Transport Session: An association between an IMG sender and 236 one or more IMG receivers within the scope of an IMG 237 transport protocol. An IMG transport session involves a 238 time bound series of IMG transport protocol interactions 239 that provide delivery of IMG metadata from the IMG sender 240 to the IMG receiver(s). 242 3 Problem Statement 244 As we enumerate the requirements for IMGs, it will become clear that 245 they are not fully addressed by the existing protocols. The Framework 246 for the Usage of Internet Media Guides [8] talks about these issues 247 in more detail. 249 The MMUSIC working group has long been investigating content, media 250 and service information delivery mechanisms and protocols, and has 251 itself produces Session Announcement Protocol (SAP), Session 252 Description Protocol (SDP), and the Session Initiation Protocol 253 (SIP). SDP is capable of describing multimedia sessions (i.e. 254 content in a wider sense) by means of limited descriptive information 255 intended for human perception plus transport, scheduling information, 256 and codecs and addresses for setting up media sessions. SIP and SAP 257 are protocols to distribute these session descriptions. 259 However, we perceive a lack of a standard solution for scalable IMG 260 delivery mechanism in the number of receivers with consistency of IMG 261 metadata between an IMG sender and IMG receiver for both 262 bi-directional and unidirectional transport. With increased service 263 dynamics and complexity, there is an increased requirement for 264 updates to these content descriptions. 266 HTTP [9] is a well known information retrieval protocol using 267 bi-directional transport and widely used to deliver web-based 268 content descriptions to many hosts. However, it has well recognized 269 limitations of scalability in the number of HTTP clients since it 270 relies on the polling mechanism to keep information consistent 271 between the server and client. 273 SAP [3] is an announcement protocol that distributes session 274 descriptions via multicast. It does not support prioritization or 275 fine-grained metadata selection and update notifications, as it 276 places restrictions on metadata payload size and always sends the 277 whole metadata. It requires a wide-area multicast infrastructure for 278 it to be deployable beyond a local area network. 280 SIP [7] and SIP-specific event notification [10] can be used to 281 notify subscribers of the update of IMG metadata for bi-directional 282 transport. However, it is necessary for SIP Event to define an event 283 package as a standard protocol for each specific application 284 including IMGs. 286 We also perceive a lack of standard solution for flexible content 287 descriptions to support a multitude of application-specific metadata 288 and associated data models with differing amount of detail and 289 different target audiences. 291 SDP [2] has a text-encoded syntax to specify multimedia sessions for 292 announcements and invitations. It is primarily intended to describe 293 client capability requirements and enable client application 294 selection. Although SDP is extensible, it has limitations such as 295 structured extensibility and capability to reference properties of a 296 multimedia session from the description of another session. 298 These are mostly overcome by the XML-based SDPng, which is intended 299 for both two-way negotiation and also unidirectional delivery. Since 300 SDPng addresses multiparty multimedia conferences, it is necessary to 301 extend the XML schema in order to describe general multimedia 302 content. 304 4 Use Cases Requiring IMGs 306 4.1 Connectivity-based Use Cases 308 4.1.1 IP Datacast to a Wireless Receiver 310 IP Datacast is the delivery of IP-based services over broadcast 311 radio. Internet content delivery is therefore unidirectional in this 312 case. However, there can be significant benefits from being able to 313 provide rich media one-to-many services to such receivers. 315 There are two main classes of receiver in this use case: fixed 316 mains-powered; and mobile battery-powered. Both of these are affected 317 by radio phenomena and so robust, or error-resilient, delivery is 318 important. Carouselled metadata transfer provides a base level of 319 robustness for an IP datacast based announcement system, although the 320 design of carouselled transfer should enable battery-powered 321 receivers to go through periods of sleep to extend their operational 322 time between charges. Insertion of Forward Error Correction (FEC) 323 data into metadata announcements improves error resilience, and 324 reordering (interleaving) data blocks further increases tolerance to 325 burst errors. 327 To enable receivers to more accurately specify the metadata they 328 are interested in, the unidirectional delivery may be distributed 329 between several logical channels. This is so that a receiver needs 330 only access the channels of interest and thus can reduce the amount 331 of time, storage and CPU resources needed for processing the IP 332 data. Also, hierarchical channels enable receivers to subscribe to 333 a, possibly well known, root multicast channel/group and 334 progressively access only those additional channels based on 335 metadata in parent channels. 337 In some cases the receiver may be multi-access, such that it is 338 capable of bi-directional communications. This enables a multitude of 339 options, but most importantly it enables NACK based reliability and 340 the individual retrieval of missed or not-multicasted sets of 341 metadata. 343 Thus, essential IMG features in this case include: robust 344 unidirectional delivery (with optional levels of reliability 345 including "plug-in FEC") which implies easily identifiable 346 segmentation of delivery data to enable FEC, carousel, interleaving 347 and other schemes possible; effective identification of metadata sets 348 (probably uniquely) to enable more efficient use of multicast and 349 unicast retrieval over multiple access systems regardless of the 350 parts of metadata and application specific extensions in use; 351 prioritization of metadata, which can (for instance) be achieved by 352 spreading it between channels and allocating/distributing bandwidth 353 accordingly. 355 Furthermore, some cases require IMG metadata authentication and some 356 group security/encryption and supporting security message exchanges 357 (out of band from the IMG multicast sessions). 359 4.1.2 Regular Fixed Dial-up Internet Connection 361 Dial-up connections tend to be reasonably slow (<56kbps in any case) 362 and thus large data transfers are less feasible, especially during an 363 active application session (such as a file transfer described by IMG 364 metadata). They can also be intermittent, especially if a user is 365 paying for the connected time, or connected through a less reliable 366 exchange. Thus this favors locally stored IMG metadata over web-based 367 browsing, especially where parts of the metadata change infrequently. 368 There may be no service provider preference over unicast and 369 multicast transport for small and medium numbers of users as the 370 last-mile dial-up connection limits per-user congestion, and a user 371 may prefer the more reliable option (unicast unless reliable 372 multicast is provided). 374 4.1.3 Broadband Always-on Fixed Internet Connection 376 Typically bandwidth is less of an issue to a broadband user and 377 unicast transport, such as using query-response methods, may be 378 typical for a PC user. If a system were only used in this context, 379 with content providers, ISPs and users having no other requirements, 380 then web- based browsing may be equally suitable. However, broadband 381 users sharing a local area network, especially wireless, may benefit 382 more from local storage features than on-line browsing, especially if 383 they have intermittent Internet access. 385 Broadband enables rich media services, which are increasingly 386 bandwidth hungry. Thus backbone operators may prefer multicast 387 communications to reduce overall congestion, if they have the 388 equipment and configuration to support this. Thus, broadband users 389 may be forced to retrieve IMG metadata over multicast if the 390 respective operators require this to keep system-wide bandwidth usage 391 feasible. 393 4.2 Content-orientated Use Cases 395 IMGs will be able to support a very wide range of use cases for 396 enabling content/media delivery. The following few sections just 397 touch the surface of what is possible and are intended to provide an 398 understanding of the scope and type of IMG usage. Many more examples 399 may be relevant, for instance those detailed in [11]. There are 400 several unique features of IMGs that set them apart from related 401 application areas such as SLP based service location discovery, LDAP 402 based indexing services and search engines such as Google. Features 403 unique to IMGs include: 405 o IMG metadata is generally time-related 407 o There are timeliness requirements in the delivery of IMG 408 metadata 410 o IMG metadata may be updated as time elapses or when an event 411 arises 413 4.2.1 TV and Radio Program Delivery 415 A sender of audio/video streaming content can use the IMG metadata to 416 describe the scheduling and other properties of audio/video sessions 417 and events within those sessions, such as individual TV and radio 418 programs and segments within those programs. IMG metadata describing 419 audio/video streaming content could be represented in a format 420 similar to that of a TV guide in newspapers, or an Electronic Program 421 Guide available on digital TV receivers. 423 TV and radio programs can be selected for reception either manually 424 by the end-user or automatically based on the content descriptions 425 and the preferences of the user. The received TV and radio content 426 can be either presented in real time or recorded for later 427 consumption. There may be changes in the scheduling of a TV or a 428 radio program, possibly affecting the transmission times of 429 subsequent programs. IMG metadata can be used to notify receivers of 430 such changes, enabling users to be prompted or recording times to be 431 adjusted. 433 4.2.2 Media Coverage of a Live Event 434 The media coverage of a live event such as a rock concert or a sports 435 event is a special case of regular TV/radio programming. There may be 436 unexpected changes in the scheduling of live event, or the event may 437 be unscheduled to start with (such as breaking news). In addition to 438 audio/video streams, textual information relevant to the event (e.g. 439 statistics of the players during a football match) may be sent to 440 user terminals. Different transport modes or even different access 441 technologies can be used for the different media: for example, a 442 unidirectional datacast transport could be used for the audio/video 443 streams and an interactive cellular connection for the textual data. 444 IMG metadata should enable terminals to discover the availability of 445 different media used to cover a live event. 447 4.2.3 Distance Learning 449 IMG metadata could describe compound sessions or services enabling 450 several alternative interaction modes between the participants. For 451 example, the combination of one-to-many media streaming, unicast 452 messaging and download of presentation material could be useful for 453 distance learning. 455 4.2.4 Multiplayer Gaming 457 Multiplayer games are an example of real time multiparty 458 communication sessions that could be advertised using IMGs. A gaming 459 session could be advertised either by a dedicated server, or by the 460 terminals of individual users. A user could use IMGs to learn of 461 active multiplayer gaming sessions, or advertise the users interest 462 in establishing such a session. 464 4.2.5 File Distribution 466 IMGs support the communication of file delivery session properties, 467 enabling the scheduled delivery or synchronization of files between a 468 number of hosts. The received IMG metadata could be subsequently used 469 by any application (also outside the scope of IMGs), for example to 470 download a file with a software update. IMG metadata can provide a 471 description to each file in a file delivery session, assisting users 472 or receiving software in selecting individual files for reception. 474 For example, when a content provider wants to distribute a large 475 amount of data in file format to thousands clients, the content 476 provider can use IMG metadata to schedule the delivery effectively. 477 Since IMG metadata can describe time-related data for each receiver, 478 the content provider can schedule delivery time for each receiver. 479 This can save network bandwidth and delivery capacity of senders. In 480 addition, IMG metadata can be used to consistency check, and thus 481 synchronize, a set of files between a sender host and receiver host, 482 when those files change as time elapses. 484 4.2.6 Coming-release and Pre-released Content 486 IMG metadata can be used to describe items of content before the 487 details of their final release are known. A user may be interested 488 in coming content (a new movie or software title where some aspects 489 of the content description are known in advance) and so subscribe 490 to an information service which notifies the user of changes to 491 metadata describing that content. Thus, as the coming release, or 492 pre-releases, (such as movie trailers or software demos) become 493 available the IMG metadata changes and the user is notified of this 494 change. For example, the user could see an announcement of a movie 495 that will be released sometime in the next few months, and 496 configure the user's terminal to receive and record any trailers or 497 promotional material as they become available. 499 5 Requirements 501 5.1 General Requirements 503 5.1.1 Independence of IMG Operations from IMG Metadata 505 REQ GEN-1: Carrying different kinds of IMG metadata format in the IMG 506 message body MUST be allowed. 508 REQ GEN-2: Delivery mechanisms SHOULD support many different 509 applications' specific metadata formats to keep the system 510 interoperable with existing applications. 512 This provides flexibility in selecting/designing IMG transport 513 protocol suited to various scenarios. 515 5.1.2 Multiple IMG Senders 517 REQ GEN-3: IMG receivers MUST be allowed to communicate with any 518 number of IMG senders simultaneously. 520 This might lead to receiving redundant IMG metadata describing the 521 same items, however it enables the IMG receiver access to more IMG 522 metadata than may be available from a single IMG sender. This also 523 provides flexibility for the IMG transport protocols and does not 524 preclude a mechanism to solve inconsistency among IMG metadata due to 525 multiple IMG senders. This document assumes a typical IMG environment 526 will involve many more IMG receivers than IMG senders and that IMG 527 senders are continually connected for the duration of interest 528 (rather than intermittently connected). 530 5.1.3 Modularity 532 REQ GEN-4: The IMG delivery mechanisms MUST allow the combination of 533 several IMG Operations. 535 This is for the purpose of extending functionality (e.g. several or 536 one protocol(s) to provide all the needed operations). Applications 537 can select an appropriate operation set to fulfill their purpose. 539 5.2 Delivery Properties 541 This section describes general performance requirements based on the 542 assumption that the range of IMG usage shall be important. However, 543 it may be noted that requirements of delivery properties may vary 544 based on the usage scenario, and thus some limited use 545 implementations place less importance on some requirements. 547 For example, it is clear that a multicast transport may provide more 548 scalable delivery than a unicast transport, however scalability 549 requirements do not preclude the unicast transport mechanisms. In 550 this sense, scalability is always important for the protocols 551 irrespective of transport mechanisms. 553 5.2.1 Scalability 555 REQ DEL-1: The IMG system MUST be scalable to large numbers of 556 messages, so as to allow design and use of delivery mechanisms that 557 will not fail in delivering up-to-date information under huge numbers 558 of transactions and massive quantities of IMG metadata. 560 REQ DEL-2: IMGs SHOULD provide a method to prevent an IMG sender from 561 sending unnecessary IMG metadata that have been stored or deleted in 562 IMG receivers. 564 REQ DEL-3: The protocol MUST be scalable to very large audience sizes 565 requiring IMG delivery. 567 5.2.2 Support for Intermittent Connectivity 569 REQ DEL-4: The system MUST enable IMG receivers with intermittent 570 access to network resources (connectivity) to receive and adequately 571 maintain sufficient IMG metadata. 573 This allows intermittent access to save power where there is no need 574 to keep communications links powered-up while they are sitting idle. 575 For instance, in this situation periodic bursts of notifies, or a 576 fast cycling update carousel, allows hosts to wake up for short 577 periods of time and still be kept up-to-date. This can be beneficial 578 for IMG receivers with sporadic connections to the fixed Internet, 579 but is critical in the battery-powered wireless Internet. 581 The implication of intermittent connectivity is that immediate 582 distribution of changes becomes infeasible and so managing data 583 consistency should be focused on the timely delivery of data. 585 5.2.3 Congestion Control 587 REQ DEL-5: Internet-friendly congestion control MUST be provided for 588 use on the public Internet. 590 REQ DEL-6: An IMG entity SHOULD invalidate the IMG metadata item when 591 an IMG metadata item has lifetime information and its lifetime is 592 over. This will lessen the need for notifications of updates from the 593 IMG sender to the IMG receiver to invalidate the item and may enable 594 lesser congestion. 596 5.2.4 Sender and Receiver Driven Delivery 598 REQ DEL-7: The system MUST be flexible in choosing sender-driven, 599 receiver-driven or both delivery schemes. 601 Sender-driven delivery achieves high scalability without interaction 602 between the IMG sender and receiver. This avoids keeping track of a 603 delivery state for every IMG receiver. 605 In contrast, the receiver-driven delivery provides on-demand delivery 606 for IMG receivers. Since an IMG sender's complete IMG metadata may be 607 a very large amount of data, the IMG receiver needs to be able to 608 access the guide when convenient (e.g. when sufficient network 609 bandwidth is available to the IMG receiver). 611 5.3 Customized IMGs 613 REQ CUS-1: The system MUST allow delivery of customized IMG metadata. 615 The IMG receiver may require a subset of all the IMG metadata 616 available according to their preferences (type of content, media 617 description, appropriate age group, etc.) and configuration. 619 The IMG receiver might send its preferences in the IMG operations 620 which can specify user specific IMG metadata to be delivered. These 621 preferences could consist of filtering rules. When receiving these 622 messages, the IMG sender might respond appropriate messages carrying 623 a subset of IMG metadata which matches the IMG receiver's 624 preferences. 626 This mechanism can reduce the amount of IMG metadata delivered from 627 the IMG sender to IMG receiver, and consequently it can save the 628 resource consumption on the IMG entities and networks. It is 629 typically useful in unicast cases and also beneficial in multicast 630 cases where an IMG sender distributes the same IMG metadata to 631 interested IMG receivers at the same time. 633 For multicast and unicast cases where the IMG sender does not provide 634 customized IMG metadata, the IMG receiver could receive all IMG 635 metadata transmitted (on its joined channels). However, it may select 636 and filter the IMG metadata to get customized IMG metadata by its 637 preferences, and thus drop unwanted metadata immediately upon 638 reception. 640 Customized metadata might be achieved by changing the IMG 641 descriptions sent and IMG receivers and/or changing the delivery 642 properties (channels used). 644 Note, customization and scalability are only somewhat exclusive. 645 Systems providing an IMG receiver to an IMG sender request-based 646 customization, will be generally less scalable to massive IMG 647 receiver populations than those without this return signaling 648 technique. Thus, customization, as with any feature which affects 649 scalability, should be carefully designed for the intended 650 application, and it may not be possible that a one-size-fits-all 651 solution for customization would meet the scalability requirements 652 for all applications and deployment cases. 654 5.4 Reliability 656 5.4.1 Managing Consistency 658 IMG metadata tends to change as time elapses, as new content is 659 added, the old IMG metadata stored in the IMG receiver becomes 660 unavailable and the parameters of the existing IMG metadata are 661 changed. 663 REQ REL-1: The system MUST manage IMG metadata consistency. 665 The IMG sender can either simply make updates available 666 (unsynchronized) or IMG sender and receiver can interact to keep 667 their copies of the IMG metadata synchronized. 669 In the unsynchronized model, the IMG sender does not know whether a 670 particular IMG receiver has an up-to-date copy of the IMG metadata. 672 In the synchronized model, updating a cached copy of the IMG metadata 673 is necessary to control consistency when the IMG sender or receiver 674 could not communicate for a while. In this case, the IMG sender or 675 receiver may need to confirm its consistency by IMG operations. 677 REQ REL-2: Since IMG metadata can change at any time, IMG receivers 678 SHOULD be notified of such changes. 680 Depending on the size of the guide, the interested party may want to 681 defer retrieving the actual information. The change notification 682 should be addressed to a logical user (or user group), rather than a 683 host, since users may change devices. 685 Note that depending on the deployment environment and application 686 specifics, the level of acceptable inconsistency varies. Thus, this 687 document does not define inconsistency as specific time and state 688 differences between IMG metadata stored in an IMG sender and IMG 689 metadata stored in an IMG receiver. 691 In general, the consistency of metadata for a content and media is 692 more important immediately prior to and during the media's 693 session(s). Hosts which forward (or otherwise resend) metadata may be 694 less tolerant to inconsistencies as delivering out of date data is 695 both misleading and bandwidth inefficient. 697 5.4.2 Reliable Message Exchange 699 REQ REL-4: An IMG transport protocol MUST support reliable message 700 exchange. 702 The extent to which this could result in 100% error free delivery to 703 100% of IMG receivers is a statistical characteristic of the 704 protocols used. Usage of reliable IMG delivery mechanisms is expected 705 to depend on the extent to which underlying networks provide 706 reliability and, conversely, introduce errors. Note, some deployments 707 of IMG transport protocols may not aim to provide perfect reception 708 to all IMG receivers in all possible cases. 710 5.5 IMG Descriptions 712 REQ DES-1: IMG metadata MUST be interoperable over any IMG transport 713 protocol, such that an application receiving the same metadata over 714 any one (or more) of several network connections and/or IMG transport 715 protocols will interpret the metadata in exactly the same way. (This 716 also relates to the 'Independence of IMG Operations from IMG 717 Metadata' requirements.) 719 REQ DES-2: IMG delivery MUST enable the carriage of any format of 720 application-specific metadata. 722 Thus, the system will support the description of many kinds of 723 multimedia content, without the need for a single homogenous metadata 724 syntax for all uses (which would be infeasible anyway). This is 725 essential for environments using IMG systems to support many kinds of 726 multimedia content and to achieve wide applicability. 728 REQ DES-3: Whereas specific applications relying on IMGs will need to 729 select one or more specific application-specific metadata formats 730 (standard, syntax, etc.), the IMG system MUST be independent of this 731 (it may be aware, but it will operate in the same way for all). 733 Thus, a metadata transfer envelope format, that is uniform across all 734 different application-specific IMG metadata formats, is needed. The 735 envelope would reference (point to) or carry (as payload) some 736 application-specific metadata, and the envelope would support the 737 maintenance of the application-specific metadata, which may also 738 serve the metadata relationships determined by the data model(s) 739 used. The envelope would not need to be aware of the data model(s) in 740 use. 742 REQ DES-4: IMG metadata MUST be structured to enable fragmentation 743 for efficient delivery. 745 This is intended to ensure that and IMG sender with more than a 746 trivial knowledge of metadata is able to deliver only part of its 747 (and the global) complete IMG metadata knowledge. (For instance, a 748 trivial quantity of knowledge could be a single SDP description.) In 749 general, the resolution of this fragmentation will be very much 750 dependent on the optimal delivery of a deployment, although some 751 metadata syntaxes will inherently effect the sensible lower limit for 752 a single element/fragment. 754 REQ DES-5: A metadata transfer envelope MUST be defined to include 755 essential parameters. 757 Examples of essential parameters are those that allow the metadata in 758 question to be uniquely identified and updated by new versions of the 759 same metadata. 761 REQ DES-6: It SHALL be possible to deduce the metadata format via the 762 metadata transfer envelope. 764 REQ DES-7: IMG senders SHALL use a metadata transfer envelope for 765 each IMG metadata transfer. 767 Thus, it will even be possible to describe relationships between 768 syntactically dissimilar application-specific formats within the same 769 body of IMG metadata knowledge. (E.g. a data model could be 770 instantiated using both SDP and SDPng.) 772 REQ DES-8: IMG metadata SHOULD support the description of differences 773 between update version and old version of IMG metadata when IMG 774 delivery mechanism carries updated IMG metadata and those differences 775 are considerably little. (E.g. by providing a 'delta' of the two 776 versions. This also relates the delivery property requirements for 777 congestion control in Section 5.2.3). 779 6 Security Considerations 781 Internet Media Guides are used to convey information about multimedia 782 resources from one or more IMG senders across one or intermediaries 783 to one or more IMG receivers. IMG metadata may be pushed to the IMG 784 receivers or interactively retrieved by them. IMGs provide metadata 785 as well as scheduling and rendezvous information about multimedia 786 resources, etc. and requests for IMG metadata may contain information 787 about the requesting users. 789 The information contained in IMG metadata as well as the operations 790 related to IMGs should be secured to avoid forged information, 791 misdirected users, spoofed IMG senders, etc. and to protect user 792 privacy. 794 The remainder of section addresses the security requirements for 795 IMGs. 797 6.1 IMG Authentication and Integrity 799 IMG metadata and its parts need to be protected against unauthorized 800 altering/adding/deletion on the way. Their originator needs to be 801 authenticated. 803 REQ AUT-1: It MUST be possible to authenticate the originator of a 804 set of IMG metadata. 806 REQ AUT-2: It MUST be possible to authenticate the originator of a 807 subpart of IMG metadata (e.g. a delta or a subset of the 808 information). 810 REQ AUT-3: It MUST be possible to validate the integrity of IMG 811 metadata. 813 REQ AUT-4: It MUST be possible to validate the integrity of a subpart 814 of IMG metadata (e.g. a delta or a subset of the information). 816 REQ AUT-5: It MUST be possible to separate or combine individually 817 authenticated pieces of IMG metadata (e.g. in an IMG transceiver) 818 without invalidating the authentication. 820 REQ AUT-6: It MUST be possible to validate the integrity of an 821 individually authenticated piece of IMG metadata even after this 822 piece had been separated from other pieces of IMG metadata and 823 combined with other pieces to form new IMG metadata. 825 REQ AUT-7: It MUST be possible to authenticate the originator of an 826 IMG operation. 828 REQ AUT-8: It MUST be possible to validate the integrity of any 829 contents of an IMG operation (e.g. the subscription or inquiry 830 information). 832 6.2 Privacy 834 Customized IMG metadata and IMG metadata delivered by notification to 835 individual users may reveal information about the habits and 836 preferences of a user and may thus deserve confidentiality 837 protection, even though the information itself is public. 839 REQ PRI-1: It MUST be possible to keep user requests to subscribe to 840 or retrieve certain (parts of) IMG metadata confidential. 842 REQ PRI-2: It MUST be possible to keep IMG metadata, pieces of IMG 843 metadata, or pointers to IMG metadata delivered to individual users 844 or groups of users confidential. 846 REQ PRI-3: It SHOULD be possible to ensure this confidentiality 847 end-to-end, that is, to prevent intermediaries (such as IMG 848 transceivers) from accessing the contained information. 850 6.3 Access Control for IMGs 852 Some IMG metadata may be freely available, while access to other IMG 853 metadata may be restricted to closed user groups (e.g. paying 854 subscribers). Also, different parts of IMG metadata may be protected 855 at different levels: e.g. metadata describing a media session may be 856 freely accessible while rendezvous information to actually access the 857 media session may require authorization. 859 REQ ACC-1: It MUST be possible to authorize user access to IMG 860 metadata. 862 REQ ACC-2: It MUST be possible to authorize access of users to pieces 863 of IMG metadata (delta information, subparts, pointers). 865 REQ ACC-3: It MUST be possible to require different authorization for 866 different parts of the same IMG metadata. 868 REQ ACC-4: It MUST be possible to access selected IMG metadata 869 anonymously. 871 REQ ACC-5: It MUST be possible for an IMG receiver to choose not to 872 receive (parts of) IMG metadata in order to avoid being identified by 873 the IMG sender. 875 REQ ACC-6: It SHOULD be possible for IMG transceiver to impose 876 different authorization requirements. 878 REQ ACC-7: It MAY be possible for IMG senders to require certain 879 authorization that cannot be overridden by intermediaries. 881 6.4 Denial-of-Service attacks 883 Retrieving or distributing IMG metadata may require state in the IMG 884 senders, transceivers, and/or receivers for the respective IMG 885 transport sessions. Attackers may create large numbers of sessions 886 with any of the above IMG entities to disrupt regular operation. 888 REQ DOS-1: IMG operations SHOULD be authenticated. 890 REQ DOS-2: It SHOULD be possible to prevent DoS attacks that build up 891 session state in IMG entities to exhaust their resources. 893 REQ DOS-3: It SHOULD be possible to avoid DoS attacks that exhaust 894 resources of IMG entities by flooding them with IMG metadata. 896 As an example, two potential solutions which may be considered are 897 running an IMG entity in stateless mode or identification and 898 discarding of malicious packets by an IMG entity. 900 6.5 Replay Attacks 902 IMG metadata disseminated by an IMG sender or an IMG transceiver may 903 be updated, deleted, or lose validity over time for some other 904 reasons. Replaying outdated IMG metadata needs to be prevented. 906 Furthermore, replay attacks may also apply to IMG operations (rather 907 than just their payload). Replaying operations also needs to be 908 prevented. 910 REQ REP-1: IMG metadata MUST be protected against partial or full 911 replacement of newer ("current") versions by older ones. 913 In a system with multiple senders it may not be feasible to prevent 914 some senders delivering older versions of metadata than others - as a 915 result of imperfect sender-sender data consistency. Thus, replay 916 attacks and delivery of inconsistent data requires that an IMG 917 receiver veryfies that the IMG metadata is valid and reliable by 918 using some security mechanism(s) (e.g. authorization, authentication 919 or integrity). 921 REQ REP-2: Mechanisms MUST be provided to mitigate replay attacks on 922 the IMG operations. 924 The level of threat from replay attacks varies very much depending on 925 system scale and how well defined or open it is. Thus mitigating 926 relay attacks may lead to different solutions for different systems, 927 independent of the basic delivery method and metadata definitions. A 928 system with multiple senders presents a more challenging scenario for 929 handling replay attacks. As an example, bundling metadata with a 930 security mechanism is one potential solution. 932 7 IANA Considerations 934 There are no IANA considerations within this document. 936 8 Normative References 938 [1] S. Bradner, "Key words for use in RFCs to indicate requirement 939 levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. 941 9 Informative References 943 [2] M. Handley and V. Jacobson, "SDP: session description protocol," 944 RFC 2327, Internet Engineering Task Force, Apr. 1998. 946 [3] M. Handley, C. E. Perkins, and E. Whelan, "Session announcement 947 protocol," RFC 2974, Internet Engineering Task Force, Oct. 2000. 949 [4] Session Directory, ftp://ftp.ee.lbl.gov/conferencing/sd/ 951 [5] Session Directory Tool, 952 http://www-mice.cs.ucl.ac.uk/multimedia/software/sdr/ 954 [6] D. Kutscher, J. Ott, and C. Bormann, "Session description and 955 capability negotiation," Internet Draft draft-ietf-mmusic-sdpng-07, 956 Internet Engineering Task Force, Oct. 2003. Work in progress. 958 [7] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J. 959 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session 960 initiation protocol," RFC 3261, Internet Engineering Task Force, June 961 2002. 963 [8] Y. Nomura, R. Walsh, J-P. Luoma, H. Asaeda, and H. Schulzrinne, 964 "A framework for the usage of Internet media guides," Internet Draft 965 draft-ietf-mmusic-img-framework-07, Internet Engineering Task Force, 966 June 2004. Work in progress. 968 [9] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, L. Masinter, P. 969 Leach and T. Berners-Lee, "Hypertext transfer protocol -- HTTP/1.1," 970 RFC 2616, Internet Engineering Task Force, June 1999. 972 [10] A. B. Roach, "Session initiation protocol (sip)-specific event 973 notification," RFC 3265, Internet Engineering Task Force, June 2002. 975 [11] B. Quinn and K. Almeroth, "IP multicast applications: Challenges 976 and solutions," RFC 3170, Internet Engineering Task Force, Sept. 977 2001. 979 10 Acknowledgements 981 The authors would like to thank Colin Perkins, Jean-Pierre Evain, 982 Gonzalo Camarillo, Magnus Westerlund, Hitoshi Asaeda, Petri 983 Koskelainen, Toni Paila and Dirk Kutscher for their excellent 984 comments and ideas on this work. 986 11 Authors' Addresses 988 Yuji Nomura 989 Fujitsu Laboratories Ltd. 990 4-1-1 Kamikodanaka, Nakahara-ku, Kawasaki 211-8588 991 Japan 992 Email: nom@flab.fujitsu.co.jp 994 Rod Walsh 995 Nokia Research Center 996 P.O. Box 100, FIN-33721 Tampere 997 Finland 998 Email: rod.walsh@nokia.com 1000 Juha-Pekka Luoma 1001 Nokia Research Center 1002 P.O. Box 100, FIN-33721 Tampere 1003 Finland 1004 Email: juha-pekka.luoma@nokia.com 1006 Joerg Ott 1007 Universitaet Bremen 1008 MZH 5180 1009 Bibliothekstr. 1 1010 D-28359 Bremen 1011 Germany 1012 Email: jo@tzi.uni-bremen.de 1014 Henning Schulzrinne 1015 Dept. of Computer Science 1016 Columbia University 1017 1214 Amsterdam Avenue 1018 New York, NY 10027 1019 USA 1020 Email: schulzrinne@cs.columbia.edu 1022 12 Full Copyright Statement 1024 Copyright (C) The Internet Society (2004). This document is subject 1025 to the rights, licenses and restrictions contained in BCP 78 and 1026 except as set forth therein, the authors retain all their rights. 1028 This document and the information contained herein are provided on an 1029 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1030 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1031 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1032 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1033 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1034 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1036 Intellectual Property 1038 The IETF takes no position regarding the validity or scope of any 1039 Intellectual Property Rights or other rights that might be claimed to 1040 pertain to the implementation or use of the technology described in 1041 this document or the extent to which any license under such rights 1042 might or might not be available; nor does it represent that it has 1043 made any independent effort to identify any such rights. Information 1044 on the procedures with respect to rights in RFC documents can be 1045 found in BCP 78 and BCP 79. 1047 Copies of IPR disclosures made to the IETF Secretariat and any 1048 assurances of licenses to be made available, or the result of an 1049 attempt made to obtain a general license or permission for the use of 1050 such proprietary rights by implementers or users of this 1051 specification can be obtained from the IETF on-line IPR repository at 1052 http://www.ietf.org/ipr. 1054 The IETF invites any interested party to bring to its attention any 1055 copyrights, patents or patent applications, or other proprietary 1056 rights that may cover technology that may be required to implement 1057 this standard. Please address the information to the IETF at ietf- 1058 ipr@ietf.org.