idnits 2.17.1 draft-ietf-mmusic-img-framework-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1032. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1043. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1050. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1056. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 420 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 (June 21, 2004) is 7246 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 2327 (ref. '2') (Obsoleted by RFC 4566) == Outdated reference: A later version (-08) exists of draft-ietf-mmusic-sdpng-07 == Outdated reference: A later version (-08) exists of draft-ietf-mmusic-img-req-07 -- Obsolete informational reference (is this intentional?): RFC 3265 (ref. '6') (Obsoleted by RFC 6665) -- Obsolete informational reference (is this intentional?): RFC 3450 (ref. '7') (Obsoleted by RFC 5775) -- Obsolete informational reference (is this intentional?): RFC 2616 (ref. '10') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 10 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-07.txt 13 June 21, 2004 14 Expires: December 2004 16 A Framework for the Usage of Internet Media Guides 18 STATUS OF THIS MEMO 20 By submitting this Internet-Draft, I certify that any applicable 21 patent or other IPR claims of which I am aware have been disclosed, 22 and any of which I become aware will be disclosed, in accordance 23 with RFC 3668." 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as 28 Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six 31 months and may be updated, replaced, or obsoleted by other 32 documents at any time. It is inappropriate to use Internet-Drafts 33 as reference material or to cite them other than a "work in 34 progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/1id-abstracts.html 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html 42 Abstract 44 This document defines a framework for the delivery of Internet Media 45 Guides (IMGs). An IMG is a structured collection of multimedia 46 session descriptions expressed using SDP, SDPng or some similar 47 session description format. This document describes a generalized 48 model for IMG delivery mechanisms, the use of existing protocols and 49 the need for additional work to create an IMG delivery 50 infrastructure. 52 Table of Contents 54 1 Introduction ........................................ 2 55 2 Terminology ......................................... 3 56 3 IMG Common Framework Model .......................... 5 57 3.1 IMG Data Types ...................................... 5 58 3.1.1 Complete IMG Description ............................ 5 59 3.1.2 Delta IMG Description ............................... 6 60 3.1.3 IMG Pointer ......................................... 6 61 3.2 Operation Set for IMG Delivery ...................... 6 62 3.2.1 IMG ANNOUNCE ........................................ 6 63 3.2.2 IMG QUERY ........................................... 7 64 3.2.3 IMG RESOLVE ......................................... 7 65 3.2.4 IMG SUBSCRIBE ....................................... 7 66 3.2.5 IMG NOTIFY .......................................... 8 67 3.2.6 Binding Between IMG Operations and Data Types ....... 8 68 3.3 IMG Entities ........................................ 9 69 3.4 Overview of Protocol Operations ..................... 10 70 4 Deployment Scenarios for IMG Entities ............... 10 71 4.1 Intermediary Cases .................................. 11 72 4.2 One-to-many Unidirectional Multicast ................ 12 73 4.3 One-to-one Bi-directional Unicast ................... 13 74 4.4 Combined Operations with Common Metadata ............ 14 75 5 Applicability of Existing Protocols to the 76 Proposed Framework Model ............................ 14 77 5.1 Existing Standard Fit to the IMG Framework Model .... 14 78 5.2 Outstanding IMG Mechanism Needs ..................... 16 79 5.2.1 A Multicast Transport Protocol ...................... 16 80 5.2.2 Usage of Unicast Transport Protocols ................ 17 81 5.2.3 IMG Envelope ........................................ 17 82 5.2.4 Baseline (Meta)Data Model Specification ............. 18 83 5.3 IMG Needs Fitting the IETF's Scope .................. 19 84 6 Security Considerations ............................. 19 85 7 IANA Considerations ................................. 21 86 8 Normative References ................................ 21 87 9 Informative References .............................. 21 88 10 Acknowledgements .................................... 22 89 11 Authors' Addresses .................................. 22 90 12 Full Copyright Statement ............................ 23 92 1 Introduction 94 Internet Media Guides (IMGs) provide and deliver structured 95 collections of multimedia descriptions expressed using SDP [2], 96 SDPng [3] or other description formats. They are used to describe 97 sets of multimedia services (e.g. television program schedules, 98 content delivery schedules) and refer to other networked 99 resources including web pages. IMGs provide an envelope for metadata 100 formats and session descriptions defined elsewhere with the aim of 101 facilitating structuring, versioning, referencing, distributing, and 102 maintaining (caching, updating) such information. 104 IMG metadata may be delivered to a potentially large audience, who 105 use it to join a subset of the sessions described, and who may need 106 to be notified of changes to the IMG metadata. Hence, a framework for 107 distributing IMG metadata in various different ways is needed to 108 accommodate the needs of different audiences: For traditional 109 broadcast-style scenarios, multicast-based (push) distribution of IMG 110 metadata needs to be supported. Where no multicast is available, 111 unicast-based push is required too. 113 This document defines a common framework model for IMG delivery 114 mechanisms and their deployment in network entities. There are 115 three fundamental components in IMG framework model: data types, 116 operation sets and entities. These components specify a set of 117 framework guidelines for efficient delivery and description of IMG 118 metadata. The data types give generalized means to deliver and 119 manage the consistency of application-specific IMG metadata. IMG 120 operations cover traditional broadcast-style scenarios, 121 multicast-based distributions, unicast-based push and interactive 122 retrievals similar to web pages. Since we envision that any 123 Internet host can be a sender and receiver of IMG metadata, a host 124 involved in IMG operations performs one or more of the roles 125 defined as the entities in IMG framework model. These are then 126 shown in a number of simplified deployment scenarios. The 127 requirements for IMG delivery mechanisms and descriptions can be 128 found in the IMG requirements document [4]. 130 Then, this document outlines the use of existing protocols to create 131 an IMG delivery infrastructure. It aims to organize existing 132 protocols into a common model and show their capabilities and 133 limitations from the viewpoint of IMG delivery functions. One of the 134 multicast-enabling IMG requirements is scaling well to a large number 135 of hosts and IMG senders in a network. Another issue is the need for 136 flexibility and diversity in delivery methods, whereas existing 137 protocols tend to be bound to a specific application. 139 2 Terminology 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in RFC 2119 [1]. 145 Internet Media Guide (IMG): IMG is a generic term to describe 146 the formation, delivery and use of IMG metadata. The 147 definition of the IMG is intentionally left imprecise. [4] 149 IMG Element: The smallest atomic element of metadata that can be 150 transmitted separately by IMG operations and referenced 151 individually from other IMG elements. [4] 153 IMG Metadata: A set of metadata consisting of one or more IMG 154 elements. IMG metadata describes the features of multimedia 155 content used to enable selection of and access to media 156 sessions containing content. For example, metadata may 157 consist of the URI, title, airtime, bandwidth needed, file 158 size, text summary, genre and access restrictions. [4] 160 IMG Description: A collection of IMG metadata which has a 161 relationship to other IMG metadata. There are three data 162 types to describe the relationship: Complete IMG 163 Descriptions, Delta IMG Description and IMG pointer. 165 IMG Delivery: The process of exchanging IMG metadata both in 166 terms of large scale and atomic data transfers. [4] 168 IMG Sender: An IMG sender is a logical entity that sends IMG 169 metadata to one or more IMG receivers. [4] 171 IMG Receiver: An IMG receiver is a logical entity that receives 172 IMG metadata from an IMG sender. [4] 174 IMG Transceiver: An IMG transceiver combines an IMG receiver and 175 sender. It may modify received IMG metadata or merge IMG 176 metadata received from a several different IMG senders. [4] 178 IMG Operation: An atomic operation of an IMG transport protocol, 179 used between IMG sender(s) and IMG receiver(s) for the 180 delivery of IMG metadata and for the control of IMG 181 sender(s)/receiver(s). [4] 183 IMG Transport Protocol: A protocol that transports IMG metadata 184 from an IMG sender to IMG receiver(s). [4] 186 IMG Transport Session: An association between an IMG sender and 187 one or more IMG receivers within the scope of an IMG 188 transport protocol. An IMG transport session involves a 189 time bound series of IMG transport protocol interactions 190 that provide delivery of IMG metadata from the IMG sender 191 to the IMG receiver(s). [4] 193 IMG Transfer: A transfer of IMG metadata consisting of Complete 194 IMG Descriptions, Delta IMG Descriptions and/or IMG 195 Pointers. 197 3 IMG Common Framework Model 199 Two common elements are found in all of existing IMG candidate cases: 200 the need to describe the services; the need to deliver the 201 descriptions. In some cases, the descriptions are multicast enablers 202 (such as the session parameters of SDP) and are thus intrinsically 203 part of the delivery aspects, and in other cases descriptions are 204 application-specific (both machine and human readable). Thus, the 205 technologies can be roughly divided into three areas: 207 o Application-specific Metadata -- data describing the services' 208 content and media which are both specific to certain 209 applications and generally human readable. 211 o Delivery Descriptions -- the descriptions (metadata) that are 212 essential to enable (e.g. multicast) delivery. These include 213 framing (headers) for application-specific metadata, the 214 metadata element identification and structure, and fundamental 215 session data. 217 o Delivery Protocols -- the methods and protocols to exchange 218 descriptions between the senders and the receivers. An IMG 219 transport protocol consists of two functions: carrying IMG 220 metadata from an IMG sender to an IMG receiver and controlling 221 an IMG transport protocol. These functions are not always 222 exclusive, therefore some messages may combine control 223 messages and metadata carriage functions to reduce the amount 224 of the messaging. 226 3.1 IMG Data Types 228 A data model is needed to precisely define the terminology and 229 relationships between sets, supersets and subsets of metadata. A 230 precise data model is essential for the implementation of IMGs 231 although it is not within the scope of this framework and requires a 232 separate specification. However there are three IMG data types in 233 general: Complete IMG Descriptions, Delta IMG Descriptions and IMG 234 Pointers. 236 3.1.1 Complete IMG Description 238 A Complete IMG Description provides a complete syntax and semantics 239 to describe a set of metadata, which does not need any additional 240 information from any other IMG element. 242 Note, this is not to be confused with "complete IMG metadata", which, 243 although vaguely defined here, represents the complete IMG metadata 244 database of an IMG sender (or related group of IMG senders -- 245 potentially the complete Internet IMG knowledge). An IMG sender will 246 generally deliver only subsets of metadata from its complete database 247 in a particular IMG transport session. 249 3.1.2 Delta IMG Description 251 A Delta IMG Description provides only part of a Complete IMG 252 Description, defining the difference from a previous version of the 253 Complete IMG Description in question. Delta transfers may be used to 254 reduce network resource usage (it may be more bandwidth and 255 congestion friendly), for instance when data consistency is essential 256 and small and frequent changes occur to IMG elements. Thus, this 257 description itself cannot represent a complete metadata set until it 258 is combined with existing, or future, description knowledge. 260 3.1.3 IMG Pointer 262 An IMG Pointer provides a simple identifier or locator, such as a 263 URI, that the IMG receiver is able to reference (or reference and 264 locate) specific metadata with. This may be used to separately obtain 265 metadata (Complete or Delta IMG Descriptions) or perform another IMG 266 management function such as data expiry (and erasure). The IMG 267 Pointer may be used to reference IMG metadata elements within the IMG 268 transport session and across IMG transport sessions. This pointer 269 type does not include IMG metadata per se (although it may also 270 appear as a data field in Complete or Delta IMG descriptors). 272 3.2 Operation Set for IMG Delivery 274 A finite set of operations both meets the IMG requirements [4] and 275 fits the roles of existing protocols. These are crystallized in the 276 next few sections. 278 3.2.1 IMG ANNOUNCE 280 When an IMG receiver participates in unidirectional communications 281 (e.g. over satellite, terrestrial radio and wired multicast networks) 282 an IMG receiver may not need to send any IMG message to an IMG sender 283 prior to IMG metadata delivery. In this case, an IMG sender can 284 initiate unsolicited distribution for IMG metadata and an IMG sender 285 is the only entity which can maintain the distribution (this includes 286 scenarios with multiple and co-operative IMG senders). This operation 287 is useful when there are considerably large numbers of IMG receivers 288 or the IMG receiver(s) do not have a guaranteed uplink connection to 289 the IMG sender(s). The IMG sender may also include authentication 290 data in the announce operation so that IMG receivers may check the 291 authenticity of the metadata. This operation is able to carry any of 292 the IMG data types. 294 Note, there is no restriction to prevent IMG ANNOUNCE from being used 295 in an asynchronous solicited manner, where a separate operation 296 (possibly out of band) enables IMG receivers to subscribe/register to 297 the IMG ANNOUNCE operation. 299 3.2.2 IMG QUERY 301 If an IMG receiver needs to obtain IMG metadata, an IMG receiver can 302 use an IMG QUERY operation and initiate a receiver-driven IMG 303 transport session. The IMG receiver expects a synchronous response to 304 the subsequent request from the IMG sender. This operation can be 305 used where a bi-directional transport network is available between 306 the IMG sender and receiver. Some IMG receivers may want to obtain 307 IMG metadata when a resource is available or just to avoid caching 308 unsolicited IMG metadata. The IMG receiver must indicate the extent 309 and data type of metadata wanted in some message in the operation 310 (extent indicates the number and grouping of metadata descriptions). 311 In some cases requesting an IMG sender's complete IMG metadata may be 312 feasible, in others it may not. 314 3.2.3 IMG RESOLVE 316 An IMG sender synchronously responds, and sends IMG metadata, to an 317 IMG QUERY which has been sent by an IMG receiver. This operation 318 can be used where a bi-directional transport network is available 319 between the IMG sender and receiver. If the IMG QUERY specifies a 320 subset of IMG metadata (extent and data type) that is available to 321 the IMG sender, the IMG sender can resolve the query; otherwise, it 322 should indicate that it is not able to resolve the query. The IMG 323 sender may authenticate the IMG receiver to investigate the IMG 324 QUERY operation in order to determine whether the IMG receiver is 325 authorized to be sent that metadata. The sender may also include 326 authentication data in the resolve operation so that IMG receivers 327 may check the authenticity of the metadata. This operation may 328 carry any of the IMG data types. 330 3.2.4 IMG SUBSCRIBE 332 If an IMG receiver wants to be notified when the IMG metadata it 333 holds is stale, the IMG receiver can use the IMG SUBSCRIBE operation 334 in advance in order to solicit notify messages from an IMG sender. 336 This operation may provide the IMG sender with specific details of 337 which metadata or notification services it is interested in (in the 338 case where the IMG sender offers more than the simplest "all data" 339 service). This operation implicitly provides the functionality of 340 unsubscribing to inform an IMG sender that an IMG receiver wishes 341 to stop getting certain (or all) notifications. It should be noted 342 that unsubscription may be provided implicitly by the expiry 343 (timeout) of a subscription before it is renewed. However, these 344 details belong to a messaging protocol instantiation of this 345 operation are beyond the scope of this document. 347 Since the IMG receiver does not know when metadata will be updated 348 and the notify message will arrive, this operation does not 349 synchronize with the notify messages. The IMG receiver may wait for 350 notify messages for a long time. The IMG sender may authenticate the 351 IMG receiver to investigate whether an IMG SUBSCRIBE operation is 352 from an authorized IMG receiver. 354 3.2.5 IMG NOTIFY 356 An IMG NOTIFY is used asynchronously in response to an earlier IMG 357 SUBSCRIBE. An IMG NOTIFY operation generates a notify message 358 indicating that updated IMG metadata is available or part of the 359 existing IMG metadata is stale. An IMG NOTIFY may be delivered more 360 than once during the time an IMG SUBSCRIBE is active. This operation 361 may carry any of the IMG data types. The IMG sender may also include 362 authentication data in the IMG NOTIFY operation so that IMG receivers 363 may check the authenticity of the messages. 365 3.2.6 Binding Between IMG Operations and Data Types 367 There is a need to provide a binding between the various IMG 368 operations and IMG data types to allow management of each discrete 369 set of IMG metadata transferred using an IMG operation. This binding 370 must be independent of any particular metadata syntax used to 371 represent a set of IMG metadata, as well as be compatible with any 372 IMG transport protocol. The binding must uniquely identify the set of 373 IMG metadata delivered within an IMG transfer, regardless of the 374 metadata syntax used. The uniqueness may only be needed within the 375 domains the metadata is used but this must enable globally unique 376 identification to support Internet usage. Scope/domain specific 377 identifications should not 'leak' outside of the scope, and always 378 using globally unique identification (e.g. based on URIs) should 379 avoid this error. 381 The binding must provide versioning to the transferred IMG metadata 382 so that changes can be easily handled and stale data identified, and 383 give temporal validity of the transferred IMG metadata. It must 384 expire the IMG metadata by indicating an expiry time, and may 385 optionally provide a time (presumably in the future) from when the 386 IMG metadata becomes valid. Temporal validity of IMG metadata may be 387 changeable for an IMG transfer, and even for specific versions of the 388 IMG transfer. Furthermore, the binding must be independent of the 389 metadata syntax(es) used for the IMG metadata, in the sense that no 390 useful syntax should be excluded. 392 3.3 IMG Entities 394 There are several fundamental IMG entities that indicate the 395 capability to perform certain roles. An Internet host involved in IMG 396 operations may adopt one or more of these roles: 398 IMG Announcer: send IMG ANNOUNCE 400 IMG Listener: receive IMG ANNOUNCE 402 IMG Querier: send IMG QUERY to receive IMG RESOLVE 404 IMG Resolver: receive IMG QUERY then send IMG RESOLVE 406 IMG Subscriber: send IMG SUBSCRIBE then receive IMG NOTIFY 408 IMG Notifier: receive IMG SUBSCRIBE then send IMG NOTIFY 410 Figure 1 shows the relationship between IMG entities and the IMG 411 sender and receiver. 413 +--------------------------------------------------------+ 414 | IMG Sender | 415 +------------------+------------------+------------------+ 416 | IMG Announcer | IMG Notifier | IMG Resolver | 417 +------------------+------------------+------------------+ 418 | ^ ^ 419 message | | | 420 direction v v v 421 +------------------+------------------+------------------+ 422 | IMG Listener | IMG Subscriber | IMG Querier | 423 +------------------+------------------+------------------+ 424 | IMG Receiver | 425 +------------------+------------------+------------------+ 427 Figure 1: Relationship between IMG Entities, Senders and Receivers 429 3.4 Overview of Protocol Operations 431 Figure 2 gives an overview of the relationship between transport 432 cases, IMG Operations and IMG data types (note, it is not a protocol 433 stack). Generalized multicast point-to-multipoint (P-to-M) and 434 unicast point-to-point (P-to-P) transports are shown. 436 +--------------------------------------------------+ 437 IMG | | 438 Data types | Complete Desc., Delta Desc., Pointer | 439 | | 440 +-------------------+----------------+-------------+ 441 IMG | IMG ANNOUNCE | IMG SUBSCRIBE | IMG QUERY | 442 Operations | | IMG NOTIFY | IMG RESOLVE | 443 +--------------+----+----------------+-------------+ 444 IMG | | | 445 Transport | P-to-M | P-to-P | 446 | | | 447 +--------------+-----------------------------------+ 449 Figure 2: IMG Transport, IMG Operations and IMG Data types 451 4 Deployment Scenarios for IMG Entities 453 This section provides some basic deployment scenarios for IMG 454 entities that illustrate common threads from protocols to use cases. 455 For the purposes of clarity, this document presents the simple 456 dataflow from an IMG sender to an IMG receiver, as shown in Figure 3. 458 +-------------+ +---------------+ 459 | IMG Sender | | IMG Receiver | 460 | |--------------->| | 461 +-------------+ +---------------+ 463 Figure 3: A Simple IMG Sender to IMG Receiver Relationship 465 4.1 Intermediary Cases 467 Some IMG metadata may be distributed to a large number of IMG 468 receivers. If, for example, some IMG metadata is public information 469 and the IMG sender provides the same information for all IMG 470 receivers. This kind of IMG metadata may be distributed from one IMG 471 sender to multiple IMG receivers (Figure 4) and/or or may be relayed 472 across a set of IMG transceivers that receive the IMG metadata, 473 possibly filter or modify its content, and then forward it. 475 +----------+ +----------+ 476 | IMG | | IMG | 477 | Sender |---- ---->| Receiver | 478 +----------+ \ / +----------+ 479 \ / 480 . \ +-----------+ / . 481 . -->|IMG |----- . 482 . -->|Transceiver| \ . 483 / +-----------+ \ 484 +----------+ / \ +----------+ 485 | IMG | / ---->| IMG | 486 | Sender |---- | Receiver | 487 +----------+ +----------+ 489 Figure 4: A Relay Network with an IMG Transceiver 491 IMG senders and receivers are logical functions and it is possible 492 for some or all hosts in a system to perform both roles, as, for 493 instance, in many-to-many communications or where a transceiver is 494 used to combine or aggregate IMG metadata for some IMG receivers. An 495 IMG receiver may be allowed to receive IMG metadata from any number 496 of IMG senders. 498 IMG metadata is used to find, obtain, manage and play content. IMG 499 metadata distributions may be modified as they are distributed. For 500 example, a server may use IMGs to retrieve media content via unicast 501 and then make it available at scheduled times via multicast, thus 502 requiring a change of the corresponding metadata. IMG transceivers 503 may add or delete information or aggregate IMG metadata from 504 different IMG senders. For example, a rating service may add its own 505 content ratings or recommendations to existing metadata. An 506 implication of changing (or aggregating) IMG metadata from one or 507 more IMG senders is that the original authenticity is lost. Thus for 508 deployments requiring these kind of features, the original metadata 509 should be reasonably fragmented already (allowing the intermediary to 510 replace a small fragment without changing the authenticity of the 511 remainder). It may be beneficial to use smaller fragments for more 512 volatile parts, and larger ones for more stable parts. 514 4.2 One-to-many Unidirectional Multicast 516 This case implies many IMG receivers and one or more IMG senders 517 implementing IMG ANNOUNCER and IMG LISTENER operations as shown in 518 Figure 5. 520 Unidirectional +----------+ 521 ---------------> | IMG | 522 downlink | Listener | 523 ------------->| 1 | 524 / +----------+ 525 +-----------+ / . 526 | IMG |-------- . 527 | Announcer | \ . 528 +-----------+ \ +----------+ 529 ------------->| IMG | 530 | Listener | 531 | # | 532 +----------+ 534 Figure 5: IMG Unidirectional Multicast Distribution Example 536 4.3 One-to-one Bi-directional Unicast 538 Both query/resolve (Figure 6) and subscribe/notify (Figure 7) message 539 exchange operations are feasible. The "time passes" activities of 540 Figure 7 are purely for example. 542 +----------+ +----------+ 543 | IMG | | IMG | 544 | Resolver | | Querier | 545 +----------+ +----------+ 546 | | 547 |<----------IMG QUERY -----------| 548 | | 549 |----------IMG RESOLVE---------->| 550 | | 552 Figure 6: Query/Resolve Sequence Example 554 +----------+ +------------+ 555 | IMG | | IMG | 556 | Notifier | | Subscriber | 557 +----------+ +------------+ 558 | | 559 |<---------IMG SUBSCRIBE---------| 560 : : 561 (time passes) 562 : : 563 |-----------IMG NOTIFY---------->| 564 : : 565 (time passes) 566 : : 567 |-----------IMG NOTIFY---------->| 568 | | 570 Figure 7: Subscribe/Notify Sequence Example 572 4.4 Combined Operations with Common Metadata 574 As shown in Figure 8, a common data model for multiple protocol 575 operations allows a diverse range of IMG senders and receivers to 576 provide consistent and interoperable sets of IMG metadata. 578 IMG Metadata IMG Senders IMG Receivers 580 +--------------+ 581 +-----------+ ---->| IMG Listener | 582 | IMG | / +--------------+ 583 /| Announcer |----- 584 +-------------+ / +-----------+ \ +--------------+ 585 | IMG |-+ / ---->| IMG Listener | 586 | description | |-+ / | - - - - - - -| 587 | metadata 1 | | | / +-----------+ /--->| IMG Querier | 588 +-------------+ | | -----| IMG |<----/ +--------------+ 589 +-------------+ | \ | Resolver | 590 +-------------+ \ +-----------+<----\ +--------------+ 591 \ \--->| IMG Querier | 592 \ +-----------+ | - - - - - - -| 593 \| IMG |<--------->| IMG | 594 | Notifier | | Subscriber | 595 +-----------+ +--------------+ 597 Figure 8: Combined System with Common Metadata 599 5 Applicability of Existing Protocols to the Proposed Framework Model 601 5.1 Existing Standard Fit to the IMG Framework Model 603 SDP: The SDP format could be used to describe session-level 604 parameters (e.g. scheduling, addressing and the use of media codecs) 605 to be included in Complete IMG Descriptions. Although there are 606 extension points in SDP allowing the format to be extended, there are 607 limitations in the flexibility of this extension mechanism. However, 608 SDP syntax cannot provide IMG Descriptions and IMG Pointers without 609 significant unused overhead. It is expected that the information 610 conveyed by SDP is just a small subset of IMG metadata, thus the use 611 of SDP for other than session parameters may not be reasonable. 613 SDPng: Similar to SDP, this format could also be used for 614 representing session-level parameters of IMG metadata. Compared to 615 SDP, the XML-based format of SDPng should be much more flexible with 616 regards to extensions and combining with other description formats. 618 MPEG-7: Descriptions based on the MPEG-7 standard could provide 619 application-specific metadata describing the properties of multimedia 620 content beyond parameters carried in SDP or SDPng descriptions. 621 MPEG-7 provides a machine-readable format of representing content 622 categories and attributes, helping end-users or receiving software in 623 choosing content for reception: this is well in line with the IMG 624 usage scenarios of IMGs introduced in 3.2. MPEG-7 is based on XML so 625 it is well suited for combining with other XML-based formats such as 626 SDPng. 628 TV-Anytime Forum: The TV-Anytime Forum [5] provides descriptions 629 based on XML schema for TV-specific program guides. TV-Anytime uses 630 the MPEG-7 User description profile to a limited extent (for user 631 preferences and usage history) and also a TV-Anytime-specific data 632 model for other schema - which are optimised to describe broadcast 633 schedules, on-demand program guides and program events. 635 HTTP: The HTTP protocol can be used as a bi-directional/unicast IMG 636 transport protocol. Being a request-reply oriented protocol, HTTP is 637 well suited for implementing synchronous operations such as QUERY, 638 RESOLVE and even SUBSCRIBE. However, HTTP does not provide 639 asynchronous operations such as ANNOUNCE and NOTIFY and to implement 640 asynchronous operations using HTTP, IMG receivers should poll the IMG 641 sender periodically. So alone, HTTP is not sufficient to fulfill IMG 642 requirements in a unicast deployment. 644 SAP: The announcement mechanism provided by SAP provides 645 unidirectional delivery of session discovery information. Although 646 SDP is the default payload format of SAP, the use of a MIME type 647 identifier for the payload allows arbitrary payload formats to be 648 used in SAP messages. Thus, SAP could be used to implement the 649 (multicast and unicast) IMG ANNOUNCE and IMG NOTIFY operations. 650 However, the limitations of SAP as a generic IMG transport protocol 651 include: 653 - Lack of reliability (through forward error correction / 654 retransmissions) 656 - Lack of payload segmentation 658 - Limited payload size 660 - Only one description allowed per SAP message 661 - Lack of congestion control 663 - Lack of Internet standard authentication / encryption mechanisms 665 - It is an Experimental RFC with no support for progressing further 667 In principle, the current SAP protocol could be extended to get 668 around its limitations (e.g. the use of a multipart MIME type in the 669 SAP payload enabling multiple descriptions to be carried in a single 670 SAP message). However, the amount of changes needed in SAP to address 671 all of the above limitations would effectively result in a new 672 protocol. Due to these limitations, the use of SAP as an IMG 673 transport protocol is not recommended. 675 SIP: The SIP-specific event mechanism described in RFC 3265 [6] 676 provides a way to implement IMG SUBSCRIBE and IMG NOTIFY operations 677 via a bi-directional unicast connection. However, there are 678 scalability problems with this approach, as RFC 3265 currently does 679 not consider multicast. 681 RTSP: The RTSP protocol defines a retrieval and update notification 682 mechanism, named DESCRIBE and ANNOUNCE, for the description of a 683 presentation or media object in order to initialize a streaming 684 session. These methods are subset of the entire streaming control 685 operations in RTSP, thus these could not be available for individual 686 mechanisms. However, the DESCRIBE method in RTSP could be use to 687 instantiate IMG QUERY, IMG RESOLVE and IMG SUBSCRIBE, and the RTSP 688 ANNOUNCE could be use to instantiate an IMG NOTIFY for a streaming 689 session controlled by RTSP. 691 5.2 Outstanding IMG Mechanism Needs 693 Several outstanding needs result from the IMG requirements, framework 694 model and existing relevant mechanisms as already shown in this 695 document. Four specific groupings of work are readily apparent which 696 are: (a) specification of an adequate multicast and unidirectional 697 capable announcement protocol; (b) specification of the use of 698 existing unicast protocols to enable unicast subscribe and 699 announcement/notification functionality; (c) specification of the 700 metadata envelope which is common to, and independent of, the 701 application metadata syntax(es) used; (d) agreement on basic metadata 702 models to enable interoperability testing of the above. The following 703 sections describe each of these. 705 5.2.1 A Multicast Transport Protocol 707 SAP is currently the only open standard protocol suited to the 708 unidirectional/multicast delivery of IMG metadata. As discussed, it 709 fails to meet the IMG requirements in many ways and, since it is not 710 designed to be extensible, we recognize that a new multicast 711 transport protocol for announcements needs to be specified to meet 712 IMG needs. This protocol will be essential to IMG delivery for 713 unidirectional and multicast deployments. 715 The Asynchronous Layered Coding (ALC) [7] protocol from the IETF 716 Reliable Multicast Transport (RMT) working group is very interesting 717 as it fulfils many of the requirements, is extensible and has the 718 ability to 'plug-in' both FEC (Forward Error Correction -- for 719 reliability) and CC (Congestion Control) functional blocks -- it is 720 specifically designed for unidirectional multicast object transport. 721 ALC is not fully specified, although RMT has a fully specified 722 protocol using ALC called FLUTE (File Delivery over Unidirectional 723 Transport) [8]. FLUTE seems to be the only fully specified transport 724 and open specification on which a new IMG announcement protocol could 725 be designed. Thus we recommend that ALC and FLUTE be the starting 726 points for this protocol's design. 728 Developing a new protocol from scratch, or attempting to improve SAP, 729 is also feasible, although it would involve repeating many of the 730 design processes and decisions already made by the IETF for ALC. 731 Thus, we recommend only to attempt this if ALC-based protocols are 732 later found to be insufficient. 734 In particular, any announcement protocol must feature sufficient 735 scalability, flexibility and reliability to meet IMG needs. Also, the 736 IMG ANNOUNCE operation must be supported and IMG NOTIFY capability 737 could be investigated for both hybrid unicast-multicast and 738 unidirectional unicast systems. 740 5.2.2 Usage of Unicast Transport Protocols 742 A thorough description of the use of existing unicast protocols is 743 essential for the use of IMGs in a unicast point-to-point 744 environment. Such a specification does not currently exist, although 745 several usable unicast transport protocols and specifications can be 746 harnessed for this (SIP [9], SIP events [6], HTTP [10], etc.) In 747 particular, both IMG SUBSCRIBE-NOTIFY and IMG QUERY-RESOLVE operation 748 pairs must be enabled. We anticipate that the IMG QUERY-RESOLVE 749 operation will be a trivial usage of HTTP, although other transport 750 protocol options may be beneficial to consider too. 752 5.2.3 IMG Envelope 754 Section 3.2.6 of this document discussed the need for binding between 755 IMG Operations and Data Types. Such a binding can be realized by 756 defining a common minimal set of information needed to manage IMG 757 metadata transfers, and by including this information with any set of 758 IMG metadata delivered to IMG receiver(s). 760 Four options for IMG metadata transfer envelope delivery are 761 feasible: 763 1. Embedding in a transport protocol header. This can be done 764 with either header extensions of existing protocols, or 765 newly defined header fields of a new (or new version of a) 766 transport protocol. However, multiple methods for the 767 variety of transport protocols would hinder 768 interoperability and transport protocol independence. 770 2. A separate envelope object, which points to the IMG 771 metadata 'object', delivered in-band with the metadata 772 transport protocol session. This might complicate 773 delivery as the envelope and 'service' metadata objects 774 would have to be bound, e.g. by pairing some kind of 775 transport object numbers (analogous to port number pairs 776 sometimes used for RTP and RTCP [11]). This would also 777 enable schemes which deliver enveope and metadata 778 'objects' on by different media, also using more than a 779 single transport protocol. 781 3. A metadata wrapper which points to and/or embeds the 782 service metadata into its 'super-syntax'. For example, an 783 XML would enable embedding generic text objects. 785 4. Embedding in the metadata itself. However, this requires 786 new field in many metadata syntaxes and would not be 787 feasible if a useful syntax were not capable of 788 extensibility in this way. It also introduces a larger 789 'implementation interpretation' variety which would hinder 790 interoperability. Thus this option is not recommended. 792 It is likely that more than one of these options will fulfill the 793 needs of IMGs so the selection, and possibly optimization, is left 794 for subsequent specification and feedback from implementation 795 experience. Such a specification is essential for IMG delivery. 797 When there are superset/subset relations between IMG descriptions, 798 it is assumed that the IMG descriptions of the subset inherit the 799 parameters of the superset. Thus, an IMG metadata transfer envelope 800 carrying the IMG descriptions of a superset may implicitly define 801 parameters of IMG descriptors belonging to its subset. The 802 relations between IMG descriptions may span from one envelope to 803 another according to a data model definition. 805 5.2.4 Baseline (Meta)Data Model Specification 806 A minimal IMG data model may be useful to any implementer/deployment 807 of IMGs. The purpose would be to ensure that multiple metadata 808 syntaxes (SDP, MPEG-7, etc.) can be related within the same body of 809 IMG knowledge, regardless of any specific metadata and data models 810 provided by the metadata syntaxes. 812 Further work may be needed to meet application-specific requirements 813 at defining metadata and data models for the successful deployment of 814 IMGs in various environments. Existing (and future) work on these 815 would need to be mapped to the IMG data types and use of the IMG 816 transfer envelope concept as described above. 818 This document is a framework for the delivery of IMG metadata and 819 thus further discussion on the definition data models for IMGs is 820 beyond its scope. 822 5.3 IMG Needs Fitting the IETF's Scope 824 A multicast transport protocol is essential to IMG delivery for 825 unidirectional and multicast deployments and no alternative exists 826 which fulfils the IMG requirements. We recommend that the 827 specification of this be taken on as an official work item in the 828 IETF. 830 Specification of the usage of unicast transport protocols is 831 essential for IMG delivery and control involving unicast 832 communications, and will relate to existing IETF standard transport 833 protocols. Thus, we recommend that the specification of this be taken 834 on as an official work item in the IETF. 836 The IMG metadata transfer envelope functionality is essential for the 837 IMG delivery fulfilling the IMG requirements. It is a required 838 feature for IMG metadata transport and maintenance. Thus, we 839 recommend that the IMG transfer envelope specification be taken on as 840 an official work item in the IETF. 842 (Meta)data model specification and application specific metadata do 843 not easily fit into the IETF scope and several other standardization 844 bodies are well placed to do this work. This aspect need not be an 845 official IETF work item. 847 Note, we acknowledge the need to exchange and agree on a baseline 848 metadata model and application specific metadata for the purposes of 849 interoperability testing between different implementations of IMG 850 related IETF protocols. However, we feel that the IETF standards 851 process may not be required for this. 853 6 Security Considerations 854 The IMG framework is developed from the IMG requirements document [4] 855 and so the selection of specific protocols and mechanism for use with 856 the IMG framework must also take into account the security 857 considerations of the IMG requirements document. This framework 858 document does not mandate the use of specific protocols. However, an 859 IMG specification would inherit the security considerations of 860 specific protocols used, although this is outside the scope of this 861 document. 863 Protocol instantiations which are used to provide IMG operations will 864 have very different security considerations depending on their scope 865 and purpose. However, there are several general issues which are 866 valuable to consider and, in some cases, provide technical solutions 867 to deal with. These are described below. 869 Individual and Group Privacy: Customized IMG metadata may reveal 870 information about the habits and preferences of a user and may thus 871 deserve confidentiality protection, even if the original information 872 were public. Snooping and protecting this IMG metadata requires the 873 same actions and measures as for other point-to-point and multicast 874 Internet communications. Naturally, the risk of snooping depends on 875 the amount of individual or group personalization the snooped IMG 876 metadata contains. Further consideration is valuable at network, 877 transport and metadata levels. 879 IMG Authenticity: In some cases, the IMG receiver needs to be assured 880 of the origin of IMG metadata or its modification history. This can 881 prevent denial of service or hijacking attempts which give an IMG 882 receiver incorrect information in or about the metadata, thus 883 preventing successful access of the media or directing the IMG 884 receiver to the incorrect media possibly with tasteless material. 885 Action upon detection of unauthorized data insertion is out of scope 886 of this document. 888 IMG Receiver Authorization: Some or all of any IMG sender's metadata 889 may be private or valuable enough to allow access to only certain IMG 890 receivers and thus make it worth authenticating users. Encrypting the 891 data is also a reasonable step, especially where group communications 892 methods results in unavoidable snooping opportunities for 893 unauthorized nodes. Encryption and the required security parameters 894 exchange are outside the scope of this document. 896 Unidirectional Specifics: A difficulty that is faced by 897 unidirectional delivery operations is that many protocols providing 898 application-level security are based on bi-directional 899 communications. The application of these security protocols in case 900 of strictly unidirectional links is not considered in the present 901 document. 903 Malicious Code: Currently, IMGs are not envisaged to deliver 904 executable code at any stage. However, as some IMG transport 905 protocols may be capable of delivering arbitrary files, it is 906 RECOMMENDED that the IMG transport methods do not have write access 907 to the system or any other critical areas. 909 Protocol Specific Attacks: It is recommended that developers of any 910 IMG protocol take account of the above risks in addition to any 911 protocol design and deployment environment risks that may be 912 reasonably identified. Currently this framework document does not 913 mandate the use of any specific protocols, however the deployment of 914 IMGs using specific protocol instantiations will naturally be subject 915 to the security considerations of those protocols. 917 Security Improvement Opportunity: The security properties of one 918 channel and protocol can be improved through the use of another 919 channel and protocol. For example, a secure unicast channel can be 920 used to deliver the keys and initialization vectors for an encryption 921 algorithm used on a multicast channel. The exploitation of this 922 opportunity is specific to the protocols used and is outside the 923 scope of this document. 925 7 IANA Considerations 927 There are no IANA considerations within this document. 929 8 Normative References 931 [1] S. Bradner, "Key words for use in RFCs to indicate requirement 932 levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. 934 9 Informative References 936 [2] M. Handley and V. Jacobson, "SDP: session description protocol," 937 RFC 2327, Internet Engineering Task Force, Apr. 1998. 939 [3] D. Kutscher, J. Ott, and C. Bormann, "Session description and 940 capability negotiation," Internet Draft draft-ietf-mmusic-sdpng-07, 941 Internet Engineering Task Force, Oct. 2003. Work in progress. 943 [4] Y. Nomura, R. Walsh, J-P. Luoma, J. Ott, and H. Schulzrinne, 944 "Requirements for Internet Media Guides," Internet Draft 945 draft-ietf-mmusic-img-req-07, Internet Engineering Task Force, June 946 2004. Work in progress. 948 [5] TV-Anytime Forum, "Broadcast and On-line Services: Search, 949 select, and rightful use of content on personal storage systems 950 ("TV-Anytime Phase 1"); Part 2: System description," ETSI-TS 102 951 822-2: System Description, V1.1.1, October 2003. 953 [6] A. B. Roach, "Session initiation protocol (sip)-specific event 954 notification," RFC 3265, Internet Engineering Task Force, June 2002. 956 [7] M. Luby, J. Gemmell, L. Vicisano, L. Rizzo, and J. Crowcroft, 957 "Asynchronous layered coding (ALC) protocol instantiation," RFC 3450, 958 Internet Engineering Task Force, Dec. 2002. 960 [8] T. Paila, M. Luby, R. Lehtonen, V. Roca, R. Walsh, "FLUTE - 961 file delivery over unidirectional transport," Internet Draft 962 draft-ietf-rmt-flute-08, Internet Engineering Task Force, 963 June 2004. Work in progress. 965 [9] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J. 966 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session 967 initiation protocol," RFC 3261, Internet Engineering Task Force, June 968 2002. 970 [10] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, L. Masinter, P. 971 Leach and T. Berners-Lee, "Hypertext transfer protocol -- HTTP/1.1," 972 RFC 2616, Internet Engineering Task Force, June 1999. 974 [11] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: 975 a transport protocol for real-time applications," RFC 3550, Internet 976 Engineering Task Force, July 2003. 978 10 Acknowledgements 980 The authors would like to thank Joerg Ott, Colin Perkins, Toni Paila, 981 Jean-Pierre Evain, Magnus Westerlund and Petri Koskelainen for their 982 excellent ideas and input to this document. 984 11 Authors' Addresses 986 Yuji Nomura 987 Fujitsu Laboratories Ltd. 988 4-1-1 Kamikodanaka, Nakahara-ku, Kawasaki 211-8588 989 Japan 990 Email: nom@flab.fujitsu.co.jp 992 Rod Walsh 993 Nokia Research Center 994 P.O. Box 100, FIN-33721 Tampere 995 Finland 996 Email: rod.walsh@nokia.com 998 Juha-Pekka Luoma 999 Nokia Research Center 1000 P.O. Box 100, FIN-33721 Tampere 1001 Finland 1002 Email: juha-pekka.luoma@nokia.com 1004 Hitoshi Asaeda 1005 INRIA 1006 Project PLANETE 1007 2004, Route des Lucioles, BP93, 1008 06902 Sophia Antipolis, 1009 France 1010 Email: Hitoshi.Asaeda@sophia.inria.fr 1012 Henning Schulzrinne 1013 Dept. of Computer Science 1014 Columbia University 1015 1214 Amsterdam Avenue 1016 New York, NY 10027 1017 USA 1018 Email: schulzrinne@cs.columbia.edu 1020 12 Full Copyright Statement 1022 Copyright (C) The Internet Society (2004). This document is subject 1023 to the rights, licenses and restrictions contained in BCP 78 and 1024 except as set forth therein, the authors retain all their rights. 1026 This document and the information contained herein are provided on an 1027 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1028 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1029 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1030 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1031 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1032 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1034 Intellectual Property 1036 The IETF takes no position regarding the validity or scope of any 1037 Intellectual Property Rights or other rights that might be claimed to 1038 pertain to the implementation or use of the technology described in 1039 this document or the extent to which any license under such rights 1040 might or might not be available; nor does it represent that it has 1041 made any independent effort to identify any such rights. Information 1042 on the procedures with respect to rights in RFC documents can be 1043 found in BCP 78 and BCP 79. 1045 Copies of IPR disclosures made to the IETF Secretariat and any 1046 assurances of licenses to be made available, or the result of an 1047 attempt made to obtain a general license or permission for the use of 1048 such proprietary rights by implementers or users of this 1049 specification can be obtained from the IETF on-line IPR repository at 1050 http://www.ietf.org/ipr. 1052 The IETF invites any interested party to bring to its attention any 1053 copyrights, patents or patent applications, or other proprietary 1054 rights that may cover technology that may be required to implement 1055 this standard. Please address the information to the IETF at ietf- 1056 ipr@ietf.org.