MMUSIC R. Walsh
Internet-Draft J-P. Luoma
Expires: May 17, 2005 Nokia
J. Peltotalo
S. Peltotalo
Tampere University of Technology
J. Greifenberg
Universitaet Bremen
November 16, 2004
The IMG Envelope
draft-walsh-mmusic-img-envelope-02
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.
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 May 17, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This document defines the metadata transfer envelope for Internet
Media Guides (IMGs). IMG metadata describes files, resources and
Walsh, et al. Expires May 17, 2005 [Page 1]
Internet-Draft The IMG Envelope November 2004
multimedia programs available for streaming or downloading via
multicast or unicast. IMG metadata is encapsulated into, or
associated with, an IMG envelope before actual transport. The IMG
envelope is a structure providing independence between IMG transport
protocols and different metadata formats. This specification
provides the IMG envelope instantiation using structured Extensible
Markup Language (XML) syntax, both as a wrapper in which to embed an
IMG metadata fragment object and as a distinct object to associate
with a distinct IMG metadata object.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. IMG Envelope Usage . . . . . . . . . . . . . . . . . . . . . . 9
4.1 Applicability of an IMG Envelope . . . . . . . . . . . . . 9
4.1.1 The Two IMG Envelope Cases . . . . . . . . . . . . . . 9
4.1.2 Relationship with IMG Data Types . . . . . . . . . . . 10
4.1.3 Relationship with IMG Operations . . . . . . . . . . . 10
4.2 IMG Metadata Structure and Fragmentation . . . . . . . . . 10
4.2.1 Fragmentation . . . . . . . . . . . . . . . . . . . . 10
4.2.2 Fragments within Fragments . . . . . . . . . . . . . . 11
4.3 IMG Metadata Discovery . . . . . . . . . . . . . . . . . . 11
4.3.1 Initial IMG Metadata Discovery . . . . . . . . . . . . 11
4.3.2 IMG Metadata Update Discovery . . . . . . . . . . . . 11
4.4 Versioning of the IMG Metadata Fragment . . . . . . . . . 13
4.4.1 Support for Non-contiguous Version Series . . . . . . 13
4.5 Detecting the IMG Metadata Fragment Format Type . . . . . 14
4.6 Securing IMG Envelope Integrity . . . . . . . . . . . . . 15
4.7 Reliable Delivery of IMG Envelope and Fragment Data . . . 15
4.8 Parsing and Storage of IMG Metadata . . . . . . . . . . . 16
4.9 Administrative Scope . . . . . . . . . . . . . . . . . . . 17
5. IMG Envelope Format . . . . . . . . . . . . . . . . . . . . . 18
5.1 IMG Envelope Semantics . . . . . . . . . . . . . . . . . . 18
5.2 XML Syntax for the IMG Envelope . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 21
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
7.1 Media-Type Registration Request for
application/envelope+xml . . . . . . . . . . . . . . . . . 23
7.2 Media-Type Registration Request for
application/envelope . . . . . . . . . . . . . . . . . . . 24
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
9.1 Normative References . . . . . . . . . . . . . . . . . . . . 27
9.2 Informative References . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 28
A. IMG Envelope Examples . . . . . . . . . . . . . . . . . . . . 30
Walsh, et al. Expires May 17, 2005 [Page 2]
Internet-Draft The IMG Envelope November 2004
A.1 SDP Metadata Fragment Embedded in an IMG Envelope . . . . 30
A.2 An IMG Envelope Referencing an XML Metadata Fragment . . . 30
B. Relationship with IMG Requirements . . . . . . . . . . . . . . 32
Intellectual Property and Copyright Statements . . . . . . . . 33
Walsh, et al. Expires May 17, 2005 [Page 3]
Internet-Draft The IMG Envelope November 2004
1. Introduction
This document defines the format and use of Internet Media Guide
(IMG) 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 files, resources and multimedia
programs available for streaming or downloading via multicast or
unicast. IMG metadata is encapsulated into, or associated with, an
IMG envelope before it is passed to an IMG transport protocol. The
purpose of the IMG envelope is to provide independence of metadata
formats from transport protocols, and to enable versioning, updating
and expiring of transmitted metadata. This specification provides
the IMG envelope instantiation using structured Extensible Markup
Language (XML) syntax [17], both as a wrapper in which to embed an
IMG metadata object and as a distinct object to associate with a
distinct IMG metadata object.
Walsh, et al. Expires May 17, 2005 [Page 4]
Internet-Draft The IMG Envelope November 2004
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].
Walsh, et al. Expires May 17, 2005 [Page 5]
Internet-Draft The IMG Envelope November 2004
3. Terminology
Complete IMG Description
Provides a complete syntax and semantics to describe an IMG
metadata fragment, which does not need any additional
information from other IMG descriptions. It may contain either
a full IMG or, more commonly, a subset thereof. [3]
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. [3]
Full IMG
Represents a subset/whole of the sender's IMG database
delivered within the scope of one IMG transport session. (In
this context, the sender's database represents the metadata
which the sender has access to, some or all of the IMG metadata
may be stored locally on the IMG sender in question.) A sender
may deliver only a subset of metadata from its whole metadata
database 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. Federations of senders
using the same definition of full IMG are allowed.
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. (This definition is copied
verbatim from [3].)
IMG ANNOUNCE
IMG ANNOUNCE is an IMG operation for the unsolicited delivery
of IMG metadata from an IMG sender to IMG receiver(s) [3].
References to parts of IMG metadata may also be included,
instead of the actual metadata. [3]
IMG Description
An IMG metadata fragment in one of three forms: Complete IMG
Description, Delta IMG Description and IMG Pointer. (This
definition is copied from [3] with modifications.)
IMG Element
The smallest atomic element of IMG metadata that can be
transmitted separately and referenced individually from other
IMG elements. (This definition is copied verbatim from [3].)
IMG Metadata
Walsh, et al. Expires May 17, 2005 [Page 6]
Internet-Draft The IMG Envelope November 2004
A set of metadata consisting of one or more IMG elements. IMG
metadata may describe many things, such as 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. (This
definition is copied from [3] with modifications.)
IMG Metadata Fragment
IMG metadata that is identified distinctly from other IMG
metadata. The uniqueness of the identification will be a
function of the administrative scope required. An IMG metadata
fragment is distinct from an IMG element in that the former may
contain multiple IMG elements and the mapping of IMG elements
to IMG metadata fragments, for transport, may be deployment
specific - even if some of the same content, and IMG elements
descriptions of that content, are common to multiple
deployments. [3]
IMG Metadata Object
A distinct and individually transportable set of IMG metadata
such as an IMG metadata fragment or an IMG envelope with an
embedded IMG metadata fragment. [3]
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. [3]
IMG Operation
An atomic process for the IMG transport protocol to deliver IMG
metadata or control IMG sender(s) or IMG receiver(s). (This
definition is copied from [3] with modifications.)
IMG Pointer
Provides a reference that the receiver is able to address
specific metadata with. An IMG Pointer may be used to
separately obtain (transport) IMG elements, or perform another
IMG management function such as data expiry and erasure. [3]
IMG QUERY
Request to receive a delivery of IMG metadata. [3]
IMG Receiver
A logical entity that receives media guides from an IMG sender,
analogous to a client. (This definition is copied from [3]
with modifications.)
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. [3]
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.
Walsh, et al. Expires May 17, 2005 [Page 7]
Internet-Draft The IMG Envelope November 2004
A sender can additionally be a receiver - see IMG transceiver.
(This definition is copied from [3] with modifications.)
IMG SUBSCRIBE
A request for notifications of changes in IMG metadata updates,
from a receiver to a sender or transceiver. [3]
IMG Transceiver
An IMG transceiver combines an IMG receiver and sender. It may
modify received IMG metadata or merge IMG metadata received
from a several different IMG senders. (This definition is
copied verbatim from [3].)
IMG Transport Protocol
A protocol that transports IMG metadata from IMG sender to IMG
receiver(s). (This definition is copied verbatim from [3].)
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 interactions that provide delivery of IMG metadata
f
rom the sender to the receiver(s). (This definition is copied
verbatim from [3].)
IMG Update Notification
Contains IMG Pointer(s) that identify the changed parts of an
IMG metadata fragment. An IMG update notification is similar
to a Delta IMG Description, with the exception that the changed
IMG metadata is not included in this IMG description. [3]
Walsh, et al. Expires May 17, 2005 [Page 8]
Internet-Draft The IMG Envelope November 2004
4. IMG Envelope Usage
4.1 Applicability of an IMG Envelope
A single IMG envelope shall describe a single IMG metadata fragment,
and thus instances of the two are paired.
4.1.1 The Two IMG Envelope Cases
An instance of IMG envelope shall be associated with an instance of
an IMG metadata fragment by one of two methods:
- Embedded: The IMG metadata fragment is embedded within the IMG
envelope
- Referenced: The IMG metadata fragment is referenced from the IMG
envelope
Figures 1a and 1b illustrate the embedded and referenced cases.
+-------------------+ +-------------------+
| IMG envelope | | IMG envelope |
| { | | { |
| <metadataURI> | | <metadataURI> | ----\
| ... | | ... | \
| } | | } | |
| | +-------------------+ |
| +---------------+ | |
| | IMG metadata | | +-------------------+ /
| | fragment | | | IMG metadata | <-/
| | { | | | fragment |
| | ... | | | { |
| | } | | | ... |
| +---------------+ | | } |
+-------------------+ +-------------------+
(a) (b)
Figure 1: IMG Envelope: (a) Embedded Case, (b) Referenced Case
In the embedded case, the envelope and fragment are, by definition,
transported together and in-band of one another. In the referenced
case, the envelope and fragment MAY be transported together and
in-band, or out-of-band of one another using different transport
sessions.
An IMG sender SHALL make an IMG envelope instance available for each
IMG metadata fragment instance. The creation and use of _both_ an
embedded envelope instance and a referenced envelope instance for a
particular fragment instance is permitted, but is not generally
Walsh, et al. Expires May 17, 2005 [Page 9]
Internet-Draft The IMG Envelope November 2004
expected.
Detailed discussion of the transport of envelope and fragment are
beyond the scope of this document, however, it is anticipated that
envelopes will be transported at least as often than their respective
fragments.
4.1.2 Relationship with IMG Data Types
An instance of an IMG envelope describes a certain instance of a
certain IMG metadata fragment, irrespective of whether the complete,
delta or pointer data type functionality is used. The content type
(MIME type) of the fragment is used to differentiate complete and
delta descriptions of an IMG metadata fragment, as described in
section 4.5.
A referencing envelope provides the functionality the pointer data
type by itself and SHOULD be used for this purpose where it is
implemented.
4.1.3 Relationship with IMG Operations
An IMG envelope is used with the following logical IMG operations:
IMG ANNOUNCE, IMG NOTIFY and IMG RESOLVE. The following sections
describe the use of IMG envelope to support both initial and update
discovery of IMG.
4.2 IMG Metadata Structure and Fragmentation
4.2.1 Fragmentation
An IMG sender SHALL select the subset (or entirety) of available IMG
metadata that it will make available to IMG receivers using IMG
ANNOUNCE and/or IMG RESOLVE. This represents a sender's full IMG and
delimits the quantity and level of dynamics a sender must maintain.
The IMG sender SHALL structure its full IMG as a set if IMG metadata
fragments, each corresponding to a Complete IMG Description. To IMG
transport protocols, an IMG metadata fragment is a discrete unit that
can be uniquely identified and versioned.
Note, multiple IMG senders may form a federation of senders/servers
and share a common definition of their full IMG and fragmentation
structure, and this may additionally be administered by some other
entity in the same domain. This document intentionally provides no
advice or requirements on federations of senders.
Walsh, et al. Expires May 17, 2005 [Page 10]
Internet-Draft The IMG Envelope November 2004
4.2.2 Fragments within Fragments
An IMG metadata fragment may contain some or all of the description
of one or more other IMG metadata fragments. However, this requires
a more complex data model, namespace and metadata maintenance
mechanisms in both senders and receivers. Some data syntaxes provide
tools to simplify the implementation of this kind of feature, such as
XPath in XML. However, the use of a general container mechanism must
be considered wherever using multiple syntaxes and syntaxes without
built-in namespace tools. Grouping mechanisms at the transport layer
and Multipart-MIME [10] are particularly good candidates for a
virtual container and a fully encapsulating container. Any such
container is a distinct IMG metadata fragment.
4.3 IMG Metadata Discovery
4.3.1 Initial IMG Metadata Discovery
An IMG receiver may need to receive a larger amount of IMG metadata
when the terminal has just started receiving from a particular IMG
sender, or when its cached copies of IMG metadata cannot be
synchronized with IMG updates or have been outdated.
The IMG receiver MUST maintain the version numbers of each IMG
metadata fragment to avoid duplication and for update discovery. How
the IMG receiver knows when it has received all the IMG metadata
fragments it requires (i.e. the determination of an IMG receiver's
"full IMG") is out of the scope of this document.
4.3.2 IMG Metadata 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. An IMG receiver may monitor the following
types of IMG metadata from an IMG sender for changes:
1. Complete description transfers (IMG ANNOUNCE or IMG RESOLVE)
2. Delta description transfers (IMG ANNOUNCE or IMG RESOLVE)
3. IMG update notifications, i.e. Pointer transfers (IMG NOTIFY,
IMG ANNOUNCE or IMG RESOLVE)
The receiver will learn of any changes in the IMG metadata by
continuing to receive the complete description transfers, for example
by periodically using an IMG RESOLVE, or by receiving transmissions
of the metadata via IMG ANNOUNCE. However, the use of delta
description transfers and/or IMG update notifications may provide
more efficient means for update discovery.
Walsh, et al. Expires May 17, 2005 [Page 11]
Internet-Draft The IMG Envelope November 2004
A Delta IMG Description provides only part of a Complete IMG
Description, defining the difference from a previous version of the
Complete IMG Description in question. An IMG receiver MAY ignore
delta descriptions and MAY silently discard them: this allows simple
"complete-only" r
eceivers to be used wherever the complexity of
implementing the delta mechanisms in those receivers is not
justified, while not preventing forward migration to delta
functionality in the same deployment. (There may be utility in using
a only the metadata management (e.g. versioning) information of a
delta even in the case of ignoring delta metadata (i.e. using just
the pointer data from a delta), however this is beyond the scope of
this document.)
The content type of a metadata fragment identifies whether it is a
delta description. Other means of delta description type
identification, such as dedicated delta transport channels, are also
permitted but are beyond the scope of this document. In the absence
of another delta description type identification type, the transport
mechanism SHOULD identify the content type (i.e. using Content-Type
in the HTTP header [4] and Content-Type in the FLUTE FDT Instances
[5]). In the case of an embedding IMG envelope, the content type
MUST be given by the envelope, and there is no further requirement on
the transport mechanism to declare this.
As with a complete description, a delta description's content type
enables a receiver to identify which component should handle this
data (i.e. is capable of patching that type of delta description).
The content type of the base version (complete description) may also
be useful in selecting and configuring the patching component's.
Delta IMG Description content types SHOULD be IANA registered.
The default behaviour of a delta-capable IMG receiver is to interpret
the version of the delta description as a single increment from the
previous version. In the default case, before applying the
incremental patch the receiver MUST have full knowledge of the
previous version (it must have received a complete description of the
previous version, or have reconstructed it using previous delta
description(s) and an earlier version of complete description).
Otherwise, the receiver MUST NOT apply the incremental patch. Other
patching behaviour, such as multiple minor delta versions to be
applied to a common major complete version, are permitted but require
additional signalling to the receiver(s) and are beyond the scope of
this document.
Where deltas are deployed, an IMG sender SHALL deliver Delta IMG
Descriptions using IMG ANNOUNCE, IMG RESOLVE or both operations.
After receiving sufficient IMG metadata, an IMG receiver may continue
Walsh, et al. Expires May 17, 2005 [Page 12]
Internet-Draft The IMG Envelope November 2004
receiving only delta descriptions, if available, instead of complete
descriptions. Each delta description describes the IMG metadata (of
a fragment) that has 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
metadata fragment; this can be accomplished by checking the version
field in the IMG envelope. The IMG receiver may attempt 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). Note,
whether or not a receiver needs to get missing updates is
implementation specific.
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 description). 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 descriptions using either IMG ANNOUNCE or IMG
QUERY.
4.4 Versioning of the IMG Metadata Fragment
The version of an IMG metadata fragment SHALL be identified by a
version field in the IMG envelope, irrespective of the IMG data type
(i.e. for complete, delta and pointer types alike). The metadataURI
("metadataURI" is defined in section 5 of this document) and version
number SHALL resolve to a unique instance of the IMG metadata
fragment (and its paired IMG envelope). The level of this uniqueness
is dependent on the administrative scope of the metadataURI namespace
and the version control.
Note: The same version number is inherited to the IMG envelope as IMG
envelope and IMG metadata fragment instances occur in matched pairs.
Thus, there is no need for an additional "version number of the
envelope" attribute.
4.4.1 Support for Non-contiguous Version Series
The system and transport protocol determines the delivery frequency
and delivery methods of envelopes and fragments. However, two
specific rules apply in the case that an IMG sender updates an IMG
metadata fragment more than once between subsequent deliveries:
Walsh, et al. Expires May 17, 2005 [Page 13]
Internet-Draft The IMG Envelope November 2004
- The delta data type MUST NOT be used if the previous version IMG
metadata fragment was not delivered to the same receiver-base. Note,
"receiver-base" may be a single receiver, for unicast IMG transport
protocols, or a user group, for multicast IMG transport protocols.
With the possible exception of a case where a receiver confirms
multicast delivery to a sender, this implies that delta descriptions
must be preceded by zero or more delta descriptions each one version
apart and, preceding those, a complete descriptions using the same
transport protocol context - i.e. the same protocol and with some
context (transaction history) preserved.
- IMG receiver SHALL support reception of subsequent IMG metadata
fragment versions, also where the version number has increased by
more than one (i.e. where one or more intermediate versions were not
send or else lost in delivery).
Note: If the previous received version is earlier than one less than
the latest received version, and the latest version delivered is a
delta description, the receiver should assume an error has occurred.
It may not be possible to determine whether the missed intermediate
versions were due to sender, delivery or receiver error. Further
discussion of action upon detection of such and error is out of scope
of this document.
4.5 Detecting the IMG Metadata Fragment Format Type
The IMG envelope SHALL provide a content type field. This field MUST
provide the MIME type of the IMG metadata fragment when the IMG
metadata fragment is embedded in the envelope. This field MAY be
used when the IMG metadata fragment is not embedded.
For IMG metadata fragments associated with their IMG envelope (not
embedded) the MIME type of the IMG metadata fragment SHOULD be
provided by the IMG transport protocol (e.g. as a Content-Type text
string or a well-specified binary encoded enumeration).
Use of IANA registered MIME types is RECOMMENDED to ensure maximum
interoperability. The specific IMG metadata fragment formats (and
syntaxes) supported may be implementation depended, although the
following IANA registered MIME types may be of particular interest:
- application/sdp
- application/xml
- multipart/mixed
Walsh, et al. Expires May 17, 2005 [Page 14]
Internet-Draft The IMG Envelope November 2004
4.6 Securing IMG Envelope Integrity
In general, the IMG envelope data SHOULD NOT be encrypted, although
it can be signed. Unencrypted envelope data allows IMG transceivers
to cache and maintain IMG metadata without being required to be a
trusted party able to decrypt the secure data.
Note, an IMG system aside from the public Internet may chose to trust
IMG transceivers, or exclude transceivers entirely. In these cases,
and where no bearer-specific security method is used, there may be
compelling reasons to encrypt this envelope data and, since in this
context the encryption of IMG envelope data presents no additional
limitations, the previous recommendation may be ignored.
IMG envelopes exposed to non-secure connections on the public
Internet SHOULD be signed to lessen the risk of security attacks
associated with delivery.
The signature, and possible encryption, method(s) used are very much
IMG envelope syntax and application specific. For example, one could
use S/MIME [15] as the content encoding type for IMG metadata objects
with an authentication wrapper, and one could use XML-DSIG [16] to
digitally sign an IMG metadata fragment or envelope. Further
specification on securing IMG envelopes is beyond the scope of this
document.
4.7 Reliable Delivery of IMG Envelope and Fragment Data
Reliable delivery of IMG metadata is a feature of the IMG transport
protocol(s) used and the technology suited to providing this very
much depends on the receiver base/group size and the selection of
unicast/multicast and bi-directional/unidirectional transport.
Reliability technology candidates include ACK, NACK, resend,
repetition and FEC schemes. Thus, the following text is for guidance
when designing or selecting IMG transport protocol(s) and the system
architecture they are used with.
The importance of the IMG envelope data and its timely delivery,
relative to its associated IMG metadata fragment, will vary from one
application and deployment to another. Where knowledge of data
consistency (envelope usage) is a higher priority than ensuring
perfect data consistency (fragment usage) then it would be prudent to
ensure the same or higher levels of reliability for the envelope
data, and vice versa.
Providing similar levels of reliable delivery overhead for both the
IMG envelope and IMG metadata fragment is a balance approach.
Walsh, et al. Expires May 17, 2005 [Page 15]
Internet-Draft The IMG Envelope November 2004
This would imply the same reliability method for the envelope and
fragment pair. However, it does not imply the same level of
reliability as, in the case that a discrete envelope object is
significantly smaller in size than its discrete fragment object,
there will be a greater loss multiplier effect for the larger object
(as it would be delivered using more IP packets providing a higher
probability that one or more is lost in transit).
Note: Providing a similar level of reliability overhead for an
embedded fragment as its embedding envelope is trivial since they are
transported as a single object.
4.8 Parsing and Storage of IMG Metadata
The IMG envelope SHALL provide option to use time stamps to set the
start and end times of the IMG metadata fragment applicability. The
end time sets the expiry time for the IMG metadata fragment, so that:
(a) a receiver would know that it needs to check whether its metadata
is consistent with the sender, (b) if the IMG metadata fragment is no
longer of use it may be discarded, (c) the same fragment version may
be unchanged but have it's time validity changed (so the client would
know that an update of the fragment is unnecessary although the
expiry is extended or shortened). The start time may be used to
postpone the use of an IMG metadata fragment until some future time.
The IMG transport protocol(s) should support all three IMG data types
(complete, delta and pointer). (This only implies that the use of
any data type shall not break the IMG transport protocol and does not
imply that a sender uses all three data types or that a receiver
harvests all three.) An IMG transport protocol MUST NOT assume that
an IMG metadata fragment is a complete description. An
implementation of an IMG transport protocol, IMG envelope management
and IMG metadata fragment management may or may not be a single
software entity. However, an IMG receiver (software) component that
is not capable of correctly using delta descriptions SHOULD NOT
process them and it SHOULD hand them to a component that is capable
of producing a new IMG metadata fragment by correctly patching the
previous version with the delta.
A simple IMG receiver MAY discard delta descriptions in the same way
it would discard complete descriptions whose MIME type is unknown.
However, in the case where the proportion of such simple IMG
receivers in the receiver-base is significant, the system design MAY
be, preferably, limited to not send delta descriptions and so avoid
the increased diversity in level of sender-receiver data consistency.
However, both of these approaches are generally NOT RECOMMENDED.
Further details of parsing and storage of IMG metadata are
Walsh, et al. Expires May 17, 2005 [Page 16]
Internet-Draft The IMG Envelope November 2004
implementation specific and so further specification of these is
beyond the scope of this document.
4.9 Administrative Scope
The definition of any administrative scope for source, aggregation or
proxy functions on IMG metadata and IMG envelope is out of the scope
of this document. It is assumed that the same administrative domain
applies to both IMG envelope and IMG metadata fragment of a specific
pair (note, this does not imply that they originate from the same
source or even same domain). It is also assumed that the namespace
is consistent with each name (URI) identifying only a single resource
(although, naturally it may identify multiple instances/versions of
that resource).
Where the administrative domain does not impose its own naming
conventions on the IMG envelope, the following naming convention
SHOULD be used for the IMG envelope name (URI):
envelopeURI = metadataURI + ".env"
Note: "metadataURI" is defined in section 5 of this document.
Walsh, et al. Expires May 17, 2005 [Page 17]
Internet-Draft The IMG Envelope November 2004
5. IMG Envelope Format
An IMG metadata fragment SHALL be encapsulated into or associated
with an IMG envelope before it is passed to an IMG transport protocol
for delivery. The IMG envelope enables each IMG metadata fragment to
be uniquely identified and versioned in a uniform way independent of
the particular IMG transport protocol used for delivery. The same
IMG envelope format is used for the logical operations IMG ANNOUNCE,
IMG NOTIFY and IMG RESOLVE.
The next section describes the mandatory semantics for any IMG
envelope format. The section after that describes the XML
instantiation of the IMG envelope. For maximum interoperability, the
given XML syntax SHOULD be used for textual representation of the IMG
envelope. However, an IMG transport protocol MAY specify the use of
an additional IMG envelope syntax, possibly providing a binary
encoding of the XML format of this document.
5.1 IMG Envelope Semantics
The following fields can be associated with the IMG metadata
fragment. The fields are mandatory to include unless marked as
optional.
The following fields are described in the IMG envelope and thus
associated with the respective IMG metadata fragment. Each field
SHALL be included in any IMG envelope, except where
specifically
marked as optional.
o metadataURI: A URI providing a unique identifier for the IMG
metadata fragment.
o version: The version number of the associated instance of the IMG
metadata fragment. The version number should be initialized to
one. The version number shall be increased by one whenever the
IMG metadata fragment is updated.
o validFrom: The date and time from which the IMG metadata fragment
is valid. (Optional). If not used, the receiver SHOULD assume
the IMG metadata fragment version is effective immediately.
o validUntil: The date and time when the IMG metadata fragment
expires. This sets the expiry time for the IMG metadata fragment.
(Optional).
o contentType: The MIME type of the IMG metadata fragment. For
textual representation, this MUST be used as defined for
"Content-Type" in [4]. For IMG envelopes which embed their IMG
metadata fragment this attribute is mandatory. For associations
by reference (not embedded) this field is optional.
An IMG envelope instantiation syntax MUST provide clear rules on the
Walsh, et al. Expires May 17, 2005 [Page 18]
Internet-Draft The IMG Envelope November 2004
determination of embedded fragment start and end boundaries. Rules
of how to avoid confusing the envelope parser with data in the
fragment (e.g. which resembles envelope data format) MUST be
provided with any IMG envelope syntax specification.
5.2 XML Syntax for the IMG Envelope
The following XML schema SHOULD be used for any textual instantiation
of the IMG envelope:
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:element name="metadataEnvelope">
<xs:complexType>
<xs:sequence>
<xs:element name="metadataFragment"
type="xs:string"
minOccurs="0"
maxOccurs="1">
</xs:element>
</xs:sequence>
<xs:attribute name="metadataURI"
type="xs:anyURI"
use="required"/>
<xs:attribute name="version"
type="xs:positiveInteger"
use="required"/>
<xs:attribute name="validFrom"
type="xs:dateTime"
use="optional"/>
<xs:attribute name="validUntil"
type="xs:dateTime"
use="optional"/>
<xs:attribute name="contentType"
type="xs:string"
use="optional"/>
<xs:anyAttribute processContents="skip"/>
</xs:complexType>
</xs:element>
</xs:schema>
Figure 2: XML Schema of the IMG Envelope XML Instance
Appendix A provides some IMG envelope XML instance examples which use
this schema.
Walsh, et al. Expires May 17, 2005 [Page 19]
Internet-Draft The IMG Envelope November 2004
The element "metadataFragment" SHALL be encapsulated in the IMG
envelope for embedded IMG metadata fragments, and SHALL NOT be
encapsulated where the IMG metadata fragment is not embedded.
"metadataFragment" contains the embedded IMG metadata fragment as
specified by the IMG envelope syntax.
As stated in the previous section, the contentType attribute is
mandatory for any IMG envelope with an IMG metadata fragment
embedding within it. The contentType is shown as optional in the
above schema as it may be omitted for referencing IMG envelopes.
An embedded IMG metadata fragment SHALL be escaped.
Generally, an embedded IMG metadata fragment SHOULD be escaped by
placing inside a CDATA section [17]. Everything starting after
"<![CDATA[" string and ending at the "]]>" string would be ignored by
the XML envelope parser (quotes not included). Thus, the embedded
parts would appear as "<![CDATA[" + IMG_metadata_fragment + "]]>".
In this case, the complete IMG envelope with embedded IMG metadata
fragment MUST NOT violate the rules of CDATA section usage [17].
In the case of an IMG metadata fragment including the XML for a CDATA
section, the embedded IMG metadata fragment MAY be escaped by
replacing illegal characters with their ampersand-escaped equivalents
[17] (instead of encapsulating the whole fragment in a CDATA
section). For instance "<" is an illegal character that would be
replaced by "<". This method is useful to avoid nesting CDATA
sections (which is not allowed).
An IMG metadata fragment which does not adhere to either of these two
methods MUST NOT be embedded in an IMG envelope, thus it may only be
referenced from an IMG envelope.
Other strategies, such encoding binary fragments as base64 [7], could
be useful. However, further specification of the correct structuring
IMG metadata fragments to meet character escaping requirements for
embedding is beyond the scope of this document.
Walsh, et al. Expires May 17, 2005 [Page 20]
Internet-Draft The IMG Envelope November 2004
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 protocol.
IMG receivers also SHOULD NOT trust IMG metadata modified by an IMG
transceiver, unless the IMG transceiver is trusted and then integrity
and authenticity of the changes must be similarly verified. However,
to operate in a typical network environment lacking infrastructure
for key distribution and trust verification, IMG receivers MAY be
configured to accept untrusted IMG metadata.
There may also be a 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 SHALL be fulfilled by the use of encryption at
IMG metadata level or by IMG transport protocol or IP network
protocol.
For multicast delivery of IMG metadata it is also recommended that
SSM [6] rather than ASM [14] delivery is used so that tampered
envelopes can be limited to man-in-the-middle attacks.
<The above consideration belongs to an architecture and/or multicast
transport specification. Keeping it in this document is tbd>
The IMG envelope is not active content and so MUST NOT be used as
executable code. In particular, an IMG envelope MUST NOT be
instantiated as a self extracting archive, or indeed in any
executable or script form. The XML IMG envelope specified in this
document meets these criteria.
Specific IMG metadata fragments are beyond the scope of this
document. However the following guidance is provided for designers
and implementers of any such IMG metadata fragments. If there is any
active content within an IMG metadata fragment, take care to
identify, document and (if reasonable) solve the security risks
associated with your use of active content. A delta description
would normally be used by a "patching application" and so delta
description might include data on actions for such an application
that could resemble a script (e.g. remove this attribute, change
that value). Thus the design and implementation of any "delta
patching application" for use with IMGs must address security risks
arising from the potential use of a delta description as active
content. The authors do not anticipate that Java (or other)
application code will be designated as IMG metadata.
Security issues associated with the m
edia types describe under the
Walsh, et al. Expires May 17, 2005 [Page 21]
Internet-Draft The IMG Envelope November 2004
IANA Considerations section of this document have been investigated
and no relevant problems have been identified.
Note, although we have taken security considerations seriously, there
is always a chance that we overlooked something apparent to the wider
Internet community. So we warmly encourage readers to inform us of
any additional issues, certain and uncertain!
Walsh, et al. Expires May 17, 2005 [Page 22]
Internet-Draft The IMG Envelope November 2004
7. IANA Considerations
The specified XML IMG envelope functions as an actual media format of
use to the general Internet community and thus media type
registration under the Standards Tree is appropriate to maximize
interoperability.
Two subtype registrations, of the application type, are requested:
type-name = application
subtype-name = envelope+xml
type-name = application
subtype-name = envelope
"application/envelope+xml" shall describe the XML IMG envelope format
and syntax as specified in section 5.2 of this document.
"application/envelope" shall describe any IMG envelope conforming to
the semantics specified in section 5.1 of this document, with the
exception of the XML instantiation specified in section 5.2 of this
document. It is HIGHLY RECOMMENDED that any additional IMG envelope
instantiations, other than that defined in section 5.2 of this
document, of interest to the general Internet community are
registered as "application/envelope.reg-name" under the Standards
Tree where:
reg-name = 1*reg-name-chars
reg-name-chars = ALPHA / DIGIT //
"!" / "#" / "$" / "%" / "&" /
"." / "+" / "-" / "^" / "_"
7.1 Media-Type Registration Request for application/envelope+xml
This section provides the registration request, as per [8] and [9],
to be submitted to IANA following IESG approval.
Type name: application
Subtype name: envelope+xml
Required parameters: none
Optional parameters: none
Encoding considerations: The envelope+xml type consists of UTF-8
ASCII characters [11] and must be well-formed XML.
Walsh, et al. Expires May 17, 2005 [Page 23]
Internet-Draft The IMG Envelope November 2004
Additional content and transfer encodings may be used with
envelope+xml files, with the appropriate encoding for any specific
file being entirely dependant upon the deployed application.
Restrictions on usage: Only for usage with IMG envelopes which are
valid according to the XML schema of section 5.2.
Security considerations: envelope+xml data is passive, and does not
generally represent a unique or new security threat. However, there
is some risk in sharing any kind of data, in that unintentional
information may be exposed, and that risk applies to envelope+xml
data as well.
Interoperability considerations: <details tbd>
Published specification: The present document including sections 5.1
and 5.2
Applications which use this media type: <details tbd>
Additional information:
Magic number(s): none
File extension(s): An IMG envelope may use the extension ".env"
but this is not required.
Macintosh File Type Code(s): none
Person & email address to contact for further information: Rod Walsh
(rod.walsh (at) nokia.com)
Intended usage: Common
Author/Change controller: <details tbd>
7.2 Media-Type Registration Request for application/envelope
This section provides the registration request, as per [8], to be
submitted to IANA following IESG approval.
Type name: application
Subtype name: envelope
Required parameters: none
Optional parameters: none
Encoding considerations: <details tbd>
Walsh, et al. Expires May 17, 2005 [Page 24]
Internet-Draft The IMG Envelope November 2004
Additional content and transfer encodings may be used with envelope
files, with the appropriate encoding for any specific file being
entirely dependant upon the deployed application.
Restrictions on usage: Only for usage with IMG envelopes which meet
the semantics of section 5.1 except for those which are valid
according to the XML schema of section 5.2 - where envelope+xml must
be used.
Security considerations: envelope data shall be passive, and does not
generally represent a unique or new security threat. However, there
is some risk in sharing any kind of data, in that unintentional
information may be exposed, and that risk applies to envelope data as
well.
Interoperability considerations: <details tbd>
Published specification: The present document including sections 5.1
and 5.2
Applications which use this media type: <details tbd>
Additional information:
Magic number(s): none
File extension(s): An IMG envelope may use the extension ".env"
but this is not required.
Macintosh File Type Code(s): none
Person & email address to contact for further information: Rod Walsh
(rod.walsh (at) nokia.com)
Intended usage: Limited use
Author/Change controller: <details tbd>
Walsh, et al. Expires May 17, 2005 [Page 25]
Internet-Draft The IMG Envelope November 2004
8. Acknowledgements
We would like to extend special thanks to Toni Paila, Jean-Pierre
Evain, Harsh Mehta and Joerg Ott whose support for, review of, and
input to this specification has been very helpful.
Walsh, et al. Expires May 17, 2005 [Page 26]
Internet-Draft The IMG Envelope November 2004
9. References
9.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCP 14, March 1997.
[2] Walsh, R., Nomura, Y., Luoma, J-P., Ott, J. and H. Schulzrinne,
"Protocol Requirements for Internet Media Guides",
draft-ietf-mmusic-img-req-07 (work in progress), June 2004.
[3] Nomura, Y., Walsh, R., Luoma, J-P., Asaeda, H. and H.
Schulzrinne, "A Framework for the Usage of Internet Media
Guides", draft-ietf-mmusic-img-framework-08 (work in progress),
July 2004.
[4] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[5] Paila, T., Luby, M., Lehtonen, R., Roca, V. and R. Walsh,
"FLUTE - File Delivery over Unidirectional Transport", RFC
3926, October 2004.
[6] Holbrook, H. and B. Gain, "Source-Specific Multicast for IP",
draft-ietf-ssm-arch-06 (work in progress), September 2004.
[7] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
RFC 3548, July 2003.
[8] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet
Mail Extensions (MIME) Part Four: Registration Procedures", RFC
2048, BCP 13, November 1996.
[9] Murata, M., St.Laurent, S. and D. Kohn, "XML Media Types", RFC
3023, January 2001.
[10] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, November
1996.
[11] Yergeau, F., "UTF-8, a transformation for
mat of ISO 10646", RFC
2279, January 1998.
9.2 Informative References
[12] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
Walsh, et al. Expires May 17, 2005 [Page 27]
Internet-Draft The IMG Envelope November 2004
[13] Ott, J., Bormann, C. and D. Kutscher, "Session Description and
Capability Negotiation", draft-ietf-mmusic-sdpng-07 (work in
progress), October 2003.
[14] Deering, S., "Host Extensions for IP Multicasting", RFC 1112,
STD 5, August 1989.
[15] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC
2633, June 1999.
[16] Eastlake, D., Reagle, J. and D. Solo, "(Extensible Markup
Language) XML-Signature Syntax and Processing"", RFC 3275,
March 2002.
[17] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., Yergeau,
F. and J. Cowan, "Extensible Markup Language (XML) 1.1"", W3C
Recommendation, February 2004.
Authors' Addresses
Rod Walsh
Nokia
P.O. Box 100 (Visiokatu 1)
Tampere FIN-33721
Finland
EMail: rod.walsh (at) nokia.com
Juha-Pekka Luoma
Nokia
P.O. Box 100 (Visiokatu 1)
Tampere FIN-33721
Finland
EMail: juha-pekka.luoma (at) nokia.com
Jani Peltotalo
Tampere University of Technology
P.O. Box 553 (Korkeakoulunkatu 1)
Tampere FIN-33101
Finland
EMail: jani.peltotalo (at) tut.fi
Walsh, et al. Expires May 17, 2005 [Page 28]
Internet-Draft The IMG Envelope November 2004
Sami Peltotalo
Tampere University of Technology
P.O. Box 553 (Korkeakoulunkatu 1)
Tampere FIN-33101
Finland
EMail: sami.peltotalo (at) tut.fi
Janico Greifenberg
Universitaet Bremen
MZH 5520
Bibliothekstr. 1
Bremen D-28359
Germany
EMail: jgre (at) tzi.de
Walsh, et al. Expires May 17, 2005 [Page 29]
Internet-Draft The IMG Envelope November 2004
Appendix A. IMG Envelope Examples
A.1 SDP Metadata Fragment Embedded in an IMG Envelope
Figure 3 gives an informational example of a Complete IMG Description
in SDP [12] embedded within the XML IMG envelope.
<?xml version="1.0" encoding="UTF-8"?>
<metadataEnvelope
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="envelope.xsd"
metadataURI="http/www.example.com/img001/session001.sdp"
version="1"
validFrom="2003-12-17T09:30:47-05:00"
validUntil="2003-12-17T09:30:47-05:00"
contentType="application/sdp">
<metadataFragment>
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
</metadataFragment>
</metadataEnvelope>
Figure 3: Example of an IMG envelope
A.2 An IMG Envelope Referencing an XML Metadata Fragment
Figure 4 gives an informational example of the XML IMG envelope
referencing a non-embedded IMG metadata fragment.
Walsh, et al. Expires May 17, 2005 [Page 30]
Internet-Draft The IMG Envelope November 2004
<?xml version="1.0" encoding="UTF-8"?>
<metadataEnvelope
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="envelope.xsd"
metadataURI="http/www.example.com/img001/service001.xml"
version="1"
validUntil="2003-12-17T09:30:47-05:00">
</metadataEnvelope>
Figure 4: Example of a Referencing IMG Envelope
Walsh, et al. Expires May 17, 2005 [Page 31]
Internet-Draft The IMG Envelope November 2004
Appendix B. Relationship with IMG Requirements
<tbd: categorize each requirement as fulfilled (and maybe how) or out
of scope of the envelope>
Walsh, et al. Expires May 17, 2005 [Page 32]
Internet-Draft The IMG Envelope November 2004
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
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 (2004). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Walsh, et al. Expires May 17, 2005 [Page 33]