MMUSIC J. Luoma Internet-Draft Nokia Research Center Expires: December 29, 2003 June 30, 2003 Internet Media Guide Metadata Baseline draft-luoma-mmusic-img-metadata-01 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 December 29, 2003. 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 December 29, 2003 [Page 1] Internet-Draft IMG Metadata June 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 4.3 Subscribing to IMG Update Notifications . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.2 The Session Part of IMG Metadata . . . . . . . . . . . . . . 13 5.2.1 IP Session . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.2.2 IP Session Component . . . . . . . . . . . . . . . . . . . . 14 5.2.3 Scheduling Info . . . . . . . . . . . . . . . . . . . . . . 15 5.2.4 Transport Channel . . . . . . . . . . . . . . . . . . . . . 15 5.3 The Content Part of IMG Metadata . . . . . . . . . . . . . . 16 5.3.1 Content . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.3.2 Content Item . . . . . . . . . . . . . . . . . . . . . . . . 17 5.3.3 Content Bundle . . . . . . . . . . . . . . . . . . . . . . . 17 5.3.4 Access info . . . . . . . . . . . . . . . . . . . . . . . . 18 5.3.5 Scheduling info . . . . . . . . . . . . . . . . . . . . . . 18 6. Transfer Envelope . . . . . . . . . . . . . . . . . . . . . 19 7. IMG Metadata Format . . . . . . . . . . . . . . . . . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . 22 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 Normative References . . . . . . . . . . . . . . . . . . . . 25 Informative References . . . . . . . . . . . . . . . . . . . 26 Author's Address . . . . . . . . . . . . . . . . . . . . . . 26 A. Example of an IMG Transfer Envelope . . . . . . . . . . . . 27 Intellectual Property and Copyright Statements . . . . . . . 28 Luoma Expires December 29, 2003 [Page 2] Internet-Draft IMG Metadata June 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 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 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 December 29, 2003 [Page 3] Internet-Draft IMG Metadata June 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 December 29, 2003 [Page 4] Internet-Draft IMG Metadata June 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 December 29, 2003 [Page 5] Internet-Draft IMG Metadata June 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 December 29, 2003 [Page 6] Internet-Draft IMG Metadata June 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 push, IMG fetch 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 December 29, 2003 [Page 7] Internet-Draft IMG Metadata June 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 push or IMG fetch. 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. 4.3 Subscribing to IMG Update Notifications Luoma Expires December 29, 2003 [Page 8] Internet-Draft IMG Metadata June 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 December 29, 2003 [Page 9] Internet-Draft IMG Metadata June 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 occurences o 1: exactly one occurence o *: zero or more occurences o 1..*: one or more occurences Luoma Expires December 29, 2003 [Page 10] Internet-Draft IMG Metadata June 2003 includes +---+ * | | 0..1 V | +----------+ includes +----------+ | IMG Root |---------->| Category | +----------+ 0..1 * +----------+ ^ is-a | | +-------------------+ | IP Service Portal | +-------------------+ | 1..* includes | V * +------------+ | 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. 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. Luoma Expires December 29, 2003 [Page 11] Internet-Draft IMG Metadata June 2003 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 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 Luoma Expires December 29, 2003 [Page 12] Internet-Draft IMG Metadata June 2003 o Logo (optional): URL to a graphical logo of the service provider / content provider 5.1.4 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) 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. Luoma Expires December 29, 2003 [Page 13] Internet-Draft IMG Metadata June 2003 +-----------------+ +------------+ | 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 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 Luoma Expires December 29, 2003 [Page 14] Internet-Draft IMG Metadata June 2003 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 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 Luoma Expires December 29, 2003 [Page 15] Internet-Draft IMG Metadata June 2003 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. +------------+ | 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 Luoma Expires December 29, 2003 [Page 16] Internet-Draft IMG Metadata June 2003 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 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 Luoma Expires December 29, 2003 [Page 17] Internet-Draft IMG Metadata June 2003 5.3.4 Access info Access info provides additional information, which a user can base their decision on whether to access that content, and may provide the receiver with additional parameters and instructions on how to access the content. For example, pricing/billing information could describe the cost of purchasing or subscribing to a content item, as well as the details of submitting a payment. 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 December 29, 2003 [Page 18] Internet-Draft IMG Metadata June 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. Figure 5: The XML Schema of the IMG Transfer Envelope Luoma Expires December 29, 2003 [Page 19] Internet-Draft IMG Metadata June 2003 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. o asciiPayload: The metadata payload in an ASCII based textual format. 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 transferID: 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. 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 December 29, 2003 [Page 20] Internet-Draft IMG Metadata June 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 December 29, 2003 [Page 21] Internet-Draft IMG Metadata June 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 December 29, 2003 [Page 22] Internet-Draft IMG Metadata June 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 December 29, 2003 [Page 23] Internet-Draft IMG Metadata June 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 December 29, 2003 [Page 24] Internet-Draft IMG Metadata June 2003 Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCD 14, March 1997. [2] Schulzrinne, H. and Y. Nomura, "Protocol Requirements for Internet Program Guides", draft-nomura-mmusic-pguide-requirements-00 (work in progress), February 2002. [3] Nomura, Y., Walsh, R., Asaeda, H. and H. Schulzrinne, "A Framework for the Usage of Internet Media Guides", draft-nomura-mmusic-img-framework-01 (work in progress), June 2003. Luoma Expires December 29, 2003 [Page 25] Internet-Draft IMG Metadata June 2003 Informative References [4] Luoma, J., "MUPPET: Internet Media Guide Unidirectional Point-to-Multipoint Transport Protocol", draft-luoma-mmusic-img-muppet-00 (work in progress), June 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 Research Center P.O. Box 100 (Visiokatu 1) Tampere FIN-33721 Finland EMail: juha-pekka.luoma@nokia.com Luoma Expires December 29, 2003 [Page 26] Internet-Draft IMG Metadata June 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 December 29, 2003 [Page 27] Internet-Draft IMG Metadata June 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 December 29, 2003 [Page 28] Internet-Draft IMG Metadata June 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 December 29, 2003 [Page 29]