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