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]