draft-ietf-mmusic-img-framework-02.txt   draft-ietf-mmusic-img-framework-03.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-02.txt draft-ietf-mmusic-img-framework-03.txt
December 22, 2003 February 16, 2003
Expires: June 2004 Expires: July 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 This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
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
skipping to change at page 2, line 21 skipping to change at page 2, line 21
3.1.1 Complete IMG Description ............................ 5 3.1.1 Complete IMG Description ............................ 5
3.1.2 Delta IMG Description ............................... 6 3.1.2 Delta IMG Description ............................... 6
3.1.3 IMG Pointer ......................................... 6 3.1.3 IMG Pointer ......................................... 6
3.2 Operation Set for IMG Delivery ...................... 6 3.2 Operation Set for IMG Delivery ...................... 6
3.2.1 IMG ANNOUNCE ........................................ 6 3.2.1 IMG ANNOUNCE ........................................ 6
3.2.2 IMG QUERY ........................................... 7 3.2.2 IMG QUERY ........................................... 7
3.2.3 IMG RESOLVE ......................................... 7 3.2.3 IMG RESOLVE ......................................... 7
3.2.4 IMG SUBSCRIBE ....................................... 7 3.2.4 IMG SUBSCRIBE ....................................... 7
3.2.5 IMG NOTIFY .......................................... 8 3.2.5 IMG NOTIFY .......................................... 8
3.2.6 Binding Between IMG Operations and Data Types ....... 8 3.2.6 Binding Between IMG Operations and Data Types ....... 8
3.3 IMG Entities ........................................ 8 3.3 IMG Entities ........................................ 9
3.4 Overview of Protocol Operations ..................... 9 3.4 Overview of Protocol Operations ..................... 10
4 Deployment Scenarios for IMG Entities ............... 9 4 Deployment Scenarios for IMG Entities ............... 10
4.1 Intermediary Cases .................................. 10 4.1 Intermediary Cases .................................. 10
4.2 One-to-many Unidirectional Multicast ................ 11 4.2 One-to-many Unidirectional Multicast ................ 12
4.3 One-to-one Bi-directional Unicast ................... 12 4.3 One-to-one Bi-directional Unicast ................... 13
4.4 Combined Operations with Common Metadata ............ 12 4.4 Combined Operations with Common Metadata ............ 13
5 Applicability of Existing Protocols to the 5 Applicability of Existing Protocols to the
Proposed Framework Model ....................................... 13 Proposed Framework Model ....................................... 13
5.1 Summary of Limitations of Existing Protocols ........ 13 5.1 Existing Protocol Fit to the IMG Framework Model
5.2 Existing Protocol Fit to the IMG Framework Model 5.2 Outstanding IMG Mechanism Needs ..................... 16
5.3 Outstanding IMG Mechanism Needs ..................... 16 5.2.1 A Multicast Transport Protocol ...................... 16
5.3.1 A Multicast Transport Protocol ...................... 16 5.2.2 Usage of Unicast Transport Protocols ................ 17
5.3.2 Usage of Unicast Transport Protocols ................ 17 5.2.3 IMG Transfer Envelope ............................... 17
5.3.3 IMG Transfer Envelope ............................... 17 5.2.4 Baseline (Meta)Data Model Specification ............. 18
5.3.4 Baseline (Meta)Data Model Specification ............. 18 5.3 IMG Needs Fitting the IETF's Scope .................. 18
5.4 IMG Needs Fitting the IETF's Scope .................. 18
6 Security Considerations ............................. 19 6 Security Considerations ............................. 19
7 Normative References ................................ 21 7 IANA Considerations ................................. 21
8 Informative References .............................. 22 8 Normative References ................................ 21
9 Acknowledgements .................................... 22 9 Informative References .............................. 21
10 Authors' Addresses .................................. 22 10 Acknowledgements .................................... 22
11 Authors' Addresses .................................. 22
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, SDPng or collections of multimedia descriptions expressed using SDP, SDPng or
some similar description format. They are used to describe sets of some similar description format. They are used to describe sets of
multimedia sessions (e.g. television program schedules, content multimedia sessions (e.g. television program schedules, content
delivery schedules etc.) and refer to other networked resources delivery schedules etc.) and refer to other networked resources
including web pages. IMGs provide an envelope for metadata formats including web pages. IMGs provide an envelope for metadata formats
and session descriptions defined elsewhere with the aim of and session descriptions defined elsewhere with the aim of
skipping to change at page 3, line 28 skipping to change at page 3, line 28
This document defines a common framework model for IMG delivery This document defines a common framework model for IMG delivery
mechanisms and their deployment in network entities. There are three mechanisms and their deployment in network entities. There are three
fundamental components in IMG framework model: data types, operation fundamental components in IMG framework model: data types, operation
sets and entities. These components specify a set of framework sets and entities. These components specify a set of framework
guideline for IMG delivery to efficiently deliver and describe IMG guideline for IMG delivery to efficiently deliver and describe IMG
metadata. The data types give common base descriptions on top of an metadata. The data types give common base descriptions on top of an
application-specific IMG metadata. IMG operations cover traditional application-specific IMG metadata. IMG operations cover traditional
broadcast-style scenarios, multicast-based distributions, unicast- broadcast-style scenarios, multicast-based distributions, unicast-
based push and interactive retrievals similar to web pages. Since we based push and interactive retrievals similar to web pages. Since we
envision that any Internet host can be a sender and receiver of IMG envision that any Internet host can be a sender and receiver of IMG
metadata, an host involved in IMG operations perform one or more of metadata, a host involved in IMG operations perform one or more of
roles defined as the entities in IMG framework model. These are then roles 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 [1]. found in [1].
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 common model and show their capabilities and protocols into 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
skipping to change at page 6, line 25 skipping to change at page 6, line 25
and small and frequent changes occur to IMG elements. Thus, this and small and frequent changes occur to IMG elements. Thus, this
description itself cannot represent complete metadata set until it is description itself cannot represent complete metadata set until it is
combined with existing, or future, description knowledge. combined with existing, or future, description knowledge.
3.1.3 IMG Pointer 3.1.3 IMG Pointer
An IMG Pointer provides a simple identifier or locator, such as a An IMG Pointer provides a simple identifier or locator, such as a
URI, that the IMG receiver is able to reference (or reference and URI, that the IMG receiver is able to reference (or reference and
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 expire (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 metadata per se (although it may also appear as type does not include metadata per se (although it may also appear as
a data field in Complete or Delta IMG descriptors). 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 [1] and A finite set of operations both meets the IMG requirements [1] 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 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
is the only entity which can maintain the distribution (this includes is the only entity which can maintain the distribution (this includes
scenarios with multiple and co-operative IMG senders). This operation scenarios with multiple and co-operative IMG senders). This operation
is useful when there are considerably large number IMG receivers or is useful when there are considerably large number IMG receivers or
IMG receiver(s) do not have a guaranteed uplink connection to the IMG IMG receiver(s) do not have a guaranteed uplink connection to the IMG
sender(s). The IMG sender may also include authentication data in the sender(s). The IMG sender may also include authentication data in the
announce operation so that IMG receivers may check the authenticity announce operation so that IMG receivers may check the authenticity
of the metadata. This operation is able to carry any of the IMG data of the metadata. This operation is able to carry any of the IMG data
types. types.
Note, there is no restriction to prevent IMG ANNOUNCE from being used Note, there is no restriction to prevent IMG ANNOUNCE from being used
in an asynchronous solicited manner, where a separate operation in an asynchronous solicited manner, where a separate operation
(possibly out of band) is able to subscribe/register IMG receivers to (possibly out of band) enables IMG receivers to subscribe/register to
the IMG ANNOUNCE operation. the IMG ANNOUNCE operation.
3.2.2 IMG QUERY 3.2.2 IMG QUERY
If an IMG receiver needs to obtain IMG metadata, an IMG receiver can If an IMG receiver needs to obtain IMG metadata, an IMG receiver can
send an IMG QUERY message and initiate a receiver-driven IMG send an IMG QUERY message and initiate a receiver-driven IMG
transport session. The IMG receiver expects a synchronous response to transport session. The IMG receiver expects a synchronous response to
the subsequent request from the IMG sender. This operation can be the subsequent request from the IMG sender. This operation can be
used where a bi-directional transport network is available between used where a bi-directional transport network is available between
the IMG sender and receiver. Some IMG receivers may want to obtain the IMG sender and receiver. Some IMG receivers may want to obtain
skipping to change at page 7, line 46 skipping to change at page 7, line 46
sent that metadata. The sender may also include authentication data sent that metadata. The sender may also include authentication data
in the resolve operation so that IMG receivers may check the in the resolve operation so that IMG receivers may check the
authenticity of the metadata. This operation may carry any of the IMG authenticity of the metadata. This operation may carry any of the IMG
data types. data types.
3.2.4 IMG SUBSCRIBE 3.2.4 IMG SUBSCRIBE
If an IMG receiver wants to be notified when the IMG metadata it If an IMG receiver wants to be notified when the IMG metadata it
holds is stale, the IMG receiver can use the IMG SUBSCRIBE operation holds is stale, the IMG receiver can use the IMG SUBSCRIBE operation
in advance in order to solicit notify messages from an IMG sender. in advance in order to solicit notify messages from an IMG sender.
This operation may provide the IMG sender with specific details of
which metadata or notification services it is interested in (in the
case where the IMG sender offers more than the simplest "all data"
service). The operation implicitly provides the functionality of
unsubscribing to inform an IMG sender that an IMG receiver wishes to
stop getting certain (or all) notifications. It should be noted that
the unsubscription may be provided implicitly by the expiry (timeout)
of a subscription before it is renewed. However, these details
belong to the messaging protocol and are beyond the scope of this
document.
Since the IMG receiver doesn't know when metadata will be updated and Since the IMG receiver doesn't know when metadata will be updated and
the notify message will arrive, this operation does not synchronize the notify message will arrive, this operation does not synchronize
with the notify messages. The IMG receiver may wait for notify with the notify messages. The IMG receiver may wait for notify
messages for a long time. The IMG sender may authenticate the IMG messages for a long time. The IMG sender may authenticate the IMG
receiver to investigate whether an IMG SUBSCRIBE operation is from an receiver to investigate whether an IMG SUBSCRIBE operation is from an
authorized IMG receiver. authorized IMG receiver.
3.2.5 IMG NOTIFY 3.2.5 IMG NOTIFY
An IMG NOTIFY is used in response to an earlier IMG SUBSCRIBE. An An IMG NOTIFY is used asynchronously in response to an earlier IMG
IMG NOTIFY generates a notify message indicating that updated IMG SUBSCRIBE. An IMG NOTIFY generates a notify message indicating that
metadata is available or part of the existing IMG metadata is stale. updated IMG metadata is available or part of the existing IMG
An IMG NOTIFY may be delivered more than once during the time an IMG metadata is stale. An IMG NOTIFY may be delivered more than once
SUBSCRIBE is active. This operation may carry any of the IMG data during the time an IMG SUBSCRIBE is active. This operation may carry
types. The IMG sender may also include authentication data in the IMG any of the IMG data types. The IMG sender may also include
NOTIFY operation so that IMG receivers may check the authenticity of authentication data in the IMG NOTIFY operation so that IMG receivers
the messages. may check the authenticity of the messages.
3.2.6 Binding Between IMG Operations and Data Types 3.2.6 Binding Between IMG Operations and Data Types
There is a need to provide a binding between the various IMG There is a need to provide a binding between the various IMG
operations and IMG data types to allow management of each discrete operations and IMG data types to allow management of each discrete
set of IMG metadata transferred using an IMG operation. This binding set of IMG metadata transferred using an IMG operation. This binding
must be independent of any particular metadata syntax used to must be independent of any particular metadata syntax used to
represent a set of IMG metadata, as well as be compatible with any represent a set of IMG metadata, as well as be compatible with any
IMG transport protocol. The binding must uniquely identify the set of IMG transport protocol. The binding must uniquely identify the set of
IMG metadata delivered within an IMG transfer, regardless of the IMG metadata delivered within an IMG transfer, regardless of the
skipping to change at page 9, line 33 skipping to change at page 9, line 45
+------------------+------------------+------------------+ +------------------+------------------+------------------+
| IMG Listener | IMG Subscriber | IMG Querier | | IMG Listener | IMG Subscriber | IMG Querier |
+------------------+------------------+------------------+ +------------------+------------------+------------------+
| IMG Receiver | | IMG Receiver |
+------------------+------------------+------------------+ +------------------+------------------+------------------+
Figure 1: Relationship with IMG Entities Figure 1: Relationship with IMG Entities
3.4 Overview of Protocol Operations 3.4 Overview of Protocol Operations
The figure 2 gives an overview of the relationship between transport Figure 2 gives an overview of the relationship between transport
cases, IMG Operations and IMG data types (note, it is not a protocol cases, IMG Operations and IMG data types (note, it is not a protocol
stack). stack).
4 Deployment Scenarios for IMG Entities
This section provides some basic deployment scenarios for IMG
entities that illustrate common threads from protocols to use cases.
For the purposes of clarity, this document presents the simple
dataflow from an IMG sender to an IMG receiver, as shown in figure 3.
+--------------------------------------------------+ +--------------------------------------------------+
IMG | | IMG | |
Data types | Complete Desc., Delta Desc., Pointer | Data types | Complete Desc., Delta Desc., Pointer |
| | | |
+-------------------+----------------+-------------+ +-------------------+----------------+-------------+
IMG | IMG ANNOUNCE | IMG SUBSCRIBE | IMG QUERY | IMG | IMG ANNOUNCE | IMG SUBSCRIBE | IMG QUERY |
Operations | | IMG NOTIFY | IMG RESOLVE | Operations | | IMG NOTIFY | IMG RESOLVE |
+--------------+----+----------------+-------------+ +--------------+----+----------------+-------------+
IMG | | | IMG | | |
Transport | P-to-M | P-to-P | Transport | P-to-M | P-to-P |
| | | | | |
+--------------+-----------------------------------+ +--------------+-----------------------------------+
Figure 2: IMG Operations and IMG Data type Figure 2: IMG Operations and IMG Data type
4 Deployment Scenarios for IMG Entities
This section provides some basic deployment scenarios for IMG
entities that illustrate common threads from protocols to use cases.
For the purposes of clarity, this document presents the simple
dataflow from an IMG sender to an IMG receiver, as shown in figure 3.
+-------------+ +---------------+ +-------------+ +---------------+
| IMG Sender | | IMG Receiver | | IMG Sender | | IMG Receiver |
| |--------------->| | | |--------------->| |
+-------------+ +---------------+ +-------------+ +---------------+
Figure 3: A Simple IMG Sender to IMG Receiver Relationship Figure 3: A Simple IMG Sender to IMG Receiver Relationship
4.1 Intermediary Cases 4.1 Intermediary Cases
Some IMG metadata may be distributed to a large number of IMG Some IMG metadata may be distributed to a large number of IMG
receivers. If, for example, some IMG metadata is public information receivers. If, for example, some IMG metadata is public information
and the IMG sender provides the same information for all IMG and the IMG sender provides the same information for all IMG
receivers. This kind of IMG metadata may be distributed from one IMG receivers. This kind of IMG metadata may be distributed from one IMG
sender to multiple IMG receivers (Figure 4) and/or or may be relayed sender to multiple IMG receivers (Figure 4) and/or or may be relayed
across a set of IMG transceivers that receive the IMG metadata, across a set of IMG transceivers that receive the IMG metadata,
possibly filter or modify its content, and then forward it. The possibly filter or modify its content, and then forward it.
relayed network architecture is similar to content distribution
network architecture [3] (CDNs). Existing CDNs may carry IMG
metadata. Satellite and peer-to-peer networks may also carry IMG
metadata.
+----------+ +----------+ +----------+ +----------+
| IMG | | IMG | | IMG | | IMG |
| Sender |---- ---->| Receiver | | Sender |---- ---->| Receiver |
+----------+ \ / +----------+ +----------+ \ / +----------+
\ / \ /
. \ +-----------+ / . . \ +-----------+ / .
. -->|IMG |----- . . -->|IMG |----- .
. -->|Transceiver| \ . . -->|Transceiver| \ .
/ +-----------+ \ / +-----------+ \
skipping to change at page 12, line 21 skipping to change at page 12, line 29
| IMG |-------- . | IMG |-------- .
| Announcer | \ . | Announcer | \ .
+-----------+ \ +----------+ +-----------+ \ +----------+
------------->| IMG | ------------->| IMG |
| Listener | | Listener |
| # | | # |
+----------+ +----------+
Figure 5: IMG Unidirectional Multicast Distribution Example Figure 5: IMG Unidirectional Multicast Distribution Example
4.3 One-to-one Bi-directional Unicast
+----------+ +----------+ +----------+ +----------+
| IMG |<------(1)------| IMG | | IMG | | IMG |
| Resolver |-------(2)----->| Querier | | Resolver | | Querier |
+----------+ +----------+ +----------+ +----------+
| |
|-----------IMG QUERY ---------->|
| |
|<---------IMG RESOLVE-----------|
| |
Figure 6: Query/Resolve Deployment Example Figure 6: Query/Resolve Sequence Example
4.3 One-to-one Bi-directional Unicast
Both query/resolve (figure 6) and subscribe/notify (figure 7) message Both query/resolve (figure 6) and subscribe/notify (figure 7) message
exchange operations are feasible. exchange operations are feasible. The "time passes" activities of
figure 7 are purely for example.
+----------+ +------------+
| IMG | | IMG |
| Notifier | | Subscriber |
+----------+ +------------+
| |
|<---------IMG SUBSCRIBE---------|
: :
(time passes)
: :
|-----------IMG NOTIFY---------->|
: :
(time passes)
: :
|-----------IMG NOTIFY---------->|
| |
Figure 7: Subscribe/Notify Sequence Example
4.4 Combined Operations with Common Metadata 4.4 Combined Operations with Common Metadata
As shown in figure 8, a common data model for multiple protocol As shown in figure 8, a common data model for multiple protocol
operations allows a diverse range of IMG senders and receivers to operations allows a diverse range of IMG senders and receivers to
provide consistent and interoperable sets of IMG metadata. provide consistent and interoperable sets of IMG metadata.
+----------+ +------------+ 5 Applicability of Existing Protocols to the Proposed Framework Model
| |<-------(1)--------| |
| IMG |--------(2)------->| IMG |
| Notifier | (time passes) | Subscriber |
| |--------(3)------->| |
+----------+ +------------+
Figure 7: Subscribe/Notify Deployment Example 5.1 Existing Protocol Fit to the IMG Framework Model
SDP: The SDP format could be used to describe session-level
parameters (e.g. scheduling, addressing and the use of media codecs)
to be included in Complete IMG Descriptions. Although there are
extension points in SDP allowing the format to be extended, there are
limitations in the flexibility of this extension mechanism. However,
SDP syntax cannot provide IMG Descriptions and IMG Pointers without
significant unused overhead. Because it is expected that the
information conveyed by SDP is just a small subset of IMG metadata
the use of SDP for other than session-level IMG parameters may not be
reasonable.
IMG Metadata IMG Senders IMG Receivers IMG Metadata IMG Senders IMG Receivers
+--------------+ +--------------+
+-----------+ ---->| IMG Listener | +-----------+ ---->| IMG Listener |
| IMG | / +--------------+ | IMG | / +--------------+
/| Announcer |----- /| Announcer |-----
+-------------+ / +-----------+ \ +--------------+ +-------------+ / +-----------+ \ +--------------+
| IMG |-+ / ---->| IMG Listener | | IMG |-+ / ---->| IMG Listener |
| Description | |-+ / | - - - - - - -| | Description | |-+ / | - - - - - - -|
skipping to change at page 13, line 35 skipping to change at page 14, line 28
+-------------+ | \ | Resolver | +-------------+ | \ | Resolver |
+-------------+ \ +-----------+<----\ +--------------+ +-------------+ \ +-----------+<----\ +--------------+
\ \--->| IMG Querier | \ \--->| IMG Querier |
\ +-----------+ | - - - - - - -| \ +-----------+ | - - - - - - -|
\| IMG |<--------->| IMG | \| IMG |<--------->| IMG |
| Notifier | | Subscriber | | Notifier | | Subscriber |
+-----------+ +--------------+ +-----------+ +--------------+
Figure 8: Combined System with Common Metadata Figure 8: Combined System with Common Metadata
5 Applicability of Existing Protocols to the Proposed Framework Model
5.1 Summary of Limitations of Existing Protocols
SDP [4] has a text-encoded syntax to specify multimedia sessions for
announcements and invitations. Although SDP is extensible, it has
limitations such as structured extensibility and capability to
reference properties of a multimedia session from the description of
another session.
These are mostly overcome by the XML-based SDPng [5], which is
intended for both two-way negotiation and also unidirectional
delivery. Since SDPng addresses multiparty multimedia conferences, it
is necessary to extend the XML schema in order to describe general
multimedia content.
MPEG-7 [6] is a collection of XML-based description tools for general
multimedia content including structured multimedia sessions. TV-
Anytime Forum [7] provides descriptions based on MPEG-7 for TV
specific program guides. These are likely to be limited to describe
pictures, music and movies, thus it may be necessary to extend these
descriptions in order to define a variety of documents, game
programs, binary files, live events and so on.
HTTP [8] is a well known information retrieval protocol using bi-
directional transport and widely used to deliver web-based content
descriptions to many hosts. However, it has well recognized
limitations of scalability in the number of HTTP clients since it
relies on the polling mechanism to keep information consistent
between the server and client.
SAP [9] is an announcement protocol that distributes session
descriptions via multicast. It does not support fine-grained metadata
selection and update notifications, as it always sends the whole
metadata. Given the lack of a wide-area multicast infrastructure, it
is likely only deployable within a local area network.
SIP [10] and SIP-specific event notification [11] can be used to
notify subscribers of the update of IMG metadata for bi-directional
transport. It is necessary for SIP Event to define an event package
for each specific application such as [12].
5.2 Existing Protocol Fit to the IMG Framework Model
SDP: The SDP format could be used to describe session-level
parameters (e.g. scheduling, addressing and the use of media codecs)
to be included in Complete IMG Descriptions. Although there are
extension points in SDP allowing the format to be extended, there are
limitations in the flexibility of this extension mechanism. However,
SDP syntax cannot provide Deleta IMG Descriptions and IMG Pointers
without significant unused overhead. Because it is expected that the
information conveyed by SDP is just a small subset of IMG metadata
the use of SDP for other than session-level IMG parameters may not be
reasonable.
SDPng: Similar to SDP, this format could also be used for SDPng: Similar to SDP, this format could also be used for
representing session-level parameters of IMG metadata. Compared to representing session-level parameters of IMG metadata. Compared to
SDP, the XML-based format of SDPng is much more flexible with regards SDP, the XML-based format of SDPng is much more flexible with regards
to extensions and combining with other description formats. to extensions and combining with other description formats.
MPEG-7: Descriptions based on the MPEG-7 standard could provide MPEG-7: Descriptions based on the MPEG-7 standard could provide
application-specific metadata describing the properties of multimedia application-specific metadata describing the properties of multimedia
content beyond parameters carried in SDP or SDPng descriptions. content beyond parameters carried in SDP or SDPng descriptions.
MPEG-7 provides a machine-readable format of representing content MPEG-7 provides a machine-readable format of representing content
categories and attributes, helping end-users or receiving software in categories and attributes, helping end-users or receiving software in
choosing content for reception: this is well in line with the IMG choosing content for reception: this is well in line with the IMG
usage scenarios of IMGs introduced in 3.2. Because MPEG-7 is based on usage scenarios of IMGs introduced in 3.2. MPEG-7 is based on XML so
XML, it is well suited for combining with other XML-based formats it is well suited for combining with other XML-based formats such as
such as SDPng. SDPng.
TV-Anytime Forum: The TV-Anytime Forum [3] provides descriptions
based on XML schema for TV-specific program guides. TV-Anytime uses
the MPEG-7 User description profile to a limited extent (for user
preferences and usage history) and also a TV-Anytime-specific data
model for other schema - which are optimised to describe broadcast
schedules, on-demand program guides and program events.
HTTP: The HTTP protocol can be used as a bi-directional/unicast IMG HTTP: The HTTP protocol can be used as a bi-directional/unicast IMG
transport protocol. Being a request-reply oriented protocol, HTTP is transport protocol. Being a request-reply oriented protocol, HTTP is
well suited for implementing synchronous operations such as QUERY, well suited for implementing synchronous operations such as QUERY,
RESOLVE and even SUBSCRIBE. However, HTTP does not provide RESOLVE and even SUBSCRIBE. However, HTTP does not provide
asynchronous operations such as ANNOUNCE and NOTIFY and to implement asynchronous operations such as ANNOUNCE and NOTIFY and to implement
asynchronous operations using HTTP, IMG receivers should poll the IMG asynchronous operations using HTTP, IMG receivers should poll the IMG
sender periodically. So alone, HTTP is not sufficient to fulfill IMG sender periodically. So alone, HTTP is not sufficient to fulfill IMG
requirements in a unicast deployment. requirements in a unicast deployment.
skipping to change at page 16, line 11 skipping to change at page 15, line 49
- It is an Experimental RFC with no support for progressing further - It is an Experimental RFC with no support for progressing further
In principle, the current SAP protocol could be extended to get In principle, the current SAP protocol could be extended to get
around its limitations (e.g. the use of a multipart MIME type in the around its limitations (e.g. the use of a multipart MIME type in the
SAP payload has been proposed, enabling multiple descriptions to be SAP payload has been proposed, enabling multiple descriptions to be
carried in a single SAP message). However, the amount of changes carried in a single SAP message). However, the amount of changes
needed in SAP to address all of the above limitations would needed in SAP to address all of the above limitations would
effectively result in a new protocol. Due to these limitations, the effectively result in a new protocol. Due to these limitations, the
use of SAP as an IMG transport protocol is not recommended. use of SAP as an IMG transport protocol is not recommended.
SIP: The SIP-specific event mechanism described in RFC 3265 [11] SIP: The SIP-specific event mechanism described in RFC 3265 [4]
provides a way to implement IMG SUBSCRIBE and IMG NOTIFY operations provides a way to implement IMG SUBSCRIBE and IMG NOTIFY operations
via a bi-directional unicast connection. However, there are via a bi-directional unicast connection. However, there are
scalability problems with this approach, as RFC 3265 currently does scalability problems with this approach, as RFC 3265 currently does
not consider multicast. not consider multicast.
5.3 Outstanding IMG Mechanism Needs RTSP: The RTSP protocol defines a retrieval and update notification
mechanism, named DESCRIBE and ANNOUNCE, for the description of a
presentation or media object in order to initialize a streaming
session. These methods are subset of the entire streaming control
operations in RTSP, thus these could not be available for individual
mechanisms. However, the DESCRIBE method in RTSP could be IMG QUERY,
RESOLVE and SUBSCRIBE, and the ANNOUNCE could be a IMG NOTIFY for a
streaming session controlled by RTSP.
5.2 Outstanding IMG Mechanism Needs
Several outstanding needs result from the IMG requirements, framework Several outstanding needs result from the IMG requirements, framework
model and existing relevant mechanisms as already shown in this model and existing relevant mechanisms as already shown in this
document. Four specific groupings of work are readily apparent which document. Four specific groupings of work are readily apparent which
are: (a) specification of an adequate multicast and unidirectional are: (a) specification of an adequate multicast and unidirectional
capable announcement protocol; (b) specification of the use of capable announcement protocol; (b) specification of the use of
existing unicast protocols to enable unicast subscribe and existing unicast protocols to enable unicast subscribe and
announcement/notification functionality; (c) specification of the announcement/notification functionality; (c) specification of the
metadata envelope which is common to, and independent of, the metadata envelope which is common to, and independent of, the
application metadata syntax(es) used; agreement on basic metadata application metadata syntax(es) used; agreement on basic metadata
models to enable interoperability testing of the above. The following models to enable interoperability testing of the above. The following
sections describe each of these. sections describe each of these.
5.3.1 A Multicast Transport Protocol 5.2.1 A Multicast Transport Protocol
SAP is currently the only open standard protocol suited to the SAP is currently the only open standard protocol suited to the
unidirectional/multicast delivery of IMG metadata. As discussed, it unidirectional/multicast delivery of IMG metadata. As discussed, it
fails to meet the IMG requirements in many ways and, since it is not fails to meet the IMG requirements in many ways and, since it is not
designed to be extensible, we recognize that a new multicast designed to be extensible, we recognize that a new multicast
transport protocol for announcements needs to be specified to meet transport protocol for announcements needs to be specified to meet
IMG needs. This protocol will be essential to IMG delivery for IMG needs. This protocol will be essential to IMG delivery for
unidirectional and multicast deployments. unidirectional and multicast deployments.
The Asynchronous Layered Coding (ALC) [13] protocol from the IETF The Asynchronous Layered Coding (ALC) [5] protocol from the IETF
Reliable Multicast Transport (RMT) working group is very interesting Reliable Multicast Transport (RMT) working group is very interesting
as it fulfils many of the requirements, is extensible and has the as it fulfils many of the requirements, is extensible and has the
ability to `plug-in' both FEC (Forward Error Correction -- for ability to `plug-in' both FEC (Forward Error Correction -- for
reliability) and CC (Congestion Control) functional blocks -- it is reliability) and CC (Congestion Control) functional blocks -- it is
specifically designed for unidirectional multicast object transport. specifically designed for unidirectional multicast object transport.
ALC is not fully specified, although RMT has a work-in-progress fully ALC is not fully specified, although RMT has a work-in-progress fully
specified protocol using ALC called FLUTE (File Delivery over specified protocol using ALC called FLUTE (File Delivery over
Unidirectional Transport) [14]. FLUTE seems to be the only fully Unidirectional Transport) [6]. FLUTE seems to be the only fully
specified transport and open specification on which a new IMG specified transport and open specification on which a new IMG
announcement protocol could be designed. Thus we recommend that ALC announcement protocol could be designed. Thus we recommend that ALC
and FLUTE be the starting points for this protocol's design. and FLUTE be the starting points for this protocol's design.
Developing a new protocol from scratch, or attempting to improve SAP, Developing a new protocol from scratch, or attempting to improve SAP,
is also feasible, although it would involve repeating many of the is also feasible, although it would involve repeating many of the
design processes and decisions already made by the IETF for ALC. design processes and decisions already made by the IETF for ALC.
Thus, we recommend only to attempt this if ALC-based protocols are Thus, we recommend only to attempt this if ALC-based protocols are
later found to be insufficient. later found to be insufficient.
In particular, any announcement protocol must feature sufficient In particular, any announcement protocol must feature sufficient
scalability, flexibility and reliability to meet IMG needs. Also, the scalability, flexibility and reliability to meet IMG needs. Also, the
ANNOUNCE operation must be supported and NOTIFY capability could be ANNOUNCE operation must be supported and NOTIFY capability could be
investigated for both hybrid unicast-multicast and unidirectional investigated for both hybrid unicast-multicast and unidirectional
unicast systems. unicast systems.
5.3.2 Usage of Unicast Transport Protocols 5.2.2 Usage of Unicast Transport Protocols
A thorough description of the use of existing unicast protocols is A thorough description of the use of existing unicast protocols is
essential for the use of IMGs in a unicast point-to-point essential for the use of IMGs in a unicast point-to-point
environment. Such a specification does not currently exist, although environment. Such a specification does not currently exist, although
several usable unicast transport protocols and specifications can be several usable unicast transport protocols and specifications can be
harnessed for this (SIP [10], SIP events [11], HTTP [8], etc.) In harnessed for this (SIP [7], SIP events [4], HTTP [8], etc.) In
particular, both SUBSCRIBE-NOTIFY and QUERY-RESOLVE operation pairs particular, both SUBSCRIBE-NOTIFY and QUERY-RESOLVE operation pairs
must be enabled. We anticipate that the FETCH operation will be a must be enabled. We anticipate that the FETCH operation will be a
trivial usage of HTTP, although other transport options may be trivial usage of HTTP, although other transport options may be
beneficial to consider too. beneficial to consider too.
5.3.3 IMG Transfer Envelope 5.2.3 IMG Transfer Envelope
Section 3.2.6 of this document discussed the need for binding between Section 3.2.6 of this document discussed the need for binding between
IMG Operations and Data Types. Such a binding can be realized by IMG Operations and Data Types. Such a binding can be realized by
defining a common minimal set of information needed needed to manage defining a common minimal set of information needed to manage IMG
IMG metadata transfers, and by including this information with any metadata transfers, and by including this information with any set of
set of IMG metadata delivered to IMG receiver(s). IMG metadata delivered to IMG receiver(s).
Four options for IMG transfer envelope delivery are feasible: Four options for IMG transfer envelope delivery are feasible:
1. Embedding in a transport protocol header. This can be done 1. Embedding in a transport protocol header. This can be done
with either header extensions of existing protocols, or with either header extensions of existing protocols, or
newly defined header fields of a new (or new version of a) newly defined header fields of a new (or new version of a)
transport protocol. However, multiple methods for the transport protocol. However, multiple methods for the
variety of transport protocols may hinder interoperability. variety of transport protocols may hinder interoperability.
2. A separate envelope object (a form of metadata itself) 2. A separate envelope object (a form of metadata itself)
delivered in-band with the metadata. This would complicate delivered in-band with the metadata. This would complicate
delivery as the envelope and `service' metadata objects delivery as the envelope and `service' metadata objects
would have to be bound, e.g. by pairing some kind of would have to be bound, e.g. by pairing some kind of
transport object numbers (analogous to port number pairs transport object numbers (analogous to port number pairs
sometimes used for RTP and RTSP). sometimes used for RTP and RTCP [9]).
3. A metadata wrapper which points to and/or embeds the 3. A metadata wrapper which points to and/or embeds the
service metadata into its `super-syntax'. For example, XML service metadata into its `super-syntax'. For example, XML
enables referencing (pointing to) other resources as well enables referencing (pointing to) other resources as well
as embedding generic text objects. as embedding generic text objects.
4. Embedding in the metadata itself. However, this requires 4. Embedding in the metadata itself. However, this requires
new field in many metadata syntaxes and would not be new field in many metadata syntaxes and would not be
feasible if a useful syntax were not capable of feasible if a useful syntax were not capable of
extensibility in this way. It also introduces a larger extensibility in this way. It also introduces a larger
skipping to change at page 18, line 30 skipping to change at page 18, line 28
experience. Such a specification is essential for IMG delivery and so experience. Such a specification is essential for IMG delivery and so
should be an official IETF work item. should be an official IETF work item.
When there are superset/subset relations between IMG descriptions, it When there are superset/subset relations between IMG descriptions, it
is assumed that the IMG descriptions of the subset inherit the is assumed that the IMG descriptions of the subset inherit the
parameters of the superset. Thus, an IMG transfer envelope carrying parameters of the superset. Thus, an IMG transfer envelope carrying
the IMG descriptions of a superset may implicitly define parameters the IMG descriptions of a superset may implicitly define parameters
of IMG descriptors belonging to its subset. The relations between IMG of IMG descriptors belonging to its subset. The relations between IMG
descriptions may span from one IMG transfer envelope to another. descriptions may span from one IMG transfer envelope to another.
5.3.4 Baseline (Meta)Data Model Specification 5.2.4 Baseline (Meta)Data Model Specification
A minimal IMG data model may be useful to any implementer/deployment A minimal IMG data model may be useful to any implementer/deployment
of IMGs. The purpose would be to ensure that multiple metadata of IMGs. The purpose would be to ensure that multiple metadata
syntaxes (SDP, MPEG-7, etc) can be related within the same body of syntaxes (SDP, MPEG-7, etc) can be related within the same body of
IMG knowledge, regardless of any specific metadata and data models IMG knowledge, regardless of any specific metadata and data models
provided by the metadata syntaxes. provided by the metadata syntaxes.
Further work may be needed to meet application-specific requirements Further work may be needed to meet application-specific requirements
at defining metadata and data models for the successful deployment of at defining metadata and data models for the successful deployment of
IMGs in various environments. Existing (and future) work on these IMGs in various environments. Existing (and future) work on these
would need to be mapped to the IMG data types and use of the IMG would need to be mapped to the IMG data types and use of the IMG
transfer envelope concept as described above. transfer envelope concept as described above.
This document is a framework for the delivery of IMG Metadata and This document is a framework for the delivery of IMG Metadata and
thus further discussion on the definition data models for IMGs is thus further discussion on the definition data models for IMGs is
beyond its scope. beyond its scope.
5.4 IMG Needs Fitting the IETF's Scope 5.3 IMG Needs Fitting the IETF's Scope
A Multicast Transport Protocol is essential to IMG delivery for A Multicast Transport Protocol is essential to IMG delivery for
unidirectional and multicast deployments and no alternative exists unidirectional and multicast deployments and no alternative exists
which fulfils the IMG requirements. We recommend that the which fulfils the IMG requirements. We recommend that the
specification of this be taken on as an official work item in the specification of this be taken on as an official work item in the
IETF. IETF.
Specification of the usage of unicast transport protocols is Specification of the usage of unicast transport protocols is
essential for IMG delivery and control involving unicast essential for IMG delivery and control involving unicast
communications, and will relate to existing IETF standard transport communications, and will relate to existing IETF standard transport
skipping to change at page 21, line 8 skipping to change at page 21, line 7
protocols. protocols.
Security Improvement Opportunity: The security properties of one Security Improvement Opportunity: The security properties of one
channel and protocol can be improved through the use of another channel and protocol can be improved through the use of another
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 Normative References 7 IANA Considerations
[1] Y. Nomura, "Protocol requirements for Internet media guides," There are no IANA considerations within this document.
Internet Draft draft-ietf-mmusic-img-req-02, Internet Engineering
Task Force, Dec. 2003. Work in progress.
[2] S. Bradner, "Key words for use in RFCs to indicate requirement 8 Normative References
levels," RFC 2119, Internet Engineering Task Force, Mar. 1997.
[3] M. Day, B. Cain, G. Tomlinson, and P. Rzewski, "A model for [1] Y. Nomura, R. Walsh, J-P. Luoma, J. Ott, and H. Schulzrinne,
content internetworking (CDI)," RFC 3466, Internet Engineering Task "Protocol requirements for Internet media guides," Internet Draft
Force, Feb. 2003. draft-ietf-mmusic-img-req-03, Internet Engineering Task Force, Feb.
2004. Work in progress.
[4] M. Handley and V. Jacobson, "SDP: session description protocol," [2] S. Bradner, "Key words for use in RFCs to indicate requirement
RFC 2327, Internet Engineering Task Force, Apr. 1998. levels," RFC 2119, Internet Engineering Task Force, Mar. 1997.
[5] D. Kutscher, J. Ott, and C. Bormann, "Session description and 9 Informative References
capability negotiation," Internet Draft draft-ietf-mmusic-sdpng-07,
Internet Engineering Task Force, Oct. 2003. Work in progress.
[6] ISO (International Organization for Standardization), "Overview [3] TV-Anytime Forum, "Broadcast and On-line Services: Search,
of the MPEG-7 standard," ISO Standard ISO/IEC JTC1/SC29/WG11 N4509, select, and rightful use of content on personal storage systems
International Organization for Standardization, Geneva, Switzerland, ("TV-Anytime Phase 1"); Part 2: System description," ETSI-TS 102
Dec. 2001. 822-2: System Description, V1.1.1, October 2003.
[7] T.-A. Forum, "Metadata specification S-3," TV-Anytime Forum [4] A. B. Roach, "Session initiation protocol (sip)-specific event
Specification SP003v1.2 Part A, TV, TV-Anytime Forum, June 2002. notification," RFC 3265, Internet Engineering Task Force, June 2002.
[8] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, and T. Berners- [5] M. Luby, J. Gemmell, L. Vicisano, L. Rizzo, and J. Crowcroft,
Lee, "Hypertext transfer protocol -- HTTP/1.1," RFC 2068, Internet "Asynchronous layered coding (ALC) protocol instantiation," RFC 3450,
Engineering Task Force, Jan. 1997. Internet Engineering Task Force, Dec. 2002.
[9] M. Handley, C. E. Perkins, and E. Whelan, "Session announcement [6] T. Paila, M. Luby, R. Lehtonen, V. Roca, and R. Walsh, "FLUTE -
protocol," RFC 2974, Internet Engineering Task Force, Oct. 2000. file delivery over unidirectional transport," Internet Draft draft-
ietf-rmt-flute-07, Internet Engineering Task Force, Dec. 2003.
Work in progress.
[10] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J. [7] 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.
[11] A. B. Roach, "Session initiation protocol (sip)-specific event [8] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, and T. Berners-
notification," RFC 3265, Internet Engineering Task Force, June 2002. Lee, "Hypertext transfer protocol -- HTTP/1.1," RFC 2068, Internet
Engineering Task Force, Jan. 1997.
[13] M. Luby, J. Gemmell, L. Vicisano, L. Rizzo, and J. Crowcroft,
"Asynchronous layered coding (ALC) protocol instantiation," RFC 3450,
Internet Engineering Task Force, Dec. 2002.
8 Informative References
[12] J. Rosenberg, "A presence event package for the session
initiation protocol (SIP)," internet draft, Internet Engineering Task
Force, Jan. 2003. Work in progress.
[14] T. Paila, "FLUTE - file delivery over unidirectional transport," [9] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: a
Internet Draft draft-ietf-rmt-flute-07, Internet Engineering Task transport protocol for real-time applications," RFC 3550, Internet
Force, Dec. 2003. Work in progress. 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
and Petri Koskelainen on for their ideas and input to this document. and Petri Koskelainen on for their 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 Corporation Nokia Corporation
Nokia Research Center Nokia Research Center
P.O. Box 100, FIN-33721 Tampere P.O. Box 100, FIN-33721 Tampere
Finland Finland
Email: rod,walsh@nokia.com Email: rod.walsh@nokia.com
Juha-Pekka Luoma Juha-Pekka Luoma
Nokia Corporation Nokia Corporation
Nokia Research Center Nokia Research Center
P.O. Box 100, FIN-33721 Tampere P.O. Box 100, FIN-33721 Tampere
Finland Finland
Email: juha-pekka.luoma@nokia.com Email: juha-pekka.luoma@nokia.com
Hitoshi Asaeda Hitoshi Asaeda
INRIA INRIA
skipping to change at page 23, line 19 skipping to change at page 23, line 8
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
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 Full Copyright Statement
Copyright (c) The Internet Society (2003). All Rights Reserved. Copyright (c) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 

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