MMUSIC R. Walsh Internet-Draft J-P. Luoma Expires: August 6, 2007 Nokia J. Peltotalo S. Peltotalo Tampere University of Technology J. Greifenberg Universitaet Bremen February 2, 2007 The IMG Envelope draft-walsh-mmusic-img-envelope-06 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 August 6, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Walsh, et al. Expires August 6, 2007 [Page 1] Internet-Draft The IMG Envelope February 2007 Abstract This document defines the metadata 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 envelope before actual transport. The IMG envelope is a structure providing independence between IMG transport protocols and different metadata formats. This specification provides the IMG envelope instantiation using structured Extensible Markup Language (XML) syntax, both as a wrapper in which to embed an IMG metadata object and as a distinct object to associate with a distinct IMG metadata object. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions Used in This Document . . . . . . . . . . . . . . 5 3. IMG Envelope Usage . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Applicability of an IMG Envelope . . . . . . . . . . . . . 6 3.1.1. The Two IMG Envelope Cases . . . . . . . . . . . . . . 6 3.1.2. Relationship with IMG Data Types . . . . . . . . . . . 7 3.1.3. Relationship with IMG Operations . . . . . . . . . . . 7 3.2. IMG Envelope Characteristics . . . . . . . . . . . . . . . 7 3.2.1. Versioning of the IMG Metadata Fragment . . . . . . . 7 3.2.2. Detecting the IMG Metadata Fragment Format Type . . . 8 3.2.3. Securing IMG Envelope Integrity . . . . . . . . . . . 8 3.2.4. Reliable Delivery of IMG Envelope and IMG Metadata Fragment . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.5. Consistency Checking for IMG Metadata . . . . . . . . 9 3.2.6. Administrative Scope . . . . . . . . . . . . . . . . . 9 3.2.7. Resolving IMG Metadata Fragments to Resource Locations . . . . . . . . . . . . . . . . . . . . . . 9 3.2.8. Describing Multiple IMG Metadata Fragments within an Index Referencing Envelope . . . . . . . . . . . . 10 3.2.9. Using Multipart MIME to bind IMG Metadata Fragment Delivery . . . . . . . . . . . . . . . . . . . . . . . 10 4. IMG Envelope Format . . . . . . . . . . . . . . . . . . . . . 11 4.1. IMG Envelope Semantics . . . . . . . . . . . . . . . . . . 11 4.2. XML Syntax for the IMG Envelope . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6.1. Registration Request for XML Schema of IMG Envelope . . . 16 6.2. Considerations for application/envelope+xml Media-Type Registration . . . . . . . . . . . . . . . . . . . . . . . 16 6.2.1. Media-Type Registration Request for application/envelope+xml . . . . . . . . . . . . . . . 16 Walsh, et al. Expires August 6, 2007 [Page 2] Internet-Draft The IMG Envelope February 2007 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 8.1. Normative References . . . . . . . . . . . . . . . . . . . 19 8.2. Informative References . . . . . . . . . . . . . . . . . . 19 Appendix A. IMG Envelope Examples . . . . . . . . . . . . . . . . 21 A.1. SDP Metadata Fragment Embedded in an IMG Envelope . . . . 21 A.2. An IMG Envelope Referencing an XML Metadata Fragment . . . 21 A.3. An Index Referencing Envelope . . . . . . . . . . . . . . 22 Appendix B. IMG Architecture Terminology . . . . . . . . . . . . 23 Appendix C. IMG Architectural Description . . . . . . . . . . . . 27 C.1. IMG Metadata Structure and Fragmentation . . . . . . . . . 27 C.1.1. Fragmentation . . . . . . . . . . . . . . . . . . . . 27 C.1.2. Fragments within Fragments . . . . . . . . . . . . . . 27 C.2. IMG Metadata Discovery . . . . . . . . . . . . . . . . . . 27 C.2.1. Initial IMG Metadata Discovery . . . . . . . . . . . . 27 C.2.2. IMG Metadata Update Discovery . . . . . . . . . . . . 28 C.3. Support for Non-contiguous IMG Metadata Fragment Version Series . . . . . . . . . . . . . . . . . . . . . . 30 C.4. Detecting the IMG Metadata Fragment Format Type . . . . . 30 C.5. Reliable Delivery of IMG Metadata . . . . . . . . . . . . 31 C.6. Parsing and Storage of IMG Metadata Related to Delta Types . . . . . . . . . . . . . . . . . . . . . . . . . . 31 C.7. Security Considerations . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 Intellectual Property and Copyright Statements . . . . . . . . . . 34 Walsh, et al. Expires August 6, 2007 [Page 3] Internet-Draft The IMG Envelope February 2007 1. Introduction This document defines the format and use of Internet Media Guide (IMG) 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 files, resources and multimedia programs available for streaming or downloading via multicast or unicast. IMG metadata is encapsulated into, or associated with, an IMG envelope before it is passed to an IMG transport protocol. The purpose of the IMG envelope is to provide independence of metadata formats from transport protocols, and to enable versioning, updating and expiring of transmitted metadata. This specification provides the IMG envelope instantiation using structured Extensible Markup Language (XML) syntax [16], both as a wrapper in which to embed an IMG metadata object and as a distinct object to associate with a distinct IMG metadata object. Walsh, et al. Expires August 6, 2007 [Page 4] Internet-Draft The IMG Envelope February 2007 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]. IMG specific definitions can be found in the IMG architecture terminology (Appendix B). Walsh, et al. Expires August 6, 2007 [Page 5] Internet-Draft The IMG Envelope February 2007 3. IMG Envelope Usage 3.1. Applicability of an IMG Envelope A single IMG envelope shall describe a single IMG metadata fragment, and thus instances of the two are paired. 3.1.1. The Two IMG Envelope Cases An instance of IMG envelope shall be associated with an instance of IMG metadata fragment by one of two methods: - Embedded: The IMG metadata fragment is embedded within the IMG envelope. - Referenced: The IMG metadata fragment is referenced from the IMG envelope. Figures 1a and 1b illustrate the embedded and referenced cases. +-------------------+ +-------------------+ | IMG envelope | | IMG envelope | | { | | { | | | | | ----\ | ... | | ... | \ | } | | } | | | | +-------------------+ | | +---------------+ | | | | IMG metadata | | +-------------------+ / | | fragment | | | IMG metadata | <-/ | | { | | | fragment | | | ... | | | { | | | } | | | ... | | +---------------+ | | } | +-------------------+ +-------------------+ (a) (b) Figure 1: IMG Envelope: (a) Embedded Case, (b) Referenced Case In the embedded case, the IMG envelope and the IMG metadata fragment are, by definition, transported together and in-band of one another. In the referenced case, the IMG envelope and the IMG metadata fragment MAY be transported together and in-band, or out-of-band of one another using different transport sessions. An IMG sender SHALL make an IMG envelope instance available for each IMG metadata fragment instance. The creation and use of both an Walsh, et al. Expires August 6, 2007 [Page 6] Internet-Draft The IMG Envelope February 2007 embedded IMG envelope instance and a referenced IMG envelope instance for a particular IMG metadata fragment instance is permitted, but is not generally expected. Detailed discussion of the transport of IMG envelope and IMG metadata fragment are beyond the scope of this document, however, it is anticipated that IMG envelopes will be transported at least as often than their respective IMG metadata fragments. 3.1.2. Relationship with IMG Data Types An instance of an IMG envelope describes a certain instance of a certain IMG metadata fragment, irrespective of whether the complete, delta or pointer data type functionality is used. The content type (MIME type) of the IMG metadata fragment is used to differentiate complete and delta descriptions of an IMG metadata fragment, as described in Section 3.2.2. A referencing IMG envelope provides the pointer data type functionality by itself and SHOULD be used for this purpose where ever the pointer data type is implemented. 3.1.3. Relationship with IMG Operations An IMG envelope is used with the following logical IMG operations: IMG ANNOUNCE, IMG NOTIFY and IMG RESOLVE. 3.2. IMG Envelope Characteristics 3.2.1. Versioning of the IMG Metadata Fragment The version of an IMG metadata fragment SHALL be identified by a version field in the IMG envelope, irrespective of the IMG data type (i.e. for complete, delta and pointer types alike). The metadataURI ("metadataURI" is defined in Section 4 of this document) and version number SHALL resolve to a unique instance of the IMG metadata fragment (and its paired IMG envelope). The level of this uniqueness is dependent on the administrative scope of the metadataURI namespace and the version control. Note: The same version number is inherited to the IMG envelope as IMG envelope and IMG metadata fragment instances occur in matched pairs. Thus, there is no need for an additional "version number of the IMG envelope" attribute. Walsh, et al. Expires August 6, 2007 [Page 7] Internet-Draft The IMG Envelope February 2007 3.2.2. Detecting the IMG Metadata Fragment Format Type The IMG envelope SHALL provide a content type field. This field MUST provide the MIME type of the IMG metadata fragment when the IMG metadata fragment is embedded in the IMG envelope. This field MAY be used when the IMG metadata fragment is not embedded. 3.2.3. Securing IMG Envelope Integrity In general, the IMG envelope data SHOULD NOT be encrypted, although it can be signed. Unencrypted IMG envelope data allows IMG transceivers to cache and maintain IMG metadata without being required to be a trusted party able to decrypt the secure data. Note, an IMG system aside from the public Internet may chose to trust IMG transceivers, or exclude transceivers entirely. In these cases, and where no bearer-specific security method is used, there may be compelling reasons to encrypt this IMG envelope data and, since in this context the encryption of IMG envelope data presents no additional limitations, the previous recommendation may be ignored. IMG envelopes exposed to non-secure connections on the public Internet SHOULD be signed to lessen the risk of security attacks associated with delivery. The signature, and possible encryption, method(s) used are very much IMG envelope syntax and application specific. For example, one could use S/MIME [14] as the content encoding type for IMG metadata objects with an authentication wrapper, and one could use XML-DSIG [15] to digitally sign an IMG metadata fragment or an IMG envelope. Further specification on securing IMG envelopes is beyond the scope of this document. 3.2.4. Reliable Delivery of IMG Envelope and IMG Metadata Fragment The importance of the IMG envelope data and its timely delivery, relative to its associated IMG metadata fragment, will vary from one application and deployment to another. Where knowledge of data consistency (envelope usage) is a higher priority than ensuring perfect data consistency (metadata fragment usage) then it would be prudent to ensure the same or higher levels of reliability for the IMG envelope data, and vice versa. Providing similar levels of reliable delivery overhead for both the IMG envelope and IMG metadata fragment is a balanced approach. This would imply the same reliability method for the IMG envelope and the IMG metadata fragment pair. However, it does not imply the same Walsh, et al. Expires August 6, 2007 [Page 8] Internet-Draft The IMG Envelope February 2007 level of reliability as, in the case that a discrete IMG envelope object is significantly smaller in size than its discrete IMG metadata object, there will be a greater loss multiplier effect for the larger object (as it would be delivered using more IP packets providing a higher probability that one or more is lost in transit). Note: Providing a similar level of reliability overhead for an embedded IMG metadata fragment as its embedding IMG envelope is trivial since they are transported as a single object. 3.2.5. Consistency Checking for IMG Metadata The IMG envelope SHALL support time stamps to set the start and end times of the IMG metadata fragment applicability. The end time sets the expiry time for the IMG metadata fragment, so that: (a) a receiver would know that it needs to check whether its metadata is consistent with the sender, (b) if the IMG metadata fragment is no longer of use it may be discarded, (c) the same IMG metadata fragment version may be unchanged but have it's time validity changed (so the client would know that an update of the IMG metadata fragment is unnecessary although the expiry is extended or shortened). The start time may be used to postpone the use of an IMG metadata fragment until some future time. 3.2.6. Administrative Scope The definition of any administrative scope for source, aggregation or proxy functions on IMG metadata and IMG envelope is out of the scope of this document. It is assumed that the same administrative domain applies to both IMG envelope and IMG metadata fragment of a specific pair (note, this does not imply that they originate from the same source or even same domain). It is also assumed that the namespace is consistent with each name (URI) identifying only a single resource (although, naturally it may identify multiple instances/versions of that resource). Where the administrative domain does not impose its own naming conventions on the IMG envelope, the following naming convention SHOULD be used for the IMG envelope name (URI): envelopeURI = metadataURI + ".env" Note: "metadataURI" is defined in Section 4 of this document. 3.2.7. Resolving IMG Metadata Fragments to Resource Locations The IMG envelope MAY provide the mechanism to identify multiple locations which a single IMG metadata fragment may be found. Walsh, et al. Expires August 6, 2007 [Page 9] Internet-Draft The IMG Envelope February 2007 "alternativeURL", defined in Section 4, is used for this purpose. 3.2.8. Describing Multiple IMG Metadata Fragments within an Index Referencing Envelope It may be more efficient to describe multiple IMG metadata fragments in a single envelope object. Therefore an index referencing envelope may describe multiple IMG metadata fragments as different items within the envelope object, i.e., multiple referencing IMG envelopes are encapsulated into a single envelope object. 3.2.9. Using Multipart MIME to bind IMG Metadata Fragment Delivery In order to bind several IMG metadata fragments into a single transport object Multipart MIME may be used. In this case the first object of Multipart MIME should be an index referencing envelope as an index to all IMG metadata fragments. Walsh, et al. Expires August 6, 2007 [Page 10] Internet-Draft The IMG Envelope February 2007 4. IMG Envelope Format An IMG metadata fragment SHALL be encapsulated into or associated with an IMG envelope before it is passed to an IMG transport protocol for delivery. The IMG envelope enables each IMG metadata fragment to be uniquely identified and versioned in a uniform way independent of the particular IMG transport protocol used for delivery. The same IMG envelope format is used for the logical operations IMG ANNOUNCE, IMG NOTIFY and IMG RESOLVE. The next section describes the mandatory semantics for any IMG envelope format. The section after that describes the XML instantiation of the IMG envelope. For maximum interoperability, the given XML syntax SHOULD be used for textual representation of the IMG envelope. However, an IMG transport protocol MAY specify the use of an additional IMG envelope syntax, possibly providing a binary encoding of the XML format of this document. 4.1. IMG Envelope Semantics The following fields can be associated with the IMG metadata fragment. The fields are mandatory to include unless marked as optional. The following fields are described in the IMG envelope and thus associated with the respective IMG metadata fragment. Each field SHALL be included in any IMG envelope, except where specifically marked as optional. o metadataURI: A URI providing a unique identifier for the IMG metadata fragment. o alternativeURL: An optional one or multiple alternative URLs to locate metadata resource by different schemes. Where the metadataURI is URL it provides the first of the list of URLs. o version: The version number of the associated instance of the IMG metadata fragment. The version number should be initialized to one. The version number shall be increased by one whenever the IMG metadata fragment is updated. o validFrom: The date and time from which the IMG metadata fragment is valid. (Optional). If not used, the receiver SHOULD assume the IMG metadata fragment version is effective immediately. o validUntil: The date and time when the IMG metadata fragment expires. This sets the expiry time for the IMG metadata fragment. Walsh, et al. Expires August 6, 2007 [Page 11] Internet-Draft The IMG Envelope February 2007 (Optional). o contentType: The MIME type of the IMG metadata fragment. For textual representation, this MUST be used as defined for "Content- Type" in [4]. For IMG envelopes which embed their IMG metadata fragment this attribute is mandatory. For associations by reference (not embedded) this field is optional. An IMG envelope instantiation syntax MUST provide clear rules on the determination of embedded IMG metadata fragment start and end boundaries. Rules of how to avoid confusing the IMG envelope parser with data in the IMG metadata fragment (e.g. which resembles envelope data format) MUST be provided with any IMG envelope syntax specification. 4.2. XML Syntax for the IMG Envelope The following XML schema SHOULD be used for any textual instantiation of the IMG envelope: Walsh, et al. Expires August 6, 2007 [Page 12] Internet-Draft The IMG Envelope February 2007 BEGIN END Appendix A provides some IMG envelope XML instance examples which use this schema. This schema enables also use of the index referencing envelope. Thus the element "metadataEnvelope" can consist of multiple "item" elements, which are the actual IMG envelopes. When an envelope object is not an index referencing envelope there SHALL BE only one "item" element. The element "metadataFragment" contains the embedded IMG metadata Walsh, et al. Expires August 6, 2007 [Page 13] Internet-Draft The IMG Envelope February 2007 fragment. The IMG metadata fragment MUST NOT be embedded where referencing IMG envelope is used. The index referencing envelope SHALL contain only referencing IMG envelopes. As stated in the previous section, the contentType attribute is mandatory for any IMG envelope with an IMG metadata fragment embedding within it. The contentType is shown as optional in the above schema as it may be omitted for referencing IMG envelopes. An embedded IMG metadata fragment SHALL be escaped. Generally, an embedded IMG metadata fragment SHOULD be escaped by placing inside a CDATA section [16]. Everything starting after "" string would be ignored by the XML parser (quotes not included). Thus, the embedded parts would appear as "". In this case, the complete IMG envelope with embedded IMG metadata fragment MUST NOT violate the rules of CDATA section usage [16]. In the case of an IMG metadata fragment including the XML for a CDATA section, the embedded IMG metadata fragment MAY be escaped by replacing illegal characters with their ampersand-escaped equivalents [16] (instead of encapsulating the whole IMG metadata fragment in a CDATA section). For instance "<" is an illegal character that would be replaced by "<". This method is useful to avoid nesting CDATA sections (which is not allowed). An IMG metadata fragment which does not adhere to either of these two methods MUST NOT be embedded in an IMG envelope, thus it may only be referenced from an IMG envelope. Other strategies, such encoding binary IMG metadata fragments as base64 [8], could be useful. However, further specification of the correct structuring IMG metadata fragments to meet character escaping requirements for embedding is beyond the scope of this document. Walsh, et al. Expires August 6, 2007 [Page 14] Internet-Draft The IMG Envelope February 2007 5. Security Considerations The IMG envelope is not active content and so MUST NOT be used as executable code. In particular, an IMG envelope MUST NOT be instantiated as a self extracting archive, or indeed in any executable or script form. The XML IMG envelope specified in this document meets these criteria. Security issues associated with the media types described under the IANA Considerations section of this document have been investigated and no relevant problems have been identified. Walsh, et al. Expires August 6, 2007 [Page 15] Internet-Draft The IMG Envelope February 2007 6. IANA Considerations This specification contains two separate items for IANA Considerations: 1. Registration Request for XML Schema of IMG Envelope (urn:ietf:params:xml:schema:img-envelope). 2. Media-Type Registration Request for application/envelope+xml. 6.1. Registration Request for XML Schema of IMG Envelope Document [17] defines an IANA maintained registry of XML documents used within IETF protocols. The following is the registration request for the IMG Envelope XML schema. URI: urn:ietf:params:xml:schema:img-envelope Registrant Contact: Rod Walsh (rod.walsh (at) nokia.com) XML: The XML Schema specified in Section 4.2. 6.2. Considerations for application/envelope+xml Media-Type Registration The specified XML IMG envelope functions as an actual media format of use to the general Internet community and thus media type registration under the Standards Tree is appropriate to maximize interoperability. One subtype registration, of the application type, is requested: type-name = application subtype-name = envelope+xml "application/envelope+xml" shall describe the XML IMG envelope format and syntax as specified in Section 4.2 of this document. 6.2.1. Media-Type Registration Request for application/envelope+xml This section provides the registration request, as per [5] and [6], to be submitted to IANA following IESG approval. Type name: application Subtype name: envelope+xml Walsh, et al. Expires August 6, 2007 [Page 16] Internet-Draft The IMG Envelope February 2007 Required parameters: none Optional parameters: none Encoding considerations: The envelope+xml type consists of UTF-8 ASCII characters [7] and must be well-formed XML. Additional content and transfer encodings may be used with envelope+ xml files, with the appropriate encoding for any specific file being entirely dependant upon the deployed application. Restrictions on usage: Only for usage with IMG envelopes which are valid according to the XML schema of Section 4.2. Security considerations: envelope+xml data is passive, and does not generally represent a unique or new security threat. However, there is some risk in sharing any kind of data, in that unintentional information may be exposed, and that risk applies to envelope+xml data as well. Interoperability considerations: none Published specification: The present document including Sections 4.1 and 4.2. Applications which use this media type: Not restricted to any particular application. Additional information: Magic number(s): none File extension(s): An IMG envelope may use the extension ".env" but this is not required. Macintosh File Type Code(s): none Person & email address to contact for further information: Rod Walsh (rod.walsh (at) nokia.com) Intended usage: Common Author/Change controller: Rod Walsh (rod.walsh (at) nokia.com) Walsh, et al. Expires August 6, 2007 [Page 17] Internet-Draft The IMG Envelope February 2007 7. Acknowledgements We would like to extend special thanks to Toni Paila, Jean-Pierre Evain, Harsh Mehta and Joerg Ott whose support for, review of, and input to this specification has been very helpful. Walsh, et al. Expires August 6, 2007 [Page 18] Internet-Draft The IMG Envelope February 2007 8. References 8.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [2] Nomura, Y., Walsh, R., Luoma, J-P., Ott, J., and H. Schulzrinne, "Requirements for Internet Media Guides (IMGs)", RFC 4473, May 2006. [3] Nomura, Y., Walsh, R., Luoma, J-P., Asaeda, H., and H. Schulzrinne, "A Framework for the Usage of Internet Media Guides (IMGs)", RFC 4435, April 2006. [4] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [5] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC 2048, BCP 13, November 1996. [6] Murata, M., St.Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001. [7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. 8.2. Informative References [8] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 3548, July 2003. [9] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [10] Paila, T., Luby, M., Lehtonen, R., Roca, V., and R. Walsh, "FLUTE - File Delivery over Unidirectional Transport", RFC 3926, October 2004. [11] Holbrook, H. and B. Gain, "Source-Specific Multicast for IP", draft-ietf-ssm-arch-07 (work in progress), October 2005. [12] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. Walsh, et al. Expires August 6, 2007 [Page 19] Internet-Draft The IMG Envelope February 2007 [13] Deering, S., "Host Extensions for IP Multicasting", RFC 1112, STD 5, August 1989. [14] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999. [15] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup Language) XML-Signature Syntax and Processing"", RFC 3275, March 2002. [16] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., Yergeau, F., and J. Cowan, "Extensible Markup Language (XML) 1.1"", W3C Recommendation, February 2004. [17] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004. Walsh, et al. Expires August 6, 2007 [Page 20] Internet-Draft The IMG Envelope February 2007 Appendix A. IMG Envelope Examples A.1. SDP Metadata Fragment Embedded in an IMG Envelope Figure 2. gives an informational example of a Complete IMG Description in SDP [12] embedded within the XML IMG envelope. 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 embedding IMG envelope A.2. An IMG Envelope Referencing an XML Metadata Fragment Figure 3. gives an informational example of the XML IMG envelope referencing an IMG metadata fragment. Walsh, et al. Expires August 6, 2007 [Page 21] Internet-Draft The IMG Envelope February 2007 Figure 3: Example of a Referencing IMG Envelope A.3. An Index Referencing Envelope Figure 4. gives an informational example of the index referencing envelope referencing multiple IMG metadata fragments. metadataURI="http/www.example.com/img001/service004.xml" version="1" validUntil="2005-12-16T09:30:47-05:00" /> Figure 4: Example of an Index Referencing Envelope Walsh, et al. Expires August 6, 2007 [Page 22] Internet-Draft The IMG Envelope February 2007 Appendix B. IMG Architecture Terminology NOTE: The following can be replaced by a reference to an eventual IMG architecture specification which includes these definitions. Complete IMG Description Provides a complete syntax and semantics to describe an IMG metadata fragment, which does not need any additional information from other IMG descriptions. It may contain either a full IMG or, more commonly, a subset thereof. 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. Full IMG Represents a subset/whole of the sender's IMG database delivered within the scope of one IMG transport session. (In this context, the sender's database represents the metadata which the sender has access to, some or all of the IMG metadata may be stored locally on the IMG sender in question.) A sender may deliver only a subset of metadata from its whole metadata database 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. Federations of senders using the same definition of full IMG are allowed. 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 IMG ANNOUNCE is an IMG operation for the unsolicited delivery of IMG metadata from an IMG sender to IMG receiver(s). Walsh, et al. Expires August 6, 2007 [Page 23] Internet-Draft The IMG Envelope February 2007 References to parts of IMG metadata may also be included, instead of the actual metadata. IMG Description An IMG metadata fragment in one of three forms: 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 may describe many things, such as 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 Metadata Fragment IMG metadata that is identified distinctly from other IMG metadata. The uniqueness of the identification will be a function of the administrative scope required. An IMG metadata fragment is distinct from an IMG element in that the former may contain multiple IMG elements and the mapping of IMG elements to IMG metadata fragments, for transport, may be deployment specific - even if some of the same content, and IMG elements descriptions of that content, are common to multiple deployments. IMG Metadata Object A distinct and individually transportable set of IMG metadata such as an IMG metadata fragment or an IMG envelope with an embedded IMG metadata fragment. 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. Walsh, et al. Expires August 6, 2007 [Page 24] Internet-Draft The IMG Envelope February 2007 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 Provides a reference that the receiver is able to address specific metadata with. An IMG Pointer may be used to separately obtain (transport) IMG elements, or perform another IMG management function such as data expiry and erasure. 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 transceiver. IMG Transceiver An IMG transceiver combines an IMG receiver and sender. It may modify received IMG metadata or merge IMG metadata received from a several different IMG senders. IMG Transport Protocol Walsh, et al. Expires August 6, 2007 [Page 25] Internet-Draft The IMG Envelope February 2007 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 interactions that provide delivery of IMG metadata from the sender to the receiver(s). IMG Update Notification Contains IMG Pointer(s) that identify the changed parts of an IMG metadata fragment. An IMG update notification is similar to a Delta IMG Description, with the exception that the changed IMG metadata is not included in this IMG description. Walsh, et al. Expires August 6, 2007 [Page 26] Internet-Draft The IMG Envelope February 2007 Appendix C. IMG Architectural Description C.1. IMG Metadata Structure and Fragmentation C.1.1. Fragmentation An IMG sender SHALL select the subset (or entirety) of available IMG metadata that it will make available to IMG receivers using IMG ANNOUNCE and/or IMG RESOLVE. This represents a sender's full IMG and delimits the quantity and level of dynamics a sender must maintain. The IMG sender SHALL structure its full IMG as a set if IMG metadata fragments, each corresponding to a Complete IMG Description. To IMG transport protocols, an IMG metadata fragment is a discrete unit that can be uniquely identified and versioned. Note, multiple IMG senders may form a federation of senders/servers and share a common definition of their full IMG and fragmentation structure, and this may additionally be administered by some other entity in the same domain. This document intentionally provides no advice or requirements on federations of senders. C.1.2. Fragments within Fragments An IMG metadata fragment may contain some or all of the description of one or more other IMG metadata fragments. However, this requires a more complex data model, namespace and metadata maintenance mechanisms in both senders and receivers. Some data syntaxes provide tools to simplify the implementation of this kind of feature, such as XPath in XML. However, the use of a general container mechanism must be considered wherever using multiple syntaxes and syntaxes without built-in namespace tools. Grouping mechanisms at the transport layer and Multipart MIME [9] are particularly good candidates for a virtual container and a fully encapsulating container. Any such container is a distinct IMG metadata fragment. C.2. IMG Metadata Discovery The following sections describe the use of IMG envelope to support both initial and update discovery of IMG. C.2.1. Initial IMG Metadata Discovery An IMG receiver may need to receive a larger amount of IMG metadata when the terminal has just started receiving from a particular IMG sender, or when its cached copies of IMG metadata cannot be synchronized with IMG updates or have been outdated. Walsh, et al. Expires August 6, 2007 [Page 27] Internet-Draft The IMG Envelope February 2007 The IMG receiver MUST maintain the version numbers of each IMG metadata fragment to avoid duplication and for update discovery. How the IMG receiver knows when it has received all the IMG metadata fragments it requires (i.e. the determination of an IMG receiver's "full IMG") is out of the scope of this document. C.2.2. IMG Metadata 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. An IMG receiver may monitor the following types of IMG metadata from an IMG sender for changes: 1. Complete description transfers (IMG ANNOUNCE or IMG RESOLVE) 2. Delta description transfers (IMG ANNOUNCE or IMG RESOLVE) 3. IMG update notifications, i.e. Pointer transfers (IMG NOTIFY, IMG ANNOUNCE or IMG RESOLVE) The receiver will learn of any changes in the IMG metadata by continuing to receive the complete description transfers, for example by periodically using an IMG RESOLVE, or by receiving transmissions of the metadata via IMG ANNOUNCE. However, the use of delta description transfers and/or IMG update notifications may provide more efficient means for update discovery. A Delta IMG Description provides only part of a Complete IMG Description, defining the difference from a previous version of the Complete IMG Description in question. An IMG receiver MAY ignore delta descriptions and MAY silently discard them: this allows simple "complete-only" receivers to be used wherever the complexity of implementing the delta mechanisms in those receivers is not justified, while not preventing forward migration to delta functionality in the same deployment. (There may be utility in using a only the metadata management (e.g. versioning) information of a delta even in the case of ignoring delta metadata (i.e. using just the pointer data from a delta), however this is beyond the scope of this document.) The content type of an IMG metadata fragment identifies whether it is a delta description. Other means of delta description type identification, such as dedicated delta transport channels, are also permitted but are beyond the scope of this document. In the absence of another delta description type identification type, the transport mechanism SHOULD identify the content type (i.e. using Content-Type in the HTTP header [4] and Content-Type in the FLUTE FDT Instances Walsh, et al. Expires August 6, 2007 [Page 28] Internet-Draft The IMG Envelope February 2007 [10]). In the case of an embedding IMG envelope, the content type MUST be given by the IMG envelope, and there is no further requirement on the transport mechanism to declare this. As with a complete description, a delta description's content type enables a receiver to identify which component should handle this data (i.e. is capable of patching that type of delta description). The content type of the base version (complete description) may also be useful in selecting and configuring the patching component's. Delta IMG Description content types SHOULD be IANA registered. The default behaviour of a delta-capable IMG receiver is to interpret the version of the delta description as a single increment from the previous version. In the default case, before applying the incremental patch the receiver MUST have full knowledge of the previous version (it must have received a complete description of the previous version, or have reconstructed it using previous delta description(s) and an earlier version of complete description). Otherwise, the receiver MUST NOT apply the incremental patch. Other patching behaviour, such as multiple minor delta versions to be applied to a common major complete version, are permitted but require additional signalling to the receiver(s) and are beyond the scope of this document. Where deltas are deployed, an IMG sender SHALL deliver Delta IMG Descriptions using IMG ANNOUNCE, IMG RESOLVE or both operations. After receiving sufficient IMG metadata, an IMG receiver may continue receiving only delta descriptions, if available, instead of complete descriptions. Each delta description describes the IMG metadata (of an IMG metadata fragment) that has 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 metadata fragment; this can be accomplished by checking the version field in the IMG envelope. The IMG receiver may attempt 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). Note, whether or not a receiver needs to get missing updates is implementation specific. 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 Walsh, et al. Expires August 6, 2007 [Page 29] Internet-Draft The IMG Envelope February 2007 recently (e.g. since the previous complete description). 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 descriptions using either IMG ANNOUNCE or IMG QUERY. C.3. Support for Non-contiguous IMG Metadata Fragment Version Series The system and transport protocol determines the delivery frequency and delivery methods of IMG envelopes and IMG metadata fragments. However, two specific rules apply in the case that an IMG sender updates an IMG metadata fragment more than once between subsequent deliveries: - The delta data type MUST NOT be used if the previous version IMG metadata fragment was not delivered to the same receiver-base. Note, "receiver-base" may be a single receiver, for unicast IMG transport protocols, or a user group, for multicast IMG transport protocols. With the possible exception of a case where a receiver confirms multicast delivery to a sender, this implies that delta descriptions must be preceded by zero or more delta descriptions each one version apart and, preceding those, a complete descriptions using the same transport protocol context - i.e. the same protocol and with some context (transaction history) preserved. - IMG receiver SHALL support reception of subsequent IMG metadata fragment versions, also where the version number has increased by more than one (i.e. where one or more intermediate versions were not send or else lost in delivery). Note: If the previous received version is earlier than one less than the latest received version, and the latest version delivered is a delta description, the receiver should assume an error has occurred. It may not be possible to determine whether the missed intermediate versions were due to sender, delivery or receiver error. Further discussion of action upon detection of such and error is out of scope of this document. C.4. Detecting the IMG Metadata Fragment Format Type For IMG metadata fragments associated with their IMG envelope (not embedded) the MIME type of the IMG metadata fragment SHOULD be provided by the IMG transport protocol (e.g. as a Content-Type text string or a well-specified binary encoded enumeration). Use of IANA registered MIME types is RECOMMENDED to ensure maximum interoperability. The specific IMG metadata fragment formats (and syntaxes) supported may be implementation depended, although the Walsh, et al. Expires August 6, 2007 [Page 30] Internet-Draft The IMG Envelope February 2007 following IANA registered MIME types may be of particular interest: - application/sdp - application/xml - multipart/mixed C.5. Reliable Delivery of IMG Metadata Reliable delivery of IMG metadata is a feature of the IMG transport protocol(s) used and the technology suited to providing this very much depends on the receiver base/group size and the selection of unicast/multicast and bi-directional/unidirectional transport. Reliability technology candidates include ACK, NACK, resend, repetition and FEC schemes. C.6. Parsing and Storage of IMG Metadata Related to Delta Types The IMG transport protocol(s) should support all three IMG data types (complete, delta and pointer). (This only implies that the use of any data type shall not break the IMG transport protocol and does not imply that a sender uses all three data types or that a receiver harvests all three.) An IMG transport protocol MUST NOT assume that an IMG metadata fragment is a complete description. An implementation of an IMG transport protocol, IMG envelope management and IMG metadata fragment management may or may not be a single software entity. However, an IMG receiver (software) component that is not capable of correctly using delta descriptions SHOULD NOT process them and it SHOULD hand them to a component that is capable of producing a new IMG metadata fragment by correctly patching the previous version with the delta. A simple IMG receiver MAY discard delta descriptions in the same way it would discard complete descriptions whose MIME type is unknown. However, in the case where the proportion of such simple IMG receivers in the receiver-base is significant, the system design MAY be, preferably, limited to not send delta descriptions and so avoid the increased diversity in level of sender-receiver data consistency. However, both of these approaches are generally NOT RECOMMENDED. C.7. 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 protocol. IMG receivers also SHOULD NOT trust IMG metadata modified by an IMG transceiver, unless the IMG transceiver is trusted and then integrity and authenticity of the changes must be similarly verified. However, to operate in a typical network environment lacking infrastructure Walsh, et al. Expires August 6, 2007 [Page 31] Internet-Draft The IMG Envelope February 2007 for key distribution and trust verification, IMG receivers MAY be configured to accept untrusted IMG metadata. There may also be a 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 SHALL be fulfilled by the use of encryption at IMG metadata level or by IMG transport protocol or IP network protocol. For multicast delivery of IMG metadata it is also recommended that SSM [11] rather than ASM [13] delivery is used so that tampered IMG envelopes can be limited to man-in-the-middle attacks. The following guidance is provided for designers and implementers of specific IMG metadata fragments. If there is any active content within an IMG metadata fragment, take care to identify, document and (if reasonable) solve the security risks associated with your use of active content. A delta description would normally be used by a "patching application" and so delta description might include data on actions for such an application that could resemble a script (e.g. remove this attribute, change that value). Thus the design and implementation of any "delta patching application" for use with IMGs must address security risks arising from the potential use of a delta description as active content. The authors do not anticipate that Java (or other) application code will be designated as IMG metadata. Walsh, et al. Expires August 6, 2007 [Page 32] Internet-Draft The IMG Envelope February 2007 Authors' Addresses Rod Walsh Nokia P.O. Box 100 (Visiokatu 1) Tampere FIN-33721 Finland Email: rod.walsh (at) nokia.com Juha-Pekka Luoma Nokia P.O. Box 100 (Visiokatu 1) Tampere FIN-33721 Finland Email: juha-pekka.luoma (at) nokia.com Jani Peltotalo Tampere University of Technology P.O. Box 553 (Korkeakoulunkatu 1) Tampere FIN-33101 Finland Email: jani.peltotalo (at) tut.fi Sami Peltotalo Tampere University of Technology P.O. Box 553 (Korkeakoulunkatu 1) Tampere FIN-33101 Finland Email: sami.peltotalo (at) tut.fi Janico Greifenberg Universitaet Bremen MZH 5520 Bibliothekstr. 1 Bremen D-28359 Germany Email: jgre (at) tzi.de Walsh, et al. Expires August 6, 2007 [Page 33] Internet-Draft The IMG Envelope February 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Walsh, et al. Expires August 6, 2007 [Page 34]