Internet DRAFT - draft-asaeda-mmusic-img-arch

draft-asaeda-mmusic-img-arch









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
                   <draft-asaeda-mmusic-img-arch-00>

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]