MMUSIC Working Group H. Asaeda Internet-Draft K. Mishima Expires: August, 2006 Keio University Y. Nomura J. Ogawa Fujitsu Labs. February 27, 2006 An Architecture for the Access of IMG Metadata Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document defines an architecture for the access of Internet Media Guide (IMG) metadata. An IMG is a structured collection of multimedia session descriptions expressed using SDP, SDPng or some similar session description format. This document proposes a common architecture that provides the IMG access methods, including the use methods of URN and IMG Envelope. H. Asaeda et. al. [Page 1] Internet Draft IMG Architecture February 2006 1 Introduction Internet Media Guides (IMGs) [2][3] provide and deliver structured collections of multimedia descriptions expressed using SDP [4], SDPng [5] or other description formats. They are used to describe sets of multimedia services (e.g. television program schedules, content delivery schedules) and refer to other networked resources including web pages. IMG metadata may be delivered to a potentially large audience, who use it to join a subset of the sessions described, and who may need to be notified of changes to the IMG metadata. Since content and its structure described by IMG metadata changes as time elapses, an IMG receiver needs to be notified of changes so that IMG metadata and content do not become stale. This document defines an architecture for the access of IMG metadata, which satisfies the IMG framework [2] and matches the IMG requirements [3]. The IMG framework [2] defines a set of abstract operations for large- scale multicast distribution ("IMG ANNOUNCE"), individual subscription and asynchronous (change) notification ("IMG SUBSCRIBE" and "IMG NOTIFY"), and interactive retrieval ("IMG QUERY" and "IMG RESOLVE"). This document clarifies the common mechanism that provides the IMG access methods, including the use methods of these corresponding operations and specifications. 2 Terminology 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]. Internet Media Guide (IMG): IMG is a generic term to describe the formation, delivery and use of IMG metadata. The definition of the IMG is intentionally left imprecise [2]. IMG Element: The smallest atomic element of metadata that can be transmitted separately by IMG operations and referenced individually from other IMG elements [2]. IMG Metadata: A set of metadata consisting of one or more IMG elements. IMG metadata describes the features of multimedia content used to enable selection of and access to media sessions containing content. For example, metadata may consist of the URI, title, airtime, bandwidth needed, file size, text summary, genre and access restrictions [2]. H. Asaeda et. al. [Page 2] Internet Draft IMG Architecture February 2006 IMG Operation: An atomic operation of an IMG transport protocol, used between IMG sender(s) and IMG receiver(s) for the delivery of IMG metadata and for the control of IMG sender(s)/receiver(s) [2]. IMG Transport Protocol: A protocol that transports IMG metadata from an IMG sender to IMG receiver(s) [2]. 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 time bound series of IMG transport protocol interactions that provide delivery of IMG metadata from the IMG sender to the IMG receiver(s) [2]. IMG Sender: An IMG sender is a logical entity that sends IMG metadata to one or more IMG receivers [2]. IMG Receiver: An IMG receiver is a logical entity that receives IMG metadata from an IMG sender [2]. IMG Pointer: An IMG pointer provides an abstract description that points out IMG metadata. For example, an IMG pointer could be described by URL or IMG URN that locates IMG metadata. An IMG pointer itself does not include IMG metadata. IMG URN: IMG URN defines a Uniform Resource Name (URN) namespace for IMG. It describes a persistent and location-independent identifier for IMG metadata or a list of IMG metadata. It can instantiate an IMG pointer. IMG Envelope: An IMG envelope specifies a common encapsulation format for metadata in support of the IMG operations. Complete IMG Description: A complete IMG description means the complete information of IMG metadata. This does NOT mean "complete IMG metadata", which represents the complete IMG metadata database an IMG sender holds. Delta IMG Description: A delta IMG description provides only part of a complete IMG description, defining the difference from a previous version of the complete IMG description. DDDS: Dynamic Delegation Discovery System (DDDS) [9] [10] [11] [12] is an abstract algorithm for applying dynamically retrieved string transformation rules to an application-unique string. 3 Expression of IMG Metadata 3.1 IMG Metadata Identification H. Asaeda et. al. [Page 3] Internet Draft IMG Architecture February 2006 An IMG receiver communicates with an IMG sender to obtain IMG metadata that the IMG receiver is interested in. IMG metadata should be in general uniquely identified. This document uses IMG Uniform Resource Name (URN) for an identifier of IMG metadata. It provides persistent and location-independent information, and any contents can be uniquely identified even with elapsed time. Hence even if the IMG metadata is relayed or cached by different IMG entities, it has the unique identifier in the corresponding IMG URN and can refer the same contents. In addition, IMG URN can be represented in a format depending upon the context of their use. For example, an IMG receiver cannot specify concrete IMG metadata but can specify an abstract description such as "all IMG metadata you know so far". Thus, one IMG URN description may describe the different IMG metadata when IMG URN means the context- dependent IMG metadata. This document does not assume any specific description for IMG URN; however, IMG URN should be specified by another document. An IMG URN scheme is being defined in a companion draft where [6] may be the candidate. An IMG receiver can initiate an IMG transport session with an appropriate IMG sender, after it refers a resolution system (e.g. DDDS, which will be explained later) with IMG URN and resolves the IMG sender that provides corresponding IMG metadata. On the other hand, IMG metadata may be updated with time due to the change of the contents. While an IMG receiver wants to obtain a complete IMG description in the initial access, it may want to obtain a delta IMG description later as it already has obtained the previous complete IMG metadata. To deal with either condition, IMG URN should express the version of IMG metadata. This version expresses update of IMG metadata, and IMG envelope (mentioned in the next section) may also include the same version information. However, the detail discussion regarding how the delta IMG description is expressed is an *open issue* of this document. 3.2 IMG URN and IMG Envelope While IMG URN provides an identifier of each IMG metadata, the IMG envelope provides a format to encapsulate and carry IMG metadata, IMG URN, or an IMG pointer used in IMG transport protocols. The IMG envelope is independent from an IMG transport protocol. Encapsulated IMG metadata, IMG URN, or an IMG pointer in the IMG envelope expresses XML based format or MIME based format. H. Asaeda et. al. [Page 4] Internet Draft IMG Architecture February 2006 An IMG envelope can specify version, update and expiration information of the encapsulated or pointed IMG metadata. The information may be used for an IMG receiver to obtain a delta IMG description and recognize the difference from the IMG metadata the IMG receiver already has. Hence, an IMG envelope must keep consistency with encapsulated information. If an IMG envelope does not encapsulate corresponding IMG URN, it should specify the information. If an IMG envelope encapsulates IMG URN and also specifies the information, it must preserve consistency of the information of the corresponding IMG metadata. This document does not assume any specific description for an IMG envelope; however, an IMG envelope should be specified by another document. There is a candidate document [7] for an IMG envelope. In addition, this document does not mention the use case or the scenario of IMG metadata, IMG URN, or an IMG pointer. It is an *open issue* that in which case IMG envelope encapsulates what kind of information (i.e. IMG metadata, IMG URN, or an IMG pointer). 4 Access to IMG Metadata The typical scenario that an IMG receiver obtains IMG metadata consists of the following three phases: (1) an IMG receiver obtains IMG URN, (2) an IMG receiver resolves corresponding IMG sender(s), and (3) an IMG receiver starts an IMG transport session to obtain its interesting IMG metadata from the IMG sender. 4.1 Register and Obtain IMG URN As one of the possible systems, this document uses Dynamic Delegation Discovery System (DDDS) [9] [10] [11] [12] to manage IMG URN that expresses IMG metadata. Network administrators or operators, or contents providers register IMG URN in their DDDS. Remember that complete IMG metadata database is maintained by an IMG sender, yet the discussion how they register information of IMG URN is out of scope of this document. To access an IMG sender and obtain IMG metadata from the IMG sender, an IMG receiver needs to know IMG URN beforehand. IMG URN may be obtained from a site-local administrator who maintains the network that the IMG receiver belongs to by an email or other tool. Or, it may be announced by some auto-configuration protocol [13] [14], whereas the operation or the protocol how IMG URN can be obtained dynamically is out of scope of this document. 4.2 DDDS-Based URN Resolution and IMG Operation When an IMG receiver does not know the information about a H. Asaeda et. al. [Page 5] Internet Draft IMG Architecture February 2006 corresponding IMG sender or IMG metadata, it uses the access method of DDDS to resolve IMG URN. DDDS gives (1) a list of corresponding IMG sender address(es) with preference, and (2) an IMG transport protocol each IMG sender uses. Figure 1 shows an IMG operation among an IMG sender, an IMG receiver, and DDDS. It expresses (1) the procedure for an IMG receiver to resolve initial information including an IMG sender, and (2) the operation to obtain complete IMG description from the IMG sender. Register IMG URN and corresponding information---+ | +---Obtain IMG URN | | | V V +--------------+ +------------+ +--------+ | IMG Receiver | | IMG Sender | | DDDS | +--------------+ +------------+ +--------+ | | | |-----------DDDS-Based URN resolution-------->| | | | |<-------------------Response-----------------| | | | |---Start IMG | | | transport session--->| | | | | |<--Obtain IMG metadata--| | Figure 1: DDDS-based URN resolution and an IMG operation to access IMG metadata After DDDS receives a query message from an IMG receiver with IMG URN, DDDS responds to tell a list of IMG senders to the IMG receiver. This list contains available IMG senders in the network the IMG receiver belongs to. When DDDS gives the available IMG senders with preference or with indicating different IMG protocols, the IMG receiver selects an appropriate IMG sender from the list of the available IMG senders. Knowing which IMG sender is appropriate and how an IMG receiver selects an appropriate operation is currently an *open issue* of this document. When an IMG receiver specifies an IMG sender in the DDDS query message and sends the message to DDDS, DDDS replies the availability and an IMG protocol the IMG sender uses. An IMG receiver may not need to resolve the IMG URN. For instance, the IMG receiver obtains the H. Asaeda et. al. [Page 6] Internet Draft IMG Architecture February 2006 same information to start the IMG transport session as the prior IMG URN which has already been resolved by DDDS. 4.3 Obtain IMG Metadata After an IMG receiver decides a corresponding IMG sender and IMG operation, it starts an IMG transport session with the IMG sender to obtain complete or delta IMG descriptions. The IMG transport session and the following procedures depend on the IMG operation and is decided by the IMG protocol the corresponding IMG sender supports. An IMG receiver may request to obtain various sets of IMG metadata, e.g. metadata expressing a single or multiple contents an IMG sender maintains. IMG URN should therefore define the corresponding value to express these sets, whereas its concrete format and value will be defined in another document (e.g. [6]). This requirement may include the specification of filtering unneeded information from the given metadata, because the size of the complete IMG metadata may be huge in some case. This specification will be also included in another document or in this document in the future. 4.3.1 IMG ANNOUNCE With the use of an IMG ANNOUNCE, an IMG receiver participates in an IMG transport session without notifying or sending any message to an IMG sender. Only an IMG receiver needs to prepare to receive IMG metadata via an IMG ANNOUNCE. An IMG ANNOUNCE may carry a complete or delta IMG description, or may carry an IMG pointer. In this operation, using broadcast would be common. 4.3.2 IMG SUBSCRIBE and IMG NOTIFY An IMG SUBSCRIBE is used to ask IMG metadata to an IMG sender and an IMG NOTIFY is used to notify IMG metadata to an IMG receiver. In these operations, an IMG receiver behaves as an IMG subscriber, and an IMG sender behaves as an IMG notifier. An IMG NOTIFY may carry a complete or delta IMG description, or may carry an IMG pointer. These operations use a bi-directional transport session between an IMG receiver and an IMG sender. 4.3.3 IMG QUERY and IMG RESOLVE An IMG QUERY initiates a receiver-driven IMG transport session, and an IMG RESOLVE responds the IMG QUERY and sends IMG metadata to the IMG receiver. An IMG RESOLVE may carry a complete or delta IMG description, or may carry an IMG pointer. These operations use a bi- directional transport session between an IMG receiver and an IMG sender. H. Asaeda et. al. [Page 7] Internet Draft IMG Architecture February 2006 4.4 Update of IMG Metadata While an IMG receiver may often need to update IMG metadata to the latest one, getting a complete IMG description is not always effective. The IMG framework [2] proposes to use a delta IMG description that provides only part of a complete IMG description, defining the difference from a previous version of the complete IMG description. The framework does not represent a complete set of metadata until it is combined with other metadata that may already exist or arrive in the future. 4.4.1 IMG ANNOUNCE or IMG NOTIFY +--------------+ +------------+ | IMG Receiver | | IMG Sender | +--------------+ +------------+ | | |-------- Start IMG transport session ------->| : : : : |<-------- IMG ANNOUNCE or IMG NOTIFY --------| | with delta IMG description | | or | | with IMG pointer to delta IMG description | Figure 2: Update operation by IMG ANNOUNCE or NOTIFY Some IMG sender implementations send the latest complete IMG description repeatedly by an IMG ANNOUNCE or an IMG NOTIFY, and other IMG sender implementations send IMG ANNOUNCE or IMG NOTIFY messages with a delta IMG description or an IMG pointer to a delta IMG description when necessary. To receive IMG NOTIFY messages, an IMG subscriber must initiate an IMG transport session to an IMG notifier by sending an IMG SUBSCRIBE message beforehand. Then, the IMG notifier sends the IMG NOTIFY message when IMG metadata should be updated in the IMG subscriber. 4.4.2 IMG QUERY and IMG RESOLVE This query operation is similar to a general polling method. Both of an IMG sender and an IMG receiver need a bi-directional transport to fulfill the operation. In these operations, using unicast or multicast would be common. 4.5 Use of IMG Pointer H. Asaeda et. al. [Page 8] Internet Draft IMG Architecture February 2006 +--------------+ +------------+ +--------+ | IMG Receiver | | IMG Sender | | DDDS | +--------------+ +------------+ +--------+ | | | |-----------DDDS-Based URN resolution-------->| | | | |<-------------------Response-----------------| | | | |---Start IMG | | | transport session--->| | | | | |<--Obtain IMG pointer---| | | | | ( |----Query to know additional information---->| ) ( | | | ) ( |<-------------------Response-----------------| ) | | | |----Start IMG QUERY---->| | | | | |<--Obtain IMG metadata--| | Figure 3: Use case of IMG Pointer If an IMG receiver receives an IMG pointer, it will be able to obtain IMG metadata by additional independent operations. Currently, there would be no contradiction of the use of IMG pointer for any operation, this document needs to clarify the detail and concrete use cases of an IMG pointer. 5 Security Considerations TBD 6 IANA Considerations This document does not request any IANA action. 7 ToDo We recognize the following discussions are needed: (1) use of companion drafts defining the spec of an IMG envelope and IMG URN, (2) definition of use method of DDDS, (3) definition of use method of IMG pointer, and (4) consideration of an IMG transceiver and its role in this architecture. Open issues described above should be also clarified in the revised version of this document. 8 Normative References H. Asaeda et. al. [Page 9] Internet Draft IMG Architecture February 2006 [1] S. Bradner, "Key words for use in RFCs to indicate requirement levels," RFC 2119, March 1997. 9 Informative References [2] Y. Nomura, R. Walsh, J-P. Luoma, H. Asaeda, and H. Schulzrinne, "A framework for the usage of Internet media guides," Internet Draft, draft-ietf-mmusic-img-framework-09, December 2005. Work in progress. [3] Y. Nomura, R. Walsh, J-P. Luoma, J. Ott, and H. Schulzrinne, "Requirements for Internet Media Guides," Internet Draft, draft-ietf- mmusic-img-req-08, December 2005. Work in progress. [4] M. Handley and V. Jacobson, "SDP: session description protocol," RFC 2327, April 1998. [5] D. Kutscher, J. Ott, and C. Bormann, "Session description and capability negotiation," Internet Draft, draft-ietf-mmusic-sdpng-07, October 2003. Work in progress. [6] J. Greifenberg, "Identifiers for Internet Media Guides (IMG)," Internet Draft, draft-greifenberg-mmusic-img-urn-01, December 2005. Work in progress. [7] R. Walsh, J-P. Luoma, J. Peltotalo, S. Peltotalo, and J. Greifenberg, "The IMG Envelope," Internet Draft, draft-walsh-mmusic- img-envelope-03, June 2005. Work in progress. [8] J. Ott and K. Loos, "Using HTTP for IMG Transport," Internet Draft, draft-ott-mmusic-img-http-00, October 2005. Work in progress. [9] M. Mealling, "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS," RFC 3401, October 2002. [10] M. Mealling, "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm," RFC 3402, October 2002. [11] M. Mealling, "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database," RFC 3403, October 2002. [12] M. Mealling, "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)," RFC 3404, October 2002. [13] R. Droms, "Dynamic Host Configuration Protocol," RFC 2131, March 1997. H. Asaeda et. al. [Page 10] Internet Draft IMG Architecture February 2006 [14] R. Droms, J. Bound, B. Volz, T. Lemon, C. Perkins, and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)," RFC 3315, July 2003. Authors' Addresses Hitoshi Asaeda Graduate School of Media and Governance Keio University 5322 Endo, Fujisawa, 252-8520 Kanagawa, Japan Email: asaeda (at) wide.ad.jp Kazuhiro Mishima Graduate School of Media and Governance Keio University 5322 Endo, Fujisawa, 252-8520 Kanagawa, Japan Email: three (at) sfc.wide.ad.jp Yuji Nomura Fujitsu Laboratories Ltd. 4-1-1 Kamikodanaka, Nakahara-ku, Kawasaki, 211-8588 Kanagawa, Japan Email: nom (at) flab.fujitsu.co.jp Jun Ogawa Fujitsu Laboratories Ltd. 4-1-1 Kamikodanaka, Nakahara-ku, Kawasaki, 211-8588 Kanagawa, Japan Email: ogawa.jun (at) jp.fujitsu.com 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 H. Asaeda et. al. [Page 11] Internet Draft IMG Architecture February 2006 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 (2005). 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. H. Asaeda et. al. [Page 12]