idnits 2.17.1 draft-ietf-mmusic-img-framework-09.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.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 994. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 970. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 977. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 983. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** 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: ---------------------------------------------------------------------------- == 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 296 has weird spacing: '...rection v ...' == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 19, 2005) is 6703 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 -- Obsolete informational reference (is this intentional?): RFC 2616 (ref. '7') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 3265 (ref. '9') (Obsoleted by RFC 6665) -- Obsolete informational reference (is this intentional?): RFC 2326 (ref. '10') (Obsoleted by RFC 7826) -- Obsolete informational reference (is this intentional?): RFC 3450 (ref. '11') (Obsoleted by RFC 5775) -- Obsolete informational reference (is this intentional?): RFC 3926 (ref. '12') (Obsoleted by RFC 6726) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC Working Group Y. Nomura 3 Internet-Draft Fujitsu Labs. 4 Expires: June 23, 2006 R. Walsh 5 J-P. Luoma 6 Nokia 7 H. Asaeda 8 INRIA 9 H. Schulzrinne 10 Columbia University 11 December 19, 2005 13 A Framework for the Usage of Internet Media Guides 14 draft-ietf-mmusic-img-framework-09 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 26 Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other 30 documents at any time. It is inappropriate to use Internet-Drafts 31 as reference material or to cite them other than as "work in 32 progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/1id-abstracts.html 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 Copyright Notice 42 Copyright (C) The Internet Society (2005). 44 Abstract 46 This document defines a framework for the delivery of Internet Media 47 Guides (IMGs). An IMG is a structured collection of multimedia 48 session descriptions expressed using SDP, SDPng or some similar 49 session description format. This document describes a generalized 50 model for IMG delivery mechanisms, the use of existing protocols and 51 the need for additional work to create an IMG delivery 52 infrastructure. 54 Table of Contents 56 1 Introduction ........................................ 3 57 2 Terminology ......................................... 3 58 2.1 New Terms ........................................... 4 59 3 IMG Common Framework Model .......................... 5 60 3.1 IMG Data Types ...................................... 5 61 3.1.1 Complete IMG Description ............................ 5 62 3.1.2 Delta IMG Description ............................... 6 63 3.1.3 IMG Pointer ......................................... 6 64 3.2 IMG Entities ........................................ 6 65 3.3 Operation Set for IMG Delivery ...................... 7 66 3.3.1 IMG ANNOUNCE ........................................ 7 67 3.3.2 IMG QUERY ........................................... 8 68 3.3.3 IMG RESOLVE ......................................... 8 69 3.3.4 IMG SUBSCRIBE ....................................... 8 70 3.3.5 IMG NOTIFY .......................................... 9 71 3.3.6 Binding Between IMG Operations and Data Types ....... 9 72 3.4 Overview of Protocol Operations ..................... 9 73 4 Deployment Scenarios for IMG Entities ............... 10 74 4.1 Intermediary Cases .................................. 10 75 4.2 One-to-many Unidirectional Multicast ................ 12 76 4.3 One-to-one Bi-directional Unicast ................... 12 77 4.4 Combined Operations with Common Metadata ............ 14 78 5 Applicability of Existing Protocols to the 79 Proposed Framework Model ............................ 14 80 5.1 Existing Standard Fitting the IMG Framework Model ... 14 81 5.2 IMG Mechanism Needs Not Yet Met ..................... 16 82 5.2.1 A Multicast Transport Protocol ...................... 16 83 5.2.2 Usage of Unicast Transport Protocols ................ 17 84 5.2.3 IMG Envelope ........................................ 17 85 5.2.4 Metadata Data Model ................................. 18 86 6 Security Considerations ............................. 18 87 7 IANA Considerations ................................. 19 88 8 Normative References ................................ 20 89 9 Informative References .............................. 20 90 10 Acknowledgements .................................... 21 91 11 Authors' Addresses .................................. 21 93 1 Introduction 95 Internet Media Guides (IMGs) provide and deliver structured 96 collections of multimedia descriptions expressed using SDP [2], 97 SDPng [3] or other description formats. They are used to describe 98 sets of multimedia services (e.g., television program schedules, 99 content delivery schedules) and refer to other networked resources 100 including web pages. IMGs provide an envelope for metadata formats 101 and session descriptions defined elsewhere with the aim of 102 facilitating structuring, versioning, referencing, distributing, and 103 maintaining (caching, updating) such information. 105 IMG metadata may be delivered to a potentially large audience, who 106 use it to join a subset of the sessions described, and who may need 107 to be notified of changes to the IMG metadata. Hence, a framework for 108 distributing IMG metadata in various different ways is needed to 109 accommodate the needs of different audiences: For traditional 110 broadcast-style scenarios, multicast-based (push) distribution of IMG 111 metadata needs to be supported. Where no multicast is available, 112 unicast-based push is required. 114 This document defines a common framework model for IMG delivery 115 mechanisms and their deployment in network entities. There are 116 three fundamental components in IMG framework model: data types, 117 operation sets and entities. These components specify a set of 118 framework guidelines for efficient delivery and description of IMG 119 metadata. The data types give generalized means to deliver and 120 manage the consistency of application-specific IMG metadata. IMG 121 operations cover broadcast, multicast distribution, event 122 notification upon change, unicast-based push and interactive 123 retrievals similar to web pages. 125 Since we envision that any Internet host can be a sender and receiver 126 of IMG metadata, a host involved in IMG operations performs one or 127 more of the roles defined as the entities in IMG framework model. 128 The requirements for IMG delivery mechanisms and descriptions can be 129 found in the IMG requirements document [4]. 131 This document outlines the use of existing protocols to create 132 an IMG delivery infrastructure. It aims to organize existing 133 protocols into a common model and show their capabilities and 134 limitations from the viewpoint of IMG delivery functions. 136 2 Terminology 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in RFC 2119 [1]. 142 2.1 New Terms 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 with a data 160 type indicating a self-contained set or a subset of IMG 161 metadata, or a reference to IMG metadata. 163 IMG Delivery: The process of exchanging IMG metadata both in 164 terms of large scale and atomic data transfers [4]. 166 IMG Sender: An IMG sender is a logical entity that sends IMG 167 metadata to one or more IMG receivers [4]. 169 IMG Receiver: An IMG receiver is a logical entity that receives 170 IMG metadata from an IMG sender [4]. 172 IMG Transceiver: An IMG transceiver combines an IMG receiver and 173 sender. It may modify received IMG metadata or merge IMG 174 metadata received from a several different IMG senders [4]. 176 IMG Operation: An atomic operation of an IMG transport protocol, 177 used between IMG sender(s) and IMG receiver(s) for the 178 delivery of IMG metadata and for the control of IMG 179 sender(s)/receiver(s) [4]. 181 IMG Transport Protocol: A protocol that transports IMG metadata 182 from an IMG sender to IMG receiver(s) [4]. 184 IMG Transport Session: An association between an IMG sender and 185 one or more IMG receivers within the scope of an IMG 186 transport protocol. An IMG transport session involves a 187 time bound series of IMG transport protocol interactions 188 that provide delivery of IMG metadata from the IMG sender 189 to the IMG receiver(s) [4]. 191 IMG Transfer: IMG Transfer: A transfer of IMG metadata from an 192 IMG sender to IMG receiver(s). 194 3 IMG Common Framework Model 196 Two common elements are found in all of existing IMG candidate cases: 197 the need to describe the services and the need to deliver the 198 descriptions. In some cases, the descriptions provide multicast 199 addresses and thus are part of the transport configuration. In other 200 cases, descriptions are specific to the media application and may be 201 either meant for human or machine consumption. Thus, the technologies 202 can be roughly divided into three areas: 204 o Application-specific Metadata -- data describing the content 205 of services and media which are both specific to certain 206 applications and generally human readable. 208 o Delivery Descriptions -- the descriptions (metadata) that are 209 essential to enable (e.g., multicast) delivery. These include 210 framing (headers) for application-specific metadata, the 211 metadata element identification and structure, and fundamental 212 session data. 214 o Delivery Protocols -- the methods and protocols to exchange 215 descriptions between the senders and the receivers. An IMG 216 transport protocol consists of two functions: carrying IMG 217 metadata from an IMG sender to an IMG receiver and controlling 218 an IMG transport protocol. These functions are not always 219 exclusive, therefore some messages may combine control 220 messages and metadata carriage functions to reduce the amount 221 of the messaging. 223 3.1 IMG Data Types 225 A data model is needed to precisely define the terminology and 226 relationships between sets, supersets and subsets of metadata. A 227 precise data model is essential for the implementation of IMGs 228 although it is not within the scope of this framework and requires a 229 separate specification. However there are three IMG data types in 230 general: Complete IMG Descriptions, Delta IMG Descriptions and IMG 231 Pointers. 233 3.1.1 Complete IMG Description 235 A complete IMG description provides a self-contained set of metadata 236 for one media object or service, i.e., it does not need additional 237 information from any other IMG element. This is not to be confused 238 with "complete IMG metadata", which, although vaguely defined here, 239 represents the complete IMG metadata database of an IMG sender (or 240 related group of IMG senders -- potentially the complete Internet IMG 241 knowledge). An IMG sender will generally deliver only subsets of 242 metadata from its complete database in a particular IMG transport 243 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. Delta IMG Descriptions may be used to 250 reduce network resource usage, for instance when data consistency 251 is essential and small and frequent changes occur to IMG elements. 252 Thus, this description does not represent a complete set of metadata 253 until it is combined with other metadata that may already exist or 254 arrive in the future. 256 3.1.3 IMG Pointer 258 An IMG pointer, typically a URI, identifies or locates metadata. This 259 may be used to separately obtain metadata (Complete or Delta IMG 260 Descriptions) or perform another IMG management function such as data 261 expiry (and erasure). The IMG Pointer may be used to reference IMG 262 metadata elements within the IMG transport session and across IMG 263 transport sessions. This pointer type does not include IMG metadata 264 per se (although it may also appear as a data field in Complete or 265 Delta IMG descriptors). 267 3.2 IMG Entities 269 There are several fundamental IMG entities that indicate the 270 capability to perform certain roles. An Internet host involved in IMG 271 operations may adopt one or more of these roles, which are defined in 272 more detail in Section 3.3. 274 IMG Announcer: sends IMG ANNOUNCE 276 IMG Listener: receives IMG ANNOUNCE 278 IMG Querier: sends IMG QUERY to receive IMG RESOLVE 280 IMG Resolver: receives IMG QUERY then send IMG RESOLVE 282 IMG Subscriber: sends IMG SUBSCRIBE then receive IMG NOTIFY 284 IMG Notifier: receives IMG SUBSCRIBE then send IMG NOTIFY 286 Figure 1 shows the relationship between IMG entities and the IMG 287 sender and receiver. 289 +--------------------------------------------------------+ 290 | IMG Sender | 291 +------------------+------------------+------------------+ 292 | IMG Announcer | IMG Notifier | IMG Resolver | 293 +------------------+------------------+------------------+ 294 | ^ ^ 295 message | | | 296 direction v v v 297 +------------------+------------------+------------------+ 298 | IMG Listener | IMG Subscriber | IMG Querier | 299 +------------------+------------------+------------------+ 300 | IMG Receiver | 301 +------------------+------------------+------------------+ 303 Figure 1: Relationship between IMG Entities, Senders and Receivers 305 3.3 Operation Set for IMG Delivery 307 A finite set of operations both meets the IMG requirements [4] and 308 fits the roles of existing protocols. These are crystallized in the 309 next few sections. 311 3.3.1 IMG ANNOUNCE 313 When an IMG receiver participates in unidirectional communications 314 (e.g., over satellite, terrestrial radio and wired multicast 315 networks) an IMG receiver may not need to send any IMG message to an 316 IMG sender prior to IMG metadata delivery. In this case, an IMG 317 sender can initiate unsolicited distribution for IMG metadata and an 318 IMG sender is the only entity which can maintain the distribution 319 (this includes scenarios with multiple and co-operative IMG senders). 320 This operation is useful when there is large numbers of IMG receivers 321 or the IMG receivers do not have a guaranteed uplink connection to 322 the IMG sender. The IMG sender may also include authentication data 323 in the announce operation so that IMG receivers may check the 324 authenticity of the metadata. This operation can carry any of the 325 IMG data types. 327 There is no restriction to prevent IMG ANNOUNCE from being used 328 in an asynchronous solicited manner, where a separate operation 329 (possibly out of band) enables IMG receivers to subscribe/register to 330 the IMG ANNOUNCE operation. 332 3.3.2 IMG QUERY 334 If an IMG receiver needs to obtain IMG metadata, an IMG receiver can 335 use an IMG QUERY operation and initiate a receiver-driven IMG 336 transport session. The IMG receiver expects a synchronous response to 337 the subsequent request from the IMG sender. This operation can be 338 used where a bi-directional transport network is available between 339 the IMG sender and receiver. Some IMG receivers may want to obtain 340 IMG metadata when network connectivity is available or just to avoid 341 caching unsolicited IMG metadata. The IMG receiver must indicate the 342 extent and data type of metadata wanted in some message in the 343 operation. The extent indicates the number and grouping of metadata 344 descriptions. In some cases requesting an IMG sender's complete IMG 345 metadata collection, it may be feasible to request. 347 3.3.3 IMG RESOLVE 349 An IMG sender synchronously responds, and sends IMG metadata, to an 350 IMG QUERY which has been sent by an IMG receiver. This operation 351 can be used where a bi-directional transport network is available 352 between the IMG sender and receiver. If the IMG QUERY specifies a 353 subset of IMG metadata (extent and data type) that is available to 354 the IMG sender, the IMG sender can resolve the query; otherwise, it 355 should indicate that it is not able to resolve the query. The IMG 356 sender may authenticate the IMG receiver to investigate the IMG 357 QUERY operation in order to determine whether the IMG receiver is 358 authorized to be sent that metadata. The sender may also include 359 authentication data in the resolve operation so that IMG receivers 360 may check the authenticity of the metadata. This operation may 361 carry any of the IMG data types. 363 3.3.4 IMG SUBSCRIBE 365 If an IMG receiver wants to be notified when the IMG metadata it 366 holds is stale, the IMG receiver can use the IMG SUBSCRIBE operation 367 in advance in order to solicit IMG NOTIFY messages from an IMG 368 sender. 370 This operation may provide the IMG sender with specific details of 371 which metadata or notification services it is interested in in the 372 case where the IMG sender offers more than the simplest "all data" 373 service. This operation implicitly provides the functionality of 374 unsubscribing to inform an IMG sender that an IMG receiver wishes 375 to stop getting certain (or all) notifications. It should be noted 376 that unsubscription may be provided implicitly by the expiry 377 (timeout) of a subscription before it is renewed. 379 Since the IMG receiver does not know when metadata will be updated 380 and the notify message will arrive, this operation does not 381 synchronize with the notify messages. The IMG receiver may wait for 382 notify messages for a long time. The IMG sender may authenticate the 383 IMG receiver to check whether an IMG SUBSCRIBE operation is from an 384 authorized IMG receiver. 386 3.3.5 IMG NOTIFY 388 An IMG NOTIFY is used asynchronously in response to an earlier IMG 389 SUBSCRIBE. An IMG NOTIFY operation indicates that updated IMG 390 metadata is available or part of the existing IMG metadata is stale. 391 An IMG NOTIFY may be delivered more than once during the time an IMG 392 SUBSCRIBE is active. This operation may carry any of the IMG data 393 types. The IMG sender may also include authentication data in the 394 IMG NOTIFY operation so that IMG receivers may check the authenticity 395 of the messages. 397 3.3.6 Binding Between IMG Operations and Data Types 399 There is a need to provide a binding between the various IMG 400 operations and IMG data types to allow management of each discrete 401 set of IMG metadata transferred using an IMG operation. This binding 402 must be independent of any particular metadata syntax used to 403 represent a set of IMG metadata, as well as be compatible with any 404 IMG transport protocol. The binding must uniquely identify the set of 405 IMG metadata delivered within an IMG transfer, regardless of the 406 metadata syntax used. The uniqueness may only be needed within the 407 domains the metadata is used but this must enable globally unique 408 identification to support Internet usage. Scope/domain specific 409 identifications should not 'leak' outside of the scope, and always 410 using globally unique identification (e.g., based on URIs) should 411 avoid this error. 413 The binding must provide versioning to the transferred IMG metadata 414 so that changes can be easily handled and stale data identified, and 415 give temporal validity of the transferred IMG metadata. It must 416 invalidate the IMG metadata by indicating an expiry time, and may 417 optionally provide a time (presumably in the future) from when the 418 IMG metadata becomes valid. Temporal validity of IMG metadata may be 419 changeable for an IMG transfer, and even for specific versions of the 420 IMG transfer. Furthermore, the binding must be independent of the 421 metadata syntax(es) used for the IMG metadata, in the sense that no 422 useful syntax should be excluded. 424 3.4 Overview of Protocol Operations 426 Figure 2 gives an overview of the relationship between transport 427 cases, IMG Operations and IMG data types. It is not a protocol 428 stack. Generalized multicast point-to-multipoint (P-to-M) and 429 unicast point-to-point (P-to-P) transports are shown. 431 +--------------------------------------------------+ 432 IMG | | 433 Data types | Complete Desc., Delta Desc., Pointer | 434 | | 435 +-------------------+----------------+-------------+ 436 IMG | IMG ANNOUNCE | IMG SUBSCRIBE | IMG QUERY | 437 Operations | | IMG NOTIFY | IMG RESOLVE | 438 +--------------+----+----------------+-------------+ 439 IMG | | | 440 Transport | P-to-M | P-to-P | 441 | | | 442 +--------------+-----------------------------------+ 444 Figure 2: IMG Transport, IMG Operations and IMG Data types 446 4 Deployment Scenarios for IMG Entities 448 This section provides some basic deployment scenarios for IMG 449 entities that illustrate common threads from protocols to use cases. 450 For the purposes of clarity, this document presents the simple 451 dataflow from an IMG sender to an IMG receiver, as shown in Figure 3. 453 +-------------+ +---------------+ 454 | IMG Sender | | IMG Receiver | 455 | |--------------->| | 456 +-------------+ +---------------+ 458 Figure 3: A Simple IMG Sender to IMG Receiver Relationship 460 4.1 Intermediary Cases 462 Some IMG metadata may be distributed to a large number of IMG 463 receivers, for example, when public metadata is distributed to all 464 IMG receivers of a certain group. This kind of IMG metadata may be 465 distributed from one IMG sender to multiple IMG receivers (Figure 4) 466 or may be relayed across a set of IMG transceivers that receive the 467 IMG metadata, possibly filter or modify its content, and then forward 468 it. 470 +----------+ +----------+ 471 | IMG | | IMG | 472 | Sender |---- ---->| Receiver | 473 +----------+ \ / +----------+ 474 \ / 475 . \ +-----------+ / . 476 . -->|IMG |----- . 477 . -->|Transceiver| \ . 478 / +-----------+ \ 479 +----------+ / \ +----------+ 480 | IMG | / ---->| IMG | 481 | Sender |---- | Receiver | 482 +----------+ +----------+ 484 Figure 4: A Relay Network with an IMG Transceiver 486 IMG senders and receivers are logical functions and it is possible 487 for some or all hosts in a system to perform both roles, as, for 488 instance, in many-to-many communications or where a transceiver is 489 used to combine or aggregate IMG metadata for some IMG receivers. An 490 IMG receiver may be allowed to receive IMG metadata from any number 491 of IMG senders. 493 IMG metadata is used to find, obtain, manage and play media content. 494 IMG metadata may be modified during IMG Transfer. For example, a 495 server may use IMGs to retrieve media content via unicast and then 496 make it available at scheduled times via multicast, thus requiring a 497 change of the corresponding metadata. IMG transceivers may add or 498 delete information or aggregate IMG metadata from different IMG 499 senders. For example, a rating service may add its own content 500 ratings or recommendations to existing metadata. An implication of 501 changing (or aggregating) IMG metadata from one or more IMG senders 502 is that the original authenticity is lost. Thus, IMG metadata 503 fragmented reasonably may be beneficial for the intermediary to 504 replace a small fragment without changing the authenticity of the 505 remainder. For example, smaller fragments may be appropriate for more 506 volatile parts, and larger ones may be appropriate for stable parts. 508 4.2 One-to-many Unidirectional Multicast 510 One-to-many unidirectional multicast case implies many IMG receivers 511 and one or more IMG senders implementing IMG ANNOUNCER and IMG 512 LISTENER operations as shown in Figure 5. 514 Unidirectional +----------+ 515 ---------------> | IMG | 516 downlink | Listener | 517 ------------->| 1 | 518 / +----------+ 519 +-----------+ / . 520 | IMG |-------- . 521 | Announcer | \ . 522 +-----------+ \ +----------+ 523 ------------->| IMG | 524 | Listener | 525 | # | 526 +----------+ 528 Figure 5: IMG Unidirectional Multicast Distribution Example 530 Note, as defined in by the IMG requirements REL-4 [4], an IMG 531 transport protocol MUST support reliable message exchange. 532 This includes the one-to-many unidirectional multicast case, 533 however, the mechanism to provide this is beyond the scope of this 534 document. 536 4.3 One-to-one Bi-directional Unicast 538 In one-to-one bi-directional unicast case, both query/resolve 539 (Figure 6) and subscribe/notify (Figure 7) message exchange 540 operations are feasible. 542 +----------+ +----------+ 543 | IMG | | IMG | 544 | Resolver | | Querier | 545 +----------+ +----------+ 546 | | 547 |<----------IMG QUERY -----------| 548 | | 549 |----------IMG RESOLVE---------->| 550 | | 552 Figure 6: Query/Resolve Sequence Example 554 +----------+ +------------+ 555 | IMG | | IMG | 556 | Notifier | | Subscriber | 557 +----------+ +------------+ 558 | | 559 |<---------IMG SUBSCRIBE---------| 560 : : 561 (time passes) 562 : : 563 |-----------IMG NOTIFY---------->| 564 : : 565 (time passes) 566 : : 567 |-----------IMG NOTIFY---------->| 568 | | 570 Figure 7: Subscribe/Notify Sequence Example 572 4.4 Combined Operations with Common Metadata 574 As shown in Figure 8, a common data model for multiple protocol 575 operations allows a diverse range of IMG senders and receivers to 576 provide consistent and interoperable sets of IMG metadata. 578 IMG Metadata IMG Senders IMG Receivers 580 +--------------+ 581 +-----------+ ---->| IMG Listener | 582 | IMG | / +--------------+ 583 /| Announcer |----- 584 +-------------+ / +-----------+ \ +--------------+ 585 | IMG |-+ / ---->| IMG Listener | 586 | description | |-+ / | - - - - - - -| 587 | metadata 1 | | | / +-----------+ /--->| IMG Querier | 588 +-------------+ | | -----| IMG |<----/ +--------------+ 589 +-------------+ | \ | Resolver | 590 +-------------+ \ +-----------+<----\ +--------------+ 591 \ \--->| IMG Querier | 592 \ +-----------+ | - - - - - - -| 593 \| IMG |<--------->| IMG | 594 | Notifier | | Subscriber | 595 +-----------+ +--------------+ 597 Figure 8: Combined System with Common Metadata 599 5 Applicability of Existing Protocols to the Proposed Framework Model 601 5.1 Existing Standard Fitting the IMG Framework Model 603 SDP: The SDP format [2] could be used to describe session-level 604 parameters (e.g., scheduling, addressing and the use of media codecs) 605 to be included in Complete IMG Descriptions. Although there are 606 extension points in SDP allowing the format to be extended, there are 607 limitations in the flexibility of this extension mechanism. However, 608 SDP syntax cannot provide IMG Descriptions and IMG Pointers without 609 significant overhead. It is expected that the information conveyed by 610 SDP is just a small subset of IMG metadata, thus, the use of SDP for 611 other than session parameters may not be reasonable. 613 SDPng [3]: Similar to SDP, this format could also be used for 614 representing session-level parameters of IMG metadata. Compared to 615 SDP, the XML-based format of SDPng should be much more flexible and 616 allow extensions and integration with other description formats. 618 MPEG-7: Descriptions based on the MPEG-7 standard [5] could provide 619 application-specific metadata describing the properties of multimedia 620 content beyond parameters carried in SDP or SDPng descriptions. 621 MPEG-7 provides a machine-readable format of representing content 622 categories and attributes, helping end-users or receiving software in 623 choosing content for reception. MPEG-7 is based on XML so it is well 624 suited to be combined with other XML-based formats such as SDPng. 626 TV-Anytime Forum: The TV-Anytime Forum [6] provides descriptions 627 based on XML schema for TV-specific program guides. TV-Anytime uses 628 the MPEG-7 User description profile to a limited extent, only for 629 user preferences and usage history, and also a TV-Anytime-specific 630 data model for other schema. These are optimised to describe 631 broadcast schedules, on-demand program guides and program events. 633 HTTP: The HTTP protocol [7] can be used as a bi-directional unicast 634 IMG transport protocol. Being a request-reply oriented protocol, HTTP 635 is well suited for implementing synchronous operations such as QUERY, 636 RESOLVE and even SUBSCRIBE. However, HTTP does not provide 637 asynchronous operations such as ANNOUNCE and NOTIFY and to implement 638 asynchronous operations using HTTP, IMG receivers should poll the IMG 639 sender periodically. Thus, by itself, HTTP is not sufficient to 640 fulfill all of the IMG requirements [4] in a unicast deployment. 642 SAP: The announcement mechanism provided by SAP [8] provides 643 unidirectional delivery of session discovery information. Although 644 SDP is the default payload format of SAP, the use of a MIME type 645 identifier for the payload allows arbitrary payload formats to be 646 used in SAP messages. Thus, SAP could be used to implement the 647 multicast and unicast IMG ANNOUNCE and IMG NOTIFY operations. 649 However, SAP lacks scalable and efficient reliability, extensibility 650 for payload size, congestion control, and only one description 651 allowed per SAP message due to lack of payload segmentation. 653 In principle, SAP could be extended to get around its limitations. 654 However, the amount of changes needed in SAP to address all of the 655 above limitations would effectively result in a new protocol. Due to 656 these limitations, the use of SAP as an IMG transport protocol is NOT 657 RECOMMENDED. 659 SIP: The SIP-specific event mechanism described in RFC 3265 [9] 660 provides a way to implement IMG SUBSCRIBE and IMG NOTIFY operations 661 via a bi-directional unicast connection. However, there are 662 scalability problems with this approach, as RFC 3265 currently does 663 not consider multicast. 665 RTSP: The RTSP protocol [10] defines a retrieval and update 666 notification mechanism, named DESCRIBE and ANNOUNCE, for the 667 description of a presentation or media object in order to initialize 668 a streaming session. These methods are subset of the entire streaming 669 control operations in RTSP, thus these could not be available for 670 individual mechanisms. However, the DESCRIBE method in RTSP could be 671 used to instantiate IMG QUERY, IMG RESOLVE and IMG SUBSCRIBE, and the 672 RTSP ANNOUNCE could be used to instantiate an IMG NOTIFY for a 673 streaming session controlled by RTSP. 675 5.2 IMG Mechanism Needs Not Yet Met 677 Several needs result from the IMG requirements, framework model and 678 existing relevant mechanisms as already shown in this document. Four 679 specific groupings of work are readily apparent which are: (a) 680 specification of an adequate multicast and unidirectional capable 681 announcement protocol; (b) specification of the use of existing 682 unicast protocols to enable unicast subscribe and 683 announcement/notification functionality; (c) specification of the 684 metadata envelope which is common to, and independent of, the 685 application metadata syntax(es) used; (d) agreement on basic metadata 686 models to enable interoperability testing of the above. The following 687 sections describe each of these. 689 5.2.1 A Multicast Transport Protocol 691 SAP is currently the only open standard protocol suited to the 692 unidirectional/multicast delivery of IMG metadata. As discussed, it 693 fails to meet the IMG requirements in many ways and, since it is not 694 designed to be extensible, we recognize that a new multicast 695 transport protocol for announcements needs to be specified to meet 696 IMG needs. This protocol will be essential to IMG delivery for 697 unidirectional and multicast deployments. 699 The Asynchronous Layered Coding (ALC) [11] protocol from the IETF 700 Reliable Multicast Transport (RMT) working group is very interesting 701 as it fulfills many of the requirements, is extensible and has the 702 ability to 'plug-in' both FEC (Forward Error Correction -- for 703 reliability) and CC (Congestion Control) functional blocks -- it is 704 specifically designed for unidirectional multicast object transport. 705 ALC is not fully specified, although RMT working group had a fully 706 specified protocol using ALC called FLUTE (File Delivery over 708 Unidirectional Transport) [12]. FLUTE seems to be the only fully 709 specified transport and open specification on which a new IMG 710 announcement protocol could be designed. Thus, we recommend that ALC 711 and FLUTE be the starting points for this protocol's design. 713 Developing a new protocol from scratch, or attempting to improve SAP, 714 is also feasible, although it would involve repeating many of the 715 design processes and decisions already made by the IETF for ALC. 717 In particular, any announcement protocol must feature sufficient 718 scalability, flexibility and reliability to meet IMG needs. Also, the 719 IMG ANNOUNCE operation must be supported and IMG NOTIFY capability 720 could be investigated for both hybrid unicast-multicast and 721 unidirectional unicast systems. 723 5.2.2 Usage of Unicast Transport Protocols 725 A thorough description of the use of existing unicast protocols is 726 essential for the use of IMGs in a unicast point-to-point 727 environment. Such a specification does not currently exist, although 728 several usable unicast transport protocols and specifications can be 729 harnessed for this (SIP [13], SIP events [9], HTTP [7], etc.) In 730 particular, both IMG SUBSCRIBE-NOTIFY and IMG QUERY-RESOLVE operation 731 pairs must be enabled. We anticipate that the IMG QUERY-RESOLVE 732 operation can be achieved using HTTP, although other transport 733 protocol options may be beneficial to consider too. 735 5.2.3 IMG Envelope 737 An IMG envelope provides binding between IMG Operations and data 738 types. Such a binding can be realized by defining a common minimal 739 set of information needed to manage IMG metadata transfers, and by 740 including this information with any set of IMG metadata delivered to 741 IMG receivers. 743 Four options for IMG metadata transfer envelope delivery are 744 feasible: 746 1. Embedding in a transport protocol header. This can be done 747 with either header extensions of existing protocols, or 748 newly defined header fields of a new (or new version of a) 749 transport protocol. However, multiple methods for the 750 variety of transport protocols would hinder 751 interoperability and transport protocol independence. 753 2. A separate envelope object, which points to the IMG 754 metadata 'object', delivered in-band with the metadata 755 transport protocol session. This might complicate 756 delivery as the envelope and 'service' metadata objects 757 would have to be bound, e.g., by pairing some kind of 758 transport object numbers (analogous to port number pairs 759 sometimes used for RTP and RTCP [14]). This would also 760 enable schemes which deliver enveope and metadata 761 'objects' on by different media, also using more than a 762 single transport protocol. 764 3. A metadata wrapper which points to and/or embeds the 765 service metadata into its 'super-syntax'. For example, an 766 XML would enable embedding generic text objects. 768 4. Embedding in the metadata itself. However, this requires 769 new field in many metadata syntaxes and would not be 770 feasible if a useful syntax were not capable of 771 extensibility in this way. It also introduces a larger 772 'implementation interpretation' variety which would hinder 773 interoperability. Thus this option is not recommended. 775 It is likely that more than one of these options will fulfill the 776 needs of IMGs so the selection, and possibly optimization, is left 777 for subsequent specification and feedback from implementation 778 experience. Such a specification is essential for IMG delivery. 780 When there are superset/subset relations between IMG descriptions, 781 it is assumed that the IMG descriptions of the subset inherit the 782 parameters of the superset. Thus, an IMG metadata transfer envelope 783 carrying the IMG descriptions of a superset may implicitly define 784 parameters of IMG descriptors belonging to its subset. The 785 relations between IMG descriptions may span from one envelope to 786 another according to a data model definition. 788 5.2.4 Metadata Data Model 790 A structured data model would allow reuse and extension of the set of 791 metadata and may enable use of multiple syntaxes (SDP, MPEG-7, etc.) 792 as part of the same body of IMG metadata. 794 Further work may be needed to meet application-specific requirements 795 at defining metadata and data models for the successful deployment of 796 IMGs in various environments. Existing (and future) work on these 797 would need to be mapped to the IMG data types and use of the IMG 798 transfer envelope concept as described above. 800 This document is a framework for the delivery of IMG metadata and 801 thus further discussion on the definition data models for IMGs is 802 beyond its scope. 804 6 Security Considerations 806 The IMG framework is developed from the IMG requirements document [4] 807 and so the selection of specific protocols and mechanism for use with 808 the IMG framework must also take into account the security 809 considerations of the IMG requirements document. This framework 810 document does not mandate the use of specific protocols. However, an 811 IMG specification would inherit the security considerations of 812 specific protocols used. 814 Protocol instantiations which are used to provide IMG operations will 815 have very different security considerations depending on their scope 816 and purpose. However, there are several general issues which are 817 valuable to consider and, in some cases, provide technical solutions 818 to deal with. These are described below. 820 Individual and group privacy: Customized IMG metadata may reveal 821 information about the habits and preferences of a user and may thus 822 deserve confidentiality protection, even if the original information 823 were public. Snooping and protecting this IMG metadata requires the 824 same actions and measures as for other point-to-point and multicast 825 Internet communications. Naturally, the risk of snooping depends on 826 the amount of individual or group personalization the snooped IMG 827 metadata contains. 829 IMG authenticity: In some cases, the IMG receiver needs to be assured 830 of the sender or origin of IMG metadata or its modification history. 831 This can prevent denial of service or hijacking attempts which give 832 an IMG receiver incorrect information in or about the metadata, thus 833 preventing successful access of the media or directing the IMG 834 receiver to the incorrect media possibly with tasteless material. 836 IMG receiver authorization: Some or all of any IMG sender's metadata 837 may be private or valuable enough to allow access to only certain IMG 838 receivers and thus make it worth authenticating users. Encrypting the 839 data is also a reasonable step, especially where group communications 840 methods results in unavoidable snooping opportunities for 841 unauthorized nodes. 843 Unidirectional specifics: A difficulty that is faced by 844 unidirectional delivery operations is that many protocols providing 845 application-level security are based on bi-directional 846 communications. The application of these security protocols in case 847 of strictly unidirectional links is not considered in the present 848 document. 850 Malicious code: Currently, IMGs are not envisaged to deliver 851 executable code at any stage. However, as some IMG transport 852 protocols may be capable of delivering arbitrary files, it is 853 RECOMMENDED that the IMG operations do not have write access to the 854 system or any other critical areas. 856 7 IANA Considerations 858 This document does not request any IANA action. 860 8 Normative References 862 [1] S. Bradner, "Key words for use in RFCs to indicate requirement 863 levels," RFC 2119, Internet Engineering Task Force, March 1997. 865 9 Informative References 867 [2] M. Handley and V. Jacobson, "SDP: session description protocol," 868 RFC 2327, Internet Engineering Task Force, April 1998. 870 [3] D. Kutscher, J. Ott, and C. Bormann, "Session description and 871 capability negotiation," Internet Draft draft-ietf-mmusic-sdpng-07, 872 Internet Engineering Task Force, October 2003. Work in progress. 874 [4] Y. Nomura, R. Walsh, J-P. Luoma, J. Ott, and H. Schulzrinne, 875 "Requirements for Internet Media Guides," Internet Draft 876 draft-ietf-mmusic-img-req-08, Internet Engineering Task Force, 877 December 2005. Work in progress. 879 [5] "Multimedia content description interface -- Part 1: Systems", 880 ISO/IEC 15938-1, July 2002. 882 [6] TV-Anytime Forum, "Broadcast and On-line Services: Search, 883 select, and rightful use of content on personal storage systems 884 ("TV-Anytime Phase 1"); Part 2: System description," ETSI-TS 102 885 822-2: System Description, V1.1.1, October 2003. 887 [7] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, L. Masinter, P. 888 Leach and T. Berners-Lee, "Hypertext transfer protocol -- HTTP/1.1," 889 RFC 2616, Internet Engineering Task Force, June 1999. 891 [8] M. Handley, C. E. Perkins, and E. Whelan, "Session announcement 892 protocol," RFC 2974, Internet Engineering Task Force, October 2000. 894 [9] A. B. Roach, "Session initiation protocol (sip)-specific event 895 notification," RFC 3265, Internet Engineering Task Force, June 2002. 897 [10] H. Schulzrinne, A. Rao, and R. Lanphier, "Real Time Streaming 898 Protocol (RTSP)", RFC 2326, Internet Engineering Task Force, 899 April 1998. 901 [11] M. Luby, J. Gemmell, L. Vicisano, L. Rizzo, and J. Crowcroft, 902 "Asynchronous layered coding (ALC) protocol instantiation," RFC 3450, 903 Internet Engineering Task Force, December 2002. 905 [12] T. Paila, M. Luby, R. Lehtonen, V. Roca, R. Walsh, "FLUTE - 906 file delivery over unidirectional transport," RFC 3926, 907 Internet Engineering Task Force, October 2004. 909 [13] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J. 910 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session 911 initiation protocol," RFC 3261, Internet Engineering Task Force, June 912 2002. 914 [14] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: 915 a transport protocol for real-time applications," RFC 3550, Internet 916 Engineering Task Force, July 2003. 918 10 Acknowledgements 920 The authors would like to thank Spencer Dawkins, Jean-Pierre Evain, 921 Ted Hardie, Petri Koskelainen, Joerg Ott, Colin Perkins, Toni Paila, 922 Magnus Westerlund, and for their excellent ideas and input to this 923 document. 925 11 Authors' Addresses 927 Yuji Nomura 928 Fujitsu Laboratories Ltd. 929 4-1-1 Kamikodanaka, Nakahara-ku, Kawasaki 211-8588 930 Japan 931 Email: nom@flab.fujitsu.co.jp 933 Rod Walsh 934 Nokia Research Center 935 P.O. Box 100, FIN-33721 Tampere 936 Finland 937 Email: rod.walsh@nokia.com 939 Juha-Pekka Luoma 940 Nokia Research Center 941 P.O. Box 100, FIN-33721 Tampere 942 Finland 943 Email: juha-pekka.luoma@nokia.com 945 Hitoshi Asaeda 946 INRIA 947 PLANETE Research Team 948 2004, Route des Lucioles, BP93, 949 06902 Sophia Antipolis, 950 France 951 Email: Hitoshi.Asaeda@sophia.inria.fr 953 Henning Schulzrinne 954 Dept. of Computer Science 955 Columbia University 956 1214 Amsterdam Avenue 957 New York, NY 10027 958 USA 959 Email: schulzrinne@cs.columbia.edu 961 Intellectual Property Statement 963 The IETF takes no position regarding the validity or scope of any 964 Intellectual Property Rights or other rights that might be claimed to 965 pertain to the implementation or use of the technology described in 966 this document or the extent to which any license under such rights 967 might or might not be available; nor does it represent that it has 968 made any independent effort to identify any such rights. Information 969 on the procedures with respect to rights in RFC documents can be 970 found in BCP 78 and BCP 79. 972 Copies of IPR disclosures made to the IETF Secretariat and any 973 assurances of licenses to be made available, or the result of an 974 attempt made to obtain a general license or permission for the use of 975 such proprietary rights by implementers or users of this 976 specification can be obtained from the IETF on-line IPR repository at 977 http://www.ietf.org/ipr. 979 The IETF invites any interested party to bring to its attention any 980 copyrights, patents or patent applications, or other proprietary 981 rights that may cover technology that may be required to implement 982 this standard. Please address the information to the IETF at ietf- 983 ipr@ietf.org. 985 Disclaimer of Validity 987 This document and the information contained herein are provided on 988 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 989 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 990 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 991 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 992 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 993 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 994 PARTICULAR PURPOSE. 996 Copyright Statement 998 Copyright (C) The Internet Society (2005). This document is subject 999 to the rights, licenses and restrictions contained in BCP 78, and 1000 except as set forth therein, the authors retain all their rights. 1002 Acknowledgement 1004 Funding for the RFC Editor function is currently provided by the 1005 Internet Society.