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