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