From: http://www.ietf.org/internet-drafts/draft-luoma-mmusic-img-metadata-envelope-00.txt Reference: draft-luoma-mmusic-img-metadata-envelope-00 Title: A Metadata Framework for Internet Media Guides: Metadata Envelope ------------------------------------------------------------------------- MMUSIC J. Luoma Internet-Draft Nokia Expires: June 8, 2004 J. Peltotalo S. Peltotalo Tampere University of Technology December 9, 2003 A Metadata Framework for Internet Media Guides: Metadata Envelope draft-luoma-mmusic-img-metadata-envelope-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 8, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document defines the transfer envelope for Internet Media Guides (IMGs). IMG metadata describes files, resources and multimedia programs available for streaming or downloading via multicast or unicast. IMG metadata is encapsulated into, or associated with, an IMG transfer envelope before actual transport. The transfer envelope is a structure providing independence between IMG transport protocols and different metadata formats. The IMG transfer envelope may be structured for example as a wrapper based on the Extensible Markup Language (XML) syntax. Luoma, et al. Expires June 8, 2004 [Page 1] Internet-Draft IMG Metadata December 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Use of IMG Transfer Envelope with IMG Operations . . . . . . . 9 4.1 Initial Discovery . . . . . . . . . . . . . . . . . . . . . . 9 4.2 Update Discovery . . . . . . . . . . . . . . . . . . . . . . . 9 4.3 Versioning . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Format of the IMG Transfer Envelope . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14 Normative References . . . . . . . . . . . . . . . . . . . . . 15 Informative References . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16 A. XML Schema for the IMG Transfer Envelope . . . . . . . . . . . 17 B. Example of an IMG Transfer Envelope . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . 20 Luoma, et al. Expires June 8, 2004 [Page 2] Internet-Draft IMG Metadata December 2003 1. Introduction This document defines the format and use of Internet Media Guide (IMG) transfer envelope. The scope and background of the work on Internet Media Guides have been described in the IMG requirements [2] and IMG framework [3] specifications. The purpose of the IMG metadata is to provide machine- and human-readable information describing the files, resources and multimedia programs available for streaming or downloading via multicast or unicast. IMG metadata is encapsulated into an IMG transfer envelope before it is passed to an IMG transport protocol, such as MUPPET [4]. The purpose of the transfer envelope is to provide independence of metadata formats from transport protocols, and to enable versioning, updating and expiring of transmitted metadata. The IMG transfer envelope may be structured for example as a wrapper based on the Extensible Markup Language (XML) syntax. Luoma, et al. Expires June 8, 2004 [Page 3] Internet-Draft IMG Metadata December 2003 2. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. Luoma, et al. Expires June 8, 2004 [Page 4] Internet-Draft IMG Metadata December 2003 3. Terminology Complete IMG Description Provides a complete syntax and semantics to describe a set of metadata, which does not need any additional information from other IMG Descriptions. It may contain either a full IMG or a subset thereof. Complete Transfer Transfer of the whole set of metadata comprising an IMG block. Delta IMG Description Provides an update to a Complete IMG Description, defining the difference from the Complete IMG Description in question. This description may be used to reduce network resource usage for instance when small and frequent changes occur to Complete IMG Description. Thus, this description itself cannot represent complete metadata set until it is combined with the corresponding Complete IMG Description. Delta Transfer Transfer of Delta IMG Description(s) to update an IMG block. Full IMG Represents a subset/whole of the sender's IMG database delivered within the scope of one IMG transport session. A sender will generally deliver only a subset of metadata from its whole database of IMG metadata as a full IMG, but a full IMG could also represent the whole IMG database of a particular sender. Different subsets of the sender's IMG database may be provided within different transport sessions; similarly, the same subset may be provided in more than one transport session. Internet Media Guide (IMG) An IMG is a generic term to describe the formation, delivery and use of IMG metadata. The definition of the IMG is intentionally left imprecise. IMG ANNOUNCE Unsolicited delivery of IMG metadata to an IMG receiver. References to parts of the IMG metadata may also be included, Luoma, et al. Expires June 8, 2004 [Page 5] Internet-Draft IMG Metadata December 2003 instead of the actual metadata. IMG Block IMG block consists of one or more IMG Descriptions. IMG Description A collection of IMG metadata. There are the following subtypes of IMG Descriptions: Complete IMG Description, Delta IMG Description and IMG Pointer. IMG Element The smallest atomic element of IMG metadata that can be transmitted separately and referenced individually from other IMG elements. IMG Metadata A set of metadata consisting of one or more IMG elements. IMG metadata describes the features of multimedia content used to enable selection of and access to media sessions containing content. For example, metadata may consist of the URI, title, airtime, bandwidth needed, file size, text summary, genre, and access restrictions. IMG NOTIFY Delivery of an IMG update notification in response to an IMG SUBSCRIBE. Identifies the parts of the IMG metadata that have changed without delivering the updated IMG metadata. IMG Operation An atomic process for the IMG transport protocol to deliver IMG metadata or control IMG sender(s) or IMG receiver(s). IMG Pointer A reference, such as URI, that the receiver is able to address specific metadata with. An IMG pointer may be used to separately obtain IMG elements, or perform another IMG management function such as data expiry and erasure. IMG Proxy IMG proxy is a combined IMG receiver and IMG sender that can Luoma, et al. Expires June 8, 2004 [Page 6] Internet-Draft IMG Metadata December 2003 filter from one or more IMG senders and output to one or more IMG transport sessions. Logically a proxy fits in between IMG senders and receivers. A proxy may also cache IMG metadata and may provide its own bandwidth control or congestion control schemes on the output. IMG QUERY Request to receive a delivery of IMG metadata. IMG Receiver A logical entity that receives media guides from an IMG sender, analogous to a client. IMG RESOLVE Delivery of IMG metadata in response to an IMG QUERY. References to parts of the IMG metadata may also be included, instead of the actual metadata. IMG Sender A logical entity that delivers IMG metadata to one or more IMG receivers, analogous to a server. A sender shall provide bandwidth control or congestion control schemes on the output. A sender can additionally be a receiver - see IMG transceiver. IMG SUBSCRIBE A request for notifications of changes in IMG metadata updates, from a receiver to a sender or proxy. IMG Transceiver A combination of an IMG receiver and sender. An IMG proxy is an example of an IMG transceiver. IMG Transport Protocol A protocol that transports IMG metadata from IMG sender to IMG receiver(s). IMG Transport Session An association between an IMG sender and one or more IMG receivers within the scope of an IMG transport protocol. An IMG transport session involves a series of IMG transport protocol Luoma, et al. Expires June 8, 2004 [Page 7] Internet-Draft IMG Metadata December 2003 interactions that provide delivery of IMG metadata from the sender to the receiver(s). IMG Update Notification An IMG Description containing one or more IMG Pointers. Luoma, et al. Expires June 8, 2004 [Page 8] Internet-Draft IMG Metadata December 2003 4. Use of IMG Transfer Envelope with IMG Operations IMG transfer envelope is used with the following logical IMG operations: IMG ANNOUNCE, IMG NOTIFY and IMG RESOLVE. The following sections describe the use of IMG transfer envelope to support both initial and update discovery of IMG. 4.1 Initial Discovery An IMG sender SHOULD make its full IMG available to IMG receivers using IMG ANNOUNCE and/or IMG RESOLVE. An IMG receiver may need to receive the full IMG when the terminal has just started receiving a particular IMG, or when its cached copy of the metadata cannot be synchronized with IMG updates or it has been outdated. The IMG sender should split its complete IMG to IMG blocks, each comprising one or more IMG elements. An IMG block is a unit for IMG transport protocols that can be uniquely identified and versioned. The complete transfer of an IMG block means the transfer of all the IMG metadata within an IMG block. The IMG receiver MUST maintain the version numbers of complete transfers for duplicate avoidance and update discovery. How the IMG receiver knows when it has received all the IMG blocks comprising a full IMG is out of scope of this document. 4.2 Update Discovery Once the IMG receiver has received and stored sufficient IMG metadata in its local database, it may try to detect any changes in the received IMG information. The following types of IMG metadata may be monitored for changes: 1. A sender's complete transfers (IMG ANNOUNCE or IMG RESOLVE) 2. A sender's delta transfers (IMG ANNOUNCE or IMG RESOLVE) 3. A sender's IMG update notifications (IMG NOTIFY, IMG ANNOUNCE or IMG RESOLVE) The receiver will learn of any changes in the IMG metadata by continuing to receive the complete transfers, for example by periodically using an IMG RESOLVE by receiving transmissions of the metadata via IMG ANNOUNCE. However, the use of delta transfers and/or IMG update notifications may provide more efficient means for update discovery. Delta transfer means transferring only the parts of the IMG metadata that have changed from the last version of the complete transfer, whereas sending an IMG update notification means transferring IMG Pointers identifying the parts of the IMG metadata Luoma, et al. Expires June 8, 2004 [Page 9] Internet-Draft IMG Metadata December 2003 that have changed from the last version of the complete transfer. An IMG sender SHOULD provide IMG metadata delta transfers via IMG ANNOUNCE, IMG RESOLVE or both, in addition to complete transfers. After receiving sufficient IMG metadata, an IMG receiver may continue receiving only delta transfers, if available, instead of complete transfers. Each delta transfer consists of the IMG elements that have recently changed. The definition of 'recently changed metadata' shall be determined by the sender (this may be dependent on time, data size and/or number of transmissions. After each delta transfer, the IMG receiver MAY need to verify if it has missed an earlier delta transfer(s) to the particular IMG block; this can be accomplished by checking the majorVersion and minorVersion fields in the IMG transfer envelope. It is recommended that the IMG receiver attempts to recover the missing update by verifying the current versions of the relevant metadata (for example, by obtaining the complete transfer again, or by querying the versions of the locally cached IMG metadata). In addition to sending complete and delta transfers, an IMG sender MAY send IMG update notifications (IMG Pointers). These IMG update notifications consist of references to IMG elements that have changed recently (e.g., since the previous complete transfer). After receiving an IMG update notification and discovering the parts of IMG that have changed, an IMG receiver MAY obtain the update from complete or delta transfers using either IMG ANNOUNCE or IMG QUERY. 4.3 Versioning The version of a complete transfer is identified by the field majorVersion in the IMG transfer envelope. The version of a delta transfer or an IMG update notification is identified by the combination of the fields majorVersion and minorVersion in the IMG transfer envelope. In the case of delta transfer or IMG update notification, the field majorVersion identifies the version of the complete transfer that the delta transfer / IMG update notification pertains to. Luoma, et al. Expires June 8, 2004 [Page 10] Internet-Draft IMG Metadata December 2003 5. Format of the IMG Transfer Envelope An IMG block must be encapsulated into or associated with an IMG transfer envelope before it is passed to an IMG transport protocol for delivery. The transfer envelope enables each IMG block to be uniquely identified and versioned in a uniform way independent of the particular IMG transport protocol used for delivery. The same envelope format is used for the logical operations IMG ANNOUNCE, IMG NOTIFY and IMG RESOLVE. The following attributes can be associated with the IMG payload. The attributes are mandatory to include unless marked as optional. o metadataID: A URI providing a unique identifier for the IMG block. o majorVersion: Current version number of the complete transfer of IMG block. The version number is initially zero, and is increased by one whenever the complete transfer is changed. o minorVersion (optional): Current version number of the delta transfer of IMG block. This field MUST be present for delta transfers and IMG update notifications (IMG Pointers), and MUST NOT be present for complete transfers. The value of this field is initially zero, and is increased by one whenever the delta transfer is changed. An updated delta transfer SHOULD be sent as soon as there has been a change in the contents of an IMG block. o lastDelta: The value of "true" in this boolean field is used to inform receivers that there will be no more updates to delta transfers or IMG update notifications pertaining to the current version of the complete transfer; the version of the complete transfer will be updated instead, and any subsequent delta transfers or IMG update notifications will pertain to the next version of the complete transfer. Receivers of delta transfers are able to reconstruct the contents of the next complete transfer by updating the current version of a complete transfer with a delta transfer that has the same value of majorVersion and a value of "true" in the lastDelta flag. o validFrom: The date and time from which the metadata is valid. o validUntil: The date and time when the metadata expires. It shall be possible to provide signing and encryption to the IMG transfer envelope, limiting the capability of any intermediaries between the original IMG sender and the IMG receiver to read and modify IMG transfer envelope fields and the IMG block associated with it. Signing, encryption or both can be applied to the whole transfer Luoma, et al. Expires June 8, 2004 [Page 11] Internet-Draft IMG Metadata December 2003 envelope or just to parts of it. An XML schema for the IMG transfer envelope is defined in Appendix A, providing a wrapper that can be used for encapsulating an IMG block before transmission. Appendix B provides a simple example of using this wrapper for IMG metadata. Luoma, et al. Expires June 8, 2004 [Page 12] Internet-Draft IMG Metadata December 2003 6. Security Considerations IMG receivers should only trust IMG metadata received from a trusted source, with data integrity and authentication of the original IMG sender provided at IMG metadata level or by IMG transport. IMG receivers also should not trust IMG metadata modified by an IMG transceiver, unless the IMG transceiver is trusted and the integrity and authenticity of the changes can be similarly verified. However, to operate in a typical network environment lacking infrastructure for key distribution and trust verification, IMG receivers may also be configured to accept untrusted IMG metadata. There may also be need to provide access control to the content described by the IMG or to protect the confidentiality of an individual user requesting a particular subset of an IMG. Such privacy requirements are met by the use of encryption at IMG metadata level or by IMG transport. Luoma, et al. Expires June 8, 2004 [Page 13] Internet-Draft IMG Metadata December 2003 7. Contributors Rod Walsh Nokia Research Center P.O. Box 100 (Visiokatu 1) FIN-33721 Tampere Finland EMail: rod.walsh@nokia.com Toni Paila Nokia Ventures Organization P.O. Box 209 (Itamerenkatu 11-13) FIN-00181 Helsinki Finland EMail: toni.paila@nokia.com Luoma, et al. Expires June 8, 2004 [Page 14] Internet-Draft IMG Metadata December 2003 Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCD 14, March 1997. [2] Nomura, Y., Walsh, R., Luoma, J., Ott, J. and H. Schulzrinne, "Protocol Requirements for Internet Media Guides", draft-ietf-mmusic-img-req-01 (work in progress), December 2003. [3] Nomura, Y., Walsh, R., Luoma, J., Asaeda, H. and H. Schulzrinne, "A Framework for the Usage of Internet Media Guides", draft-ietf-mmusic-img-framework-01 (work in progress), December 2003. Luoma, et al. Expires June 8, 2004 [Page 15] Internet-Draft IMG Metadata December 2003 Informative References [4] Luoma, J., "MUPPET: Internet Media Guide Unidirectional Point-to-Multipoint Transport Protocol", draft-luoma-mmusic-img-muppet-03 (work in progress), October 2003. [5] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [6] Ott, J., Bormann, C. and D. Kutscher, "Session Description and Capability Negotiation", draft-ietf-mmusic-sdpng-07 (work in progress), October 2003. Authors' Addresses Juha-Pekka Luoma Nokia P.O. Box 100 (Visiokatu 1) Tampere FIN-33721 Finland EMail: juha-pekka.luoma@nokia.com Jani Peltotalo Tampere University of Technology P.O. Box 553 (Korkeakoulunkatu 1) Tampere FIN-33101 Finland EMail: jani.peltotalo@tut.fi Sami Peltotalo Tampere University of Technology P.O. Box 553 (Korkeakoulunkatu 1) Tampere FIN-33101 Finland EMail: sami.peltotalo@tut.fi Luoma, et al. Expires June 8, 2004 [Page 16] Internet-Draft IMG Metadata December 2003 Appendix A. XML Schema for the IMG Transfer Envelope Different formats can be provided for conveying the IMG transfer envelope parameters specified in Section 5. Figure 1 provides a non-normative example of an XML schema specifying the IMG transfer envelope syntax. Figure 1: The XML Schema of the IMG Transfer Envelope The fields of the IMG transfer envelope (represented as attributes in the XML schema) are used as described in Section 5, with the following additional notes. o lastDelta (optional): if this attribute is not present, the value of "false" is assumed. The following additional fields in the XML schema enable either XML or plain ASCII payload to be used in the envelope payload. o xmlPayload: The metadata payload in an XML based textual format. Any number of XML metadata formats for this field may be supported by senders and receivers, for example Session Description and Capability Negotiation (SDPng) [6]. Only well-formed XML must be used in this field. The XML payload MUST contain a reference to a valid XML schema, enabling receivers to determine the format of the XML payload. o asciiPayload: The metadata payload in a textual, non-XML format. The MIME content type of the textual payload (for example, "application/sdp" referring to the Session Description Protocol [5] format) MUST be indicated using the "type" attribute. Luoma, et al. Expires June 8, 2004 [Page 18] Internet-Draft IMG Metadata December 2003 Appendix B. Example of an IMG Transfer Envelope Figure 2 shows a non-normative example of a Complete IMG Description encapsulated within an IMG transfer envelope. In this example, the format defined in Appendix A is used for the IMG transfer envelope, and the SDP syntax [5] is used for the IMG Description. v=0 o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4 s=SDP Seminar i=A Seminar on the session description protocol u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps e=mjh@isi.edu (Mark Handley) c=IN IP4 224.2.17.12/127 t=2873397496 2873404696 a=recvonly m=audio 49170 RTP/AVP 0 m=video 51372 RTP/AVP 31 m=application 32416 udp wb a=orient:portrait Figure 2: Example of an IMG transfer envelope Luoma, et al. Expires June 8, 2004 [Page 19] Internet-Draft IMG Metadata December 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Luoma, et al. Expires June 8, 2004 [Page 20] Internet-Draft IMG Metadata December 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Luoma, et al. Expires June 8, 2004 [Page 21]