MMUSIC J. Luoma Internet-Draft Nokia Expires: April 26, 2004 October 27, 2003 A Metadata Framework for Internet Media Guides: Metadata Envelope and Baseline Data Model draft-luoma-mmusic-img-metadata-02 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 26, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document defines the base metadata format for Internet Media Guides (IMGs), applicable to a wide variety of Internet hosts and communication links. IMG metadata describes files, resources and multimedia programs available for streaming or downloading via multicast or unicast. An IMG metadata model, semantics of the IMG media metadata entities, and an XML-based framing structure for IMG media metadata are defined. The aim is to reuse existing metadata standards for the IMG metadata format where possible. Luoma Expires April 26, 2004 [Page 1] Internet-Draft IMG Metadata October 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 4. The Use of IMG Metadata for IP Media Discovery . . . . . . . 7 4.1 Initial Discovery . . . . . . . . . . . . . . . . . . . . . 7 4.2 Update Discovery . . . . . . . . . . . . . . . . . . . . . . 7 5. IMG Metadata Model . . . . . . . . . . . . . . . . . . . . . 9 5.1 The Relational Part of IMG Metadata . . . . . . . . . . . . 9 5.1.1 IMG Root . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1.2 Category . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1.3 IP Service Portal . . . . . . . . . . . . . . . . . . . . . 12 5.1.4 IP Service Unit . . . . . . . . . . . . . . . . . . . . . . 13 5.1.5 Access Info . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1.6 IP Service Bundle . . . . . . . . . . . . . . . . . . . . . 13 5.1.7 IP Service . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.2 The Session Part of IMG Metadata . . . . . . . . . . . . . . 14 5.2.1 IP Session . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.2.2 IP Session Component . . . . . . . . . . . . . . . . . . . . 15 5.2.3 Scheduling Info . . . . . . . . . . . . . . . . . . . . . . 15 5.2.4 Transport Channel . . . . . . . . . . . . . . . . . . . . . 16 5.3 The Content Part of IMG Metadata . . . . . . . . . . . . . . 16 5.3.1 Content . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.3.2 Content Item . . . . . . . . . . . . . . . . . . . . . . . . 17 5.3.3 Content Bundle . . . . . . . . . . . . . . . . . . . . . . . 18 5.3.4 Access Info . . . . . . . . . . . . . . . . . . . . . . . . 18 5.3.5 Scheduling Info . . . . . . . . . . . . . . . . . . . . . . 18 6. Transfer Envelope . . . . . . . . . . . . . . . . . . . . . 19 7. IMG Metadata Format . . . . . . . . . . . . . . . . . . . . 22 8. Security Considerations . . . . . . . . . . . . . . . . . . 23 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 Normative References . . . . . . . . . . . . . . . . . . . . 26 Informative References . . . . . . . . . . . . . . . . . . . 27 Author's Address . . . . . . . . . . . . . . . . . . . . . . 27 A. Example of an IMG Transfer Envelope . . . . . . . . . . . . 28 Intellectual Property and Copyright Statements . . . . . . . 29 Luoma Expires April 26, 2004 [Page 2] Internet-Draft IMG Metadata October 2003 1. Introduction This document defines the Internet Media Guide (IMG) metadata model, the framing structure for IMG metadata, and the IMG media metadata elements. This is intended as a baseline specification of the IMG metadata format that can be supplemented by other specifications, e.g. for application-specific extensions. The scope and background of the work on Internet Media Guides have been described in the IMG requirements [2] and IMG framework [3] specifications. The purpose of the IMG metadata is to provide machine- and human-readable information describing the files, resources and multimedia programs available for streaming or downloading via multicast or unicast. The IMG metadata format will be used in the IMG framework [3] as a payload format for IMG transport protocols, such as MUPPET [4]. The syntax of the IMG metadata framing format is based on the Extensible Markup Language (XML). The IMG media metadata (or references to it) are encapsulated in IMG metadata framing. The aim is to reuse existing metadata standards for the IMG metadata format where possible. Luoma Expires April 26, 2004 [Page 3] Internet-Draft IMG Metadata October 2003 2. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Luoma Expires April 26, 2004 [Page 4] Internet-Draft IMG Metadata October 2003 3. Terminology IMG ANNOUNCE Unsolicited delivery of IMG metadata to an IMG receiver. References to parts of the IMG metadata may also be included, instead of the actual metadata. IMG Media Guide An IMG is a set of meta-data describing the features of multimedia content. For example, meta-data may consist of the URI, title, air time, bandwidth needed, file size, text summary, genre, and access restrictions. IMG Media Metadata Includes the relational part, session part and content part of IMG metadata. Does not include the metadata relating to IMG delivery, e.g. the fields of the IMG transfer envelope. IMG Metadata Model Defines the information content, semantics and relations of the different IMG metadata entities IMG NOTIFY Delivery of a change notification in response to an IMG SUBSCRIBE. Identifies the parts of the IMG metadata that have changed without delivering the updated IMG metadata. 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 Luoma Expires April 26, 2004 [Page 5] Internet-Draft IMG Metadata October 2003 IMG Sender A logical entity that delivers IMG metadata to one or more IMG receivers, analogous to a server. A sender shall provide bandwidth control or congestion control schemes on the output. A sender can additionally be a receiver - see IMG transceiver. IMG SUBSCRIBE A request for notifications of changes in IMG metadata updates, from a receiver to a sender or proxy. IMG Transceiver A combination of an IMG receiver and sender. An IMG proxy is an example of an IMG transceiver. Luoma Expires April 26, 2004 [Page 6] Internet-Draft IMG Metadata October 2003 4. The Use of IMG Metadata for IP Media Discovery The following sections describe the use of IMG metadata to support both initial and update discovery of IP media. 4.1 Initial Discovery The IMG sender should make its full IMG metadata available to clients using IMG ANNOUNCE and/or IMG RESOLVE. An IMG receiver may need to receive the full set of metadata for an IMG when the terminal has just started receiving a particular IMG, or when its cached copy of the metadata cannot be synchronized with IMG update transmissions. 4.2 Update Discovery Once the IMG receiver has received and stored sufficient IMG metadata in its local database, it may try to detect any changes in the received IMG information. The following types of IMG metadata may be monitored for changes: 1. A sender's full IMG metadata set (IMG ANNOUNCE or IMG RESOLVE) 2. A sender's IMG metadata update (IMG ANNOUNCE or IMG RESOLVE) 3. A sender's IMG change notification (IMG NOTIFY, IMG ANNOUNCE or IMG RESOLVE) The receiver will learn of any changes in the IMG metadata by continuing to receive the full set of metadata, for example by periodically using an IMG RESOLVE by receiving transmissions of the metadata via IMG ANNOUNCE. However, the use of update IMG metadata transfers and/or IMG update notifications may provide more efficient means for update discovery. An IMG sender SHOULD provide IMG metadata updates via IMG ANNOUNCE, IMG RESOLVE or both (in addition to any full IMG metadata transfer). After receiving sufficient IMG metadata, an IMG receiver MAY continue receiving only these updates, if available, instead of receiving the full IMG. Each IMG update transfer consists of the IMG elements that have recently changed. The definition of 'recently changed metadata' shall be determined by the sender (this may be dependent on time, data size and/or number of transmissions). For example, an update may include media metadata changed since the previous version(s) of the relevant parts of IMG media metadata transferred, or since the last full IMG transfer. After receiving each IMG metadata update, the IMG receiver MUST verify if it has missed an earlier update to this set of IMG media Luoma Expires April 26, 2004 [Page 7] Internet-Draft IMG Metadata October 2003 metadata; this can be accomplished by checking the version number and update version number fields in the IMG transfer envelope (Section 6). It is recommended that the IMG receiver attempt to recover the missing update by verifying the current versions of the relevant metadata (for example, by obtaining the full set of IMG metadata again, or by querying the versions of the locally cached IMG metadata). In addition to sending an IMG metadata transfer, an IMG sender MAY send IMG change notifications. These change notifications consist of references to IMG metadata elements that have changed recently (e.g., since the previous version of the IMG transfer). After receiving an IMG update notification and discovering the parts of IMG that have changed, an IMG receiver MAY obtain the latest full IMG metadata set of a sender or an IMG metadata update using either IMG ANNOUNCE or IMG QUERY. The version number and update version number of the IMG transfer envelope are maintained for IMG change notifications, just as in the earlier case of IMG update transfers. Similarly, these fields MUST be checked by IMG receivers to learn when it is necessary to again obtain the related IMG media metadata as in Section 4.1. Luoma Expires April 26, 2004 [Page 8] Internet-Draft IMG Metadata October 2003 5. IMG Metadata Model The media metadata in an Internet Media Guide is structured in three parts: a relatively static part known as the 'relational part' and the more dynamic parts known as the 'session part' and 'content part'. This chapter describes the metadata entities and their relations in the three parts of IMG metadata. This chapter describes a baseline metadata model for Internet Media Guides that includes metadata entities common for most IMG usage scenarios. It should be possible to extend the IMG metadata format, e.g. with application-specific parts, but such extensions are outside the scope of this document. Note, some metadata fields are marked '(optional)' to indicate that it is optional whether to use these fields in the respective metadata. However, IMG receivers MUST be capable of parsing both 'mandatory' and 'optional' fields. 5.1 The Relational Part of IMG Metadata The relation part of the IMG metadata is used to relate the various parts of the metadata. This includes IP service portals based on the type of content, and to organize IP services into IP service portals. The metadata in the relational part is intended to be browsed by end-users and by end-user applications, allowing them to decide on what content to receive. For example, an IMG could be rendered as a simple hierarchy as shown in Figure 1. Luoma Expires April 26, 2004 [Page 9] Internet-Draft IMG Metadata October 2003 Root | +--News Category | | | +--CNN IP service portal | | | | | +--World news Category | | | | | | | +--LiveUpdate IP service | | | | | +--Business news Category | | | | | +--Sports news Category | | | +--BBC World IP service portal | +--Entertainment Category | +--Music Category | +--Videos Category Figure 1: Example of an IMG service hierarchy The relations between the metadata elements that constitute an IMG hierarchy are shown in Figure 2. Note that the cardinalities between metadata elements in this and the other entity relationship diagrams are denoted as follows: o 0..1: zero or one occurrences o 1: exactly one occurrence o *: zero or more occurrences o 1..*: one or more occurrences Luoma Expires April 26, 2004 [Page 10] Internet-Draft IMG Metadata October 2003 includes +---+ * | | 0..1 V | +----------+ includes +----------+ | IMG Root |---------->| Category | +----------+ 0..1 * +----------+ ^ is-a | | +-------------------+ | IP Service Portal | +-------------------+ | 1..* includes | V * +-------------------+ +-------------+ +--------------->| IP Service Unit |--------| Access info | | +-------------------+ 1 0..1 +-------------+ | ^ | | | +-------------+-----------+ | | | | +-------------------+ +------------+ +--| IP service bundle | | IP service | +-------------------+ +------------+ | 1..* includes | V * +------------+ | IP Session | +------------+ Figure 2: Hierarchy part of the IMG metadata The metadata elements of the hierarchy part are described in the following subsections. Note that IP session belongs to the session part rather than the hierarchy part of IMG metadata, and is only shown in Figure 2 to show the connection between the two parts - see Section 5.2.1 for definition of IP session. 5.1.1 IMG Root The IMG root is a logical entity that represents one IMG database. It is expected that both single logical receivers and single logical senders will maintain their own single IMG root (thus a IMG single database). Thus an IMG root is unique to a unique logical host. Luoma Expires April 26, 2004 [Page 11] Internet-Draft IMG Metadata October 2003 It may be desirable or a host to separate IMG roots from different senders (or senders in separately administered domains). Thus, a practical refinement is that one receiver may maintain more than one IMG root (in one or more actual databases). In this case the receiver is behaving as multiple logical receivers, possibly sharing actual processes, databases and user interfaces. The document does not impose any requirements on the relationships between the deployment of physical devices and of: logical senders; logical transceivers; and, logical receivers. IMG root is a container for the other IMG metadata elements. The only information field in the IMG root itself is the identifier of the Internet Media Guide represented by the IMG root. o IMG ID: unique ID of the IMG 5.1.2 Category The category provides a classification for content, allowing end-users to browse available content according to category or client software to automatically filter content. Each category node MAY be associated with categories of the next lower hierarchy level. Except for root-level categories, one higher-level category node MUST be associated with every category node. The following information fields are included for a category: o Category ID: the unique identifier of the category o Name: the name of the category o Description (optional): short description for the category o Parental rating (optional): minimum recommended age to access the category - if absent it is assumed there are no restrictions o Additional information (optional): a URL for retrieving additional information 5.1.3 IP Service Portal An IP service portal is a collection of services offered by a single service provider or a content provider. An IP service portal MUST be associated with one content category node. The path of content category nodes from the root of service hierarchy tree to the IP service portal (e.g., 'entertainment.music.videos') defines the Luoma Expires April 26, 2004 [Page 12] Internet-Draft IMG Metadata October 2003 category of the portal. IP Service Portal inherits the field of category and also uses: o Contact details (optional): URL to human-readable contact info o Logo (optional): URL to a graphical logo of the service provider / content provider 5.1.4 IP Service Unit Any number of IP service units can be included in an IP service portal. IP service unit is used here as an abstract entity that is realized either as an IP service or an IP service bundle. A separate access info element may be associated either with an IP service or an IP service bundle. 5.1.5 Access Info Access info describes the requirements or preconditions that must be met in order to access a particular IP service unit or content. For example, details of pricing/billing and age limits could be part of the access info. 5.1.6 IP Service Bundle An IP service bundle is a set consisting of IP services or other IP service bundles. For example, an IP service offering a number of sessions carrying sports-related content might be bundled together with an IP service carrying sessions that distribute movie content. 5.1.7 IP Service An IP service consists of a number of IP sessions and belongs to one or more content categories. The following information fields are included: o Service ID: unique identifier of IP service o Name: name of the IP service o Description (optional): short description of the IP service o Genre (optional): genre of the IP service o Parental rating: minimum recommended age to access the IP service (optional - if absent it is assumed there are no restrictions) Luoma Expires April 26, 2004 [Page 13] Internet-Draft IMG Metadata October 2003 o Client content path (optional): Recommended path in the receiver's file system for storing the content of this service. This would be a relative path, which also requires a (receiving) application-specific base path to identify the complete local path. o Response URL (optional): a URL that can be used by clients to provide feedback, e.g. a five-star rating for the service o Additional information (optional): A URL for retrieving additional information 5.2 The Session Part of IMG Metadata The session part of IMG metadata is used to describe the scheduling, transport and any audio/video codec parameters of media streams, as well as the binding of these media streams into IP sessions (see Figure 3). Using this part of IMG metadata, client-side applications are able to receive and present media streams belonging to IP sessions. +-----------------+ +------------+ | Scheduling info |---------------| IP session | +-----------------+ 1 1 +------------+ | 1 consists of | V 1..* +--------------------+ delivers +----------------------+ | Transport channel |--------->| IP session component | +--------------------+ 1..* 1 +----------------------+ Figure 3: Session part of the IMG metadata 5.2.1 IP Session An IP session is the collection of related media streams used for delivering IP based content to clients. A session is associated with one or more IP services, and shares the category assigned to those IP services. The lifetime of an IP session is typically much shorter than that of an IP service. The following information fields are included in this metadata element: o Session ID: unique identifier of the IP session o Version: version number of the session description Luoma Expires April 26, 2004 [Page 14] Internet-Draft IMG Metadata October 2003 o Name: name of the IP session o Owner (optional): name of the owner/creator of the IP session o Bandwidth (optional): total bandwidth requirements of the IP session o Encryption info (optional): type of content encryption used and related parameters o Authentication info (optional): type of content authentication used and related parameters 5.2.2 IP Session Component An IP session component refers to a single media stream that is part of an IP session, e.g. video, audio or data flow. Each media stream is delivered on one more logical transport channels. An IP session component is described using the following parameters: o Bandwidth (optional): bandwidth requirements of the IP session component o Addressing: The Layer 3 and Layer 4 addressing used for delivering the IP session component. o Transport: The transport protocol used. o Codec parameters (optional): The parameters of the audio/video codec needed to present the media stream o Encryption info (optional): type of content encryption used and related parameters o Authentication info (optional): type of content authentication used and related parameters 5.2.3 Scheduling Info A delivery schedule is always associated with an IP session. Both the start and the end time of an IP session are usually bounded. Either a single time period, or a repeating schedule may be specified. The following information fields are included: o Start (optional): the start time Luoma Expires April 26, 2004 [Page 15] Internet-Draft IMG Metadata October 2003 o End (optional): the end time o Repeat (optional): information on the repetition pattern o Timezone (optional): information on any timezone adjustments taking place 5.2.4 Transport Channel A logical transport channel in an IP network is defined here by the Layer 3 and Layer 4 protocols and addressing parameters used. It includes the following: o Source IP address: IPv4 or IPv6 address o Destination/group IP address: IPv4 or IPv6 address o Source port: port number o Destination port: port number o Transport protocol: transport layer protocol(s) used, e.g. RTP/UDP o Additional transport parameters (optional): 5.3 The Content Part of IMG Metadata The content part of IMG metadata identifies and describes items of content delivered within IP sessions, and grouping of these content items into bundles of related content (see Figure 4). This part of the IMG metadata provides more details into the available content, helping end-users and client applications to decide on which IP sessions to receive. Luoma Expires April 26, 2004 [Page 16] Internet-Draft IMG Metadata October 2003 +------------+ | IP session | +------------+ | 1..* delivers | V * includes +---------+ +-------------+ +------------------>| Content |----------| Access info | | 1..* +---------+ 1 0..1 +-------------+ | ^ | | is-a | +---------+---------+ | | | | +----------------+ +--------------+ +-----| Content bundle | | Content item | 0..1 +----------------+ +--------------+ | 1 | | 0..1 +-----------------+ | Scheduling info | +-----------------+ Figure 4: Content part of the IMG metadata The metadata elements of the content part are described in the following subsections. Note that IP session belongs to the session part rather than content part of IMG metadata, and is only shown in Figure 2 to show the connection between the two parts. See Section 5.2.1 for definition of IP session. 5.3.1 Content Any number of instances of content can be included in an IP session. Content is used here as an abstract entity that is realized either as a content item or a content bundle. 5.3.2 Content Item A content item is an atomic item of content delivered by the IP network and consumed by the end-user, such as an MP3 file or a real-time audio/video stream. The following information fields are included: o Content item ID: the unique identifier of the content item o Name: the name of the content item Luoma Expires April 26, 2004 [Page 17] Internet-Draft IMG Metadata October 2003 o Content location (optional): the URL or filename used for accessing the content item o Genre (optional): the genre of the content item o Creator (optional): the creator of the content item o Owner (optional): the owner rights to this content item (note, the rights may be dependent on the context, e.g. copyright ownership for streaming delivery) o Description (optional): short description of the content item o Parental rating (optional): minimum recommended age to access the content item o Rating URL (optional): a URL that can be used by clients for rating the service 5.3.3 Content Bundle A content bundle is a set of content items or other content bundles. For example, a set of PC game downloads can be defined as a content bundle. Similarly, a news broadcast that consists of the domestic, foreign and sports news as separate content items can be defined as a content bundle. The following information fields are included: o Bundle ID: the unique identifier of the content bundle o Name: the name of the content bundle 5.3.4 Access Info As described in Section 5.1.5. 5.3.5 Scheduling Info There may be a delivery schedule associated with an individual content item. This information content of this entity is as defined in Section 5.2.3. Luoma Expires April 26, 2004 [Page 18] Internet-Draft IMG Metadata October 2003 6. Transfer Envelope IMG metadata must be encapsulated into an IMG transfer envelope before it is passed to an IMG transport protocol for delivery. The same encapsulation is used for the logical operations IMG ANNOUNCE, IMG NOTIFY and IMG RESOLVE. The transfer envelope is an XML document defined by the XML schema shown in Figure 5. See Appendix A for an example of an XML description based on this XML schema. Luoma Expires April 26, 2004 [Page 19] Internet-Draft IMG Metadata October 2003 Figure 5: The XML Schema of the IMG Transfer Envelope The payload of the IMG transfer envelope is represented as an XML structure that includes an XML or as plain ASCII text by including either of the following elements. The actual metadata syntax used in the payload is outside the scope of this specification. o xmlPayload: The metadata payload in an XML based textual format. Any number of XML metadata formats for this field may be supported by senders and receivers. Only well-formed XML must be used in this field. The XML payload MUST contain a reference to a valid XML schema, enabling receivers to determine the format of the XML payload. o asciiPayload: The metadata payload in a textual, non-XML format. The MIME content type of the textual payload MUST be indicated using the "type" attribute. At least the value of "application/ sdp" referring to the Session Description Protocol [5] format MUST be supported for this attribute. The following attributes can be associated with the IMG payload. The attributes are mandatory to include unless marked as optional. o xmlPayload: The metadata payload in XML format. o asciiPayload: The metadata payload in ASCII format. o metadataID: Unique identifier for this set of IMG metadata. o version: Current version number of the full transfer. The version number is initially zero, and is increased by one whenever the full IMG metadata is changed. o minorVersion (optional): Current version number of the update transfer. This field MUST be present for update metadata transfers and update notifications, and MUST NOT be present for full IMG metadata transfers. The value of this field is initially zero, and is increased by one for whenever the IMG metadata update is changed. o validFrom: the date and time from which the metadata is valid. o validUntil: the date and time when the metadata expires. Luoma Expires April 26, 2004 [Page 20] Internet-Draft IMG Metadata October 2003 It shall be possible to provide signing and encryption to the IMG transfer envelope, limiting the capability of any intermediaries between the original IMG sender and the IMG receiver to read and modify IMG metadata fields. Signing, encryption or both can be applied to the whole transfer envelope or just to parts of it. Luoma Expires April 26, 2004 [Page 21] Internet-Draft IMG Metadata October 2003 7. IMG Metadata Format An XML schema will be defined for IMG transfer envelope, and if necessary for other parts of the IMG metadata that cannot be implemented using existing standards. Currently, the following standards are being considered for IMG metadata: o MPEG-7 (content part of IMG media metadata) o SDP or SDPng (session part of IMG media metadata) o XPath or XPointer (references to IMG metadata elements) o XML Encryption Syntax and Processing (IMG transfer envelope) o XML-Signature Syntax and Processing (IMG transfer envelope) Luoma Expires April 26, 2004 [Page 22] Internet-Draft IMG Metadata October 2003 8. Security Considerations IMG receivers should only trust IMG metadata received from a trusted source, with data integrity and authentication of the original IMG sender provided at IMG metadata level or by IMG transport. IMG receivers also should not trust IMG metadata modified by an IMG transceiver, unless the IMG transceiver is trusted and the integrity and authenticity of the changes can be similarly verified. However, to operate in a typical network environment lacking infrastructure for key distribution and trust verification, IMG receivers may also be configured to accept untrusted IMG metadata. There may also be need to provide access control to the content described by the IMG or to protect the confidentiality of an individual user requesting a particular subset of an IMG. Such privacy requirements are met by the use of encryption at IMG metadata level or by IMG transport. Luoma Expires April 26, 2004 [Page 23] Internet-Draft IMG Metadata October 2003 9. Contributors Rod Walsh Nokia Research Center P.O. Box 100 (Visiokatu 1) FIN-33721 Tampere Finland EMail: rod.walsh@nokia.com Toni Paila Nokia Ventures Organization P.O. Box 209 (Itamerenkatu 11-13) FIN-00181 Helsinki Finland EMail: toni.paila@nokia.com Luoma Expires April 26, 2004 [Page 24] Internet-Draft IMG Metadata October 2003 10. Acknowledgements The author wishes to thank Yuji Nomura, Henning Schulzrinne, Rami Lehtonen, Jani Peltotalo and Sami Peltotalo for providing comments on IMG metadata design. Luoma Expires April 26, 2004 [Page 25] Internet-Draft IMG Metadata October 2003 Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCD 14, March 1997. [2] Nomura, Y., Walsh, R., Ott, J. and H. Schulzrinne, "Protocol Requirements for Internet Media Guides", draft-ietf-mmusic-img-requirements-00 (work in progress), September 2003. [3] Nomura, Y., Walsh, R., Luoma, J., Asaeda, H. and H. Schulzrinne, "A Framework for the Usage of Internet Media Guides", draft-ietf-mmusic-img-framework-00 (work in progress), October 2003. Luoma Expires April 26, 2004 [Page 26] Internet-Draft IMG Metadata October 2003 Informative References [4] Luoma, J., "MUPPET: Internet Media Guide Unidirectional Point-to-Multipoint Transport Protocol", draft-luoma-mmusic-img-muppet-03 (work in progress), October 2003. [5] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [6] Ott, J., Bormann, C. and D. Kutscher, "Session Description and Capability Negotiation", draft-ietf-mmusic-sdpng-05 (work in progress), July 2002. Author's Address Juha-Pekka Luoma Nokia P.O. Box 100 (Visiokatu 1) Tampere FIN-33721 Finland EMail: juha-pekka.luoma@nokia.com Luoma Expires April 26, 2004 [Page 27] Internet-Draft IMG Metadata October 2003 Appendix A. Example of an IMG Transfer Envelope The specification of a metadata formats conforming to the IMG metada framework is outside the scope of this specification. Although it only conforms to a subset of the IMG metadata framework, SDP is an existing metadata format that could be used as a payload format for IMG metadata transport protocols. Figure 6 shows a non-normative example of an SDP description encapsulated within an 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 6: Example of an IMG transfer envelope Luoma Expires April 26, 2004 [Page 28] Internet-Draft IMG Metadata October 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Luoma Expires April 26, 2004 [Page 29] Internet-Draft IMG Metadata October 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Luoma Expires April 26, 2004 [Page 30]