Network Working Group Y. Nomura
Request for Comments: 4435 Fujitsu Labs.
Category: Informational R. Walsh
J-P. Luoma
Nokia
H. Asaeda
Keio University
H. Schulzrinne
Columbia University
April 2006
Network Working Group Y. Nomura
Request for Comments: 4435 Fujitsu Labs.
Category: Informational R. Walsh
J-P. Luoma
Nokia
H. Asaeda
Keio University
H. Schulzrinne
Columbia University
April 2006
A Framework for the Usage of Internet Media Guides (IMGs)
互联网媒体指南（IMG）使用框架
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document defines a framework for the delivery of Internet Media Guides (IMGs). An IMG is a structured collection of multimedia session descriptions expressed using the Session Description Protocol (SDP), SDPng, or some similar session description format. This document describes a generalized model for IMG delivery mechanisms, the use of existing protocols, and the need for additional work to create an IMG delivery infrastructure.
本文件定义了互联网媒体指南（IMG）的交付框架。IMG是使用会话描述协议（SDP）、SDPng或某些类似会话描述格式表示的多媒体会话描述的结构化集合。本文档描述了IMG交付机制的通用模型、现有协议的使用以及创建IMG交付基础设施所需的额外工作。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................3
2.1. New Terms ..................................................4
3. IMG Common Framework Model ......................................5
3.1. IMG Data Types .............................................5
3.1.1. Complete IMG Description ............................5
3.1.2. Delta IMG Description ...............................6
3.1.3. IMG Pointer .........................................6
3.2. IMG Entities ...............................................6
3.3. Operation Set for IMG Delivery .............................7
3.3.1. IMG ANNOUNCE ........................................7
3.3.2. IMG QUERY ...........................................8
3.3.3. IMG RESOLVE .........................................8
3.3.4. IMG SUBSCRIBE .......................................8
3.3.5. IMG NOTIFY ..........................................9
3.3.6. Binding between IMG Operations and Data Types .......9
3.4. Overview of Protocol Operations ...........................10
4. Deployment Scenarios for IMG Entities ..........................10
4.1. Intermediary Cases ........................................10
4.2. One-to-Many Unidirectional Multicast ......................12
4.3. One-to-One Bidirectional Unicast ..........................12
4.4. Combined Operations with Common Metadata ..................13
5. Applicability of Existing Protocols to the Proposed
Framework Model ................................................14
5.1. Existing Standard Fitting the IMG Framework Model .........14
5.2. IMG Mechanism Needs Which Are Not Met by Existing
Standards .................................................15
5.2.1. A Multicast Transport Protocol .....................16
5.2.2. Usage of Unicast Transport Protocols ...............16
5.2.3. IMG Envelope .......................................17
5.2.4. Metadata Data Model ................................18
6. Security Considerations ........................................18
7. Normative References ...........................................19
8. Informative References .........................................19
9. Acknowledgements ...............................................20
1. Introduction ....................................................3
2. Terminology .....................................................3
2.1. New Terms ..................................................4
3. IMG Common Framework Model ......................................5
3.1. IMG Data Types .............................................5
3.1.1. Complete IMG Description ............................5
3.1.2. Delta IMG Description ...............................6
3.1.3. IMG Pointer .........................................6
3.2. IMG Entities ...............................................6
3.3. Operation Set for IMG Delivery .............................7
3.3.1. IMG ANNOUNCE ........................................7
3.3.2. IMG QUERY ...........................................8
3.3.3. IMG RESOLVE .........................................8
3.3.4. IMG SUBSCRIBE .......................................8
3.3.5. IMG NOTIFY ..........................................9
3.3.6. Binding between IMG Operations and Data Types .......9
3.4. Overview of Protocol Operations ...........................10
4. Deployment Scenarios for IMG Entities ..........................10
4.1. Intermediary Cases ........................................10
4.2. One-to-Many Unidirectional Multicast ......................12
4.3. One-to-One Bidirectional Unicast ..........................12
4.4. Combined Operations with Common Metadata ..................13
5. Applicability of Existing Protocols to the Proposed
Framework Model ................................................14
5.1. Existing Standard Fitting the IMG Framework Model .........14
5.2. IMG Mechanism Needs Which Are Not Met by Existing
Standards .................................................15
5.2.1. A Multicast Transport Protocol .....................16
5.2.2. Usage of Unicast Transport Protocols ...............16
5.2.3. IMG Envelope .......................................17
5.2.4. Metadata Data Model ................................18
6. Security Considerations ........................................18
7. Normative References ...........................................19
8. Informative References .........................................19
9. Acknowledgements ...............................................20
Internet Media Guides (IMGs) provide and deliver structured collections of multimedia descriptions expressed using SDP [2], SDPng [3], or other description formats. They are used to describe sets of multimedia services (e.g., television program schedules, content delivery schedules) and refer to other networked resources including web pages. IMGs provide an envelope for metadata formats and session descriptions defined elsewhere with the aim of facilitating structuring, versioning, referencing, distributing, and maintaining (caching, updating) such information.
互联网媒体指南（IMG）提供并交付使用SDP[2]、SDPng[3]或其他描述格式表示的多媒体描述的结构化集合。它们用于描述多媒体服务集（例如，电视节目时间表、内容交付时间表），并引用包括网页在内的其他网络资源。IMG为其他地方定义的元数据格式和会话描述提供了一个信封，目的是促进此类信息的结构化、版本控制、引用、分发和维护（缓存、更新）。
IMG metadata may be delivered to a potentially large audience, which uses it to join a subset of the sessions described and which may need to be notified of changes to the IMG metadata. Hence, a framework for distributing IMG metadata in various different ways is needed to accommodate the needs of different audiences: For traditional broadcast-style scenarios, multicast-based (push) distribution of IMG metadata needs to be supported. Where no multicast is available, unicast-based push is required.
IMG元数据可以交付给潜在的大量受众，他们使用IMG元数据加入所描述的会话的子集，并且可能需要通知IMG元数据的更改。因此，需要一个以各种不同方式分发IMG元数据的框架来满足不同受众的需求：对于传统的广播风格场景，需要支持基于多播（push）的IMG元数据分发。如果没有多播可用，则需要基于单播的推送。
This document defines a common framework model for IMG delivery mechanisms and their deployment in network entities. There are three fundamental components in the IMG framework model: data types, operation sets, and entities. These components specify a set of framework guidelines for efficient delivery and description of IMG metadata. The data types give generalized means to deliver and manage the consistency of application-specific IMG metadata. IMG operations cover broadcast, multicast distribution, event notification upon change, unicast-based push, and interactive retrievals similar to web pages.
本文档为IMG交付机制及其在网络实体中的部署定义了通用框架模型。IMG框架模型中有三个基本组件：数据类型、操作集和实体。这些组件为IMG元数据的高效交付和描述指定了一套框架指南。数据类型为交付和管理特定于应用程序的IMG元数据的一致性提供了通用方法。IMG操作包括广播、多播分发、更改时的事件通知、基于单播的推送以及类似于网页的交互式检索。
Since we envision that any Internet host can be a sender and receiver of IMG metadata, a host involved in IMG operations performs one or more of the roles defined as the entities in the IMG framework model. The requirements for IMG delivery mechanisms and descriptions can be found in the IMG requirements document [4].
由于我们设想任何Internet主机都可以是IMG元数据的发送者和接收者，因此参与IMG操作的主机将执行IMG框架模型中定义为实体的一个或多个角色。IMG交付机制和说明的要求可在IMG要求文件[4]中找到。
This document outlines the use of existing protocols to create an IMG delivery infrastructure. It aims to organize existing protocols into a common model and show their capabilities and limitations from the viewpoint of IMG delivery functions.
本文档概述了如何使用现有协议创建IMG交付基础设施。它旨在将现有协议组织成一个通用模型，并从IMG交付功能的角度展示其功能和局限性。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[1]中所述进行解释。
Internet Media Guide (IMG): IMG is a generic term to describe the formation, delivery, and use of IMG metadata. The definition of the IMG is intentionally left imprecise [4].
互联网媒体指南（IMG）：IMG是一个通用术语，用于描述IMG元数据的形成、交付和使用。IMG的定义故意不精确[4]。
IMG Element: The smallest atomic element of metadata that can be transmitted separately by IMG operations and referenced individually from other IMG elements [4].
IMG元素：元数据中最小的原子元素，可通过IMG操作单独传输，并可从其他IMG元素中单独引用[4]。
IMG Metadata: A set of metadata consisting of one or more IMG elements. IMG metadata describes the features of multimedia content used to enable selection of and access to media sessions containing content. For example, metadata may consist of a media object's URI, title, airtime, bandwidth needed, file size, text summary, genre, and access restrictions [4].
IMG元数据：由一个或多个IMG元素组成的一组元数据。IMG元数据描述了用于选择和访问包含内容的媒体会话的多媒体内容的功能。例如，元数据可能包括媒体对象的URI、标题、播放时间、所需带宽、文件大小、文本摘要、类型和访问限制[4]。
IMG Description: A collection of IMG metadata with a data type indicating a self-contained set or a subset of IMG metadata, or a reference to IMG metadata.
IMG描述：IMG元数据的集合，其数据类型指示IMG元数据的自包含集或子集，或IMG元数据的引用。
IMG Delivery: The process of exchanging IMG metadata both in terms of large-scale and atomic data transfers [4].
IMG交付：在大规模和原子数据传输方面交换IMG元数据的过程[4]。
IMG Sender: An IMG sender is a logical entity that sends IMG metadata to one or more IMG receivers [4].
IMG发送方：IMG发送方是一个逻辑实体，它向一个或多个IMG接收方发送IMG元数据[4]。
IMG Receiver: An IMG receiver is a logical entity that receives IMG metadata from an IMG sender [4].
IMG接收方：IMG接收方是从IMG发送方接收IMG元数据的逻辑实体[4]。
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 [4].
IMG收发器：IMG收发器结合了IMG接收器和发送器。它可以修改接收到的IMG元数据或合并从几个不同的IMG发送方接收到的IMG元数据[4]。
IMG Operation: An atomic operation of an IMG transport protocol, used between IMG sender(s) and IMG receiver(s) for the delivery of IMG metadata and for the control of IMG sender(s)/receiver(s) [4].
IMG操作：IMG传输协议的原子操作，在IMG发送方和IMG接收方之间用于传递IMG元数据和控制IMG发送方/接收方[4]。
IMG Transport Protocol: A protocol that transports IMG metadata from an IMG sender to IMG receiver(s) [4].
IMG传输协议：将IMG元数据从IMG发送方传输到IMG接收方的协议[4]。
IMG Transport Session: An association between an IMG sender and one or more IMG receivers within the scope of an IMG transport protocol. An IMG transport session involves a time-bound series of IMG transport protocol interactions that provide delivery of IMG metadata from the IMG sender to the IMG receiver(s) [4].
IMG传输会话：在IMG传输协议范围内，IMG发送方和一个或多个IMG接收方之间的关联。IMG传输会话涉及一系列有时间限制的IMG传输协议交互，这些交互将IMG元数据从IMG发送方传递到IMG接收方[4]。
IMG Transfer: A transfer of IMG metadata from an IMG sender to IMG receiver(s).
IMG传输：将IMG元数据从IMG发送方传输到IMG接收方。
Two common elements are found in all existing IMG candidate cases: the need to describe the services and the need to deliver the descriptions. In some cases, the descriptions provide multicast addresses and thus are part of the transport configuration. In other cases, descriptions are specific to the media application and may be meant for either human or machine consumption. Thus, the technologies can be roughly divided into three areas:
在所有现有的IMG候选案例中都可以找到两个共同的元素：描述服务的需要和交付描述的需要。在某些情况下，描述提供多播地址，因此是传输配置的一部分。在其他情况下，描述是特定于媒体应用程序的，可能是用于人或机器消费。因此，这些技术可以大致分为三个领域：
o Application-specific Metadata: data describing the content of services and media which are both specific to certain applications and generally human readable.
o 特定于应用程序的元数据：描述服务和媒体内容的数据，这些内容既特定于某些应用程序，又通常是人类可读的。
o Delivery Descriptions: the descriptions (metadata) that are essential to enable (e.g., multicast) delivery. These include framing (headers) for application-specific metadata, the metadata element identification and structure, and fundamental session data.
o 交付描述：对启用（例如，多播）交付至关重要的描述（元数据）。这些包括特定于应用程序的元数据的框架（标头）、元数据元素标识和结构以及基本会话数据。
o Delivery Protocols: the methods and protocols to exchange descriptions between the senders and the receivers. An IMG transport protocol consists of two functions: carrying IMG metadata from an IMG sender to an IMG receiver and controlling an IMG transport protocol. These functions are not always exclusive; therefore, some messages may combine control messages and metadata carriage functions to reduce the amount of the messaging.
o 传递协议：发送方和接收方之间交换描述的方法和协议。IMG传输协议包括两个功能：将IMG元数据从IMG发送方传送到IMG接收方，以及控制IMG传输协议。这些功能并不总是排他性的；所以，一些消息可以结合控制消息和元数据承载功能来减少消息量。
A data model is needed to precisely define the terminology and relationships between sets, supersets, and subsets of metadata. A precise data model is essential for the implementation of IMGs, although it is not within the scope of this framework and requires a separate specification. However, there are three IMG data types in general: Complete IMG Descriptions, Delta IMG Descriptions, and IMG Pointers.
需要一个数据模型来精确定义元数据集、超集和子集之间的术语和关系。精确的数据模型对于IMGs的实施至关重要，尽管它不在本框架的范围内，需要单独的规范。但是，通常有三种IMG数据类型：完整IMG描述、增量IMG描述和IMG指针。
A Complete IMG Description provides a self-contained set of metadata for one media object or service, i.e., it does not need additional information from any other IMG element. This is not to be confused with "complete IMG metadata", which, although vaguely defined here,
完整的IMG描述为一个媒体对象或服务提供了一组自包含的元数据，即它不需要来自任何其他IMG元素的附加信息。不要将其与“完整的IMG元数据”混淆，尽管此处定义模糊，
represents the complete IMG metadata database of an IMG sender (or related group of IMG senders -- potentially the complete Internet IMG knowledge). An IMG sender will generally deliver only subsets of metadata from its complete database in a particular IMG transport session.
表示IMG发送者的完整IMG元数据数据库（或IMG发送者的相关组——可能是完整的互联网IMG知识）。IMG发送方通常只在特定IMG传输会话中从其完整数据库中交付元数据子集。
A Delta IMG Description provides only part of a Complete IMG Description, defining the difference from a previous version of the Complete IMG Description. Delta IMG Descriptions may be used to reduce network resource usage, for instance, when data consistency is essential and small and frequent changes occur to IMG elements. Thus, this description does not represent a complete set of metadata until it is combined with other metadata that may already exist or arrive in the future.
增量IMG描述仅提供完整IMG描述的一部分，定义了与完整IMG描述之前版本的差异。增量IMG描述可用于减少网络资源使用，例如，当数据一致性至关重要且IMG元素发生小而频繁的更改时。因此，在与可能已经存在或将来到达的其他元数据组合之前，此描述并不表示完整的元数据集。
An IMG Pointer identifies or locates metadata. This may be used to separately obtain metadata (Complete or Delta IMG Descriptions) or perform another IMG management function such as data expiry (and erasure). The IMG Pointer may be used to reference IMG metadata elements within the IMG transport session and across IMG transport sessions. This pointer type does not include IMG metadata per se (although it may also appear as a data field in Complete or Delta IMG Descriptions).
IMG指针标识或定位元数据。这可用于单独获取元数据（完整或增量IMG描述）或执行其他IMG管理功能，如数据过期（和擦除）。IMG指针可用于在IMG传输会话内和跨IMG传输会话引用IMG元数据元素。此指针类型本身不包括IMG元数据（尽管它也可能在完整或增量IMG描述中显示为数据字段）。
There are several fundamental IMG entities that indicate the capability to perform certain roles. An Internet host involved in IMG operations may adopt one or more of these roles, which are defined in more detail in Section 3.3.
有几个基本的IMG实体表示执行某些角色的能力。参与IMG运营的互联网主机可采用其中一个或多个角色，详见第3.3节。
IMG Announcer: sends IMG ANNOUNCE
IMG播音员：发送IMG播音
IMG Listener: receives IMG ANNOUNCE
IMG侦听器：接收IMG公告
IMG Querier: sends IMG QUERY and receives IMG RESOLVE
IMG查询器：发送IMG查询并接收IMG解析
IMG Resolver: receives IMG QUERY then sends IMG RESOLVE
IMG解析程序：接收IMG查询，然后发送IMG解析
IMG Subscriber: sends IMG SUBSCRIBE then receives IMG NOTIFY
IMG订阅方：发送IMG订阅，然后接收IMG通知
IMG Notifier: receives IMG SUBSCRIBE then sends IMG NOTIFY
IMG通知程序：接收IMG订阅，然后发送IMG通知
Figure 1 shows the relationship between IMG entities and the IMG sender and receiver.
图1显示了IMG实体与IMG发送方和接收方之间的关系。
+--------------------------------------------------------+
| IMG Sender |
+------------------+------------------+------------------+
| IMG Announcer | IMG Notifier | IMG Resolver |
+------------------+------------------+------------------+
| ^ ^
message | | |
direction v v v
+------------------+------------------+------------------+
| IMG Listener | IMG Subscriber | IMG Querier |
+------------------+------------------+------------------+
| IMG Receiver |
+------------------+------------------+------------------+
+--------------------------------------------------------+
| IMG Sender |
+------------------+------------------+------------------+
| IMG Announcer | IMG Notifier | IMG Resolver |
+------------------+------------------+------------------+
| ^ ^
message | | |
direction v v v
+------------------+------------------+------------------+
| IMG Listener | IMG Subscriber | IMG Querier |
+------------------+------------------+------------------+
| IMG Receiver |
+------------------+------------------+------------------+
Figure 1: Relationship between IMG Entities, Senders, and Receivers
图1:IMG实体、发送方和接收方之间的关系
A finite set of operations both meets the IMG requirements [4] and fits the roles of existing protocols. These are crystallized in the next few sections.
有限的操作集既满足IMG要求[4]，又适合现有协议的角色。这些将在接下来的几节中具体化。
When an IMG receiver participates in unidirectional communications (e.g., over satellite, terrestrial radio, and wired multicast networks), an IMG receiver may not need to send any IMG message to an IMG sender prior to IMG metadata delivery. In this case, an IMG sender can initiate unsolicited distribution for IMG metadata and an IMG sender is the only entity that can maintain the distribution (this includes scenarios with multiple and cooperative IMG senders). This operation is useful when there are large numbers of IMG receivers or the IMG receivers do not have a guaranteed uplink connection to the IMG sender. The IMG sender may also include authentication data in the ANNOUNCE operation so that IMG receivers may check the authenticity of the metadata. This operation can carry any of the IMG data types.
当IMG接收机参与单向通信（例如，通过卫星、地面无线电和有线多播网络）时，IMG接收机可能不需要在IMG元数据交付之前向IMG发送方发送任何IMG消息。在这种情况下，IMG发送者可以主动发起IMG元数据的分发，并且IMG发送者是唯一可以维护分发的实体（这包括具有多个IMG发送者和协作IMG发送者的场景）。当存在大量IMG接收器或IMG接收器没有到IMG发送器的保证上行链路连接时，此操作非常有用。IMG发送方还可以在通告操作中包括认证数据，以便IMG接收方可以检查元数据的真实性。此操作可以携带任何IMG数据类型。
There is no restriction to prevent IMG ANNOUNCE from being used in an asynchronous solicited manner, where a separate operation (possibly out of band) enables IMG receivers to subscribe/register to the IMG ANNOUNCE operation.
不存在阻止以异步请求方式使用IMG annound的限制，其中单独的操作（可能带外）使IMG接收机能够订阅/注册IMG annound操作。
If an IMG receiver needs to obtain IMG metadata, an IMG receiver can use an IMG QUERY operation and initiate a receiver-driven IMG transport session. The IMG receiver expects a synchronous response to the subsequent request from the IMG sender. This operation can be used where a bidirectional transport network is available between the IMG sender and receiver. Some IMG receivers may want to obtain IMG metadata when network connectivity is available or just to avoid caching unsolicited IMG metadata. The IMG receiver must indicate the extent and data type of metadata wanted in some message in the operation. The extent indicates the number and grouping of metadata descriptions. In some cases, it may be feasible to request an IMG sender's complete metadata collection.
如果IMG接收器需要获取IMG元数据，IMG接收器可以使用IMG查询操作并启动接收器驱动的IMG传输会话。IMG接收方期望对来自IMG发送方的后续请求做出同步响应。当IMG发送方和接收方之间存在双向传输网络时，可使用此操作。一些IMG接收器可能希望在网络连接可用时获取IMG元数据，或者只是为了避免缓存未经请求的IMG元数据。IMG接收器必须指示操作中某些消息所需元数据的范围和数据类型。范围指示元数据描述的数量和分组。在某些情况下，请求IMG发送者的完整元数据收集可能是可行的。
An IMG sender synchronously responds, and sends IMG metadata, to an IMG QUERY that has been sent by an IMG receiver. This operation can be used where a bidirectional transport network is available between the IMG sender and receiver. If the IMG QUERY specifies a subset of IMG metadata (extent and data type) that is available to the IMG sender, the IMG sender can resolve the query; otherwise, it should indicate that it is not able to resolve the query. The IMG sender may authenticate the IMG receiver during the QUERY operation to determine if the IMG receiver is authorized to receive that metadata. The sender may also include authentication data in the RESOLVE operation so that IMG receivers may check the authenticity of the metadata. This operation may carry any of the IMG data types.
IMG发送方同步响应IMG接收方发送的IMG查询，并发送IMG元数据。当IMG发送方和接收方之间存在双向传输网络时，可使用此操作。如果IMG查询指定IMG发送方可用的IMG元数据子集（范围和数据类型），IMG发送方可以解析该查询；否则，它应该指示它无法解析查询。IMG发送方可以在查询操作期间认证IMG接收方，以确定IMG接收方是否被授权接收该元数据。发送方还可以在解析操作中包括认证数据，以便IMG接收方可以检查元数据的真实性。此操作可携带任何IMG数据类型。
If an IMG receiver wants to be notified when the IMG metadata it holds becomes stale, the IMG receiver can use the IMG SUBSCRIBE operation in advance in order to solicit IMG NOTIFY messages from an IMG sender.
如果IMG接收方希望在其持有的IMG元数据过时时得到通知，则IMG接收方可以提前使用IMG SUBSCRIBE操作，以便从IMG发送方请求IMG NOTIFY消息。
This operation may provide the IMG sender with specific details of which metadata or notification services it is interested in the case where the IMG sender offers more than the simplest "all data" service. This 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 unsubscription may be provided implicitly by the expiry (timeout) of a subscription before it is renewed.
在IMG发送方提供的不仅仅是最简单的“所有数据”服务的情况下，此操作可以向IMG发送方提供其感兴趣的元数据或通知服务的具体细节。此操作隐式提供取消订阅功能，以通知IMG发送方IMG接收方希望停止接收某些（或全部）通知。应该注意的是，退订可以通过续订前的订阅到期（超时）隐式提供。
Since the IMG receiver does not know when metadata will be updated and the notify message will arrive, this operation does not synchronize with the notify messages. The IMG receiver may wait for notify messages for a long time. The IMG sender may authenticate the IMG receiver to check whether an IMG SUBSCRIBE operation is from an authorized IMG receiver.
由于IMG接收方不知道元数据何时更新以及notify消息何时到达，因此此操作不与notify消息同步。IMG接收器可能会等待通知消息很长时间。IMG发送方可以认证IMG接收方，以检查IMG订阅操作是否来自经授权的IMG接收方。
An IMG NOTIFY is used asynchronously in response to an earlier IMG SUBSCRIBE. An IMG NOTIFY operation indicates that updated IMG metadata is available or part of the existing IMG metadata is stale. An IMG NOTIFY may be delivered more than once during the time an IMG SUBSCRIBE is active. This operation may carry any of the IMG data types. The IMG sender may also include authentication data in the IMG NOTIFY operation so that IMG receivers may check the authenticity of the messages.
IMG NOTIFY异步用于响应早期IMG订阅。IMG NOTIFY操作表示更新的IMG元数据可用或现有IMG元数据的一部分过时。在IMG订阅处于活动状态期间，IMG通知可能会发送多次。此操作可携带任何IMG数据类型。IMG发送方还可以在IMG通知操作中包括认证数据，以便IMG接收方可以检查消息的真实性。
There is a need to provide a binding between the various IMG operations and IMG data types to allow management of each discrete set of IMG metadata transferred using an IMG operation. This binding must be independent of any particular metadata syntax used to 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 metadata delivered within an IMG transfer, regardless of the metadata syntax used. The uniqueness may only be needed within the domains the metadata is used, but this must enable globally unique identification to support Internet usage. Care should be taken that scope- and domain-specific identifiers do not leak outside the scope; using globally unique identifiers such as URLs avoids these problems.
需要在各种IMG操作和IMG数据类型之间提供绑定，以允许管理使用IMG操作传输的每个离散IMG元数据集。此绑定必须独立于用于表示一组IMG元数据的任何特定元数据语法，并且与任何IMG传输协议兼容。绑定必须唯一标识IMG传输中传递的IMG元数据集，而不管使用的元数据语法如何。唯一性可能仅在使用元数据的域内需要，但这必须启用全局唯一标识以支持Internet使用。应注意范围和域特定标识符不会泄漏到范围之外；使用全局唯一标识符（如URL）可以避免这些问题。
The binding must provide versioning to the transferred IMG metadata so that changes can be easily handled and stale data identified, and give temporal validity of the transferred IMG metadata. It must invalidate the IMG metadata by indicating an expiry time, and may optionally provide a time (presumably in the future) from when the IMG metadata becomes valid. The temporal validity of a metadata object may need to be updated later. Furthermore, the binding must be independent of any specific metadata syntax used for the IMG metadata, in the sense that no useful syntax should be excluded.
绑定必须为传输的IMG元数据提供版本控制，以便可以轻松处理更改和识别过时数据，并提供传输的IMG元数据的时间有效性。它必须通过指示到期时间使IMG元数据无效，并且可以选择提供IMG元数据开始生效的时间（可能在将来）。元数据对象的时间有效性可能需要稍后更新。此外，绑定必须独立于IMG元数据使用的任何特定元数据语法，也就是说，不应排除任何有用的语法。
Figure 2 gives an overview of the relationship between transport cases, IMG operations, and IMG data types. It is not a protocol stack. Generalized multicast point-to-multipoint (P-to-M) and unicast point-to-point (P-to-P) transports are shown.
图2概述了传输案例、IMG操作和IMG数据类型之间的关系。它不是一个协议栈。显示了广义多播点对多点（P-to-M）和单播点对点（P-to-P）传输。
+--------------------------------------------------+
IMG | |
Data Types | Complete Desc., Delta Desc., Pointer |
| |
+-------------------+----------------+-------------+
IMG | IMG ANNOUNCE | IMG SUBSCRIBE | IMG QUERY |
Operations | | IMG NOTIFY | IMG RESOLVE |
+--------------+----+----------------+-------------+
IMG | | |
Transport | P-to-M | P-to-P |
| | |
+--------------+-----------------------------------+
+--------------------------------------------------+
IMG | |
Data Types | Complete Desc., Delta Desc., Pointer |
| |
+-------------------+----------------+-------------+
IMG | IMG ANNOUNCE | IMG SUBSCRIBE | IMG QUERY |
Operations | | IMG NOTIFY | IMG RESOLVE |
+--------------+----+----------------+-------------+
IMG | | |
Transport | P-to-M | P-to-P |
| | |
+--------------+-----------------------------------+
Figure 2: IMG Transport, IMG Operations, and IMG Data Types
图2:IMG传输、IMG操作和IMG数据类型
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发送方到IMG接收方的简单数据流，如图3所示。
+-------------+ +---------------+
| IMG Sender | | IMG Receiver |
| |--------------->| |
+-------------+ +---------------+
+-------------+ +---------------+
| IMG Sender | | IMG Receiver |
| |--------------->| |
+-------------+ +---------------+
Figure 3: A Simple IMG Sender to IMG Receiver Relationship
图3：一个简单的IMG发送者到IMG接收者的关系
Some IMG metadata may be distributed to a large number of IMG receivers, for example, when public metadata is distributed to all IMG receivers of a certain group. This kind of IMG metadata may be distributed from one IMG sender to multiple IMG receivers (Figure 4) or may be relayed across a set of IMG transceivers that receive the IMG metadata, possibly filter or modify its content, and then forward it.
一些IMG元数据可以分发给大量IMG接收者，例如，当公共元数据分发给某个组的所有IMG接收者时。这种IMG元数据可以从一个IMG发送者分发到多个IMG接收者（图4），或者可以在接收IMG元数据的一组IMG收发器之间中继，可能过滤或修改其内容，然后转发它。
+----------+ +----------+
| IMG | | IMG |
| Sender |---- ---->| Receiver |
+----------+ \ / +----------+
\ /
. \ +-----------+ / .
. -->|IMG |----- .
. -->|Transceiver| \ .
/ +-----------+ \
+----------+ / \ +----------+
| IMG | / ---->| IMG |
| Sender |---- | Receiver |
+----------+ +----------+
+----------+ +----------+
| IMG | | IMG |
| Sender |---- ---->| Receiver |
+----------+ \ / +----------+
\ /
. \ +-----------+ / .
. -->|IMG |----- .
. -->|Transceiver| \ .
/ +-----------+ \
+----------+ / \ +----------+
| IMG | / ---->| IMG |
| Sender |---- | Receiver |
+----------+ +----------+
Figure 4: A Relay Network with an IMG Transceiver
图4：带有IMG收发器的中继网络
IMG senders and receivers are logical functions, and it is possible for some or all hosts in a system to perform both roles, as, for instance, in many-to-many communications or where a transceiver is used to combine or aggregate IMG metadata for some IMG receivers. An IMG receiver may be allowed to receive IMG metadata from any number of IMG senders.
IMG发送器和接收器是逻辑功能，并且系统中的一些或所有主机可以执行这两个角色，例如，在多对多通信中，或者在使用收发器组合或聚合一些IMG接收器的IMG元数据的情况下。可以允许IMG接收方从任意数量的IMG发送方接收IMG元数据。
IMG metadata is used to find, obtain, manage, and play media content. IMG metadata may be modified during IMG transfer. For example, a server may use IMGs to retrieve media content via unicast and then make it available at scheduled times via multicast, thus requiring a change of the corresponding metadata. IMG transceivers may add or delete information or aggregate IMG metadata from different IMG senders. For example, a rating service may add its own content ratings or recommendations to existing metadata. An implication of changing (or aggregating) IMG metadata from one or more IMG senders is that the original authenticity is lost. Thus, it may be beneficial to sign fragments so that the intermediary can replace a fragment without changing the authenticity of the remainder. For example, smaller fragments may be appropriate for more volatile parts, and larger ones may be appropriate for stable parts.
IMG元数据用于查找、获取、管理和播放媒体内容。IMG元数据可以在IMG传输期间修改。例如，服务器可以使用img通过单播检索媒体内容，然后通过多播在预定时间使其可用，从而需要更改相应的元数据。IMG收发器可以添加或删除来自不同IMG发送者的信息或聚合IMG元数据。例如，评级服务可以将自己的内容评级或建议添加到现有元数据中。更改（或聚合）来自一个或多个IMG发送者的IMG元数据意味着原始真实性丢失。因此，对片段进行签名可能是有益的，以便中介可以在不改变剩余片段真实性的情况下替换片段。例如，较小的片段可能适用于较易挥发的部分，较大的片段可能适用于稳定的部分。
The one-to-many unidirectional multicast case implies many IMG receivers and one or more IMG senders implementing IMG announcer and IMG listener operations as shown in Figure 5.
一对多单向多播情况意味着许多IMG接收器和一个或多个IMG发送器实现IMG播音器和IMG侦听器操作，如图5所示。
Unidirectional +----------+
---------------> | IMG |
downlink | Listener |
------------->| 1 |
/ +----------+
+-----------+ / .
| IMG |-------- .
| Announcer | \ .
+-----------+ \ +----------+
------------->| IMG |
| Listener |
| # |
+----------+
Unidirectional +----------+
---------------> | IMG |
downlink | Listener |
------------->| 1 |
/ +----------+
+-----------+ / .
| IMG |-------- .
| Announcer | \ .
+-----------+ \ +----------+
------------->| IMG |
| Listener |
| # |
+----------+
Figure 5: IMG Unidirectional Multicast Distribution Example
图5:IMG单向多播分发示例
Note, as defined in the IMG requirement REL-4 [4], an IMG transport protocol MUST support reliable message exchange. This includes the one-to-many unidirectional multicast case; however, the mechanism to provide this is beyond the scope of this document.
注意，如IMG要求REL-4[4]中所定义，IMG传输协议必须支持可靠的消息交换。这包括一对多单向多播情况；然而，提供这一点的机制超出了本文件的范围。
In the one-to-one bidirectional unicast case, both query/resolve (Figure 6) and subscribe/notify (Figure 7) message exchange operations are feasible.
在一对一双向单播情况下，查询/解析（图6）和订阅/通知（图7）消息交换操作都是可行的。
+----------+ +----------+
| IMG | | IMG |
| Resolver | | Querier |
+----------+ +----------+
| |
|<----------IMG QUERY -----------|
| |
|----------IMG RESOLVE---------->|
| |
+----------+ +----------+
| IMG | | IMG |
| Resolver | | Querier |
+----------+ +----------+
| |
|<----------IMG QUERY -----------|
| |
|----------IMG RESOLVE---------->|
| |
Figure 6: Query/Resolve Sequence Example
图6：查询/解析序列示例
+----------+ +------------+
| IMG | | IMG |
| Notifier | | Subscriber |
+----------+ +------------+
| |
|<---------IMG SUBSCRIBE---------|
: :
(time passes)
: :
|-----------IMG NOTIFY---------->|
: :
(time passes)
: :
|-----------IMG NOTIFY---------->|
| |
+----------+ +------------+
| IMG | | IMG |
| Notifier | | Subscriber |
+----------+ +------------+
| |
|<---------IMG SUBSCRIBE---------|
: :
(time passes)
: :
|-----------IMG NOTIFY---------->|
: :
(time passes)
: :
|-----------IMG NOTIFY---------->|
| |
Figure 7: Subscribe/Notify Sequence Example
图7：订阅/通知序列示例
As shown in Figure 8, a common data model for multiple protocol operations allows a diverse range of IMG senders and receivers to provide consistent and interoperable sets of IMG metadata.
如图8所示，多协议操作的通用数据模型允许不同范围的IMG发送方和接收方提供一致且可互操作的IMG元数据集。
IMG Metadata IMG Senders IMG Receivers
IMG元数据IMG发送方IMG接收方
+--------------+
+-----------+ ---->| IMG Listener |
| IMG | / +--------------+
/| Announcer |-----
+-------------+ / +-----------+ \ +--------------+
| IMG |-+ / ---->| IMG Listener |
| description | |-+ / | - - - - - - -|
| metadata 1 | | | / +-----------+ /--->| IMG Querier |
+-------------+ | | -----| IMG |<----/ +--------------+
+-------------+ | \ | Resolver |
+-------------+ \ +-----------+<----\ +--------------+
\ \--->| IMG Querier |
\ +-----------+ | - - - - - - -|
\| IMG |<--------->| IMG |
| Notifier | | Subscriber |
+-----------+ +--------------+
+--------------+
+-----------+ ---->| IMG Listener |
| IMG | / +--------------+
/| Announcer |-----
+-------------+ / +-----------+ \ +--------------+
| IMG |-+ / ---->| IMG Listener |
| description | |-+ / | - - - - - - -|
| metadata 1 | | | / +-----------+ /--->| IMG Querier |
+-------------+ | | -----| IMG |<----/ +--------------+
+-------------+ | \ | Resolver |
+-------------+ \ +-----------+<----\ +--------------+
\ \--->| IMG Querier |
\ +-----------+ | - - - - - - -|
\| IMG |<--------->| IMG |
| Notifier | | Subscriber |
+-----------+ +--------------+
Figure 8: Combined System with Common Metadata
图8：具有通用元数据的组合系统
SDP: The SDP format [2] 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 overhead. It is expected that the information conveyed by SDP is just a small subset of IMG metadata; thus, the use of SDP for other than session parameters may not be reasonable.
SDP:SDP格式[2]可用于描述会话级参数（例如，调度、寻址和媒体编解码器的使用），以包含在完整的IMG描述中。虽然SDP中存在允许扩展格式的扩展点，但此扩展机制的灵活性存在限制。然而，SDP语法不能提供IMG描述和IMG指针，而不会带来很大的开销。预计SDP传递的信息只是IMG元数据的一小部分；因此，将SDP用于会话参数以外的其他参数可能是不合理的。
SDPng [3]: Similar to SDP, this format could also be used for representing session-level parameters of IMG metadata. Compared to SDP, the XML-based format of SDPng should be much more flexible and allow extensions and integration with other description formats.
SDPng[3]：与SDP类似，此格式也可用于表示IMG元数据的会话级参数。与SDP相比，基于XML的SDPng格式应该更加灵活，并允许扩展和与其他描述格式集成。
MPEG-7: Descriptions based on the MPEG-7 standard [5] could provide application-specific metadata describing the properties of multimedia content beyond parameters carried in SDP or SDPng descriptions. MPEG-7 provides a machine-readable format of representing content categories and attributes, helping end-users or receiving software in choosing content for reception. MPEG-7 is based on XML, so it is well suited to be combined with other XML-based formats such as SDPng.
MPEG-7：基于MPEG-7标准[5]的描述可以提供特定于应用程序的元数据，描述SDP或SDPng描述中携带的参数以外的多媒体内容的属性。MPEG-7提供了一种表示内容类别和属性的机器可读格式，帮助最终用户或接收软件选择要接收的内容。MPEG-7基于XML，因此非常适合与其他基于XML的格式（如SDPng）结合使用。
TV-Anytime: The TV-Anytime Forum [6] provides descriptions based on XML schema for TV-specific program guides. TV-Anytime uses the MPEG-7 User description profile to a limited extent, only for user preferences and usage history, and also a TV-Anytime-specific data model for other schema. These are optimized to describe broadcast schedules, on-demand program guides and program events.
TV Anytime:TV Anytime论坛[6]基于XML模式为特定于电视的节目指南提供描述。TV Anytime在有限的范围内使用MPEG-7用户描述配置文件，仅用于用户偏好和使用历史记录，也用于其他模式的TV Anytime特定数据模型。这些被优化以描述广播时间表、点播节目指南和节目事件。
HTTP: The HTTP protocol [7] can be used as a bidirectional unicast IMG transport protocol. Being a request-reply-oriented protocol, HTTP is well suited for implementing synchronous operations such as QUERY, RESOLVE, and even SUBSCRIBE. However, HTTP does not provide asynchronous operations such as ANNOUNCE and NOTIFY and to implement asynchronous operations using HTTP, IMG receivers should poll the IMG sender periodically. Thus, by itself, HTTP is not sufficient to fulfill all of the IMG requirements [4] in a unicast deployment.
HTTP:HTTP协议[7]可用作双向单播IMG传输协议。作为一种面向请求-应答的协议，HTTP非常适合实现同步操作，例如查询、解析，甚至订阅。但是，HTTP不提供诸如通告和通知之类的异步操作，为了使用HTTP实现异步操作，IMG接收方应该定期轮询IMG发送方。因此，HTTP本身不足以满足单播部署中的所有IMG需求[4]。
Session Announcement Protocol (SAP): The announcement mechanism provided by SAP [8] provides unidirectional delivery of session discovery information. Although SDP is the default payload format of SAP, the use of a MIME type identifier for the payload allows
会话公告协议（SAP）：SAP[8]提供的公告机制提供会话发现信息的单向传递。尽管SDP是SAP的默认有效负载格式，但对有效负载使用MIME类型标识符允许
arbitrary payload formats to be used in SAP messages. Thus, SAP could be used to implement the multicast and unicast IMG ANNOUNCE and IMG NOTIFY operations.
SAP消息中要使用的任意有效负载格式。因此，SAP可用于实现多播和单播IMG公告和IMG通知操作。
However, SAP lacks scalable and efficient reliability, extensibility for payload size, and congestion control, and only one description is allowed per SAP message due to lack of payload segmentation.
然而，SAP缺乏可扩展和高效的可靠性、有效负载大小的可扩展性和拥塞控制，并且由于缺乏有效负载分段，每个SAP消息只允许一个描述。
In principle, SAP could be extended to get around its limitations. However, the amount of changes needed in SAP to address all of the above limitations would effectively result in a new protocol. Due to these limitations, the use of SAP as an IMG transport protocol is not recommended.
原则上，SAP可以进行扩展以克服其局限性。然而，SAP中为解决上述所有限制所需的大量更改将有效地产生一个新的协议。由于这些限制，不建议将SAP用作IMG传输协议。
SIP: The SIP-specific event mechanism described in RFC 3265 [9] provides a way to implement IMG SUBSCRIBE and IMG NOTIFY operations via a bidirectional unicast connection. However, there are scalability problems with this approach, as RFC 3265 currently does not consider multicast.
SIP：RFC 3265[9]中描述的特定于SIP的事件机制提供了一种通过双向单播连接实现IMG SUBSCRIBE和IMG NOTIFY操作的方法。然而，这种方法存在可伸缩性问题，因为RFC 3265目前不考虑多播。
Real Time Streaming Protocol (RTSP): The RTSP protocol [10] 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 a 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 used to instantiate IMG QUERY, IMG RESOLVE, and IMG SUBSCRIBE, and the RTSP ANNOUNCE could be used to instantiate an IMG NOTIFY for a streaming session controlled by RTSP.
实时流协议（RTSP）：RTSP协议[10]定义了一种检索和更新通知机制，名为descripe and annound，用于描述演示或媒体对象，以初始化流会话。这些方法是RTSP中整个流控制操作的子集；因此，这些机制无法用于个别机制。然而，RTSP中的描述方法可用于实例化IMG查询、IMG解析和IMG订阅，RTSP公告可用于实例化RTSP控制的流会话的IMG通知。
Several needs result from the IMG requirements, framework model, and existing relevant mechanisms as already shown in this document. Four specific groupings of work are readily apparent: (a) specification of an adequate multicast- and unidirectional-capable announcement protocol; (b) specification of the use of existing unicast protocols to enable unicast subscribe and announcement/notification functionality; (c) specification of the metadata envelope that is common to, and independent of, the application metadata syntax(es) used; and (d) agreement on basic metadata models to enable interoperability testing of the above. The following sections describe each of these.
如本文件所示，IMG需求、框架模型和现有相关机制产生了一些需求。四个具体的工作组显而易见：（a）适当的多播和单向广播协议的规范；（b） 使用现有单播协议实现单播订阅和公告/通知功能的规范；（c） 元数据信封的规范，该规范与所使用的应用程序元数据语法通用且独立；（d）就基本元数据模型达成协议，以便能够对上述各项进行互操作性测试。以下各节介绍了其中的每一项。
SAP is currently the only open standard protocol suited to the unidirectional/multicast delivery of IMG metadata. As discussed, it fails to meet the IMG requirements in many ways and, since it is not designed to be extensible, we recognize that a new multicast transport protocol for announcements needs to be specified to meet IMG needs. This protocol will be essential to IMG delivery for unidirectional and multicast deployments.
SAP是目前唯一适用于IMG元数据单向/多播交付的开放标准协议。如前所述，它在许多方面都不能满足IMG的要求，而且由于它的设计不可扩展，我们认识到需要指定一个新的广播多播传输协议来满足IMG的需要。该协议对于单向和多播部署的IMG交付至关重要。
The Asynchronous Layered Coding (ALC) [11] protocol from the IETF Reliable Multicast Transport (RMT) working group is very interesting as it fulfills many of the requirements, is extensible, and has the ability to 'plug-in' both FEC (Forward Error Correction, for reliability) and CC (Congestion Control) functional blocks. It is specifically designed for unidirectional multicast object transport. ALC is not fully specified, although the RMT working group had a fully specified protocol using ALC called FLUTE (File Delivery over Unidirectional Transport) [12]. FLUTE seems to be the only fully specified transport and open specification on which a new IMG announcement protocol could be designed. Thus, we recommend that ALC and FLUTE be the starting points for this protocol's design.
IETF可靠多播传输（RMT）工作组的异步分层编码（ALC）[11]协议非常有趣，因为它满足许多要求，可扩展，并且能够“插入”FEC（可靠性前向纠错）和CC（拥塞控制）功能块。它是专为单向多播对象传输而设计的。虽然RMT工作组有一个使用ALC的完全指定的协议，称为FLUTE（单向传输上的文件传递）[12]，但ALC并没有完全指定。长笛似乎是唯一一个完全指定的传输和开放规范，可以设计一个新的IMG公告协议。因此，我们建议将ALC和FLUTE作为本协议设计的起点。
Developing a new protocol from scratch, or attempting to improve SAP, is also feasible, although it would involve repeating many of the design processes and decisions already made by the IETF for ALC. In particular, any announcement protocol must feature sufficient scalability, flexibility, and reliability to meet IMG needs. Also, the IMG ANNOUNCE operation must be supported and IMG NOTIFY capability could be investigated for both hybrid unicast-multicast and unidirectional unicast systems.
从头开始开发一个新的协议，或者尝试改进SAP，也是可行的，尽管它需要重复IETF已经为ALC制定的许多设计过程和决策。特别是，任何公告协议都必须具有足够的可伸缩性、灵活性和可靠性，以满足IMG需求。此外，必须支持IMG公告操作，并且可以研究混合单播多播和单向单播系统的IMG通知功能。
A thorough description of the use of existing unicast protocols is essential for the use of IMGs in a unicast point-to-point environment. Such a specification has not been published, although several usable unicast transport protocols and specifications can be harnessed for this (SIP [13], SIP events [9], HTTP [7], etc.). In particular, both IMG SUBSCRIBE-NOTIFY and IMG QUERY-RESOLVE operation pairs must be enabled. We anticipate that the IMG QUERY-RESOLVE operation can be achieved using HTTP, although other transport protocol options may be beneficial to consider too.
对现有单播协议使用的全面描述对于在单播点对点环境中使用IMG至关重要。这样的规范尚未发布，尽管可以为此利用几种可用的单播传输协议和规范（SIP[13]、SIP事件[9]、HTTP[7]等）。特别是，必须同时启用IMG SUBSCRIBE-NOTIFY和IMG QUERY-RESOLVE操作对。我们预期IMG查询解析操作可以使用HTTP实现，尽管其他传输协议选项也可能是有益的。
An IMG envelope provides the binding between IMG operations and data types. Such a binding can be realized by defining a common minimal set of information needed to manage IMG metadata transfers, and by including this information with any set of IMG metadata delivered to IMG receivers.
IMG信封提供IMG操作和数据类型之间的绑定。这种绑定可以通过定义管理IMG元数据传输所需的公共最小信息集，并通过将该信息与交付给IMG接收方的任何IMG元数据集一起包含来实现。
Four options for IMG metadata transfer envelope delivery are feasible:
IMG元数据传输信封交付的四个选项是可行的：
1. Embedding in a transport protocol header. This can be done with either header extensions of existing protocols, or newly defined header fields of a new (or new version of a) transport protocol. However, multiple methods for the variety of transport protocols would hinder interoperability and transport protocol independence.
1. 嵌入到传输协议头中。这可以通过现有协议的头扩展或新（或新版本）传输协议的新定义头字段来完成。然而，多种传输协议的多种方法会阻碍互操作性和传输协议独立性。
2. A separate envelope object, which points to the IMG metadata 'object', delivered in-band with the metadata transport protocol session. This might complicate delivery as the envelope and 'service' metadata objects would have to be bound, e.g., by pairing some kind of transport object numbers (analogous to port number pairs sometimes used for RTP and RTCP [14]). This would also enable schemes that deliver envelope and metadata 'objects' by different media, also using more than a single transport protocol.
2. 一个单独的信封对象，指向IMG元数据“对象”，与元数据传输协议会话一起在频带内交付。这可能会使交付复杂化，因为信封和“服务”元数据对象必须绑定，例如，通过配对某种传输对象号（类似于有时用于RTP和RTCP的端口号对[14]）。这也将使通过不同媒体传递信封和元数据“对象”的方案成为可能，也将使用不止一个传输协议。
3. A metadata wrapper that points to and/or embeds the service metadata into its 'super-syntax'. For example, XML would enable embedding generic text objects.
3. 指向和/或将服务元数据嵌入其“超级语法”的元数据包装器。例如，XML将支持嵌入通用文本对象。
4. Embedding in the metadata itself. However, this requires a new field in many metadata syntaxes and would not be feasible if a useful syntax were not capable of extensibility in this way. It also introduces a larger 'implementation interpretation' variety, which would hinder interoperability. Thus, this option is not recommended.
4. 嵌入元数据本身。然而，在许多元数据语法中，这需要一个新字段，如果有用的语法不能以这种方式扩展，那么这是不可行的。它还引入了更大的“实现解释”种类，这将阻碍互操作性。因此，不建议使用此选项。
It is likely that more than one of these options will fulfill the needs of IMGs, so the selection, and possibly optimization, is left for subsequent specification and feedback from implementation experience. Such a specification is essential for IMG delivery.
这些选项中很可能有一个以上将满足IMG的需求，因此选择和可能的优化将留待后续规范和实施经验的反馈。此类规范对于IMG交付至关重要。
When there are superset/subset relations between IMG Descriptions, it is assumed that the IMG Descriptions of the subset inherit the parameters of the superset. Thus, an IMG metadata transfer envelope carrying the IMG Descriptions of a superset may implicitly define
当IMG描述之间存在超集/子集关系时，假定子集的IMG描述继承了超集的参数。因此，携带超集的IMG描述的IMG元数据传输信封可以隐式定义
parameters of IMG Descriptions belonging to its subset. The relations between IMG Descriptions may span from one envelope to another according to a data model definition.
属于其子集的IMG描述的参数。根据数据模型定义，IMG描述之间的关系可以从一个信封延伸到另一个信封。
A structured data model would allow reuse and extension of the set of metadata and may enable use of multiple syntaxes (SDP, MPEG-7, etc.) as part of the same body of IMG metadata.
结构化数据模型将允许元数据集的重用和扩展，并允许将多个语法（SDP、MPEG-7等）用作IMG元数据的同一主体的一部分。
For the successful deployment of IMGs in various environments, further work may be needed to define metadata and data models for application-specific requirements. Existing (and future) work on these would need to be mapped to the IMG data types and use of the IMG transfer envelope concept as described above.
为了在各种环境中成功部署IMG，可能需要进一步的工作来定义元数据和数据模型，以满足特定于应用程序的需求。关于这些方面的现有（和未来）工作需要映射到IMG数据类型和IMG传输包络概念的使用，如上所述。
This document is a framework for the delivery of IMG metadata and thus further discussion on the definition data models for IMGs is beyond its scope.
本文件是IMG元数据交付的框架，因此，关于IMG定义数据模型的进一步讨论超出了其范围。
The IMG framework is developed from the IMG requirements document [4], and so the selection of specific protocols and mechanism for use with the IMG framework must also take into account the security considerations of the IMG requirements document. This framework document does not mandate the use of specific protocols. However, an IMG specification would inherit the security considerations of specific protocols used.
IMG框架是根据IMG需求文件[4]开发的，因此，选择与IMG框架一起使用的特定协议和机制也必须考虑IMG需求文件的安全考虑。本框架文件不强制使用特定协议。然而，IMG规范将继承所使用的特定协议的安全考虑。
Protocol instantiations that are used to provide IMG operations will have very different security considerations depending on their scope and purpose. However, there are several general issues that are valuable to consider and, in some cases, provide technical solutions for. These are described below.
用于提供IMG操作的协议实例化将根据其范围和用途有非常不同的安全考虑。然而，有几个一般的问题是值得考虑的，在某些情况下，提供技术解决方案。下文对这些问题进行了说明。
Individual and group privacy: Customized IMG metadata may reveal information about the habits and preferences of a user and may thus deserve confidentiality protection, even if the original information were public. Protecting this metadata against snooping requires the same actions and measures as for other point-to-point and multicast Internet communications. Naturally, the risk of snooping depends on the amount of individual or group personalization the IMG metadata contains.
个人和团体隐私：定制的IMG元数据可能会泄露有关用户习惯和偏好的信息，因此可能需要保密保护，即使原始信息是公开的。保护此元数据免受窥探需要与其他点对点和多播Internet通信相同的操作和措施。当然，窥探的风险取决于IMG元数据包含的个人或组个性化的数量。
IMG authenticity: In some cases, the IMG receiver needs to be assured of the sender or origin of IMG metadata or its modification history. This can prevent denial-of-service or hijacking attempts that give an
IMG真实性：在某些情况下，IMG接收者需要确保IMG元数据的发送者或来源或其修改历史。这可以防止拒绝服务或劫持企图，从而导致
IMG receiver incorrect information in or about the metadata, thus preventing successful access of the media or directing the IMG receiver to the incorrect media possibly with tasteless material.
IMG接收器元数据中或关于元数据的错误信息，从而阻止媒体的成功访问，或将IMG接收器指向可能含有无味材料的错误媒体。
IMG receiver authorization: Some or all of any IMG sender's metadata may be private or valuable enough to allow access to only certain IMG receivers and thus make it worth authenticating users. Encrypting the data is also a reasonable step, especially where group communications methods results in unavoidable snooping opportunities for unauthorized nodes.
IMG接收方授权：IMG发送方的部分或全部元数据可能是私有的或有价值的，只允许访问某些IMG接收方，因此值得对用户进行身份验证。对数据进行加密也是一个合理的步骤，尤其是当组通信方法导致无法避免的未经授权节点的窥探机会时。
Unidirectional specifics: A difficulty that is faced by unidirectional delivery operations is that many protocols providing application-level security are based on bidirectional communications. The application of these security protocols in case of strictly unidirectional links is not considered in the present document.
单向细节：单向交付操作面临的一个困难是，许多提供应用程序级安全性的协议都基于双向通信。本文件不考虑在严格单向链路的情况下应用这些安全协议。
Malicious code: Currently, IMGs are not envisaged to deliver executable code at any stage. However, as some IMG transport protocols may be capable of delivering arbitrary files, it is RECOMMENDED that the IMG operations do not have write access to the system or any other critical areas.
恶意代码：目前，IMG不打算在任何阶段交付可执行代码。但是，由于某些IMG传输协议可能能够传输任意文件，因此建议IMG操作不具有对系统或任何其他关键区域的写访问权限。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[2] Handley，M.和V.Jacobson，“SDP：会话描述协议”，RFC 2327，1998年4月。
[3] Kutscher, D., Ott, J., and C. Bormann, "Session description and capability negotiation", Work in Progress, October 2003.
[3] Kutscher，D.，Ott，J.，和C.Bormann，“会话描述和能力协商”，正在进行的工作，2003年10月。
[4] Nomura, Y., Walsh, R., Luoma, J-P., Ott, J., and H. Schulzrinne, "Requirements for Internet Media Guides", Work in Progress, December 2005.
[4] 野村，Y.，沃尔什，R.，骆马，J-P.，Ott，J.，和H.Schulzrinne，“互联网媒体指南的要求”，正在进行的工作，2005年12月。
[5] "Multimedia content description interface -- Part 1: Systems", ISO/IEC 15938-1, July 2002.
[5] “多媒体内容描述接口——第1部分：系统”，ISO/IEC 15938-11902年7月。
[6] TV-Anytime Forum, "Broadcast and On-line Services: Search, select, and rightful use of content on personal storage systems ("TV-Anytime Phase 1"); Part 2: System description," ETSI-TS 102 822-2: System Description, V1.1.1, October 2003.
[6] TV Anytime Forum，“广播和在线服务：在个人存储系统上搜索、选择和合法使用内容（TV Anytime阶段1）”；第2部分：系统描述”，ETSI-TS 102 822-2：系统描述，V1.1.12003年10月。
[7] 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.
[7] 菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC2616，1999年6月。
[8] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[8] Handley，M.，Perkins，C.，和E.Whelan，“会话公告协议”，RFC 29742000年10月。
[9] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[9] Roach，A.，“会话启动协议（SIP）-特定事件通知”，RFC3265，2002年6月。
[10] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[10] Schulzrinne，H.，Rao，A.，和R.Lanphier，“实时流协议（RTSP）”，RFC2326，1998年4月。
[11] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., and J. Crowcroft, "Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC 3450, December 2002.
[11] Luby，M.，Gemmell，J.，Vicisano，L.，Rizzo，L.，和J.Crowcroft，“异步分层编码（ALC）协议实例化”，RFC 3450，2002年12月。
[12] Paila, T., Luby, M., Lehtonen, R., Roca, V., and R. Walsh, "FLUTE - File Delivery over Unidirectional Transport", RFC 3926, October 2004.
[12] Paila，T.，Luby，M.，Lehtonen，R.，Roca，V.，和R.Walsh，“长笛-单向传输上的文件交付”，RFC 3926，2004年10月。
[13] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[13] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[14] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[14] Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
The authors would like to thank Spencer Dawkins, Jean-Pierre Evain, Ted Hardie, Petri Koskelainen, Joerg Ott, Colin Perkins, Toni Paila, and Magnus Westerlund for their excellent ideas and input to this document.
作者要感谢斯宾塞·道金斯、让·皮埃尔·埃瓦因、特德·哈迪、佩特里·科斯凯莱宁、约尔格·奥特、科林·帕金斯、托尼·帕伊拉和马格纳斯·韦斯特隆德为本文件提出的出色想法和意见。
Authors' Addresses
作者地址
Yuji Nomura Fujitsu Laboratories Ltd. 4-1-1 Kamikodanaka, Nakahara-ku, Kawasaki 211-8588 Japan
野村裕二富士通实验室有限公司，位于日本川崎市中川区镰田中4-1-1，邮编：211-8588
EMail: nom@flab.fujitsu.co.jp
EMail: nom@flab.fujitsu.co.jp
Rod Walsh Nokia Research Center P.O. Box 100, FIN-33721 Tampere Finland
罗德·沃尔什诺基亚研究中心邮政信箱100，芬兰坦佩雷FIN-33721
EMail: rod.walsh@nokia.com
EMail: rod.walsh@nokia.com
Juha-Pekka Luoma Nokia Research Center P.O. Box 100, FIN-33721 Tampere Finland
Juha Pekka Luoma诺基亚研究中心芬兰坦佩雷FIN-33721邮政信箱100
EMail: juha-pekka.luoma@nokia.com
EMail: juha-pekka.luoma@nokia.com
Hitoshi Asaeda Keio University Graduate School of Media and Governance 5322 Endo, Fujisawa, 252-8520 Kanagawa, Japan
日本神奈川藤泽市藤泽内多5322号浅田庆应大学媒体与治理研究生院，252-8520
EMail: asaeda@wide.ad.jp
EMail: asaeda@wide.ad.jp
Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA
美国纽约州纽约市阿姆斯特丹大道1214号哥伦比亚大学计算机科学系
EMail: schulzrinne@cs.columbia.edu
EMail: schulzrinne@cs.columbia.edu
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
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.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
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.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。