MMUSIC J. Luoma
Internet-Draft Nokia
Expires: June 8, 2004 J. Peltotalo
S. Peltotalo
Tampere University of Technology
December 9, 2003
A Metadata Framework for Internet Media Guides: Metadata Envelope
draft-luoma-mmusic-img-metadata-envelope-00
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 June 8, 2004.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document defines the transfer envelope for Internet Media Guides
(IMGs). IMG metadata describes files, resources and multimedia
programs available for streaming or downloading via multicast or
unicast. IMG metadata is encapsulated into, or associated with, an
IMG transfer envelope before actual transport. The transfer envelope
is a structure providing independence between IMG transport protocols
and different metadata formats. The IMG transfer envelope may be
structured for example as a wrapper based on the Extensible Markup
Language (XML) syntax.
Luoma, et al. Expires June 8, 2004 [Page 1]
Internet-Draft IMG Metadata December 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Use of IMG Transfer Envelope with IMG Operations . . . . . . . 9
4.1 Initial Discovery . . . . . . . . . . . . . . . . . . . . . . 9
4.2 Update Discovery . . . . . . . . . . . . . . . . . . . . . . . 9
4.3 Versioning . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Format of the IMG Transfer Envelope . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14
Normative References . . . . . . . . . . . . . . . . . . . . . 15
Informative References . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16
A. XML Schema for the IMG Transfer Envelope . . . . . . . . . . . 17
B. Example of an IMG Transfer Envelope . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . 20
Luoma, et al. Expires June 8, 2004 [Page 2]
Internet-Draft IMG Metadata December 2003
1. Introduction
This document defines the format and use of Internet Media Guide
(IMG) transfer envelope. The scope and background of the work on
Internet Media Guides have been described in the IMG requirements [2]
and IMG framework [3] specifications.
The purpose of the IMG metadata is to provide machine- and
human-readable information describing the files, resources and
multimedia programs available for streaming or downloading via
multicast or unicast. IMG metadata is encapsulated into an IMG
transfer envelope before it is passed to an IMG transport protocol,
such as MUPPET [4]. The purpose of the transfer envelope is to
provide independence of metadata formats from transport protocols,
and to enable versioning, updating and expiring of transmitted
metadata. The IMG transfer envelope may be structured for example as
a wrapper based on the Extensible Markup Language (XML) syntax.
Luoma, et al. Expires June 8, 2004 [Page 3]
Internet-Draft IMG Metadata December 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 [1].
Luoma, et al. Expires June 8, 2004 [Page 4]
Internet-Draft IMG Metadata December 2003
3. Terminology
Complete IMG Description
Provides a complete syntax and semantics to describe a set of
metadata, which does not need any additional information from
other IMG Descriptions. It may contain either a full IMG or a
subset thereof.
Complete Transfer
Transfer of the whole set of metadata comprising an IMG block.
Delta IMG Description
Provides an update to a Complete IMG Description, defining the
difference from the Complete IMG Description in question. This
description may be used to reduce network resource usage for
instance when small and frequent changes occur to Complete IMG
Description. Thus, this description itself cannot represent
complete metadata set until it is combined with the
corresponding Complete IMG Description.
Delta Transfer
Transfer of Delta IMG Description(s) to update an IMG block.
Full IMG
Represents a subset/whole of the sender's IMG database
delivered within the scope of one IMG transport session. A
sender will generally deliver only a subset of metadata from
its whole database of IMG metadata as a full IMG, but a full
IMG could also represent the whole IMG database of a particular
sender. Different subsets of the sender's IMG database may be
provided within different transport sessions; similarly, the
same subset may be provided in more than one transport session.
Internet Media Guide (IMG)
An IMG is a generic term to describe the formation, delivery
and use of IMG metadata. The definition of the IMG is
intentionally left imprecise.
IMG ANNOUNCE
Unsolicited delivery of IMG metadata to an IMG receiver.
References to parts of the IMG metadata may also be included,
Luoma, et al. Expires June 8, 2004 [Page 5]
Internet-Draft IMG Metadata December 2003
instead of the actual metadata.
IMG Block
IMG block consists of one or more IMG Descriptions.
IMG Description
A collection of IMG metadata. There are the following subtypes
of IMG Descriptions: Complete IMG Description, Delta IMG
Description and IMG Pointer.
IMG Element
The smallest atomic element of IMG metadata that can be
transmitted separately and referenced individually from other
IMG elements.
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.
IMG NOTIFY
Delivery of an IMG update notification in response to an IMG
SUBSCRIBE. Identifies the parts of the IMG metadata that have
changed without delivering the updated IMG metadata.
IMG Operation
An atomic process for the IMG transport protocol to deliver IMG
metadata or control IMG sender(s) or IMG receiver(s).
IMG Pointer
A reference, such as URI, that the receiver is able to address
specific metadata with. An IMG pointer may be used to
separately obtain IMG elements, or perform another IMG
management function such as data expiry and erasure.
IMG Proxy
IMG proxy is a combined IMG receiver and IMG sender that can
Luoma, et al. Expires June 8, 2004 [Page 6]
Internet-Draft IMG Metadata December 2003
filter from one or more IMG senders and output to one or more
IMG transport sessions. Logically a proxy fits in between IMG
senders and receivers. A proxy may also cache IMG metadata and
may provide its own bandwidth control or congestion control
schemes on the output.
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.
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.
IMG Transport Protocol
A protocol that transports IMG metadata from IMG sender to IMG
receiver(s).
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 series of IMG transport protocol
Luoma, et al. Expires June 8, 2004 [Page 7]
Internet-Draft IMG Metadata December 2003
interactions that provide delivery of IMG metadata from the
sender to the receiver(s).
IMG Update Notification
An IMG Description containing one or more IMG Pointers.
Luoma, et al. Expires June 8, 2004 [Page 8]
Internet-Draft IMG Metadata December 2003
4. Use of IMG Transfer Envelope with IMG Operations
IMG transfer envelope is used with the following logical IMG
operations: IMG ANNOUNCE, IMG NOTIFY and IMG RESOLVE. The following
sections describe the use of IMG transfer envelope to support both
initial and update discovery of IMG.
4.1 Initial Discovery
An IMG sender SHOULD make its full IMG available to IMG receivers
using IMG ANNOUNCE and/or IMG RESOLVE. An IMG receiver may need to
receive the full IMG when the terminal has just started receiving a
particular IMG, or when its cached copy of the metadata cannot be
synchronized with IMG updates or it has been outdated.
The IMG sender should split its complete IMG to IMG blocks, each
comprising one or more IMG elements. An IMG block is a unit for IMG
transport protocols that can be uniquely identified and versioned.
The complete transfer of an IMG block means the transfer of all the
IMG metadata within an IMG block. The IMG receiver MUST maintain the
version numbers of complete transfers for duplicate avoidance and
update discovery. How the IMG receiver knows when it has received all
the IMG blocks comprising a full IMG is out of scope of this
document.
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 complete transfers (IMG ANNOUNCE or IMG RESOLVE)
2. A sender's delta transfers (IMG ANNOUNCE or IMG RESOLVE)
3. A sender's IMG update notifications (IMG NOTIFY, IMG ANNOUNCE or
IMG RESOLVE)
The receiver will learn of any changes in the IMG metadata by
continuing to receive the complete transfers, for example by
periodically using an IMG RESOLVE by receiving transmissions of the
metadata via IMG ANNOUNCE. However, the use of delta transfers and/or
IMG update notifications may provide more efficient means for update
discovery. Delta transfer means transferring only the parts of the
IMG metadata that have changed from the last version of the complete
transfer, whereas sending an IMG update notification means
transferring IMG Pointers identifying the parts of the IMG metadata
Luoma, et al. Expires June 8, 2004 [Page 9]
Internet-Draft IMG Metadata December 2003
that have changed from the last version of the complete transfer.
An IMG sender SHOULD provide IMG metadata delta transfers via IMG
ANNOUNCE, IMG RESOLVE or both, in addition to complete transfers.
After receiving sufficient IMG metadata, an IMG receiver may continue
receiving only delta transfers, if available, instead of complete
transfers. Each delta 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.
After each delta transfer, the IMG receiver MAY need to verify if it
has missed an earlier delta transfer(s) to the particular IMG block;
this can be accomplished by checking the majorVersion and
minorVersion fields in the IMG transfer envelope. It is recommended
that the IMG receiver attempts to recover the missing update by
verifying the current versions of the relevant metadata (for example,
by obtaining the complete transfer again, or by querying the versions
of the locally cached IMG metadata).
In addition to sending complete and delta transfers, an IMG sender
MAY send IMG update notifications (IMG Pointers). These IMG update
notifications consist of references to IMG elements that have changed
recently (e.g., since the previous complete transfer). After
receiving an IMG update notification and discovering the parts of IMG
that have changed, an IMG receiver MAY obtain the update from
complete or delta transfers using either IMG ANNOUNCE or IMG QUERY.
4.3 Versioning
The version of a complete transfer is identified by the field
majorVersion in the IMG transfer envelope. The version of a delta
transfer or an IMG update notification is identified by the
combination of the fields majorVersion and minorVersion in the IMG
transfer envelope. In the case of delta transfer or IMG update
notification, the field majorVersion identifies the version of the
complete transfer that the delta transfer / IMG update notification
pertains to.
Luoma, et al. Expires June 8, 2004 [Page 10]
Internet-Draft IMG Metadata December 2003
5. Format of the IMG Transfer Envelope
An IMG block must be encapsulated into or associated with an IMG
transfer envelope before it is passed to an IMG transport protocol
for delivery. The transfer envelope enables each IMG block to be
uniquely identified and versioned in a uniform way independent of the
particular IMG transport protocol used for delivery. The same
envelope format is used for the logical operations IMG ANNOUNCE, IMG
NOTIFY and IMG RESOLVE.
The following attributes can be associated with the IMG payload. The
attributes are mandatory to include unless marked as optional.
o metadataID: A URI providing a unique identifier for the IMG block.
o majorVersion: Current version number of the complete transfer of
IMG block. The version number is initially zero, and is increased
by one whenever the complete transfer is changed.
o minorVersion (optional): Current version number of the delta
transfer of IMG block. This field MUST be present for delta
transfers and IMG update notifications (IMG Pointers), and MUST
NOT be present for complete transfers. The value of this field is
initially zero, and is increased by one whenever the delta
transfer is changed. An updated delta transfer SHOULD be sent as
soon as there has been a change in the contents of an IMG block.
o lastDelta: The value of "true" in this boolean field is used to
inform receivers that there will be no more updates to delta
transfers or IMG update notifications pertaining to the current
version of the complete transfer; the version of the complete
transfer will be updated instead, and any subsequent delta
transfers or IMG update notifications will pertain to the next
version of the complete transfer. Receivers of delta transfers are
able to reconstruct the contents of the next complete transfer by
updating the current version of a complete transfer with a delta
transfer that has the same value of majorVersion and a value of
"true" in the lastDelta flag.
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 transfer envelope fields and the IMG block associated with
it. Signing, encryption or both can be applied to the whole transfer
Luoma, et al. Expires June 8, 2004 [Page 11]
Internet-Draft IMG Metadata December 2003
envelope or just to parts of it.
An XML schema for the IMG transfer envelope is defined in Appendix A,
providing a wrapper that can be used for encapsulating an IMG block
before transmission. Appendix B provides a simple example of using
this wrapper for IMG metadata.
Luoma, et al. Expires June 8, 2004 [Page 12]
Internet-Draft IMG Metadata December 2003
6. 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, et al. Expires June 8, 2004 [Page 13]
Internet-Draft IMG Metadata December 2003
7. 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, et al. Expires June 8, 2004 [Page 14]
Internet-Draft IMG Metadata December 2003
Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCD 14, March 1997.
[2] Nomura, Y., Walsh, R., Luoma, J., Ott, J. and H. Schulzrinne,
"Protocol Requirements for Internet Media Guides",
draft-ietf-mmusic-img-req-01 (work in progress), December 2003.
[3] Nomura, Y., Walsh, R., Luoma, J., Asaeda, H. and H. Schulzrinne,
"A Framework for the Usage of Internet Media Guides",
draft-ietf-mmusic-img-framework-01 (work in progress), December
2003.
Luoma, et al. Expires June 8, 2004 [Page 15]
Internet-Draft IMG Metadata December 2003
Informative References
[4] Luoma, J., "MUPPET: Internet Media Guide Unidirectional
Point-to-Multipoint Transport Protocol",
draft-luoma-mmusic-img-muppet-03 (work in progress), October
2003.
[5] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[6] Ott, J., Bormann, C. and D. Kutscher, "Session Description and
Capability Negotiation", draft-ietf-mmusic-sdpng-07 (work in
progress), October 2003.
Authors' Addresses
Juha-Pekka Luoma
Nokia
P.O. Box 100 (Visiokatu 1)
Tampere FIN-33721
Finland
EMail: juha-pekka.luoma@nokia.com
Jani Peltotalo
Tampere University of Technology
P.O. Box 553 (Korkeakoulunkatu 1)
Tampere FIN-33101
Finland
EMail: jani.peltotalo@tut.fi
Sami Peltotalo
Tampere University of Technology
P.O. Box 553 (Korkeakoulunkatu 1)
Tampere FIN-33101
Finland
EMail: sami.peltotalo@tut.fi
Luoma, et al. Expires June 8, 2004 [Page 16]
Internet-Draft IMG Metadata December 2003
Appendix A. XML Schema for the IMG Transfer Envelope
Different formats can be provided for conveying the IMG transfer
envelope parameters specified in Section 5. Figure 1 provides a
non-normative example of an XML schema specifying the IMG transfer
envelope syntax.
Figure 1: The XML Schema of the IMG Transfer Envelope
The fields of the IMG transfer envelope (represented as attributes in
the XML schema) are used as described in Section 5, with the
following additional notes.
o lastDelta (optional): if this attribute is not present, the value
of "false" is assumed.
The following additional fields in the XML schema enable either XML
or plain ASCII payload to be used in the envelope payload.
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, for example Session Description and
Capability Negotiation (SDPng) [6]. Only well-formed XML must be
used in this field. The XML payload MUST contain a reference to a
valid XML schema, enabling receivers to determine the format of
the XML payload.
o asciiPayload: The metadata payload in a textual, non-XML format.
The MIME content type of the textual payload (for example,
"application/sdp" referring to the Session Description Protocol
[5] format) MUST be indicated using the "type" attribute.
Luoma, et al. Expires June 8, 2004 [Page 18]
Internet-Draft IMG Metadata December 2003
Appendix B. Example of an IMG Transfer Envelope
Figure 2 shows a non-normative example of a Complete IMG Description
encapsulated within an IMG transfer envelope. In this example, the
format defined in Appendix A is used for the IMG transfer envelope,
and the SDP syntax [5] is used for the IMG Description.
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 2: Example of an IMG transfer envelope
Luoma, et al. Expires June 8, 2004 [Page 19]
Internet-Draft IMG Metadata December 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, et al. Expires June 8, 2004 [Page 20]
Internet-Draft IMG Metadata December 2003
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Luoma, et al. Expires June 8, 2004 [Page 21]