idnits 2.17.1 draft-ietf-mmusic-img-framework-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 401 has weird spacing: '...rection v ...' -- 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 (December 22, 2003) is 7428 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-08) exists of draft-ietf-mmusic-img-req-02 ** Downref: Normative reference to an Informational draft: draft-ietf-mmusic-img-req (ref. '1') ** Obsolete normative reference: RFC 3466 (ref. '3') (Obsoleted by RFC 7336) ** Obsolete normative reference: RFC 2327 (ref. '4') (Obsoleted by RFC 4566) == Outdated reference: A later version (-08) exists of draft-ietf-mmusic-sdpng-07 -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' ** Obsolete normative reference: RFC 2068 (ref. '8') (Obsoleted by RFC 2616) ** Downref: Normative reference to an Experimental RFC: RFC 2974 (ref. '9') ** Obsolete normative reference: RFC 3265 (ref. '11') (Obsoleted by RFC 6665) ** Obsolete normative reference: RFC 3450 (ref. '13') (Obsoleted by RFC 5775) == Outdated reference: A later version (-08) exists of draft-ietf-rmt-flute-07 Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 4 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 H. Asaeda 9 INRIA 10 H. Schulzrinne 11 Columbia University 12 draft-ietf-mmusic-img-framework-02.txt 13 December 22, 2003 14 Expires: June 2004 16 A Framework for the Usage of 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 document defines a framework for the delivery of Internet Media 42 Guides (IMGs). An IMG is a structured collection of multimedia 43 session descriptions expressed using SDP, SDPng or some similar 44 session description format. This document describes a generalized 45 model for IMG delivery mechanisms, and the use of existing protocol 46 to create an IMG delivery infrastructure. 48 Table of Contents 50 1 Introduction ........................................ 2 51 2 Terminology ......................................... 3 52 3 IMG Common Framework Model .......................... 5 53 3.1 IMG Data Types ...................................... 5 54 3.1.1 Complete IMG Description ............................ 5 55 3.1.2 Delta IMG Description ............................... 6 56 3.1.3 IMG Pointer ......................................... 6 57 3.2 Operation Set for IMG Delivery ...................... 6 58 3.2.1 IMG ANNOUNCE ........................................ 6 59 3.2.2 IMG QUERY ........................................... 7 60 3.2.3 IMG RESOLVE ......................................... 7 61 3.2.4 IMG SUBSCRIBE ....................................... 7 62 3.2.5 IMG NOTIFY .......................................... 8 63 3.2.6 Binding Between IMG Operations and Data Types ....... 8 64 3.3 IMG Entities ........................................ 8 65 3.4 Overview of Protocol Operations ..................... 9 66 4 Deployment Scenarios for IMG Entities ............... 9 67 4.1 Intermediary Cases .................................. 10 68 4.2 One-to-many Unidirectional Multicast ................ 11 69 4.3 One-to-one Bi-directional Unicast ................... 12 70 4.4 Combined Operations with Common Metadata ............ 12 71 5 Applicability of Existing Protocols to the 72 Proposed Framework Model ....................................... 13 73 5.1 Summary of Limitations of Existing Protocols ........ 13 74 5.2 Existing Protocol Fit to the IMG Framework Model 75 5.3 Outstanding IMG Mechanism Needs ..................... 16 76 5.3.1 A Multicast Transport Protocol ...................... 16 77 5.3.2 Usage of Unicast Transport Protocols ................ 17 78 5.3.3 IMG Transfer Envelope ............................... 17 79 5.3.4 Baseline (Meta)Data Model Specification ............. 18 80 5.4 IMG Needs Fitting the IETF's Scope .................. 18 81 6 Security Considerations ............................. 19 82 7 Normative References ................................ 21 83 8 Informative References .............................. 22 84 9 Acknowledgements .................................... 22 85 10 Authors' Addresses .................................. 22 87 1 Introduction 89 Internet Media Guides (IMGs) provide and deliver structured 90 collections of multimedia descriptions expressed using SDP, SDPng or 91 some similar description format. They are used to describe sets of 92 multimedia sessions (e.g. television program schedules, content 93 delivery schedules etc.) and refer to other networked resources 94 including web pages. IMGs provide an envelope for metadata formats 95 and session descriptions defined elsewhere with the aim of 96 facilitating structuring, versioning, referencing, distributing, and 97 maintaining (caching, updating) such information. 99 IMG metadata must be delivered to a potentially large audience, who 100 use it to join a subset of the sessions described, and who may need 101 to be notified of changes to the IMG metadata. Hence, a framework for 102 distributing IMG metadata in various different ways is needed to 103 accommodate the needs of different audiences: For traditional 104 broadcast-style scenarios, multicast-based (push) distribution of IMG 105 metadata needs to be supported. Where no multicast is available, 106 unicast-based push is required, too. 108 This document defines a common framework model for IMG delivery 109 mechanisms and their deployment in network entities. There are three 110 fundamental components in IMG framework model: data types, operation 111 sets and entities. These components specify a set of framework 112 guideline for IMG delivery to efficiently deliver and describe IMG 113 metadata. The data types give common base descriptions on top of an 114 application-specific IMG metadata. IMG operations cover traditional 115 broadcast-style scenarios, multicast-based distributions, unicast- 116 based push and interactive retrievals similar to web pages. Since we 117 envision that any Internet host can be a sender and receiver of IMG 118 metadata, an host involved in IMG operations perform one or more of 119 roles defined as the entities in IMG framework model. These are then 120 shown in a number of simplified deployment scenarios. The 121 requirements for IMG delivery mechanisms and descriptions can be 122 found in [1]. 124 Then, this document outlines the use of existing protocols to create 125 an IMG delivery infrastructure. It aims to organize existing 126 protocols into common model and show their capabilities and 127 limitations from the viewpoint of IMG delivery functions. One of the 128 multicast-enabling IMG requirements is scaling well to a large number 129 of hosts and IMG senders in a network. Another issue is the need for 130 flexibility and diversity in delivery methods, whereas existing 131 protocols tend to be bound to a specific application. 133 2 Terminology 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in RFC 2119 [2]. 139 Internet Media Guide (IMG): IMG is a generic term to describe 140 the formation, delivery and use of IMG metadata. The 141 definition of the IMG is intentionally left imprecise. 143 IMG Element: The smallest atomic element of metadata that can be 144 transmitted separately by IMG operations and referenced 145 individually from other IMG elements. 147 IMG Metadata: A set of metadata consisting of one or more IMG 148 elements. IMG metadata describes the features of multimedia 149 content used to enable selection of and access to media 150 sessions containing content. For example, metadata may 151 consist of the URI, title, airtime, bandwidth needed, file 152 size, text summary, genre and access restrictions. 154 IMG Description: A collection of IMG metadata which has a 155 relationship to other IMG metadata. There are three data 156 types to describe the relationship: Complete IMG 157 Descriptions, Delta IMG Description and IMG pointer. 159 IMG Delivery: The process of exchanging IMG metadata both in 160 terms of large scale and atomic data transfers. 162 IMG Sender: An IMG sender is a logical entity that sends IMG 163 metadata to one or more IMG receivers. 165 IMG Receiver: An IMG receiver is a logical entity that receives 166 IMG metadata from an IMG sender. 168 IMG Transceiver: An IMG transceiver combines an IMG receiver and 169 sender. It may modify received IMG metadata or merge IMG 170 metadata received from a several different IMG senders. 172 IMG Operation: An atomic operation of an IMG transport protocol, 173 used between IMG sender(s) and IMG receiver(s) for the 174 delivery of IMG metadata and for the control of IMG 175 sender(s)/receiver(s). 177 IMG Transport Protocol: A protocol that transports IMG metadata 178 from an IMG sender to IMG receiver(s). 180 IMG Transport Session: An association between an IMG sender and 181 one or more IMG receivers within the scope of an IMG 182 transport protocol. An IMG transport session involves a 183 series of IMG transport protocol interactions that provide 184 delivery of IMG metadata from the IMG sender to the IMG 185 receiver(s). 187 IMG Transfer: A transfer of IMG metadata consisting of Complete 188 IMG Descriptions, Delta IMG Descriptions and/or IMG 189 Pointers. 191 3 IMG Common Framework Model 193 Two common elements are found in all of existing IMG candidate cases: 194 the need to describe the services; the need to deliver the 195 descriptions. In some cases, the descriptions are multicast enablers 196 (such as the session parameters of SDP) and are thus intrinsically 197 part of the delivery aspects, and in other cases descriptions are 198 application-specific (both machine and human readable). Thus, the 199 technologies can be roughly divided into three areas: 201 o Application-specific Metadata -- data describing the services' 202 content and media which are both specific to certain 203 applications and generally human readable. 205 o Delivery Descriptions -- the descriptions (metadata) that are 206 essential to enable (e.g. multicast) delivery. These include 207 framing (headers) for application-specific metadata, the 208 metadata element identification and structure, fundamental 209 session descriptions. 211 o Delivery Protocols -- the methods and protocols to exchange 212 descriptions between the senders and the receivers. An IMG 213 transport protocol consists of two functions: carrying IMG 214 metadata from an IMG sender to an IMG receiver and controlling 215 an IMG transport protocol. These functions are not always 216 exclusive, therefore some messages may combine control 217 messages and metadata carriage functions metadata to reduce 218 the amount of the messaging. 220 3.1 IMG Data Types 222 A data model is needed to precisely define the terminology and 223 relationships between sets, supersets and subsets of metadata. A 224 precise data model is essential for the implementation of IMGs 225 although it is not within the scope of this framework and requires a 226 separate specification. However there are three IMG data types in 227 general: Complete IMG Descriptions, Delta IMG Description and IMG 228 Pointer. 230 3.1.1 Complete IMG Description 232 A Complete IMG Description provides a complete syntax and semantics 233 to describe a set of metadata, which does not need any additional 234 information from any other IMG element. 236 Note, this is not to be confused with "complete IMG metadata", which, 237 although vaguely defined here, represents the complete IMG metadata 238 database of an IMG sender (or related group of IMG senders -- 239 potentially the complete Internet IMG knowledge). An IMG sender will 240 generally deliver only subsets of metadata from its complete database 241 in a particular IMG transport session. 243 3.1.2 Delta IMG Description 245 A Delta IMG Description provides only part of a Complete IMG 246 Description, defining the difference from a previous version of the 247 Complete IMG Description in question. Delta transfers may be used to 248 reduce network resource usage (it may be more bandwidth and 249 congestion friendly), for instance when data consistency is essential 250 and small and frequent changes occur to IMG elements. Thus, this 251 description itself cannot represent complete metadata set until it is 252 combined with existing, or future, description knowledge. 254 3.1.3 IMG Pointer 256 An IMG Pointer provides a simple identifier or locator, such as a 257 URI, that the IMG receiver is able to reference (or reference and 258 locate) specific metadata with. This may be used to separately obtain 259 metadata (Complete or Delta IMG Descriptions) or perform another IMG 260 management function such as data expire (and erasure). The IMG 261 Pointer may be used to reference IMG metadata elements within the IMG 262 transport session and across IMG transport sessions. This pointer 263 type does not include metadata per se (although it may also appear as 264 a data field in Complete or Delta IMG descriptors). 266 3.2 Operation Set for IMG Delivery 268 A finite set of operations both meets the IMG requirements [1] and 269 fits the roles of existing protocols. These are crystallized in the 270 next few sections. 272 3.2.1 IMG ANNOUNCE 274 When an IMG receiver participates in unidirectional communications 275 (e.g. over satellite, terrestrial radio and wired multicast networks) 276 an IMG receiver may not need to send any message to an IMG sender 277 prior to IMG metadata delivery. In this case, an IMG sender can 278 initiate unsolicited distribution for IMG metadata and an IMG sender 279 is the only entity which can maintain the distribution (this includes 280 scenarios with multiple and co-operative IMG senders). This operation 281 is useful when there are considerably large number IMG receivers or 282 IMG receiver(s) do not have a guaranteed uplink connection to the IMG 283 sender(s). The IMG sender may also include authentication data in the 284 announce operation so that IMG receivers may check the authenticity 285 of the metadata. This operation is able to carry any of the IMG data 286 types. 288 Note, there is no restriction to prevent IMG ANNOUNCE from being used 289 in an asynchronous solicited manner, where a separate operation 290 (possibly out of band) is able to subscribe/register IMG receivers to 291 the IMG ANNOUNCE operation. 293 3.2.2 IMG QUERY 295 If an IMG receiver needs to obtain IMG metadata, an IMG receiver can 296 send an IMG QUERY message and initiate a receiver-driven IMG 297 transport session. The IMG receiver expects a synchronous response to 298 the subsequent request from the IMG sender. This operation can be 299 used where a bi-directional transport network is available between 300 the IMG sender and receiver. Some IMG receivers may want to obtain 301 IMG metadata when a resource is available or just to avoid caching 302 unsolicited IMG metadata. The IMG receiver must indicate the extent 303 and data type of metadata wanted in some message in the operation 304 (Extent indicates the number and grouping of metadata descriptions). 305 In some cases requesting an IMG sender's complete IMG metadata may be 306 feasible, in others it may not. 308 3.2.3 IMG RESOLVE 310 An IMG sender synchronously responds and sends IMG metadata to an IMG 311 QUERY which has been sent by an IMG receiver. This operation can be 312 used where a bi-directional transport network is available between 313 the IMG sender and receiver. If the IMG QUERY specifies a subset of 314 IMG metadata (extent and data type) that is available to the IMG 315 sender, the IMG sender can resolve query; otherwise, it should 316 indicate that it is not able to resolve the query. The IMG sender may 317 authenticate the IMG receiver to investigate the IMG QUERY operation 318 in order to determine whether the IMG receiver is authorized to be 319 sent that metadata. The sender may also include authentication data 320 in the resolve operation so that IMG receivers may check the 321 authenticity of the metadata. This operation may carry any of the IMG 322 data types. 324 3.2.4 IMG SUBSCRIBE 326 If an IMG receiver wants to be notified when the IMG metadata it 327 holds is stale, the IMG receiver can use the IMG SUBSCRIBE operation 328 in advance in order to solicit notify messages from an IMG sender. 329 Since the IMG receiver doesn't know when metadata will be updated and 330 the notify message will arrive, this operation does not synchronize 331 with the notify messages. The IMG receiver may wait for notify 332 messages for a long time. The IMG sender may authenticate the IMG 333 receiver to investigate whether an IMG SUBSCRIBE operation is from an 334 authorized IMG receiver. 336 3.2.5 IMG NOTIFY 338 An IMG NOTIFY is used in response to an earlier IMG SUBSCRIBE. An 339 IMG NOTIFY generates a notify message indicating that updated IMG 340 metadata is available or part of the existing IMG metadata is stale. 341 An IMG NOTIFY may be delivered more than once during the time an IMG 342 SUBSCRIBE is active. This operation may carry any of the IMG data 343 types. The IMG sender may also include authentication data in the IMG 344 NOTIFY operation so that IMG receivers may check the authenticity of 345 the messages. 347 3.2.6 Binding Between IMG Operations and Data Types 349 There is a need to provide a binding between the various IMG 350 operations and IMG data types to allow management of each discrete 351 set of IMG metadata transferred using an IMG operation. This binding 352 must be independent of any particular metadata syntax used to 353 represent a set of IMG metadata, as well as be compatible with any 354 IMG transport protocol. The binding must uniquely identify the set of 355 IMG metadata delivered within an IMG transfer, regardless of the 356 metadata syntax used. The uniqueness may only be needed within the 357 domains the metadata is used but this must enable globally unique 358 identification to support Internet usage. Scope/domain specific 359 identifications should not 'leak' outside of the scope, and always 360 using globally unique identification (e.g. based on URIs) should 361 avoid this error. 363 The binding must provide versioning to the transferred IMG metadata 364 so that changes can be easily handled and stale data identified, and 365 give temporal validity of the transferred IMG metadata. It must 366 expire the IMG metadata by indicating an expiry time, and may 367 optionally provide a time (presumably in the future) from when the 368 IMG metadata becomes valid. Temporal validity of IMG metadata may be 369 changeable for an IMG transfer, and even for specific versions of the 370 IMG transfer. Furthermore, the binding must be independent of the 371 metadata syntax(es) used for the IMG metadata, in the sense that no 372 useful syntax should be excluded. 374 3.3 IMG Entities 376 There are several fundamental IMG entities that indicate the 377 capability to perform certain roles. An Internet host involved in IMG 378 operations may adopt one or more of these roles: 380 IMG Announcer : send IMG ANNOUNCE 382 IMG Listener : receive IMG ANNOUNCE 383 IMG Querier : send IMG QUERY to receive IMG RESOLVE 385 IMG Resolver : receive IMG QUERY then send IMG RESOLVE 387 IMG Subscriber: send IMG SUBSCRIBE then receive IMG NOTIFY 389 IMG Notifier : receive IMG SUBSCRIBE then send IMG NOTIFY 391 Finally, figure 1 shows a relationship between IMG entities and the 392 IMG sender and receiver. 394 +--------------------------------------------------------+ 395 | IMG Sender | 396 +------------------+------------------+------------------+ 397 | IMG Announcer | IMG Notifier | IMG Resolver | 398 +------------------+------------------+------------------+ 399 | ^ ^ 400 message | | | 401 direction v v v 402 +------------------+------------------+------------------+ 403 | IMG Listener | IMG Subscriber | IMG Querier | 404 +------------------+------------------+------------------+ 405 | IMG Receiver | 406 +------------------+------------------+------------------+ 408 Figure 1: Relationship with IMG Entities 410 3.4 Overview of Protocol Operations 412 The figure 2 gives an overview of the relationship between transport 413 cases, IMG Operations and IMG data types (note, it is not a protocol 414 stack). 416 4 Deployment Scenarios for IMG Entities 418 This section provides some basic deployment scenarios for IMG 419 entities that illustrate common threads from protocols to use cases. 420 For the purposes of clarity, this document presents the simple 421 dataflow from an IMG sender to an IMG receiver, as shown in figure 3. 423 +--------------------------------------------------+ 424 IMG | | 425 Data types | Complete Desc., Delta Desc., Pointer | 426 | | 427 +-------------------+----------------+-------------+ 428 IMG | IMG ANNOUNCE | IMG SUBSCRIBE | IMG QUERY | 429 Operations | | IMG NOTIFY | IMG RESOLVE | 430 +--------------+----+----------------+-------------+ 431 IMG | | | 432 Transport | P-to-M | P-to-P | 433 | | | 434 +--------------+-----------------------------------+ 436 Figure 2: IMG Operations and IMG Data type 438 +-------------+ +---------------+ 439 | IMG Sender | | IMG Receiver | 440 | |--------------->| | 441 +-------------+ +---------------+ 443 Figure 3: A Simple IMG Sender to IMG Receiver Relationship 445 4.1 Intermediary Cases 447 Some IMG metadata may be distributed to a large number of IMG 448 receivers. If, for example, some IMG metadata is public information 449 and the IMG sender provides the same information for all IMG 450 receivers. This kind of IMG metadata may be distributed from one IMG 451 sender to multiple IMG receivers (Figure 4) and/or or may be relayed 452 across a set of IMG transceivers that receive the IMG metadata, 453 possibly filter or modify its content, and then forward it. The 454 relayed network architecture is similar to content distribution 455 network architecture [3] (CDNs). Existing CDNs may carry IMG 456 metadata. Satellite and peer-to-peer networks may also carry IMG 457 metadata. 459 +----------+ +----------+ 460 | IMG | | IMG | 461 | Sender |---- ---->| Receiver | 462 +----------+ \ / +----------+ 463 \ / 464 . \ +-----------+ / . 465 . -->|IMG |----- . 466 . -->|Transceiver| \ . 467 / +-----------+ \ 468 +----------+ / \ +----------+ 469 | IMG | / ---->| IMG | 470 | Sender |---- | Receiver | 471 +----------+ +----------+ 473 Figure 4: A Relay Network with an IMG Transceiver 475 IMG senders and receivers are logical functions and it is possible 476 for some or all hosts in a system to perform both roles, as, for 477 instance, in many-to-many communications or where a transceiver is 478 used to combine or aggregate IMG metadata for some IMG receivers. An 479 IMG receiver may be allowed to receive IMG metadata from any number 480 of IMG senders. 482 IMG metadata is used to find, obtain, manage and play content. IMG 483 metadata distributions may be modified as they are distributed. For 484 example, a server may use IMGs to retrieve media content via unicast 485 and then make it available at scheduled times via multicast, thus 486 requiring a change of the corresponding metadata. IMG transceivers 487 may add or delete information or aggregate IMG metadata from 488 different IMG senders. For example, a rating service may add its own 489 content ratings or recommendations to existing meta-data. An 490 implication of changing (or aggregating) IMG metadata from one or 491 more IMG senders is that the original authenticity is lost. Thus for 492 deployments requiring these kind of features, the original metadata 493 should be reasonably fragmented already (allowing the intermediary to 494 replace a small fragment without changing the authenticity of the 495 remainder). It may be beneficial to use smaller fragments for more 496 volatile parts, and larger one for more stable parts. 498 4.2 One-to-many Unidirectional Multicast 500 This case implies many IMG receivers and one or more IMG senders 501 implementing IMG ANNOUNCER and IMG LISTENER operations as shown in 502 figure 5. 504 Unidirectional +----------+ 505 ---------------> | IMG | 506 downlink | Listener | 507 ------------->| 1 | 508 / +----------+ 509 +-----------+ / . 510 | IMG |-------- . 511 | Announcer | \ . 512 +-----------+ \ +----------+ 513 ------------->| IMG | 514 | Listener | 515 | # | 516 +----------+ 518 Figure 5: IMG Unidirectional Multicast Distribution Example 520 4.3 One-to-one Bi-directional Unicast 522 +----------+ +----------+ 523 | IMG |<------(1)------| IMG | 524 | Resolver |-------(2)----->| Querier | 525 +----------+ +----------+ 527 Figure 6: Query/Resolve Deployment Example 529 Both query/resolve (figure 6) and subscribe/notify (figure 7) message 530 exchange operations are feasible. 532 4.4 Combined Operations with Common Metadata 534 As shown in figure 8, a common data model for multiple protocol 535 operations allows a diverse range of IMG senders and receivers to 536 provide consistent and interoperable sets of IMG metadata. 538 +----------+ +------------+ 539 | |<-------(1)--------| | 540 | IMG |--------(2)------->| IMG | 541 | Notifier | (time passes) | Subscriber | 542 | |--------(3)------->| | 543 +----------+ +------------+ 545 Figure 7: Subscribe/Notify Deployment Example 547 IMG Metadata IMG Senders IMG Receivers 549 +--------------+ 550 +-----------+ ---->| IMG Listener | 551 | IMG | / +--------------+ 552 /| Announcer |----- 553 +-------------+ / +-----------+ \ +--------------+ 554 | IMG |-+ / ---->| IMG Listener | 555 | Description | |-+ / | - - - - - - -| 556 | metadata 1 | | | / +-----------+ /--->| IMG Querier | 557 +-------------+ | | -----| IMG |<----/ +--------------+ 558 +-------------+ | \ | Resolver | 559 +-------------+ \ +-----------+<----\ +--------------+ 560 \ \--->| IMG Querier | 561 \ +-----------+ | - - - - - - -| 562 \| IMG |<--------->| IMG | 563 | Notifier | | Subscriber | 564 +-----------+ +--------------+ 566 Figure 8: Combined System with Common Metadata 568 5 Applicability of Existing Protocols to the Proposed Framework Model 570 5.1 Summary of Limitations of Existing Protocols 572 SDP [4] has a text-encoded syntax to specify multimedia sessions for 573 announcements and invitations. Although SDP is extensible, it has 574 limitations such as structured extensibility and capability to 575 reference properties of a multimedia session from the description of 576 another session. 578 These are mostly overcome by the XML-based SDPng [5], which is 579 intended for both two-way negotiation and also unidirectional 580 delivery. Since SDPng addresses multiparty multimedia conferences, it 581 is necessary to extend the XML schema in order to describe general 582 multimedia content. 584 MPEG-7 [6] is a collection of XML-based description tools for general 585 multimedia content including structured multimedia sessions. TV- 586 Anytime Forum [7] provides descriptions based on MPEG-7 for TV 587 specific program guides. These are likely to be limited to describe 588 pictures, music and movies, thus it may be necessary to extend these 589 descriptions in order to define a variety of documents, game 590 programs, binary files, live events and so on. 592 HTTP [8] is a well known information retrieval protocol using bi- 593 directional transport and widely used to deliver web-based content 594 descriptions to many hosts. However, it has well recognized 595 limitations of scalability in the number of HTTP clients since it 596 relies on the polling mechanism to keep information consistent 597 between the server and client. 599 SAP [9] is an announcement protocol that distributes session 600 descriptions via multicast. It does not support fine-grained metadata 601 selection and update notifications, as it always sends the whole 602 metadata. Given the lack of a wide-area multicast infrastructure, it 603 is likely only deployable within a local area network. 605 SIP [10] and SIP-specific event notification [11] can be used to 606 notify subscribers of the update of IMG metadata for bi-directional 607 transport. It is necessary for SIP Event to define an event package 608 for each specific application such as [12]. 610 5.2 Existing Protocol Fit to the IMG Framework Model 612 SDP: The SDP format could be used to describe session-level 613 parameters (e.g. scheduling, addressing and the use of media codecs) 614 to be included in Complete IMG Descriptions. Although there are 615 extension points in SDP allowing the format to be extended, there are 616 limitations in the flexibility of this extension mechanism. However, 617 SDP syntax cannot provide Deleta IMG Descriptions and IMG Pointers 618 without significant unused overhead. Because it is expected that the 619 information conveyed by SDP is just a small subset of IMG metadata 620 the use of SDP for other than session-level IMG parameters may not be 621 reasonable. 623 SDPng: Similar to SDP, this format could also be used for 624 representing session-level parameters of IMG metadata. Compared to 625 SDP, the XML-based format of SDPng is much more flexible with regards 626 to extensions and combining with other description formats. 628 MPEG-7: Descriptions based on the MPEG-7 standard could provide 629 application-specific metadata describing the properties of multimedia 630 content beyond parameters carried in SDP or SDPng descriptions. 631 MPEG-7 provides a machine-readable format of representing content 632 categories and attributes, helping end-users or receiving software in 633 choosing content for reception: this is well in line with the IMG 634 usage scenarios of IMGs introduced in 3.2. Because MPEG-7 is based on 635 XML, it is well suited for combining with other XML-based formats 636 such as SDPng. 638 HTTP: The HTTP protocol can be used as a bi-directional/unicast IMG 639 transport protocol. Being a request-reply oriented protocol, HTTP is 640 well suited for implementing synchronous operations such as QUERY, 641 RESOLVE and even SUBSCRIBE. However, HTTP does not provide 642 asynchronous operations such as ANNOUNCE and NOTIFY and to implement 643 asynchronous operations using HTTP, IMG receivers should poll the IMG 644 sender periodically. So alone, HTTP is not sufficient to fulfill IMG 645 requirements in a unicast deployment. 647 SAP: The announcement mechanism provided by SAP provides 648 unidirectional delivery of session discovery information. Although 649 SDP is the default payload format of SAP, the use of a MIME type 650 identifier for the payload allows arbitrary payload formats to be 651 used in SAP messages. Thus, SAP could be used to implement the 652 (multicast and unicast) IMG ANNOUNCE and IMG NOTIFY operations. 653 However, the limitations of SAP as a generic IMG transport protocol 654 include: 656 - Lack of reliability (through forward error correction / 657 retransmissions) 659 - Lack of payload segmentation 661 - Limited payload size 663 - Only one description allowed per SAP message 665 - Lack of congestion control 667 - Lack of Internet standard authentication / encryption mechanisms 669 - It is an Experimental RFC with no support for progressing further 671 In principle, the current SAP protocol could be extended to get 672 around its limitations (e.g. the use of a multipart MIME type in the 673 SAP payload has been proposed, enabling multiple descriptions to be 674 carried in a single SAP message). However, the amount of changes 675 needed in SAP to address all of the above limitations would 676 effectively result in a new protocol. Due to these limitations, the 677 use of SAP as an IMG transport protocol is not recommended. 679 SIP: The SIP-specific event mechanism described in RFC 3265 [11] 680 provides a way to implement IMG SUBSCRIBE and IMG NOTIFY operations 681 via a bi-directional unicast connection. However, there are 682 scalability problems with this approach, as RFC 3265 currently does 683 not consider multicast. 685 5.3 Outstanding IMG Mechanism Needs 687 Several outstanding needs result from the IMG requirements, framework 688 model and existing relevant mechanisms as already shown in this 689 document. Four specific groupings of work are readily apparent which 690 are: (a) specification of an adequate multicast and unidirectional 691 capable announcement protocol; (b) specification of the use of 692 existing unicast protocols to enable unicast subscribe and 693 announcement/notification functionality; (c) specification of the 694 metadata envelope which is common to, and independent of, the 695 application metadata syntax(es) used; agreement on basic metadata 696 models to enable interoperability testing of the above. The following 697 sections describe each of these. 699 5.3.1 A Multicast Transport Protocol 701 SAP is currently the only open standard protocol suited to the 702 unidirectional/multicast delivery of IMG metadata. As discussed, it 703 fails to meet the IMG requirements in many ways and, since it is not 704 designed to be extensible, we recognize that a new multicast 705 transport protocol for announcements needs to be specified to meet 706 IMG needs. This protocol will be essential to IMG delivery for 707 unidirectional and multicast deployments. 709 The Asynchronous Layered Coding (ALC) [13] protocol from the IETF 710 Reliable Multicast Transport (RMT) working group is very interesting 711 as it fulfils many of the requirements, is extensible and has the 712 ability to `plug-in' both FEC (Forward Error Correction -- for 713 reliability) and CC (Congestion Control) functional blocks -- it is 714 specifically designed for unidirectional multicast object transport. 715 ALC is not fully specified, although RMT has a work-in-progress fully 716 specified protocol using ALC called FLUTE (File Delivery over 717 Unidirectional Transport) [14]. FLUTE seems to be the only fully 718 specified transport and open specification on which a new IMG 719 announcement protocol could be designed. Thus we recommend that ALC 720 and FLUTE be the starting points for this protocol's design. 722 Developing a new protocol from scratch, or attempting to improve SAP, 723 is also feasible, although it would involve repeating many of the 724 design processes and decisions already made by the IETF for ALC. 725 Thus, we recommend only to attempt this if ALC-based protocols are 726 later found to be insufficient. 728 In particular, any announcement protocol must feature sufficient 729 scalability, flexibility and reliability to meet IMG needs. Also, the 730 ANNOUNCE operation must be supported and NOTIFY capability could be 731 investigated for both hybrid unicast-multicast and unidirectional 732 unicast systems. 734 5.3.2 Usage of Unicast Transport Protocols 736 A thorough description of the use of existing unicast protocols is 737 essential for the use of IMGs in a unicast point-to-point 738 environment. Such a specification does not currently exist, although 739 several usable unicast transport protocols and specifications can be 740 harnessed for this (SIP [10], SIP events [11], HTTP [8], etc.) In 741 particular, both SUBSCRIBE-NOTIFY and QUERY-RESOLVE operation pairs 742 must be enabled. We anticipate that the FETCH operation will be a 743 trivial usage of HTTP, although other transport options may be 744 beneficial to consider too. 746 5.3.3 IMG Transfer Envelope 748 Section 3.2.6 of this document discussed the need for binding between 749 IMG Operations and Data Types. Such a binding can be realized by 750 defining a common minimal set of information needed needed to manage 751 IMG metadata transfers, and by including this information with any 752 set of IMG metadata delivered to IMG receiver(s). 754 Four options for IMG transfer envelope delivery are feasible: 756 1. Embedding in a transport protocol header. This can be done 757 with either header extensions of existing protocols, or 758 newly defined header fields of a new (or new version of a) 759 transport protocol. However, multiple methods for the 760 variety of transport protocols may hinder interoperability. 762 2. A separate envelope object (a form of metadata itself) 763 delivered in-band with the metadata. This would complicate 764 delivery as the envelope and `service' metadata objects 765 would have to be bound, e.g. by pairing some kind of 766 transport object numbers (analogous to port number pairs 767 sometimes used for RTP and RTSP). 769 3. A metadata wrapper which points to and/or embeds the 770 service metadata into its `super-syntax'. For example, XML 771 enables referencing (pointing to) other resources as well 772 as embedding generic text objects. 774 4. Embedding in the metadata itself. However, this requires 775 new field in many metadata syntaxes and would not be 776 feasible if a useful syntax were not capable of 777 extensibility in this way. It also introduces a larger 778 'implementation interpretation' variety which would hinder 779 interoperability. Thus this option is not recommended. 781 It is likely that more than one of these options will fulfill the 782 needs of IMGs so the selection, and possibly optimization, is left 783 for subsequent specification and feedback from implementation 784 experience. Such a specification is essential for IMG delivery and so 785 should be an official IETF work item. 787 When there are superset/subset relations between IMG descriptions, it 788 is assumed that the IMG descriptions of the subset inherit the 789 parameters of the superset. Thus, an IMG transfer envelope carrying 790 the IMG descriptions of a superset may implicitly define parameters 791 of IMG descriptors belonging to its subset. The relations between IMG 792 descriptions may span from one IMG transfer envelope to another. 794 5.3.4 Baseline (Meta)Data Model Specification 796 A minimal IMG data model may be useful to any implementer/deployment 797 of IMGs. The purpose would be to ensure that multiple metadata 798 syntaxes (SDP, MPEG-7, etc) can be related within the same body of 799 IMG knowledge, regardless of any specific metadata and data models 800 provided by the metadata syntaxes. 802 Further work may be needed to meet application-specific requirements 803 at defining metadata and data models for the successful deployment of 804 IMGs in various environments. Existing (and future) work on these 805 would need to be mapped to the IMG data types and use of the IMG 806 transfer envelope concept as described above. 808 This document is a framework for the delivery of IMG Metadata and 809 thus further discussion on the definition data models for IMGs is 810 beyond its scope. 812 5.4 IMG Needs Fitting the IETF's Scope 814 A Multicast Transport Protocol is essential to IMG delivery for 815 unidirectional and multicast deployments and no alternative exists 816 which fulfils the IMG requirements. We recommend that the 817 specification of this be taken on as an official work item in the 818 IETF. 820 Specification of the usage of unicast transport protocols is 821 essential for IMG delivery and control involving unicast 822 communications, and will relate to existing IETF standard transport 823 protocols. Thus, we recommend that the specification of this be taken 824 on as an official work item in the IETF. 826 The IMG transfer envelope functionality is essential for the IMG 827 delivery fulfilling the IMG requirements. It is a required feature 828 for IMG metadata transport and maintenance. Thus, we recommend that 829 the IMG transfer envelope specification be taken on as an official 830 work item in the IETF. 832 (Meta)data model specification and application specific metadata do 833 not easily fit into the IETF scope and several other standardization 834 bodies are well placed to do this work. We recommend that aspect 835 shall not be an official IETF work item. 837 Note, we acknowledge the need to exchange and agree on a baseline 838 metadata model and application specific metadata for the purposes of 839 interoperability testing between different implementations of IMG 840 related IETF protocols. However, we feel that the IETF standards 841 process is not required for this. 843 6 Security Considerations 845 The IMG framework is developed from the IMG Requirements document [1] 846 and so the selection of specific protocols and mechanism for use with 847 the IMG framework must also take into account the security 848 considerations of the IMG Requirements document. This framework 849 document does not mandate the use of specific protocols. However, an 850 IMG specification would inherit the security considerations of 851 specific protocols used, although this is outside the scope of this 852 document. 854 Protocol instantiations which are used to provide IMG operations will 855 have very different security considerations depending on their scope 856 and purpose. However, there are several general issues which are 857 valuable to consider and, in some cases, provide technical solutions 858 to deal with. These are described below. 860 Individual and Group Privacy: Customized IMG metadata may reveal 861 information about the habits and preferences of a user and may thus 862 deserve confidentiality protection, even if the original information 863 were public. Snooping and protecting this IMG metadata requires the 864 same actions and measures as for other point-to-point and multicast 865 Internet communications. Naturally, the risk of snooping depends on 866 the amount of individual or group personalization the snooped IMG 867 metadata contains. Further consideration is valuable at both 868 transport and metadata levels. 870 IMG Authenticity: In some cases, the IMG receiver needs to be assured 871 of the origin of IMG metadata or its modification history. This can 872 prevent denial of service or hijacking attempts which give an IMG 873 receiver incorrect information in or about the metadata, thus 874 preventing successful access of the media or directing the IMG 875 receiver to the incorrect media possibly with tasteless material. 876 Action upon detection of unauthorized data insertion is out of scope 877 of this document. 879 IMG Receiver Authorization: Some or all of any IMG sender's metadata 880 may be private or valuable enough to allow access to only certain IMG 881 receivers and thus make it worth authenticating users. Encrypting the 882 data is also a reasonable step, especially where group communications 883 methods results in unavoidable snooping opportunities for 884 unauthorized nodes. Encryption and the required security parameters 885 exchange are outside the scope of this document. 887 Unidirectional Specifics: A difficulty that is faced by 888 unidirectional delivery operations is that many protocols providing 889 application-level security are based on bi-directional 890 communications. The application of these security protocols in case 891 of strictly unidirectional links is not considered in the present 892 document. 894 Malicious Code: Currently, IMGs are not envisaged to deliver 895 executable code at any stage. However, as some IMG transport 896 protocols may be capable of delivering arbitrary files, it is 897 RECOMMENDED that the FLUTE delivery service does not have write 898 access to the system or any other critical areas. 900 Protocol Specific Attacks: It is recommended that developers of any 901 IMG protocol take account of the above risks in addition to any 902 protocol design and deployment environment risks that may be 903 reasonably identified. Currently this framework document does not 904 recommend or mandate the use of any specific protocols, however the 905 deployment of IMGs using specific protocol instantiations will 906 naturally be subject to the security considerations of those 907 protocols. 909 Security Improvement Opportunity: The security properties of one 910 channel and protocol can be improved through the use of another 911 channel and protocol. For example, a secure unicast channel can be 912 used to deliver the keys and initialization vectors for an encryption 913 algorithm used on a multicast channel. The exploitation of this 914 opportunity is specific to the protocols used and is outside the 915 scope of this document. 917 7 Normative References 919 [1] Y. Nomura, "Protocol requirements for Internet media guides," 920 Internet Draft draft-ietf-mmusic-img-req-02, Internet Engineering 921 Task Force, Dec. 2003. Work in progress. 923 [2] S. Bradner, "Key words for use in RFCs to indicate requirement 924 levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. 926 [3] M. Day, B. Cain, G. Tomlinson, and P. Rzewski, "A model for 927 content internetworking (CDI)," RFC 3466, Internet Engineering Task 928 Force, Feb. 2003. 930 [4] M. Handley and V. Jacobson, "SDP: session description protocol," 931 RFC 2327, Internet Engineering Task Force, Apr. 1998. 933 [5] D. Kutscher, J. Ott, and C. Bormann, "Session description and 934 capability negotiation," Internet Draft draft-ietf-mmusic-sdpng-07, 935 Internet Engineering Task Force, Oct. 2003. Work in progress. 937 [6] ISO (International Organization for Standardization), "Overview 938 of the MPEG-7 standard," ISO Standard ISO/IEC JTC1/SC29/WG11 N4509, 939 International Organization for Standardization, Geneva, Switzerland, 940 Dec. 2001. 942 [7] T.-A. Forum, "Metadata specification S-3," TV-Anytime Forum 943 Specification SP003v1.2 Part A, TV, TV-Anytime Forum, June 2002. 945 [8] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, and T. Berners- 946 Lee, "Hypertext transfer protocol -- HTTP/1.1," RFC 2068, Internet 947 Engineering Task Force, Jan. 1997. 949 [9] M. Handley, C. E. Perkins, and E. Whelan, "Session announcement 950 protocol," RFC 2974, Internet Engineering Task Force, Oct. 2000. 952 [10] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J. 953 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session 954 initiation protocol," RFC 3261, Internet Engineering Task Force, June 955 2002. 957 [11] A. B. Roach, "Session initiation protocol (sip)-specific event 958 notification," RFC 3265, Internet Engineering Task Force, June 2002. 960 [13] M. Luby, J. Gemmell, L. Vicisano, L. Rizzo, and J. Crowcroft, 961 "Asynchronous layered coding (ALC) protocol instantiation," RFC 3450, 962 Internet Engineering Task Force, Dec. 2002. 964 8 Informative References 966 [12] J. Rosenberg, "A presence event package for the session 967 initiation protocol (SIP)," internet draft, Internet Engineering Task 968 Force, Jan. 2003. Work in progress. 970 [14] T. Paila, "FLUTE - file delivery over unidirectional transport," 971 Internet Draft draft-ietf-rmt-flute-07, Internet Engineering Task 972 Force, Dec. 2003. Work in progress. 974 9 Acknowledgements 976 The authors would like to thank Joerg Ott, Colin Perkins, Toni Paila 977 and Petri Koskelainen on for their ideas and input to this document. 979 10 Authors' Addresses 981 Yuji Nomura 982 Fujitsu Laboratories Ltd. 983 4-1-1 Kamikodanaka, Nakahara-ku, Kawasaki 211-8588 984 Japan 985 Email: nom@flab.fujitsu.co.jp 987 Rod Walsh 988 Nokia Corporation 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 Corporation 996 Nokia Research Center 997 P.O. Box 100, FIN-33721 Tampere 998 Finland 999 Email: juha-pekka.luoma@nokia.com 1001 Hitoshi Asaeda 1002 INRIA 1003 Project PLANETE 1004 2004, Route des Lucioles, BP93, 1005 06902 Sophia Antipolis, 1006 France 1007 Email: Hitoshi.Asaeda@sophia.inria.fr 1009 Henning Schulzrinne 1010 Dept. of Computer Science 1011 Columbia University 1012 1214 Amsterdam Avenue 1013 New York, NY 10027 1014 USA 1015 Email: schulzrinne@cs.columbia.edu 1017 Full Copyright Statement 1019 Copyright (c) The Internet Society (2003). All Rights Reserved. 1021 This document and translations of it may be copied and furnished to 1022 others, and derivative works that comment on or otherwise explain it 1023 or assist in its implementation may be prepared, copied, published 1024 and distributed, in whole or in part, without restriction of any 1025 kind, provided that the above copyright notice and this paragraph are 1026 included on all such copies and derivative works. However, this 1027 document itself may not be modified in any way, such as by removing 1028 the copyright notice or references to the Internet Society or other 1029 Internet organizations, except as needed for the purpose of 1030 developing Internet standards in which case the procedures for 1031 copyrights defined in the Internet Standards process must be 1032 followed, or as required to translate it into languages other than 1033 English. 1035 The limited permissions granted above are perpetual and will not be 1036 revoked by the Internet Society or its successors or assigns. 1038 This document and the information contained herein is provided on an 1039 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1040 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1041 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1042 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1043 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.