draft-ietf-mmusic-img-framework-06.txt   draft-ietf-mmusic-img-framework-07.txt 
skipping to change at page 1, line 13 skipping to change at page 1, line 13
Internet Engineering Task Force MMUSIC WG Internet Engineering Task Force MMUSIC WG
Internet Draft Y. Nomura Internet Draft Y. Nomura
Fujitsu Labs. Fujitsu Labs.
R. Walsh R. Walsh
J-P. Luoma J-P. Luoma
Nokia Nokia
H. Asaeda H. Asaeda
INRIA INRIA
H. Schulzrinne H. Schulzrinne
Columbia University Columbia University
draft-ietf-mmusic-img-framework-06.txt draft-ietf-mmusic-img-framework-07.txt
June 1, 2004 June 21, 2004
Expires: December 2004 Expires: December 2004
A Framework for the Usage of Internet Media Guides A Framework for the Usage of Internet Media Guides
STATUS OF THIS MEMO STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, I certify that any applicable
all provisions of Section 10 of RFC2026. patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance
with RFC 3668."
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as
Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six
and may be updated, replaced, or obsoleted by other documents at any months and may be updated, replaced, or obsoleted by other
time. It is inappropriate to use Internet-Drafts as reference documents at any time. It is inappropriate to use Internet-Drafts
material or to cite them other than as "work in progress". as reference material or to cite them other than a "work in
progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/1id-abstracts.html
To view the list Internet-Draft Shadow Directories, see The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html
Abstract Abstract
This document defines a framework for the delivery of Internet Media This document defines a framework for the delivery of Internet Media
Guides (IMGs). An IMG is a structured collection of multimedia Guides (IMGs). An IMG is a structured collection of multimedia
session descriptions expressed using SDP, SDPng or some similar session descriptions expressed using SDP, SDPng or some similar
session description format. This document describes a generalized session description format. This document describes a generalized
model for IMG delivery mechanisms, the use of existing protocols and model for IMG delivery mechanisms, the use of existing protocols and
the need for additional work to create an IMG delivery the need for additional work to create an IMG delivery
infrastructure. infrastructure.
skipping to change at page 2, line 39 skipping to change at page 2, line 39
Proposed Framework Model ............................ 14 Proposed Framework Model ............................ 14
5.1 Existing Standard Fit to the IMG Framework Model .... 14 5.1 Existing Standard Fit to the IMG Framework Model .... 14
5.2 Outstanding IMG Mechanism Needs ..................... 16 5.2 Outstanding IMG Mechanism Needs ..................... 16
5.2.1 A Multicast Transport Protocol ...................... 16 5.2.1 A Multicast Transport Protocol ...................... 16
5.2.2 Usage of Unicast Transport Protocols ................ 17 5.2.2 Usage of Unicast Transport Protocols ................ 17
5.2.3 IMG Envelope ........................................ 17 5.2.3 IMG Envelope ........................................ 17
5.2.4 Baseline (Meta)Data Model Specification ............. 18 5.2.4 Baseline (Meta)Data Model Specification ............. 18
5.3 IMG Needs Fitting the IETF's Scope .................. 19 5.3 IMG Needs Fitting the IETF's Scope .................. 19
6 Security Considerations ............................. 19 6 Security Considerations ............................. 19
7 IANA Considerations ................................. 21 7 IANA Considerations ................................. 21
8 References .......................................... 21 8 Normative References ................................ 21
9 Acknowledgements .................................... 22 9 Informative References .............................. 21
10 Authors' Addresses .................................. 22 10 Acknowledgements .................................... 22
11 Full Copyright Statement ............................ 23 11 Authors' Addresses .................................. 22
12 Full Copyright Statement ............................ 23
1 Introduction 1 Introduction
Internet Media Guides (IMGs) provide and deliver structured Internet Media Guides (IMGs) provide and deliver structured
collections of multimedia descriptions expressed using SDP [1], collections of multimedia descriptions expressed using SDP [2],
SDPng [2] or other description formats. They are used to describe SDPng [3] or other description formats. They are used to describe
sets of multimedia services (e.g. television program schedules, sets of multimedia services (e.g. television program schedules,
content delivery schedules) and refer to other networked content delivery schedules) and refer to other networked
resources including web pages. IMGs provide an envelope for metadata resources including web pages. IMGs provide an envelope for metadata
formats and session descriptions defined elsewhere with the aim of formats and session descriptions defined elsewhere with the aim of
facilitating structuring, versioning, referencing, distributing, and facilitating structuring, versioning, referencing, distributing, and
maintaining (caching, updating) such information. maintaining (caching, updating) such information.
IMG metadata may be delivered to a potentially large audience, who 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 use it to join a subset of the sessions described, and who may need
to be notified of changes to the IMG metadata. Hence, a framework for to be notified of changes to the IMG metadata. Hence, a framework for
skipping to change at page 3, line 33 skipping to change at page 3, line 33
metadata. The data types give generalized means to deliver and metadata. The data types give generalized means to deliver and
manage the consistency of application-specific IMG metadata. IMG manage the consistency of application-specific IMG metadata. IMG
operations cover traditional broadcast-style scenarios, operations cover traditional broadcast-style scenarios,
multicast-based distributions, unicast-based push and interactive multicast-based distributions, unicast-based push and interactive
retrievals similar to web pages. Since we envision that any retrievals similar to web pages. Since we envision that any
Internet host can be a sender and receiver of IMG metadata, a host Internet host can be a sender and receiver of IMG metadata, a host
involved in IMG operations performs one or more of the roles involved in IMG operations performs one or more of the roles
defined as the entities in IMG framework model. These are then defined as the entities in IMG framework model. These are then
shown in a number of simplified deployment scenarios. The shown in a number of simplified deployment scenarios. The
requirements for IMG delivery mechanisms and descriptions can be requirements for IMG delivery mechanisms and descriptions can be
found in the IMG requirements document [3]. found in the IMG requirements document [4].
Then, this document outlines the use of existing protocols to create Then, this document outlines the use of existing protocols to create
an IMG delivery infrastructure. It aims to organize existing an IMG delivery infrastructure. It aims to organize existing
protocols into a common model and show their capabilities and protocols into a common model and show their capabilities and
limitations from the viewpoint of IMG delivery functions. One of the limitations from the viewpoint of IMG delivery functions. One of the
multicast-enabling IMG requirements is scaling well to a large number multicast-enabling IMG requirements is scaling well to a large number
of hosts and IMG senders in a network. Another issue is the need for of hosts and IMG senders in a network. Another issue is the need for
flexibility and diversity in delivery methods, whereas existing flexibility and diversity in delivery methods, whereas existing
protocols tend to be bound to a specific application. protocols tend to be bound to a specific application.
2 Terminology 2 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [4]. document are to be interpreted as described in RFC 2119 [1].
Internet Media Guide (IMG): IMG is a generic term to describe Internet Media Guide (IMG): IMG is a generic term to describe
the formation, delivery and use of IMG metadata. The the formation, delivery and use of IMG metadata. The
definition of the IMG is intentionally left imprecise. [3] definition of the IMG is intentionally left imprecise. [4]
IMG Element: The smallest atomic element of metadata that can be IMG Element: The smallest atomic element of metadata that can be
transmitted separately by IMG operations and referenced transmitted separately by IMG operations and referenced
individually from other IMG elements. [3] individually from other IMG elements. [4]
IMG Metadata: A set of metadata consisting of one or more IMG IMG Metadata: A set of metadata consisting of one or more IMG
elements. IMG metadata describes the features of multimedia elements. IMG metadata describes the features of multimedia
content used to enable selection of and access to media content used to enable selection of and access to media
sessions containing content. For example, metadata may sessions containing content. For example, metadata may
consist of the URI, title, airtime, bandwidth needed, file consist of the URI, title, airtime, bandwidth needed, file
size, text summary, genre and access restrictions. [3] size, text summary, genre and access restrictions. [4]
IMG Description: A collection of IMG metadata which has a IMG Description: A collection of IMG metadata which has a
relationship to other IMG metadata. There are three data relationship to other IMG metadata. There are three data
types to describe the relationship: Complete IMG types to describe the relationship: Complete IMG
Descriptions, Delta IMG Description and IMG pointer. Descriptions, Delta IMG Description and IMG pointer.
IMG Delivery: The process of exchanging IMG metadata both in IMG Delivery: The process of exchanging IMG metadata both in
terms of large scale and atomic data transfers. [3] terms of large scale and atomic data transfers. [4]
IMG Sender: An IMG sender is a logical entity that sends IMG IMG Sender: An IMG sender is a logical entity that sends IMG
metadata to one or more IMG receivers. [3] metadata to one or more IMG receivers. [4]
IMG Receiver: An IMG receiver is a logical entity that receives IMG Receiver: An IMG receiver is a logical entity that receives
IMG metadata from an IMG sender. [3] IMG metadata from an IMG sender. [4]
IMG Transceiver: An IMG transceiver combines an IMG receiver and IMG Transceiver: An IMG transceiver combines an IMG receiver and
sender. It may modify received IMG metadata or merge IMG sender. It may modify received IMG metadata or merge IMG
metadata received from a several different IMG senders. [3] metadata received from a several different IMG senders. [4]
IMG Operation: An atomic operation of an IMG transport protocol, IMG Operation: An atomic operation of an IMG transport protocol,
used between IMG sender(s) and IMG receiver(s) for the used between IMG sender(s) and IMG receiver(s) for the
delivery of IMG metadata and for the control of IMG delivery of IMG metadata and for the control of IMG
sender(s)/receiver(s). [3] sender(s)/receiver(s). [4]
IMG Transport Protocol: A protocol that transports IMG metadata IMG Transport Protocol: A protocol that transports IMG metadata
from an IMG sender to IMG receiver(s). [3] from an IMG sender to IMG receiver(s). [4]
IMG Transport Session: An association between an IMG sender and IMG Transport Session: An association between an IMG sender and
one or more IMG receivers within the scope of an IMG one or more IMG receivers within the scope of an IMG
transport protocol. An IMG transport session involves a transport protocol. An IMG transport session involves a
time bound series of IMG transport protocol interactions time bound series of IMG transport protocol interactions
that provide delivery of IMG metadata from the IMG sender that provide delivery of IMG metadata from the IMG sender
to the IMG receiver(s). [3] to the IMG receiver(s). [4]
IMG Transfer: A transfer of IMG metadata consisting of Complete IMG Transfer: A transfer of IMG metadata consisting of Complete
IMG Descriptions, Delta IMG Descriptions and/or IMG IMG Descriptions, Delta IMG Descriptions and/or IMG
Pointers. Pointers.
3 IMG Common Framework Model 3 IMG Common Framework Model
Two common elements are found in all of existing IMG candidate cases: Two common elements are found in all of existing IMG candidate cases:
the need to describe the services; the need to deliver the the need to describe the services; the need to deliver the
descriptions. In some cases, the descriptions are multicast enablers descriptions. In some cases, the descriptions are multicast enablers
skipping to change at page 6, line 37 skipping to change at page 6, line 37
locate) specific metadata with. This may be used to separately obtain locate) specific metadata with. This may be used to separately obtain
metadata (Complete or Delta IMG Descriptions) or perform another IMG metadata (Complete or Delta IMG Descriptions) or perform another IMG
management function such as data expiry (and erasure). The IMG management function such as data expiry (and erasure). The IMG
Pointer may be used to reference IMG metadata elements within the IMG Pointer may be used to reference IMG metadata elements within the IMG
transport session and across IMG transport sessions. This pointer transport session and across IMG transport sessions. This pointer
type does not include IMG metadata per se (although it may also type does not include IMG metadata per se (although it may also
appear as a data field in Complete or Delta IMG descriptors). appear as a data field in Complete or Delta IMG descriptors).
3.2 Operation Set for IMG Delivery 3.2 Operation Set for IMG Delivery
A finite set of operations both meets the IMG requirements [3] and A finite set of operations both meets the IMG requirements [4] and
fits the roles of existing protocols. These are crystallized in the fits the roles of existing protocols. These are crystallized in the
next few sections. next few sections.
3.2.1 IMG ANNOUNCE 3.2.1 IMG ANNOUNCE
When an IMG receiver participates in unidirectional communications When an IMG receiver participates in unidirectional communications
(e.g. over satellite, terrestrial radio and wired multicast networks) (e.g. over satellite, terrestrial radio and wired multicast networks)
an IMG receiver may not need to send any IMG message to an IMG sender an IMG receiver may not need to send any IMG message to an IMG sender
prior to IMG metadata delivery. In this case, an IMG sender can prior to IMG metadata delivery. In this case, an IMG sender can
initiate unsolicited distribution for IMG metadata and an IMG sender initiate unsolicited distribution for IMG metadata and an IMG sender
skipping to change at page 20, line 4 skipping to change at page 20, line 4
bodies are well placed to do this work. This aspect need not be an bodies are well placed to do this work. This aspect need not be an
official IETF work item. official IETF work item.
Note, we acknowledge the need to exchange and agree on a baseline Note, we acknowledge the need to exchange and agree on a baseline
metadata model and application specific metadata for the purposes of metadata model and application specific metadata for the purposes of
interoperability testing between different implementations of IMG interoperability testing between different implementations of IMG
related IETF protocols. However, we feel that the IETF standards related IETF protocols. However, we feel that the IETF standards
process may not be required for this. process may not be required for this.
6 Security Considerations 6 Security Considerations
The IMG framework is developed from the IMG requirements document [3] The IMG framework is developed from the IMG requirements document [4]
and so the selection of specific protocols and mechanism for use with and so the selection of specific protocols and mechanism for use with
the IMG framework must also take into account the security the IMG framework must also take into account the security
considerations of the IMG requirements document. This framework considerations of the IMG requirements document. This framework
document does not mandate the use of specific protocols. However, an document does not mandate the use of specific protocols. However, an
IMG specification would inherit the security considerations of IMG specification would inherit the security considerations of
specific protocols used, although this is outside the scope of this specific protocols used, although this is outside the scope of this
document. document.
Protocol instantiations which are used to provide IMG operations will Protocol instantiations which are used to provide IMG operations will
have very different security considerations depending on their scope have very different security considerations depending on their scope
skipping to change at page 21, line 31 skipping to change at page 21, line 31
channel and protocol. For example, a secure unicast channel can be channel and protocol. For example, a secure unicast channel can be
used to deliver the keys and initialization vectors for an encryption used to deliver the keys and initialization vectors for an encryption
algorithm used on a multicast channel. The exploitation of this algorithm used on a multicast channel. The exploitation of this
opportunity is specific to the protocols used and is outside the opportunity is specific to the protocols used and is outside the
scope of this document. scope of this document.
7 IANA Considerations 7 IANA Considerations
There are no IANA considerations within this document. There are no IANA considerations within this document.
8 References 8 Normative References
[1] M. Handley and V. Jacobson, "SDP: session description protocol," [1] S. Bradner, "Key words for use in RFCs to indicate requirement
levels," RFC 2119, Internet Engineering Task Force, Mar. 1997.
9 Informative References
[2] M. Handley and V. Jacobson, "SDP: session description protocol,"
RFC 2327, Internet Engineering Task Force, Apr. 1998. RFC 2327, Internet Engineering Task Force, Apr. 1998.
[2] D. Kutscher, J. Ott, and C. Bormann, "Session description and [3] D. Kutscher, J. Ott, and C. Bormann, "Session description and
capability negotiation," Internet Draft draft-ietf-mmusic-sdpng-07, capability negotiation," Internet Draft draft-ietf-mmusic-sdpng-07,
Internet Engineering Task Force, Oct. 2003. Work in progress. Internet Engineering Task Force, Oct. 2003. Work in progress.
[3] Y. Nomura, R. Walsh, J-P. Luoma, J. Ott, and H. Schulzrinne, [4] Y. Nomura, R. Walsh, J-P. Luoma, J. Ott, and H. Schulzrinne,
"Protocol requirements for Internet media guides," Internet Draft "Requirements for Internet Media Guides," Internet Draft
draft-ietf-mmusic-img-req-06, Internet Engineering Task Force, June draft-ietf-mmusic-img-req-07, Internet Engineering Task Force, June
2004. Work in progress. 2004. Work in progress.
[4] S. Bradner, "Key words for use in RFCs to indicate requirement
levels," RFC 2119, Internet Engineering Task Force, Mar. 1997.
[5] TV-Anytime Forum, "Broadcast and On-line Services: Search, [5] TV-Anytime Forum, "Broadcast and On-line Services: Search,
select, and rightful use of content on personal storage systems select, and rightful use of content on personal storage systems
("TV-Anytime Phase 1"); Part 2: System description," ETSI-TS 102 ("TV-Anytime Phase 1"); Part 2: System description," ETSI-TS 102
822-2: System Description, V1.1.1, October 2003. 822-2: System Description, V1.1.1, October 2003.
[6] A. B. Roach, "Session initiation protocol (sip)-specific event [6] A. B. Roach, "Session initiation protocol (sip)-specific event
notification," RFC 3265, Internet Engineering Task Force, June 2002. notification," RFC 3265, Internet Engineering Task Force, June 2002.
[7] M. Luby, J. Gemmell, L. Vicisano, L. Rizzo, and J. Crowcroft, [7] M. Luby, J. Gemmell, L. Vicisano, L. Rizzo, and J. Crowcroft,
"Asynchronous layered coding (ALC) protocol instantiation," RFC 3450, "Asynchronous layered coding (ALC) protocol instantiation," RFC 3450,
Internet Engineering Task Force, Dec. 2002. Internet Engineering Task Force, Dec. 2002.
[8] T. Paila, M. Luby, R. Lehtonen, V. Roca, R. Walsh, "FLUTE - file [8] T. Paila, M. Luby, R. Lehtonen, V. Roca, R. Walsh, "FLUTE -
delivery over unidirectional transport," Internet Draft draft-ietf- file delivery over unidirectional transport," Internet Draft
rmt-flute-07, Internet Engineering Task Force, Dec. 2003. Work in draft-ietf-rmt-flute-08, Internet Engineering Task Force,
progress. June 2004. Work in progress.
[9] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J. [9] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J.
Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session
initiation protocol," RFC 3261, Internet Engineering Task Force, June initiation protocol," RFC 3261, Internet Engineering Task Force, June
2002. 2002.
[10] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, L. Masinter, P. [10] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, L. Masinter, P.
Leach and T. Berners-Lee, "Hypertext transfer protocol -- HTTP/1.1," Leach and T. Berners-Lee, "Hypertext transfer protocol -- HTTP/1.1,"
RFC 2616, Internet Engineering Task Force, June 1999. RFC 2616, Internet Engineering Task Force, June 1999.
[11] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: [11] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP:
a transport protocol for real-time applications," RFC 3550, Internet a transport protocol for real-time applications," RFC 3550, Internet
Engineering Task Force, July 2003. Engineering Task Force, July 2003.
9 Acknowledgements 10 Acknowledgements
The authors would like to thank Joerg Ott, Colin Perkins, Toni Paila, The authors would like to thank Joerg Ott, Colin Perkins, Toni Paila,
Jean-Pierre Evain, Magnus Westerlund and Petri Koskelainen for their Jean-Pierre Evain, Magnus Westerlund and Petri Koskelainen for their
excellent ideas and input to this document. excellent ideas and input to this document.
10 Authors' Addresses 11 Authors' Addresses
Yuji Nomura Yuji Nomura
Fujitsu Laboratories Ltd. Fujitsu Laboratories Ltd.
4-1-1 Kamikodanaka, Nakahara-ku, Kawasaki 211-8588 4-1-1 Kamikodanaka, Nakahara-ku, Kawasaki 211-8588
Japan Japan
Email: nom@flab.fujitsu.co.jp Email: nom@flab.fujitsu.co.jp
Rod Walsh Rod Walsh
Nokia Research Center Nokia Research Center
P.O. Box 100, FIN-33721 Tampere P.O. Box 100, FIN-33721 Tampere
skipping to change at page 23, line 23 skipping to change at page 23, line 23
Email: Hitoshi.Asaeda@sophia.inria.fr Email: Hitoshi.Asaeda@sophia.inria.fr
Henning Schulzrinne Henning Schulzrinne
Dept. of Computer Science Dept. of Computer Science
Columbia University Columbia University
1214 Amsterdam Avenue 1214 Amsterdam Avenue
New York, NY 10027 New York, NY 10027
USA USA
Email: schulzrinne@cs.columbia.edu Email: schulzrinne@cs.columbia.edu
11 Full Copyright Statement 12 Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78 and to the rights, licenses and restrictions contained in BCP 78 and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/