idnits 2.17.1 draft-ietf-mmusic-img-req-04.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 1003. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1013. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1020. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1026. ** 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 (April 13, 2004) is 7312 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 (-09) exists of draft-ietf-mmusic-img-framework-04 ** Downref: Normative reference to an Informational draft: draft-ietf-mmusic-img-framework (ref. '7') ** Obsolete normative reference: RFC 2068 (ref. '8') (Obsoleted by RFC 2616) ** Obsolete normative reference: RFC 3265 (ref. '9') (Obsoleted by RFC 6665) == Outdated reference: A later version (-08) exists of draft-ietf-mmusic-sdpng-07 ** 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-04.txt 13 April 13, 2004 14 Expires: October 2004 16 Protocol Requirements for Internet Media Guides 18 STATUS OF THIS MEMO 20 This document is an Internet-Draft and is in full conformance with 21 all provisions of Section 10 of RFC2026. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress". 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 To view the list Internet-Draft Shadow Directories, see 37 http://www.ietf.org/shadow.html. 39 Abstract 41 This memo specifies requirements for a protocol for accessing and 42 updating Internet Media Guide (IMG) information for media-on-demand 43 and multicast applications. These requirements are designed to guide 44 development of an IMG protocol for efficient and scalable delivery. 46 Table of Contents 48 1 Introduction ........................................ 3 49 1.1 Background and Motivation ........................... 3 50 1.2 Scope of This Document .............................. 4 51 2 Terminology ......................................... 5 52 3 Problem Statement ................................... 6 53 4 Use Cases Requiring IMGs ............................ 7 54 4.1 Connectivity-based Use Cases ........................ 7 55 4.1.1 IP Datacast to a Wireless Receiver .................. 7 56 4.1.2 Regular Fixed Dial-up Internet Connection ........... 8 57 4.1.3 Broadband Always-on Fixed Internet Connection ....... 8 58 4.2 Content-orientated Use Cases ........................ 9 59 4.2.1 TV and Radio Program Delivery ....................... 9 60 4.2.2 Media Coverage of a Live Event ...................... 9 61 4.2.3 Distance Learning ................................... 10 62 4.2.4 Multiplayer Gaming .................................. 10 63 4.2.5 File Distribution ................................... 10 64 4.2.6 Coming-release and Pre-released Content ............. 11 65 5 Requirements ........................................ 11 66 5.1 General Requirements ................................ 11 67 5.1.1 Independence of IMG Operations from IMG Metadata 68 5.1.2 Multiple IMG Senders ................................ 11 69 5.1.3 Modularity .......................................... 11 70 5.2 Delivery Properties ................................. 12 71 5.2.1 Scalability ......................................... 12 72 5.2.2 Support for Intermittent Connectivity ............... 12 73 5.2.3 Congestion Control .................................. 13 74 5.2.4 Sender and Receiver Driven Delivery ................. 13 75 5.3 Customized IMGs ..................................... 13 76 5.4 Reliability ......................................... 14 77 5.4.1 Managing consistency ................................ 14 78 5.4.2 Reliable Message Exchange ........................... 15 79 5.5 IMG Descriptions .................................... 15 80 6 Security Considerations ............................. 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 ................................. 19 87 8 References .......................................... 19 88 9 Acknowledgements .................................... 20 89 10 Authors' Addresses .................................. 20 90 11 Full Copyright Statement ............................ 21 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 or some 122 similar session description format. This is used to describe a set of 123 multimedia sessions (e.g. television program schedules, content 124 delivery schedules etc.) but may also refer to other networked 125 resources including web pages. IMGs provide the envelope for metadata 126 formats and session descriptions defined elsewhere with the aim of 127 facilitating structuring, versioning, referencing, distributing, and 128 maintaining (caching, updating) such information. 130 The IMG metadata must be delivered to a potentially large audience, 131 who use it to join a subset of the sessions described, and who may 132 need to be notified of changes to this information. Hence, a 133 framework for distributing IMG metadata in various different ways is 134 needed to accommodate the needs of different audiences: For 135 traditional broadcast-style scenarios, multicast-based (push) 136 distribution of IMG metadata needs to be supported. Where no 137 multicast is available, unicast-based push is required, too. 138 Furthermore, IMG metadata may need to be retrieved interactively, 139 similar to web pages (e.g. after rebooting a system or when a user is 140 browsing after network connectivity has been re-established). 141 Finally, IMG metadata may be updated as time elapses because content 142 described in the guide may be changed: for example, the airtime of an 143 event such as a concert or sports event may change, possibly 144 affecting the airtime of subsequent media. This may be done by 145 polling the IMG sender as well as by asynchronous change 146 notifications. 148 Furthermore, any Internet host can be a sender of content and thus an 149 IMG sender. Some of the content sources and sinks may only be 150 connected to the Internet sporadically. Also, a single human user may 151 use many different devices to access metadata. Thus, we envision that 152 IMG metadata can be sent and received by, among others, by cellular 153 phones, PDA (Personal Digital Assistant), personal computer, 154 streaming video server, set-top box, video camera, and DVR (Digital 155 Video Recorder) and that they be carried across arbitrary types of 156 link layers, including bandwidth-constrained mobile networks. 157 However, generally we expect IMG Senders to be well connected hosts. 159 Finally, with many potential senders and receivers, different types 160 of networks, and presumably numerous service providers, IMG metadata 161 may need to be combined, split, filtered, augmented, modified, etc. 162 on their way from the sender(s) to the receiver(s) to provide the 163 ultimate user with a suitable selection of multimedia programs 164 according to her preferences, subscriptions, location, context (e.g. 165 devices, access networks), etc. 167 1.2 Scope of This Document 169 This document defines requirements that Internet Media Guide (IMG) 170 mechanisms must satisfy in order to deliver IMG metadata to a 171 potentially large audience. Since IMGs can describe many kinds of 172 multimedia content, IMG methods are generally applicable to several 173 scenarios. 175 In considering wide applicability, this document provides the problem 176 statement and existing mechanisms in this area. Then several use case 177 scenarios for IMGs are explained including descriptions of how IMG 178 metadata and IMG delivery mechanisms contribute to these scenarios. 179 Following this, this document provides general requirements that are 180 independent of any transport layer mechanism and application, such as 181 delivery properties, reliability and IMG descriptions. 183 This document reflects investigating work on delivery mechanisms for 184 IMGs and generalizing work on session announcement and initiation 185 protocols, especially in the field of the MMUSIC working group (SAP, 186 SIP [5], 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 [6]. 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 [7] talks about 242 these issues in more detail. 244 The MMUSIC working group has long been investigating content, media 245 and service information delivery mechanisms and protocols, and has 246 itself produces Session Announcement Protocol (SAP), Session 247 Description Protocol (SDP), and the Session Initiation Protocol 248 (SIP). SDP is capable of describing multimedia sessions (i.e. 249 content in a wider sense) by means of limited descriptive information 250 intended for human perception plus transport, scheduling information, 251 and codecs and addresses for setting up media sessions. SIP and SAP 252 are protocols to distribute these session descriptions. 254 However, we perceive a lack of standard solution for scalable IMG 255 delivery mechanism in the number of receivers with consistency of IMG 256 metadata between an IMG sender and IMG receiver for both bi- 257 directional and unidirectional transport. With increased service 258 dynamics and complexity, there is an increased requirement for 259 updates to these content descriptions. 261 HTTP [8] is a well known information retrieval protocol using bi- 262 directional transport and widely used to deliver web-based content 263 descriptions to many hosts. However, it has well recognized 264 limitations of scalability in the number of HTTP clients since it 265 relies on the polling mechanism to keep information consistent 266 between the server and client. 268 SAP [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 [5] and SIP-specific event notification [9] can be used to notify 275 subscribers of the update of IMG metadata for bi-directional 276 transport. However, it is necessary for SIP Event to define an event 277 package as a standard protocol for each specific application 278 including IMGs. 280 We also perceive a lack of standard solution for flexible content 281 descriptions to support a multitude of application-specific data 282 models with differing amount of detail and different target 283 audiences. 285 SDP [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 [10], which is 292 intended for both two-way negotiation and also unidirectional 293 delivery. Since SDPng addresses multiparty multimedia conferences, it 294 is necessary to extend the XML schema in order to describe general 295 multimedia content. 297 4 Use Cases Requiring IMGs 299 4.1 Connectivity-based Use Cases 301 4.1.1 IP Datacast to a Wireless Receiver 303 IP Datacast is the delivery of IP-based services over broadcast 304 radio. Internet content delivery is therefore unidirectional in this 305 case. However, there can be significant benefits from being able to 306 provide rich media one-to-many services to such receivers. 308 There are two main classes of receiver in this use case: fixed 309 mains-powered; and mobile battery-powered. Both of these are affected 310 by radio phenomena and so robust, or error-resilient, delivery is 311 important. Carouselled metadata transfer provides a base level of 312 robustness for an IP datacast based announcement system, although the 313 design of carouselled transfer should enable battery-powered 314 receivers to go through periods of sleep to extend their operational 315 time between charges. Insertion of Forward Error Correction (FEC) 316 data into metadata announcements improves error resilience, and 317 reordering (interleaving) data blocks further increases tolerance to 318 burst errors. 320 To enable receivers to more accurately specify the metadata they are 321 interested in, the unidirectional delivery is distributed between 322 several logical channels. This is so that a receiver need only access 323 the channels of interest and thus can reduce the amount of time, 324 storage and CPU resources needed for processing the IP data. Also, 325 hierarchical channels enable receivers to subscribe to a root, 326 possibly well known, multicast channel/group and progressively access 327 only those additional channels based on metadata in parent channels. 329 In some cases the receiver may be multi-access, such that it is 330 capable of bi-directional communications. This enables a multitude of 331 options, but most importantly it enables NACK based reliability and 332 the individual retrieval of missed or not-multicasted sets of 333 metadata. 335 Thus, essential IMG features in this case include: robust 336 unidirectional delivery (with optional levels of reliability 337 including "plug-in FEC") which implies easily identifiable 338 segmentation of delivery data to enable FEC, carousel, interleaving 339 and other schemes possible; effective identification of metadata sets 340 (probably uniquely) to enable more efficient use of multicast and 341 unicast retrieval over multiple access systems regardless of the 342 parts of metadata and application specific extensions in use; 343 prioritization of metadata, which can (for instance) be achieved by 344 spreading it between channels and allocating/distributing bandwidth 345 accordingly. 347 Furthermore, some cases require IMG metadata authentication and some 348 group security/encryption and supporting security message exchanges 349 (out of band from the IMG multicast sessions). 351 4.1.2 Regular Fixed Dial-up Internet Connection 353 Dial-up connections tend to be reasonably slow (<56kbps in any case) 354 and thus large data transfers are less feasible, especially during an 355 active application session (such as a file transfer described by IMG 356 metadata). They can also be intermittent, especially if a user is 357 paying for the connected time, or connected through a less reliable 358 exchange. Thus this favors locally stored IMG metadata over web-based 359 browsing, especially where parts of the metadata change infrequently. 360 There may be no service provider preference over unicast and 361 multicast transport for small and medium numbers of users as the 362 last-mile dial-up connection limits per-user congestion, and a user 363 may prefer the more reliable option (unicast unless reliable 364 multicast is provided). 366 4.1.3 Broadband Always-on Fixed Internet Connection 368 Typically bandwidth is less of an issue to a broadband user and 369 unicast transport, such as using IMG QUERY, may be typical for a PC 370 user. If a system were only used in this context, with content 371 providers, ISPs and users having no other requirements, then web- 372 based browsing may be equally suitable. However, broadband users 373 sharing a local area network, especially wireless, may benefit more 374 from local storage features than on-line browsing, especially if they 375 have intermittent Internet access. 377 Broadband enables rich media services, which are increasingly 378 bandwidth hungry. Thus backbone operators may prefer multicast 379 communications to reduce overall congestion, if they have the 380 equipment and configuration to support this. Thus, broadband users 381 may be forced to retrieve IMG metadata over multicast if the 382 respective operators require this to keep system-wide bandwidth usage 383 feasible. 385 4.2 Content-orientated Use Cases 387 IMGs will be able to support a very wide range of use cases for 388 content/media delivery. The following few sections just touch the 389 surface of what is possible and are intended to provide an 390 understanding of the scope and type of IMG usage. Many more examples 391 may be relevant, for instance those detailed in [11]. There are 392 several unique features of IMGs that set them apart from related 393 application areas such as SLP based service location discovery, LDAP 394 based indexing services and search engines such as Google. Features 395 unique to IMGs include: 397 o IMG metadata is generally time-related 399 o There are timeliness requirements in the delivery of IMG 400 metadata 402 o IMG metadata may be updated as time elapses or when an event 403 arises 405 4.2.1 TV and Radio Program Delivery 407 A sender of audio/video streaming content can use the IMG metadata to 408 describe the scheduling and other properties of audio/video sessions 409 and events within those sessions, such as individual TV and radio 410 programs and segments within those programs. IMG metadata describing 411 audio/video streaming content could be represented in a format 412 similar to that of a TV guide in newspapers, or an Electronic Program 413 Guide available on digital TV receivers. 415 Similarly to file reception, TV and radio programs can be selected 416 for reception either manually by the end-user or automatically based 417 on the content descriptions and the preferences of the user. The 418 received TV and radio content can be either presented in real time or 419 recorded for consuming later. There may be changes in the scheduling 420 of a TV or a radio program, possibly affecting the transmission times 421 of subsequent programs. IMG metadata can be used to notify receivers 422 of such changes, enabling users to be prompted or recording times to 423 be adjusted. 425 4.2.2 Media Coverage of a Live Event 427 The media coverage of a live event such as a rock concert or a sports 428 event is a special case of regular TV/radio programming. There may be 429 unexpected changes in the scheduling of live event, or the event may 430 be unscheduled to start with (such as breaking news). In addition to 431 audio/video streams, textual information relevant to the event (e.g. 432 statistics of the players during a football match) may be sent to 433 user terminals. Different transport modes or even different access 434 technologies can be used for the different media: for example, a 435 unidirectional datacast transport could be used for the audio/video 436 streams and an interactive cellular connection for the textual data. 437 IMG metadata should enable terminals to discover the availability of 438 different media used to cover a live event. 440 4.2.3 Distance Learning 442 IMG metadata could describe compound sessions or services enabling 443 several alternative interaction modes between the participants. For 444 example, the combination of one-to-many media streaming, unicast 445 messaging and download of presentation material could be useful for 446 distance learning. 448 4.2.4 Multiplayer Gaming 450 Multiplayer games are an example of real-time multiparty 451 communication sessions that could be advertised using IMGs. A gaming 452 session could be advertised either by a dedicated server, or by the 453 terminals of individual users. A user could use IMGs to learn of 454 active multiplayer gaming sessions, or advertise the users interest 455 in establishing such a session. 457 4.2.5 File Distribution 459 IMGs support the communication of file delivery session properties, 460 enabling the scheduled delivery or synchronization of files between a 461 number of hosts. The received IMG metadata could be subsequently used 462 by any application (also outside the scope of IMGs), for example to 463 download a file with a software update. IMG metadata can provide a 464 description to each file in a file delivery session, assisting users 465 or receiving software in selecting individual files for reception. 467 For example, when a content provider wants to distribute a large 468 amount of data in file format to thousands clients, the content 469 provider can use IMG metadata to schedule the delivery effectively. 470 Since IMG metadata can describe time-related data for each receiver, 471 the content provider can schedule delivery time for each receiver. 472 This can save network bandwidth and delivery capacity of senders. In 473 addition, IMG metadata can be used to synchronize a set of files 474 between a sender host and receiver host, when those files change as 475 time elapses. 477 4.2.6 Coming-release and Pre-released Content 479 IMG metadata can be used to describe items of content before the 480 details of their final release are known. A user may be interested in 481 coming content (a new movie or software title where some aspects of 482 the content description are known in advance) and so subscribe to an 483 information service which notifies the user of changes to metadata 484 describing that content. Thus, as the coming release, or pre-releases 485 (such as movie trailers or software demos), become available the IMG 486 metadata changes and the user is notified of this change. For 487 example, the user could see an announcement of a movie that will be 488 released sometime in the next few months, and configure the user's 489 terminal to receive and record any trailers or promotional material 490 as they become available. 492 5 Requirements 494 5.1 General Requirements 496 5.1.1 Independence of IMG Operations from IMG Metadata 498 REQ GEN-1: Carrying different kinds of IMG metadata format in the IMG 499 message body MUST be allowed. 501 REQ GEN-2: Delivery mechanisms SHOULD support many different 502 applications specific metadata formats to keep the system 503 interoperable with existing applications. 505 This provides flexibility in selecting/designing IMG transport 506 protocol suited to various scenarios. 508 5.1.2 Multiple IMG Senders 510 REQ GEN-3: IMG receivers MUST be allowed to communicate with any 511 number of IMG senders simultaneously. 513 This might lead to receiving redundant IMG metadata describing the 514 same items, however it enables the IMG receiver access to more IMG 515 metadata than may be available from a single IMG sender. This also 516 provides flexibility for the IMG transport protocols and does not 517 preclude a mechanism to solve inconsistency among IMG metadata due to 518 multiple IMG senders. This document assumes a typical IMG environment 519 will involve many more IMG receivers than IMG senders and that IMG 520 senders are continually connected for the duration of interest 521 (rather than intermittently connected). 523 5.1.3 Modularity 524 REQ GEN-4: The IMG delivery mechanisms MUST allow the combination of 525 several IMG Operations. 527 This is for the purpose of extending functionality (e.g. several or 528 one protocol(s) to provide all the needed operations). Applications 529 can select an appropriate operation set to fulfill their purpose. 531 5.2 Delivery Properties 533 This section describes general performance requirements based on the 534 assumption that the range of IMG usage shall be important. However, 535 it may be noted that requirements of delivery properties may vary 536 based on the usage scenario, and thus some limited use 537 implementations place less importance on some requirements. 539 For example, it is clear that a multicast transport may provide more 540 scalable delivery than a unicast transport, however scalability 541 requirements do not preclude the unicast transport mechanisms. In 542 this sense, scalability is always important for the protocols 543 irrespective of transport mechanisms. 545 5.2.1 Scalability 547 REQ DEL-1: The 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 MUST 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 5.2.3 Congestion Control 575 REQ DEL-5: Internet-friendly congestion control MUST be provided for 576 use on the public Internet. 578 REQ DEL-6: An IMG entity SHOULD invalidate the IMG metadata item when 579 an IMG metadata item has lifetime information and its lifetime is 580 over. This will lessen the need for notifications of updates from the 581 IMG sender to the IMG receiver to invalidate the item and may enable 582 lesser congestion. 584 5.2.4 Sender and Receiver Driven Delivery 586 REQ DEL-7: The system MUST be flexible in choosing sender-driven, 587 receiver-driven or both delivery schemes. 589 Sender-driven delivery achieves high scalability without interaction 590 between the IMG sender and receiver. This avoids keeping track of a 591 delivery state of every IMG receiver. 593 In contrast, the receiver-driven delivery provides on-demand delivery 594 for IMG receivers. Since an IMG sender's complete IMG metadata may be 595 a very large amount of data, the IMG receiver needs to be able to 596 access the guide when convenient (e.g., when sufficient network 597 bandwidth is available to the IMG receiver). 599 5.3 Customized IMGs 601 REQ CUS-1: The system MUST allow delivery of customized IMG metadata. 603 The IMG receiver may require a subset of all the IMG metadata 604 available according to their preferences (type of content, media 605 description, appropriate age group, etc.) and configuration. 607 The IMG receiver might send its preferences in the IMG operations 608 which can specify user specific IMG metadata to be delivered. These 609 preferences could consist of filtering rules. When receiving these 610 messages, the IMG sender might respond appropriate messages carrying 611 a subset of IMG metadata which matches the IMG receiver's 612 preferences. 614 This mechanism can reduce the amount of IMG metadata delivered from 615 the IMG sender to IMG receiver, and consequently it can save the 616 resource consumption on the IMG entities and networks. It is 617 typically useful in unicast case and also beneficial in multicast 618 case where IMG sender distributes the same IMG metadata to interested 619 IMG receivers at the same time. 621 For multicast and unicast cases where the IMG sender does not provide 622 customized IMG metadata, the IMG receiver could receive all IMG 623 metadata transmitted (on its joined channels). However, it may select 624 and filter the IMG metadata to get customized IMG metadata by its 625 preferences, and thus drop unwanted metadata immediately upon 626 reception. 628 Customized metadata might be achieved by changing the IMG 629 descriptions sent and IMG receivers and/or changing the delivery 630 properties (channels used). 632 Note, customization and scalability are only somewhat exclusive. 633 Systems providing an IMG receiver to an IMG sender request-based 634 customization, will be generally less scalable to massive IMG 635 receiver populations than those without this return signaling 636 technique. Thus, customization, as with any feature which affects 637 scalability, should be carefully designed for the intended 638 application, and it may not be possible that a one-size-fits-all 639 solution for customization would meet the scalability requirements 640 for all applications and deployment cases. 642 5.4 Reliability 644 5.4.1 Managing consistency 646 IMG metadata tends to change as time elapses, as new content is 647 added, the old IMG metadata stored in the IMG receiver becomes 648 unavailable and the parameters of the existing IMG metadata are 649 changed. 651 REQ REL-1: The system MUST manage IMG metadata consistency. 653 The IMG sender can either simply make updates available 654 (unsynchronized) or IMG sender and receiver can interact to keep 655 their copies of the IMG metadata synchronized. 657 In the unsynchronized model, the IMG sender does not know whether a 658 particular IMG receiver has an up-to-date copy of the IMG metadata. 660 In the synchronized model, updating cached copy of the IMG metadata 661 is necessary to control consistency when the IMG sender or receiver 662 could not communicate for a while. In this case, the IMG sender or 663 receiver may need to confirm its consistency by IMG operations. 665 REQ REL-2: Since IMG metadata can change at any time, IMG receivers 666 SHOULD be notified of such changes. 668 Depending on the size of the guide, the interested party may want to 669 defer retrieving the actual information. The change notification 670 should be addressed to a logical user (or user group), not a host, 671 since users may change devices. 673 Note that depending on the deployment environment and application 674 specifics, the level of acceptable inconsistency varies. Thus, this 675 document does not define inconsistency as specific time and state 676 differences between IMG metadata stored in an IMG sender and IMG 677 metadata stored in an IMG receiver. 679 In general, the consistency of metadata for a content and media is 680 more important immediately prior to and during the media's 681 session(s). Hosts which forward (or otherwise resend) metadata may be 682 less tolerant to inconsistencies as delivering out of date data is 683 both misleading and bandwidth inefficient. 685 REQ REL-3: The IMG system SHOULD allow for hosts with intermittent 686 connectivity. 688 The implication of intermittent connectivity is that immediate 689 distribution of changes becomes infeasible and so managing data 690 consistency should be focused on the timely delivery of data. 692 5.4.2 Reliable Message Exchange 694 REQ REL-4: An IMG transport protocol MUST support reliable message 695 exchange. 697 The extent to which this could result in 100% error free delivery to 698 100% of IMG receivers is a statistical characteristic of the 699 protocols used. Usage of reliable IMG delivery mechanisms is expected 700 to depend on the extent to which underlying networks provide 701 reliability and, conversely, introduce errors. Note, some deployments 702 of IMG transport protocols may not aim to provide perfect reception 703 to all IMG receivers in all possible cases. 705 5.5 IMG Descriptions 707 REQ DES-1: IMG metadata MUST be interoperable over any IMG transport 708 protocol, such that an application receiving the same metadata over 709 any one (or more) of several network connections and/or IMG transport 710 protocols will interpret the metadata in exactly the same way. (This 711 also relates to the 'Independence of IMG Operations from IMG 712 Metadata' requirement). 714 REQ DES-2: IMG delivery MUST enable the carriage of any format of 715 application-specific metadata. 717 Thus, the system will support the description of many kinds of 718 multimedia content, without the need for a single homogenous metadata 719 syntax for all uses (which would be infeasible anyway). This is 720 essential for environments using IMG systems to support many kinds of 721 multimedia content and to achieve wide applicability. 723 REQ DES-3: Whereas specific applications relying on IMGs will need to 724 select one or more specific application-specific metadata formats 725 (standard, syntax, etc.), the IMG system MUST be independent of this 726 (it may be aware, but it will operate in the same way for all). 728 Thus, a transfer envelope format, that is uniform across all 729 different application-specific IMG metadata formats, is needed. The 730 payload of this transfer envelope would be some application-specific 731 metadata, and the envelope would support the maintenance of the 732 application-specific metadata including the metadata relationships 733 determined by the data model(s) used. The transfer envelope would not 734 need to be aware of the data model(s) in use. 736 REQ DES-4: IMG metadata MUST be structured to enable fragmentation 737 for efficient delivery. 739 This it is intended to ensure that and IMG sender with more than a 740 trivial knowledge of metadata is able to deliver only part of its 741 (and the global) complete IMG metadata knowledge. (For instance, a 742 trivial quantity of knowledge could be a single SDP description). In 743 general, the resolution of this fragmentation will be very much 744 dependent on the optimal delivery of a deployment, although some 745 metadata syntaxes will inherently effect the sensible lower limit for 746 a single element/fragment. 748 REQ DES-5: A transfer envelope MUST be defined to include essential 749 parameters. 751 Examples of essential parameters are those that allow the metadata in 752 question to be uniquely identified and updated by new versions of the 753 same metadata. 755 REQ DES-6: It SHALL be possible to deduce the metadata format from 756 the transfer envelope. 758 REQ DES-7: IMG senders SHALL use the transfer envelope for each IMG 759 metadata transfer. 761 Thus, it will even be possible to describe relationships between 762 syntactically dissimilar application-specific formats within the same 763 body of IMG metadata knowledge. 765 REQ DES-8: IMG metadata SHOULD support to describe differences 766 between update version and old version of IMG metadata when IMG 767 delivery mechanism carries updated IMG metadata and those differences 768 are considerably little. (This also relates the delivery property 769 requirements for congestion control in Section 5.2.3). 771 6 Security Considerations 773 Internet Media Guides are used to convey information about multimedia 774 resources from one or more IMG senders across one or intermediaries 775 to one or more IMG receivers. IMG metadata may be pushed to the IMG 776 receivers or interactively retrieved by them. IMGs provide metadata 777 as well as scheduling and rendezvous information about multimedia 778 resources, etc. and requests for IMG metadata may contain information 779 about the requesting users. 781 The information contained in IMG metadata as well as the operations 782 related to IMGs should be secured to avoid forging information, 783 misdirecting users, spoofing IMG senders, etc. and to protect user 784 privacy. 786 The remainder of section addresses the security requirements for 787 IMGs. 789 6.1 IMG Authentication and Integrity 791 IMG metadata and its parts need to be protected against unauthorized 792 altering/adding/deletion on the way. Their originator needs to be 793 authenticated. 795 REQ AUT-1: It MUST be possible to authenticate the originator of a 796 set of IMG metadata. 798 REQ AUT-2: It MUST be possible to authenticate the originator of a 799 subpart of IMG metadata (e.g. a delta or a subset of the 800 information). 802 REQ AUT-3: It MUST be possible to validate the integrity of IMG 803 metadata. 805 REQ AUT-4: It MUST be possible to validate the integrity of a subpart 806 of IMG metadata (e.g. a delta or a subset of the information). 808 REQ AUT-5: It MUST be possible to separate or combine individually 809 authenticated pieces of IMG metadata (e.g. in an IMG transceiver) 810 without invalidating the authentication. 812 REQ AUT-6: It MUST be possible to validate the integrity of an 813 individually authenticated piece of IMG metadata even after this 814 piece had been separated from other pieces of IMG metadata and 815 combined with other pieces to form new IMG metadata. 817 REQ AUT-7: It MUST be possible to authenticate the originator of an 818 IMG operation. 820 REQ AUT-8: It MUST be possible to validate the integrity of any 821 contents of an IMG operation (e.g. the subscription or inquiry 822 information). 824 6.2 Privacy 826 Customized IMG metadata and IMG metadata delivered by notification to 827 individual users may reveal information about the habits and 828 preferences of a user and may thus deserve confidentiality 829 protection, even though the information itself is public. 831 REQ PRI-1: It MUST be possible to keep user requests to subscribe to 832 or retrieve certain (parts of) IMG metadata confidential. 834 REQ PRI-2: It MUST be possible to keep IMG metadata, pieces of IMG 835 metadata, or pointers to IMG metadata delivered to individual users 836 or groups of users confidential. 838 REQ PRI-3: It SHOULD be possible to ensure this confidentiality end- 839 to-end, that is, to prevent intermediaries (such as IMG transceivers) 840 from accessing the contained information. 842 6.3 Access Control for IMGs 844 Some IMG metadata may be freely available, while access to other may 845 be restricted to closed user groups (e.g. paying subscribers). Also, 846 different parts of IMG metadata may be protected at different levels: 847 e.g. metadata describing a media session may be freely accessible 848 while rendezvous information to actually access the media session may 849 require authorization. 851 REQ ACC-1: It MUST be possible to authorize user access to IMG 852 metadata. 854 REQ ACC-2: It MUST be possible to authorize access of users to pieces 855 of IMG metadata (delta information, subparts, pointers). 857 REQ ACC-3: It MUST be possible to require different authorization for 858 different parts of the same IMG metadata. 860 REQ ACC-4: It MUST be possible to access selected IMG metadata 861 anonymously. 863 REQ ACC-5: It MUST be possible for an IMG receiver to choose not to 864 receive (parts of) IMG metadata in order to avoid being identified by 865 the IMG sender. 867 REQ ACC-6: It SHOULD be possible for IMG transceiver to impose 868 different authorization requirements. 870 REQ ACC-7: It MAY be possible for IMG senders to require certain 871 authorization that cannot be overridden by intermediaries. 873 6.4 Denial-of-Service attacks 875 Retrieving or distributing IMG metadata may require state in the IMG 876 senders, transceivers, and/or receivers for the respective IMG 877 transport sessions. Attackers may create large numbers of sessions 878 with any of the above IMG entities to disrupt regular operation. 880 REQ DOS-1: IMG operations SHOULD be authenticated. 882 REQ DOS-2: It SHOULD be possible to prevent DoS attacks that build up 883 session state in IMG entities to exhaust their resources. 885 REQ DOS-3: It SHOULD be possible to avoid DoS attacks that exhaust 886 resources of IMG entities by flooding them with IMG metadata. 888 6.5 Replay Attacks 890 IMG metadata disseminated by an IMG sender or an IMG transceiver may 891 be updated, deleted, or lose validity over time for some other 892 reasons. Replaying outdated IMG metadata needs to be prevented. 894 Furthermore, replay attacks may also apply to IMG operations (rather 895 than just their payload). Replaying operations needs also be 896 prevented. 898 REQ REP-1: IMG metadata MUST be protected against partial or full 899 replacement of newer ("current") versions by older ones. 901 REQ REP-2: Mechanisms MUST be provided to mitigate replay attacks on 902 the IMG operations. 904 7 IANA Considerations 906 There are no IANA considerations within this document. 908 8 References 910 [1] M. Handley and V. Jacobson, "SDP: session description protocol," 911 RFC 2327, Internet Engineering Task Force, Apr. 1998. 913 [2] M. Handley, C. E. Perkins, and E. Whelan, "Session announcement 914 protocol," RFC 2974, Internet Engineering Task Force, Oct. 2000. 916 [3] Session Directory, ftp://ftp.ee.lbl.gov/conferencing/sd/ 918 [4] Session Directory Tool, 919 http://www-mice.cs.ucl.ac.uk/multimedia/software/sdr/ 921 [5] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J. 922 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session 923 initiation protocol," RFC 3261, Internet Engineering Task Force, June 924 2002. 926 [6] S. Bradner, "Key words for use in RFCs to indicate requirement 927 levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. 929 [7] Y. Nomura, R. Walsh, J-P. Luoma, H. Asaeda, and H. Schulzrinne, 930 "A framework for the usage of Internet media guides," Internet Draft 931 draft-ietf-mmusic-img-framework-04, Internet Engineering Task Force, 932 April 2004. Work in progress. 934 [8] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, and T. Berners- 935 Lee, "Hypertext transfer protocol -- HTTP/1.1," RFC 2068, Internet 936 Engineering Task Force, Jan. 1997. 938 [9] A. B. Roach, "Session initiation protocol (sip)-specific event 939 notification," RFC 3265, Internet Engineering Task Force, June 2002. 941 [10] D. Kutscher, J. Ott, and C. Bormann, "Session description and 942 capability negotiation," Internet Draft draft-ietf-mmusic-sdpng-07, 943 Internet Engineering Task Force, Oct. 2003. Work in progress. 945 [11] B. Quinn and K. Almeroth, "IP multicast applications: Challenges 946 and solutions," RFC 3170, Internet Engineering Task Force, Sept. 947 2001. 949 9 Acknowledgements 951 The authors would like to thank Colin Perkins, Jean-Pierre Evain, 952 Hitoshi Asaeda, Petri Koskelainen, Toni Paila and Dirk Kutscher for 953 their comments and ideas on this work. 955 10 Authors' Addresses 957 Yuji Nomura 958 Fujitsu Laboratories Ltd. 959 4-1-1 Kamikodanaka, Nakahara-ku, Kawasaki 211-8588 960 Japan 961 Email: nom@flab.fujitsu.co.jp 963 Rod Walsh 964 Nokia Research Center 965 P.O. Box 100, FIN-33721 Tampere 966 Finland 967 Email: rod.walsh@nokia.com 969 Juha-Pekka Luoma 970 Nokia Research Center 971 P.O. Box 100, FIN-33721 Tampere 972 Finland 973 Email: juha-pekka.luoma@nokia.com 975 Joerg Ott 976 Universitaet Bremen 977 MZH 5180 978 Bibliothekstr. 1 979 D-28359 Bremen 980 Germany 981 Email: jo@tzi.uni-bremen.de 983 Henning Schulzrinne 984 Dept. of Computer Science 985 Columbia University 986 1214 Amsterdam Avenue 987 New York, NY 10027 988 USA 989 Email: schulzrinne@cs.columbia.edu 991 11 Full Copyright Statement 993 Copyright (C) The Internet Society (2004). This document is subject 994 to the rights, licenses and restrictions contained in BCP 78 and 995 except as set forth therein, the authors retain all their rights. 997 This document and the information contained herein are provided on an 998 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 999 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1000 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1001 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1002 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1003 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1005 Intellectual Property 1006 The IETF takes no position regarding the validity or scope of any 1007 Intellectual Property Rights or other rights that might be claimed to 1008 pertain to the implementation or use of the technology described in 1009 this document or the extent to which any license under such rights 1010 might or might not be available; nor does it represent that it has 1011 made any independent effort to identify any such rights. Information 1012 on the procedures with respect to rights in RFC documents can be 1013 found in BCP 78 and BCP 79. 1015 Copies of IPR disclosures made to the IETF Secretariat and any 1016 assurances of licenses to be made available, or the result of an 1017 attempt made to obtain a general license or permission for the use of 1018 such proprietary rights by implementers or users of this 1019 specification can be obtained from the IETF on-line IPR repository at 1020 http://www.ietf.org/ipr. 1022 The IETF invites any interested party to bring to its attention any 1023 copyrights, patents or patent applications, or other proprietary 1024 rights that may cover technology that may be required to implement 1025 this standard. Please address the information to the IETF at ietf- 1026 ipr@ietf.org.