idnits 2.17.1 draft-ietf-mmusic-img-req-05.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 1019. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1030. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1037. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1043. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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 the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 22 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. 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 (May 24, 2004) is 7269 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 normative reference: RFC 2327 (ref. '1') (Obsoleted by RFC 4566) ** Downref: Normative reference to an Experimental RFC: RFC 2974 (ref. '2') -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' == 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-05 ** Downref: Normative reference to an Informational draft: draft-ietf-mmusic-img-framework (ref. '8') ** Obsolete normative reference: RFC 2068 (ref. '9') (Obsoleted by RFC 2616) ** Obsolete normative reference: RFC 3265 (ref. '10') (Obsoleted by RFC 6665) ** Downref: Normative reference to an Informational RFC: RFC 3170 (ref. '11') Summary: 14 errors (**), 0 flaws (~~), 5 warnings (==), 8 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-05.txt 13 May 24, 2004 14 Expires: November 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 .... 11 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 ............................. 17 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 ................................. 20 87 8 References .......................................... 20 88 9 Acknowledgements .................................... 21 89 10 Authors' Addresses .................................. 21 90 11 Full Copyright Statement ............................ 22 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 [1] 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) [2] and tools such as SD [3] or SDR [4]; 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 [5] or 122 some similar session description format. This is used to describe a 123 set of multimedia sessions (e.g. television program schedules, 124 content delivery schedules etc.) but may also refer to other 125 networked resources including web pages. IMGs provide the envelope 126 for metadata formats and session descriptions defined elsewhere with 127 the aim of facilitating structuring, versioning, referencing, 128 distributing, and 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 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 [6], 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 [7]. 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 [8] 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 [9] 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 [2] 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 [6] and SIP-specific event notification [10] can be used to 275 notify 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 [1] 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, which is intended 292 for both two-way negotiation and also unidirectional delivery. Since 293 SDPng addresses multiparty multimedia conferences, it is necessary to 294 extend the XML schema in order to describe general multimedia 295 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 needs only 323 access the channels of interest and thus can reduce the amount of 324 time, storage and CPU resources needed for processing the IP data. 325 Also, 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 IMG system MUST be scalable to large numbers of 548 messages, so as to allow design and use of delivery mechanisms that 549 will not fail in delivering up-to-date information under huge numbers 550 of transactions and massive quantities of IMG metadata. 552 REQ DEL-2: IMGs SHOULD provide a method to prevent an IMG sender from 553 sending unnecessary IMG metadata that have been stored or deleted in 554 IMG receivers. 556 REQ DEL-3: The protocol MUST be scalable to very large audience sizes 557 requiring IMG delivery. 559 5.2.2 Support for Intermittent Connectivity 561 REQ DEL-4: The system SHOULD enable IMG receivers with intermittent 562 access to network resources (connectivity) to receive and adequately 563 maintain sufficient IMG metadata. 565 This allows intermittent access to save power where there is no need 566 to keep communications links powered-up while they are sitting idle. 567 For instance, in this situation periodic bursts of notifies, or a 568 fast cycling update carousel, allows hosts to wake up for short 569 periods of time and still be kept up-to-date. This can be beneficial 570 for IMG receivers with sporadic connects to the fixed Internet, but 571 is critical in the battery-powered wireless Internet. 573 The implication of intermittent connectivity is that immediate 574 distribution of changes becomes infeasible and so managing data 575 consistency should be focused on the timely delivery of data. 577 5.2.3 Congestion Control 579 REQ DEL-5: Internet-friendly congestion control MUST be provided for 580 use on the public Internet. 582 REQ DEL-6: An IMG entity SHOULD invalidate the IMG metadata item when 583 an IMG metadata item has lifetime information and its lifetime is 584 over. This will lessen the need for notifications of updates from the 585 IMG sender to the IMG receiver to invalidate the item and may enable 586 lesser congestion. 588 5.2.4 Sender and Receiver Driven Delivery 590 REQ DEL-7: The system MUST be flexible in choosing sender-driven, 591 receiver-driven or both delivery schemes. 593 Sender-driven delivery achieves high scalability without interaction 594 between the IMG sender and receiver. This avoids keeping track of a 595 delivery state of every IMG receiver. 597 In contrast, the receiver-driven delivery provides on-demand delivery 598 for IMG receivers. Since an IMG sender's complete IMG metadata may be 599 a very large amount of data, the IMG receiver needs to be able to 600 access the guide when convenient (e.g. when sufficient network 601 bandwidth is available to the IMG receiver). 603 5.3 Customized IMGs 605 REQ CUS-1: The system MUST allow delivery of customized IMG metadata. 607 The IMG receiver may require a subset of all the IMG metadata 608 available according to their preferences (type of content, media 609 description, appropriate age group, etc.) and configuration. 611 The IMG receiver might send its preferences in the IMG operations 612 which can specify user specific IMG metadata to be delivered. These 613 preferences could consist of filtering rules. When receiving these 614 messages, the IMG sender might respond appropriate messages carrying 615 a subset of IMG metadata which matches the IMG receiver's 616 preferences. 618 This mechanism can reduce the amount of IMG metadata delivered from 619 the IMG sender to IMG receiver, and consequently it can save the 620 resource consumption on the IMG entities and networks. It is 621 typically useful in unicast case and also beneficial in multicast 622 case where IMG sender distributes the same IMG metadata to interested 623 IMG receivers at the same time. 625 For multicast and unicast cases where the IMG sender does not provide 626 customized IMG metadata, the IMG receiver could receive all IMG 627 metadata transmitted (on its joined channels). However, it may select 628 and filter the IMG metadata to get customized IMG metadata by its 629 preferences, and thus drop unwanted metadata immediately upon 630 reception. 632 Customized metadata might be achieved by changing the IMG 633 descriptions sent and IMG receivers and/or changing the delivery 634 properties (channels used). 636 Note, customization and scalability are only somewhat exclusive. 637 Systems providing an IMG receiver to an IMG sender request-based 638 customization, will be generally less scalable to massive IMG 639 receiver populations than those without this return signaling 640 technique. Thus, customization, as with any feature which affects 641 scalability, should be carefully designed for the intended 642 application, and it may not be possible that a one-size-fits-all 643 solution for customization would meet the scalability requirements 644 for all applications and deployment cases. 646 5.4 Reliability 648 5.4.1 Managing Consistency 650 IMG metadata tends to change as time elapses, as new content is 651 added, the old IMG metadata stored in the IMG receiver becomes 652 unavailable and the parameters of the existing IMG metadata are 653 changed. 655 REQ REL-1: The system MUST manage IMG metadata consistency. 657 The IMG sender can either simply make updates available 658 (unsynchronized) or IMG sender and receiver can interact to keep 659 their copies of the IMG metadata synchronized. 661 In the unsynchronized model, the IMG sender does not know whether a 662 particular IMG receiver has an up-to-date copy of the IMG metadata. 664 In the synchronized model, updating cached copy of the IMG metadata 665 is necessary to control consistency when the IMG sender or receiver 666 could not communicate for a while. In this case, the IMG sender or 667 receiver may need to confirm its consistency by IMG operations. 669 REQ REL-2: Since IMG metadata can change at any time, IMG receivers 670 SHOULD be notified of such changes. 672 Depending on the size of the guide, the interested party may want to 673 defer retrieving the actual information. The change notification 674 should be addressed to a logical user (or user group), not a host, 675 since users may change devices. 677 Note that depending on the deployment environment and application 678 specifics, the level of acceptable inconsistency varies. Thus, this 679 document does not define inconsistency as specific time and state 680 differences between IMG metadata stored in an IMG sender and IMG 681 metadata stored in an IMG receiver. 683 In general, the consistency of metadata for a content and media is 684 more important immediately prior to and during the media's 685 session(s). Hosts which forward (or otherwise resend) metadata may be 686 less tolerant to inconsistencies as delivering out of date data is 687 both misleading and bandwidth inefficient. 689 5.4.2 Reliable Message Exchange 691 REQ REL-4: An IMG transport protocol MUST support reliable message 692 exchange. 694 The extent to which this could result in 100% error free delivery to 695 100% of IMG receivers is a statistical characteristic of the 696 protocols used. Usage of reliable IMG delivery mechanisms is expected 697 to depend on the extent to which underlying networks provide 698 reliability and, conversely, introduce errors. Note, some deployments 699 of IMG transport protocols may not aim to provide perfect reception 700 to all IMG receivers in all possible cases. 702 5.5 IMG Descriptions 704 REQ DES-1: IMG metadata MUST be interoperable over any IMG transport 705 protocol, such that an application receiving the same metadata over 706 any one (or more) of several network connections and/or IMG transport 707 protocols will interpret the metadata in exactly the same way. (This 708 also relates to the 'Independence of IMG Operations from IMG 709 Metadata' requirement.) 711 REQ DES-2: IMG delivery MUST enable the carriage of any format of 712 application-specific metadata. 714 Thus, the system will support the description of many kinds of 715 multimedia content, without the need for a single homogenous metadata 716 syntax for all uses (which would be infeasible anyway). This is 717 essential for environments using IMG systems to support many kinds of 718 multimedia content and to achieve wide applicability. 720 REQ DES-3: Whereas specific applications relying on IMGs will need to 721 select one or more specific application-specific metadata formats 722 (standard, syntax, etc.), the IMG system MUST be independent of this 723 (it may be aware, but it will operate in the same way for all). 725 Thus, a transfer envelope format, that is uniform across all 726 different application-specific IMG metadata formats, is needed. The 727 payload of this transfer envelope would be some application-specific 728 metadata, and the envelope would support the maintenance of the 729 application-specific metadata including the metadata relationships 730 determined by the data model(s) used. The transfer envelope would not 731 need to be aware of the data model(s) in use. 733 REQ DES-4: IMG metadata MUST be structured to enable fragmentation 734 for efficient delivery. 736 This is intended to ensure that and IMG sender with more than a 737 trivial knowledge of metadata is able to deliver only part of its 738 (and the global) complete IMG metadata knowledge. (For instance, a 739 trivial quantity of knowledge could be a single SDP description.) In 740 general, the resolution of this fragmentation will be very much 741 dependent on the optimal delivery of a deployment, although some 742 metadata syntaxes will inherently effect the sensible lower limit for 743 a single element/fragment. 745 REQ DES-5: A transfer envelope MUST be defined to include essential 746 parameters. 748 Examples of essential parameters are those that allow the metadata in 749 question to be uniquely identified and updated by new versions of the 750 same metadata. 752 REQ DES-6: It SHALL be possible to deduce the metadata format from 753 the transfer envelope. 755 REQ DES-7: IMG senders SHALL use the transfer envelope for each IMG 756 metadata transfer. 758 Thus, it will even be possible to describe relationships between 759 syntactically dissimilar application-specific formats within the same 760 body of IMG metadata knowledge. 762 REQ DES-8: IMG metadata SHOULD support to describe differences 763 between update version and old version of IMG metadata when IMG 764 delivery mechanism carries updated IMG metadata and those differences 765 are considerably little. (This also relates the delivery property 766 requirements for congestion control in Section 5.2.3). 768 6 Security Considerations 770 Internet Media Guides are used to convey information about multimedia 771 resources from one or more IMG senders across one or intermediaries 772 to one or more IMG receivers. IMG metadata may be pushed to the IMG 773 receivers or interactively retrieved by them. IMGs provide metadata 774 as well as scheduling and rendezvous information about multimedia 775 resources, etc. and requests for IMG metadata may contain information 776 about the requesting users. 778 The information contained in IMG metadata as well as the operations 779 related to IMGs should be secured to avoid forging information, 780 misdirecting users, spoofing IMG senders, etc. and to protect user 781 privacy. 783 The remainder of section addresses the security requirements for 784 IMGs. 786 6.1 IMG Authentication and Integrity 788 IMG metadata and its parts need to be protected against unauthorized 789 altering/adding/deletion on the way. Their originator needs to be 790 authenticated. 792 REQ AUT-1: It MUST be possible to authenticate the originator of a 793 set of IMG metadata. 795 REQ AUT-2: It MUST be possible to authenticate the originator of a 796 subpart of IMG metadata (e.g. a delta or a subset of the 797 information). 799 REQ AUT-3: It MUST be possible to validate the integrity of IMG 800 metadata. 802 REQ AUT-4: It MUST be possible to validate the integrity of a subpart 803 of IMG metadata (e.g. a delta or a subset of the information). 805 REQ AUT-5: It MUST be possible to separate or combine individually 806 authenticated pieces of IMG metadata (e.g. in an IMG transceiver) 807 without invalidating the authentication. 809 REQ AUT-6: It MUST be possible to validate the integrity of an 810 individually authenticated piece of IMG metadata even after this 811 piece had been separated from other pieces of IMG metadata and 812 combined with other pieces to form new IMG metadata. 814 REQ AUT-7: It MUST be possible to authenticate the originator of an 815 IMG operation. 817 REQ AUT-8: It MUST be possible to validate the integrity of any 818 contents of an IMG operation (e.g. the subscription or inquiry 819 information). 821 6.2 Privacy 823 Customized IMG metadata and IMG metadata delivered by notification to 824 individual users may reveal information about the habits and 825 preferences of a user and may thus deserve confidentiality 826 protection, even though the information itself is public. 828 REQ PRI-1: It MUST be possible to keep user requests to subscribe to 829 or retrieve certain (parts of) IMG metadata confidential. 831 REQ PRI-2: It MUST be possible to keep IMG metadata, pieces of IMG 832 metadata, or pointers to IMG metadata delivered to individual users 833 or groups of users confidential. 835 REQ PRI-3: It SHOULD be possible to ensure this confidentiality end- 836 to-end, that is, to prevent intermediaries (such as IMG transceivers) 837 from accessing the contained information. 839 6.3 Access Control for IMGs 841 Some IMG metadata may be freely available, while access to other may 842 be restricted to closed user groups (e.g. paying subscribers). Also, 843 different parts of IMG metadata may be protected at different levels: 844 e.g. metadata describing a media session may be freely accessible 845 while rendezvous information to actually access the media session may 846 require authorization. 848 REQ ACC-1: It MUST be possible to authorize user access to IMG 849 metadata. 851 REQ ACC-2: It MUST be possible to authorize access of users to pieces 852 of IMG metadata (delta information, subparts, pointers). 854 REQ ACC-3: It MUST be possible to require different authorization for 855 different parts of the same IMG metadata. 857 REQ ACC-4: It MUST be possible to access selected IMG metadata 858 anonymously. 860 REQ ACC-5: It MUST be possible for an IMG receiver to choose not to 861 receive (parts of) IMG metadata in order to avoid being identified by 862 the IMG sender. 864 REQ ACC-6: It SHOULD be possible for IMG transceiver to impose 865 different authorization requirements. 867 REQ ACC-7: It MAY be possible for IMG senders to require certain 868 authorization that cannot be overridden by intermediaries. 870 6.4 Denial-of-Service attacks 872 Retrieving or distributing IMG metadata may require state in the IMG 873 senders, transceivers, and/or receivers for the respective IMG 874 transport sessions. Attackers may create large numbers of sessions 875 with any of the above IMG entities to disrupt regular operation. 877 REQ DOS-1: IMG operations SHOULD be authenticated. 879 REQ DOS-2: It SHOULD be possible to prevent DoS attacks that build up 880 session state in IMG entities to exhaust their resources. 882 REQ DOS-3: It SHOULD be possible to avoid DoS attacks that exhaust 883 resources of IMG entities by flooding them with IMG metadata. 885 As an example, two potential solutions which may be considered are 886 running an IMG entity in stateless mode or identification and 887 discarding of malicious packets by an IMG entity. 889 6.5 Replay Attacks 891 IMG metadata disseminated by an IMG sender or an IMG transceiver may 892 be updated, deleted, or lose validity over time for some other 893 reasons. Replaying outdated IMG metadata needs to be prevented. 895 Furthermore, replay attacks may also apply to IMG operations (rather 896 than just their payload). Replaying operations needs also be 897 prevented. 899 REQ REP-1: IMG metadata MUST be protected against partial or full 900 replacement of newer ("current") versions by older ones. 902 In a system with multiple senders it may not be feasible to prevent 903 some senders delivering older versions of metadata than others - as a 904 result of imperfect sender-sender data consistency. It is not a 905 replay attack but data inconsistency as long as an IMG receiver 906 regards IMG metadata reliable by using some security mechanisms (e.g. 907 authorization, authentication or integrity). 909 REQ REP-2: Mechanisms MUST be provided to mitigate replay attacks on 910 the IMG operations. 912 The level of threat from replay attacks varies very much depending on 913 system scale and how well defined or open it is. Thus mitigating 914 relay attacks may lead to different solutions for different systems, 915 independent of the basic delivery method and metadata definitions. A 916 system with multiple senders presents a more challenging scenario for 917 handling replay attacks. As an example, bundling metadata with a 918 security mechanism is one potential solution. 920 7 IANA Considerations 922 There are no IANA considerations within this document. 924 8 References 926 [1] M. Handley and V. Jacobson, "SDP: session description protocol," 927 RFC 2327, Internet Engineering Task Force, Apr. 1998. 929 [2] M. Handley, C. E. Perkins, and E. Whelan, "Session announcement 930 protocol," RFC 2974, Internet Engineering Task Force, Oct. 2000. 932 [3] Session Directory, ftp://ftp.ee.lbl.gov/conferencing/sd/ 934 [4] Session Directory Tool, http://www- 935 mice.cs.ucl.ac.uk/multimedia/software/sdr/ 937 [5] D. Kutscher, J. Ott, and C. Bormann, "Session description and 938 capability negotiation," Internet Draft draft-ietf-mmusic-sdpng-07, 939 Internet Engineering Task Force, Oct. 2003. Work in progress. 941 [6] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J. 942 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session 943 initiation protocol," RFC 3261, Internet Engineering Task Force, June 944 2002. 946 [7] S. Bradner, "Key words for use in RFCs to indicate requirement 947 levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. 949 [8] Y. Nomura, R. Walsh, J-P. Luoma, H. Asaeda, and H. Schulzrinne, 950 "A framework for the usage of Internet media guides," Internet Draft 951 draft-ietf-mmusic-img-framework-05, Internet Engineering Task Force, 952 April 2004. Work in progress. 954 [9] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, and T. Berners- 955 Lee, "Hypertext transfer protocol -- HTTP/1.1," RFC 2068, Internet 956 Engineering Task Force, Jan. 1997. 958 [10] A. B. Roach, "Session initiation protocol (sip)-specific event 959 notification," RFC 3265, Internet Engineering Task Force, June 2002. 961 [11] B. Quinn and K. Almeroth, "IP multicast applications: Challenges 962 and solutions," RFC 3170, Internet Engineering Task Force, Sept. 963 2001. 965 9 Acknowledgements 967 The authors would like to thank Colin Perkins, Jean-Pierre Evain, 968 Hitoshi Asaeda, Petri Koskelainen, Toni Paila and Dirk Kutscher for 969 their comments and ideas on this work. 971 10 Authors' Addresses 973 Yuji Nomura 974 Fujitsu Laboratories Ltd. 975 4-1-1 Kamikodanaka, Nakahara-ku, Kawasaki 211-8588 976 Japan 977 Email: nom@flab.fujitsu.co.jp 979 Rod Walsh 980 Nokia Research Center 981 P.O. Box 100, FIN-33721 Tampere 982 Finland 983 Email: rod.walsh@nokia.com 985 Juha-Pekka Luoma 986 Nokia Research Center 987 P.O. Box 100, FIN-33721 Tampere 988 Finland 989 Email: juha-pekka.luoma@nokia.com 991 Joerg Ott 992 Universitaet Bremen 993 MZH 5180 994 Bibliothekstr. 1 995 D-28359 Bremen 996 Germany 997 Email: jo@tzi.uni-bremen.de 999 Henning Schulzrinne 1000 Dept. of Computer Science 1001 Columbia University 1002 1214 Amsterdam Avenue 1003 New York, NY 10027 1004 USA 1005 Email: schulzrinne@cs.columbia.edu 1007 11 Full Copyright Statement 1009 Copyright (C) The Internet Society (2004). This document is subject 1010 to the rights, licenses and restrictions contained in BCP 78 and 1011 except as set forth therein, the authors retain all their rights. 1013 This document and the information contained herein are provided on an 1014 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1015 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1016 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1017 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1018 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1019 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1021 Intellectual Property 1023 The IETF takes no position regarding the validity or scope of any 1024 Intellectual Property Rights or other rights that might be claimed to 1025 pertain to the implementation or use of the technology described in 1026 this document or the extent to which any license under such rights 1027 might or might not be available; nor does it represent that it has 1028 made any independent effort to identify any such rights. Information 1029 on the procedures with respect to rights in RFC documents can be 1030 found in BCP 78 and BCP 79. 1032 Copies of IPR disclosures made to the IETF Secretariat and any 1033 assurances of licenses to be made available, or the result of an 1034 attempt made to obtain a general license or permission for the use of 1035 such proprietary rights by implementers or users of this 1036 specification can be obtained from the IETF on-line IPR repository at 1037 http://www.ietf.org/ipr. 1039 The IETF invites any interested party to bring to its attention any 1040 copyrights, patents or patent applications, or other proprietary 1041 rights that may cover technology that may be required to implement 1042 this standard. Please address the information to the IETF at ietf- 1043 ipr@ietf.org.