MMUSIC R. Walsh Internet-Draft J-P. Luoma Expires: April 15, 2005 Nokia J. Peltotalo S. Peltotalo Tampere University of Technology October 15, 2004 The IMG Envelope draft-walsh-mmusic-img-envelope-00 Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. 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 April 15, 2005. Copyright Notice Copyright (C) The Internet Society (2004). 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 Walsh, et al. Expires April 15, 2005 [Page 1] Internet-Draft The IMG Envelope October 2004 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 fragment 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. IMG Envelope Usage . . . . . . . . . . . . . . . . . . . . . . 9 4.1 Applicability of an IMG Envelope . . . . . . . . . . . . . 9 4.1.1 The Two IMG Envelope Cases . . . . . . . . . . . . . . 9 4.1.2 Relationship with IMG Metadata Data Types . . . . . . 10 4.1.3 Relationship with IMG Operations . . . . . . . . . . . 10 4.2 IMG Metadata Structure and Fragmentation . . . . . . . . . 10 4.2.1 Fragmentation . . . . . . . . . . . . . . . . . . . . 10 4.2.2 Fragments within Fragments . . . . . . . . . . . . . . 10 4.3 IMG Metadata Discovery . . . . . . . . . . . . . . . . . . 11 4.3.1 Initial IMG Metadata Discovery . . . . . . . . . . . . 11 4.3.2 IMG Metadata Update Discovery . . . . . . . . . . . . 11 4.4 Versioning of the IMG Metadata Fragment . . . . . . . . . 12 4.4.1 Support for Non-contiguous Version Series . . . . . . 12 4.5 Detecting the IMG Metadata Fragment Format Type . . . . . 13 4.6 Securing IMG Envelope Integrity . . . . . . . . . . . . . 14 4.7 Reliable Delivery of IMG Envelope and Fragment Data . . . 14 4.8 Parsing and Storage of IMG Metadata . . . . . . . . . . . 15 4.9 Administrative Scope . . . . . . . . . . . . . . . . . . . 16 5. IMG Envelope Format . . . . . . . . . . . . . . . . . . . . . 17 5.1 IMG Envelope Semantics . . . . . . . . . . . . . . . . . . 17 5.2 XML Syntax for the IMG Envelope . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 7.1 Media-Type Registration Request for application/envelope+xml . . . . . . . . . . . . . . . . . 22 7.2 Media-Type Registration Request for application/envelope . . . . . . . . . . . . . . . . . . . 23 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 26 9.2 Informative References . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27 A. IMG Envelope Examples . . . . . . . . . . . . . . . . . . . . 29 A.1 SDP Metadata Fragment Embedded in an IMG Envelope . . . . 29 A.2 An IMG Envelope Referencing an XML Metadata Fragment . . . 29 Walsh, et al. Expires April 15, 2005 [Page 2] Internet-Draft The IMG Envelope October 2004 B. Relationship with IMG Requirements . . . . . . . . . . . . . . 31 Intellectual Property and Copyright Statements . . . . . . . . 32 Walsh, et al. Expires April 15, 2005 [Page 3] Internet-Draft The IMG Envelope October 2004 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 April 15, 2005 [Page 4] Internet-Draft The IMG Envelope October 2004 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]. Walsh, et al. Expires April 15, 2005 [Page 5] Internet-Draft The IMG Envelope October 2004 3. Terminology 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. [3] 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. [3] 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. (This definition is copied verbatim from [3].) IMG ANNOUNCE IMG ANNOUNCE is an IMG operation for the unsolicited delivery of IMG metadata from an IMG sender to IMG receiver(s) [3]. References to parts of IMG metadata may also be included, instead of the actual metadata. [3] IMG Description An IMG metadata fragment in one of three forms: Complete IMG Description, Delta IMG Description and IMG Pointer. (This definition is copied from [3] with modifications.) IMG Element The smallest atomic element of IMG metadata that can be transmitted separately and referenced individually from other IMG elements. (This definition is copied verbatim from [3].) IMG Metadata A set of metadata consisting of one or more IMG elements. IMG metadata may describe many things, such as the features of Walsh, et al. Expires April 15, 2005 [Page 6] Internet-Draft The IMG Envelope October 2004 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. (This definition is copied from [3] with modifications.) 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. [3] 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. [3] 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. [3] IMG Operation An atomic process for the IMG transport protocol to deliver IMG metadata or control IMG sender(s) or IMG receiver(s). (This definition is copied from [3] with modifications.) 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. [3] IMG QUERY Request to receive a delivery of IMG metadata. [3] IMG Receiver A logical entity that receives media guides from an IMG sender, analogous to a client. (This definition is copied from [3] with modifications.) 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. [3] 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. (This definition is copied from [3] with modifications.) Walsh, et al. Expires April 15, 2005 [Page 7] Internet-Draft The IMG Envelope October 2004 IMG SUBSCRIBE A request for notifications of changes in IMG metadata updates, from a receiver to a sender or transceiver. [3] 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. (This definition is copied verbatim from [3].) IMG Transport Protocol A protocol that transports IMG metadata from IMG sender to IMG receiver(s). (This definition is copied verbatim from [3].) 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). (This definition is copied verbatim from [3].) 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. [3] Walsh, et al. Expires April 15, 2005 [Page 8] Internet-Draft The IMG Envelope October 2004 4. IMG Envelope Usage 4.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. 4.1.1 The Two IMG Envelope Cases An instance of IMG envelope shall be associated an instance of an 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 envelope and fragment are, by definition, transported together and in-band of one another. In the referenced case, the envelope and 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 embedded envelope instance and a referenced envelope instance for a particular fragment instance is permitted, but is not generally expected. Walsh, et al. Expires April 15, 2005 [Page 9] Internet-Draft The IMG Envelope October 2004 Detailed discussion of the transport of envelope and fragment are beyond the scope of this document, however, it is anticipated that envelopes will be transported at least as often than their respective fragments. 4.1.2 Relationship with IMG Metadata 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 fragment is used to differentiate complete and delta descriptions of a metadata fragment, as described in section 4.5. A referencing envelope provides the functionality the pointer data type by itself and SHOULD be used for this purpose where it is implemented. 4.1.3 Relationship with IMG Operations An IMG envelope is used with the following logical IMG operations: IMG ANNOUNCE, IMG NOTIFY and IMG RESOLVE. The following sections describe the use of IMG envelope to support both initial and update discovery of IMG. 4.2 IMG Metadata Structure and Fragmentation 4.2.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. 4.2.2 Fragments within Fragments An IMG metadata fragment may contain some or all of the description Walsh, et al. Expires April 15, 2005 [Page 10] Internet-Draft The IMG Envelope October 2004 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. 4.3 IMG Metadata Discovery 4.3.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. 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. 4.3.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. Delta transfer means transferring only the parts of the IMG metadata that have changed from the last version of the complete description transfer, whereas sending an IMG update notification means transferring IMG Pointers identifying the parts of the IMG metadata that have changed from the last version of the complete description transfer. Walsh, et al. Expires April 15, 2005 [Page 11] Internet-Draft The IMG Envelope October 2004 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 a 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 fragment; this can be accomplished by checking the version field (see section 5.1 for definition) 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 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. 4.4 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 (see section 5.1 for definition) 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 envelope" attribute. 4.4.1 Support for Non-contiguous Version Series The system and transport protocol determines the delivery frequency and delivery methods of envelopes and fragments. However, two Walsh, et al. Expires April 15, 2005 [Page 12] Internet-Draft The IMG Envelope October 2004 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 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. 4.5 Detecting the IMG Metadata Fragment Format Type The IMG envelope SHALL provide a contentType field (see section 5.1 for definition). This field MUST provide the MIME type of the IMG metadata fragment when the IMG metadata fragment is embedded in the envelope. This field MAY be used when the IMG metadata fragment is not embedded. 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 following IANA registered MIME types may be of particular interest: - application/sdp - application/xml - multipart/mixed Walsh, et al. Expires April 15, 2005 [Page 13] Internet-Draft The IMG Envelope October 2004 4.6 Securing IMG Envelope Integrity In general, the IMG envelope data SHOULD NOT be encrypted, although it can be signed. Unencrypted 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 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 envelope. Further specification on securing IMG envelopes is beyond the scope of this document. 4.7 Reliable Delivery of IMG Envelope and Fragment Data 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. Thus, the following text is for guidance when designing or selecting IMG transport protocol(s) and the system architecture they are used with. 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 (fragment usage) then it would be prudent to ensure the same or higher levels of reliability for the envelope data, and vice versa. Providing similar levels of reliable delivery overhead for both the IMG envelope and IMG metadata fragment is a balance approach. Walsh, et al. Expires April 15, 2005 [Page 14] Internet-Draft The IMG Envelope October 2004 This would imply the same reliability method for the envelope and fragment pair. However, it does not imply the same level of reliability as, in the case that a discrete envelope object is significantly smaller in size than its discrete fragment 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 fragment as its embedding envelope is trivial since they are transported as a single object. 4.8 Parsing and Storage of IMG Metadata The IMG envelope SHALL provide option to use time stamps to set the start and end times of the IMG metadata fragment applicability. The end time sets the expiry time for the 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 metadata fragment is no longer of use it may be discarded, (c) the same fragment version may be unchanged but have it's time validity changed (so the client would know that an update of the 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. 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. Further details of parsing and storage of IMG metadata are Walsh, et al. Expires April 15, 2005 [Page 15] Internet-Draft The IMG Envelope October 2004 implementation specific and so further specification of these is beyond the scope of this document. 4.9 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 5 of this document. Walsh, et al. Expires April 15, 2005 [Page 16] Internet-Draft The IMG Envelope October 2004 5. 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 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. 5.1 IMG Envelope Semantics The following fields/attributes can be associated with the IMG metadata fragment. The attributes are mandatory to include unless marked as optional. The following fields/attributes are described in the IMG envelope and thus associated with the respective IMG metadata fragment. Each attribute 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 version: The version number of the associated instance of the IMG metadata fragment. The version number should be initialized to zero. The version number shall be increased by one whenever the IMG metadata fragment is updated. o validFrom: The date and time from which the metadata is valid. (Optional). If not used, the receiver SHOULD assume the fragment version is effective immediately. o validUntil: The date and time when the metadata expires. This sets the expiry time for the metadata fragment. (Optional). o contentType: The MIME type of the IMG metadata fragment. For textual representation, this SHOULD 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 attribute is optional. An IMG envelope instantiation syntax MUST provide clear rules on the determination of embedded fragment start and end boundaries. Rules of how to avoid confusing the envelope parser with data in the Walsh, et al. Expires April 15, 2005 [Page 17] Internet-Draft The IMG Envelope October 2004 fragment (e.g. which resembles envelope data format) MUST be provided with any IMG envelope syntax specification. 5.2 XML Syntax for the IMG Envelope The following XML schema SHOULD be used for any textual instantiation of the IMG envelope: Figure 2: XML Schema of the IMG Envelope XML Instance Appendix A provides some IMG envelope XML instance examples which use this schema. The element "metadataFragment" SHALL be included in the IMG envelope for embedded IMG metadata fragments, and SHALL NOT be included where Walsh, et al. Expires April 15, 2005 [Page 18] Internet-Draft The IMG Envelope October 2004 the IMG metadata fragment is not embedded. "metadataFragment" contains the embedded IMG metadata fragment as specified by the IMG envelope syntax. 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 envelope 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 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 fragments as base64 [6], 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 April 15, 2005 [Page 19] Internet-Draft The IMG Envelope October 2004 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 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 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 [5] rather than ASM [13] delivery is used so that tampered envelopes can be limited to man-in-the-middle attacks. 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. Specific IMG metadata fragments are beyond the scope of this document. However the following guidance is provided for designers and implementers of any such 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. Security issues associated with the media types describe under the Walsh, et al. Expires April 15, 2005 [Page 20] Internet-Draft The IMG Envelope October 2004 IANA Considerations section of this document have been investigated and no relevant problems have been identified. Note, although we have taken security considerations seriously, there is always a chance that we overlooked something apparent to the wider Internet community. So we warmly encourage readers to inform us of any additional issues, certain and uncertain! Walsh, et al. Expires April 15, 2005 [Page 21] Internet-Draft The IMG Envelope October 2004 7. IANA Considerations 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. Two subtype registrations, of the application type, are requested: type-name = application subtype-name = envelope+xml type-name = application subtype-name = envelope "application/envelope+xml" shall describe the XML IMG envelope format and syntax as specified in section 5.2 of this document. "application/envelope" shall describe any IMG envelope conforming to the semantics specified in section 5.1 of this document, with the exception of the XML instantiation specified in section 5.2 of this document. It is HIGHLY RECOMMENDED that any additional IMG envelope instantiations, other than that defined in section 5.2 of this document, of interest to the general Internet community are registered as "application/envelope.reg-name" under the Standards Tree where: reg-name = 1*reg-name-chars reg-name-chars = ALPHA / DIGIT // "!" / "#" / "$" / "%" / "&" / "." / "+" / "-" / "^" / "_" 7.1 Media-Type Registration Request for application/envelope+xml This section provides the registration request, as per [7] and [8], to be submitted to IANA following IESG approval. Type name: application Subtype name: envelope+xml Required parameters: none Optional parameters: none Encoding considerations: The envelope+xml type consists of UTF-8 ASCII characters [10] and must be well-formed XML. Walsh, et al. Expires April 15, 2005 [Page 22] Internet-Draft The IMG Envelope October 2004 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 5.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:
Published specification: The present document including sections 5.1 and 5.2 Applications which use this media type:
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@nokia.com) Intended usage: Common Author/Change controller:
7.2 Media-Type Registration Request for application/envelope This section provides the registration request, as per [RFC2048], to be submitted to IANA following IESG approval. Type name: application Subtype name: envelope Required parameters: none Optional parameters: none Encoding considerations:
Walsh, et al. Expires April 15, 2005 [Page 23] Internet-Draft The IMG Envelope October 2004 Additional content and transfer encodings may be used with envelope 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 meet the semantics of section 5.1 except for those which are valid according to the XML schema of section 5.2 - where envelope+xml must be used. Security considerations: envelope data shall be 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 data as well. Interoperability considerations:
Published specification: The present document including sections 5.1 and 5.2 Applications which use this media type:
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@nokia.com) Intended usage: Limited use Author/Change controller:
Walsh, et al. Expires April 15, 2005 [Page 24] Internet-Draft The IMG Envelope October 2004 8. 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 April 15, 2005 [Page 25] Internet-Draft The IMG Envelope October 2004 9. References 9.1 Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCD 14, March 1997. [2] Walsh, R., Nomura, Y., Luoma, J-P., Ott, J. and H. Schulzrinne, "Protocol Requirements for Internet Media Guides", draft-ietf-mmusic-img-req-07 (work in progress), June 2004. [3] Nomura, Y., Walsh, R., Luoma, J-P., Asaeda, H. and H. Schulzrinne, "A Framework for the Usage of Internet Media Guides", draft-ietf-mmusic-img-framework-08 (work in progress), July 2004. [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] Holbrook, H. and B. Gain, "Source-Specific Multicast for IP", draft-ietf-ssm-arch-06 (work in progress), September 2004. [6] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 3548, July 2003. [7] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC 2048, BCP 13, November 1996. [8] Murata, M., St.Laurent, S. and D. Kohn, "XML Media Types", RFC 3023, January 2001. [9] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [10] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. 9.2 Informative References [11] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [12] Ott, J., Bormann, C. and D. Kutscher, "Session Description and Capability Negotiation", draft-ietf-mmusic-sdpng-07 (work in progress), October 2003. Walsh, et al. Expires April 15, 2005 [Page 26] Internet-Draft The IMG Envelope October 2004 [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. Authors' Addresses Rod Walsh Nokia P.O. Box 100 (Visiokatu 1) Tampere FIN-33721 Finland EMail: rod.walsh@nokia.com 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 Walsh, et al. Expires April 15, 2005 [Page 27] Internet-Draft The IMG Envelope October 2004 Sami Peltotalo Tampere University of Technology P.O. Box 553 (Korkeakoulunkatu 1) Tampere FIN-33101 Finland EMail: sami.peltotalo@tut.fi Walsh, et al. Expires April 15, 2005 [Page 28] Internet-Draft The IMG Envelope October 2004 Appendix A. IMG Envelope Examples A.1 SDP Metadata Fragment Embedded in an IMG Envelope Figure 3 gives an informational example of a Complete IMG Description in SDP [11] embedded within the XML IMG envelope. contentType="application/sdp" 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 3: Example of an IMG envelope A.2 An IMG Envelope Referencing an XML Metadata Fragment Figure 4 gives an informational example of an IMG envelope referencing a non-embedded IMG metadata fragment. Walsh, et al. Expires April 15, 2005 [Page 29] Internet-Draft The IMG Envelope October 2004 Figure 4: Example of a Referencing IMG Envelope Walsh, et al. Expires April 15, 2005 [Page 30] Internet-Draft The IMG Envelope October 2004 Appendix B. Relationship with IMG Requirements Walsh, et al. Expires April 15, 2005 [Page 31] Internet-Draft The IMG Envelope October 2004 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2004). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Walsh, et al. Expires April 15, 2005 [Page 32]