Network Working Group Y. Nomura
Request for Comments: 4473 Fujitsu Labs
Category: Informational R. Walsh
J-P. Luoma
Nokia
J. Ott
Helsinki University of Technology
H. Schulzrinne
Columbia University
May 2006
Network Working Group Y. Nomura
Request for Comments: 4473 Fujitsu Labs
Category: Informational R. Walsh
J-P. Luoma
Nokia
J. Ott
Helsinki University of Technology
H. Schulzrinne
Columbia University
May 2006
Requirements for 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 memo specifies requirements for a framework and protocols for accessing and updating Internet Media Guide (IMG) information for media-on-demand and multicast applications. These requirements are designed to guide choice and development of IMG protocols for efficient and scalable delivery.
本备忘录规定了访问和更新媒体点播和多播应用程序的互联网媒体指南（IMG）信息的框架和协议要求。这些要求旨在指导IMG协议的选择和开发，以实现高效、可扩展的交付。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Background and Motivation ..................................3
1.2. Scope of This Document .....................................4
2. Terminology .....................................................5
2.1. New Terms ..................................................5
3. Problem Statement ...............................................6
4. Use Cases Requiring IMGs ........................................7
4.1. Connectivity-based Use Cases ...............................7
4.1.1. IP Datacast to a Wireless Receiver ..................7
4.1.2. Regular Fixed Dial-up Internet Connection ...........8
4.1.3. Broadband Always-on Fixed Internet Connection .......9
4.2. Content-orientated Use Cases ...............................9
4.2.1. TV and Radio Program Delivery .......................9
4.2.2. Media Coverage of a Live Event .....................10
4.2.3. Distance Learning ..................................10
4.2.4. Multiplayer Gaming .................................10
4.2.5. File Distribution ..................................11
4.2.6. Coming-release and Pre-released Content ............11
5. Requirements ...................................................11
5.1. General Requirements ......................................11
5.1.1. Independence of IMG Operations from IMG Metadata ...11
5.1.2. Multiple IMG Senders ...............................12
5.1.3. Modularity .........................................12
5.2. Delivery Properties .......................................12
5.2.1. Scalability ........................................13
5.2.2. Support for Intermittent Connectivity ..............13
5.2.3. Congestion Control .................................13
5.2.4. Sender- and Receiver-Driven Delivery ...............13
5.3. Customized IMGs ...........................................14
5.4. Reliability ...............................................15
5.4.1. Managing Consistency ...............................15
5.4.2. Reliable Message Exchange ..........................16
5.5. IMG Descriptions ..........................................16
6. Security Considerations ........................................17
6.1. IMG Authentication and Integrity ..........................18
6.2. Privacy ...................................................19
6.3. Access Control for IMGs ...................................19
6.4. Denial-of-Service (DOS) Attacks ...........................20
6.5. Replay Attacks ............................................20
7. Normative References ...........................................21
8. Informative References .........................................21
9. Acknowledgements ...............................................22
1. Introduction ....................................................3
1.1. Background and Motivation ..................................3
1.2. Scope of This Document .....................................4
2. Terminology .....................................................5
2.1. New Terms ..................................................5
3. Problem Statement ...............................................6
4. Use Cases Requiring IMGs ........................................7
4.1. Connectivity-based Use Cases ...............................7
4.1.1. IP Datacast to a Wireless Receiver ..................7
4.1.2. Regular Fixed Dial-up Internet Connection ...........8
4.1.3. Broadband Always-on Fixed Internet Connection .......9
4.2. Content-orientated Use Cases ...............................9
4.2.1. TV and Radio Program Delivery .......................9
4.2.2. Media Coverage of a Live Event .....................10
4.2.3. Distance Learning ..................................10
4.2.4. Multiplayer Gaming .................................10
4.2.5. File Distribution ..................................11
4.2.6. Coming-release and Pre-released Content ............11
5. Requirements ...................................................11
5.1. General Requirements ......................................11
5.1.1. Independence of IMG Operations from IMG Metadata ...11
5.1.2. Multiple IMG Senders ...............................12
5.1.3. Modularity .........................................12
5.2. Delivery Properties .......................................12
5.2.1. Scalability ........................................13
5.2.2. Support for Intermittent Connectivity ..............13
5.2.3. Congestion Control .................................13
5.2.4. Sender- and Receiver-Driven Delivery ...............13
5.3. Customized IMGs ...........................................14
5.4. Reliability ...............................................15
5.4.1. Managing Consistency ...............................15
5.4.2. Reliable Message Exchange ..........................16
5.5. IMG Descriptions ..........................................16
6. Security Considerations ........................................17
6.1. IMG Authentication and Integrity ..........................18
6.2. Privacy ...................................................19
6.3. Access Control for IMGs ...................................19
6.4. Denial-of-Service (DOS) Attacks ...........................20
6.5. Replay Attacks ............................................20
7. Normative References ...........................................21
8. Informative References .........................................21
9. Acknowledgements ...............................................22
For some ten years, multicast-based (multimedia) conferences (including IETF working group sessions) as well as broadcasts of lectures/seminars, concerts, and other events have been used in the Internet, more precisely, on the MBONE. Schedules and descriptions for such multimedia sessions as well as the transport addresses, codecs, and their parameters have been described using the Session Description Protocol (SDP) [2] as a rudimentary (but as of then largely sufficient) means. Descriptions have been disseminated using the Session Announcement Protocol (SAP) [3] and Session Directory Tools such as SD [4] or SDR [5]; descriptions have also been put up on web pages, sent by electronic mail, etc.
大约十年来，基于多播的（多媒体）会议（包括IETF工作组会议）以及讲座/研讨会、音乐会和其他活动的广播已在互联网上使用，更准确地说，是在MBONE上。已经使用会话描述协议（SDP）[2]作为基本（但到那时基本上已经足够）手段来描述此类多媒体会话的时间表和描述以及传输地址、编解码器及其参数。使用会话公告协议（SAP）[3]和会话目录工具（如SD[4]或SDR[5]）发布了说明；通过电子邮件等方式在网页上发布说明。
Recently, interest has grown to expand -- or better: to generalize -- the applicability of these kinds of session descriptions. Descriptions are becoming more elaborate in terms of included metadata, more generic regarding the types of media sessions, and possibly also support other transports than just IP (e.g., legacy TV channel addresses). This peers well with the DVB (Digital Video Broadcasting) [6] Organization's increased activities towards IP-based communications over satellite, cable, and terrestrial radio networks, also considering IP as the basis for TV broadcasts and further services. The program/content descriptions are referred to as Internet Media Guides (IMGs) and can be viewed as a generalization of Electronic Program Guides (EPGs) and multimedia session descriptions.
最近，人们对这些会话描述的适用性越来越感兴趣，或者更好地说，对其进行概括。在包含的元数据方面，描述变得更加详细，关于媒体会话类型的描述更加通用，并且可能还支持除IP之外的其他传输（例如，传统电视频道地址）。这与DVB（数字视频广播）[6]组织增加了通过卫星、有线和地面无线电网络进行基于IP的通信的活动，也将IP视为电视广播和进一步服务的基础。节目/内容描述称为互联网媒体指南（IMG），可被视为电子节目指南（EPG）和多媒体会话描述的概括。
An Internet Media Guide (IMG) has a structured collection of multimedia session descriptions expressed using SDP, SDPng [7], or some similar session description format. This is used to describe a set of multimedia services (e.g., television program schedules, content delivery schedules) but may also refer to other networked resources including web pages. IMGs provide the envelope for metadata formats and session descriptions defined elsewhere with the aim of facilitating structuring, versioning, referencing, distributing, and maintaining (caching, updating) such information.
Internet Media Guide（IMG）具有使用SDP、SDPng[7]或某些类似会话描述格式表示的多媒体会话描述的结构化集合。这用于描述一组多媒体服务（例如，电视节目时间表、内容交付时间表），但也可以指其他网络资源，包括网页。IMG为其他地方定义的元数据格式和会话描述提供了信封，目的是促进此类信息的结构化、版本控制、引用、分发和维护（缓存、更新）。
The IMG metadata may be delivered to a potentially large audience, who uses it to join a subset of the sessions described, and who may need to be notified of changes to this information. 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, too.
IMG元数据可以交付给潜在的大量受众，他们使用IMG元数据加入所述会话的子集，并且可能需要通知这些信息的更改。因此，需要一个以各种不同方式分发IMG元数据的框架来满足不同受众的需求：对于传统的广播风格场景，需要支持基于多播（push）的IMG元数据分发。在没有多播可用的情况下，也需要基于单播的推送。
Furthermore, IMG metadata may need to be retrieved interactively, similar to web pages (e.g., after rebooting a system or when a user is browsing after network connectivity has been re-established). Finally, IMG metadata may be updated as time elapses because content described in the guide may be changed: for example, the airtime of an event such as a concert or sports event may change, possibly affecting the airtime of subsequent media. This may be done by polling the IMG sender as well as by asynchronous change notifications.
此外，可能需要以交互方式检索IMG元数据，类似于web页面（例如，在重新启动系统后或在重新建立网络连接后用户浏览时）。最后，IMG元数据可能会随着时间的推移而更新，因为指南中描述的内容可能会更改：例如，音乐会或体育赛事等活动的播放时间可能会更改，可能会影响后续媒体的播放时间。这可以通过轮询IMG发送方以及异步更改通知来完成。
Furthermore, any Internet host can be a sender of content and thus an IMG sender. Some of the content sources and sinks may only be connected to the Internet sporadically. Also, a single human user may use many different devices to access metadata. Thus, we envision that IMG metadata can be sent and received by, among others, cellular phones, Personal Digital Assistants (PDAs), personal computers, streaming video servers, set-top boxes, video cameras, and Digital Video Recorders (DVRs), and that the data be carried across arbitrary types of link layers, including bandwidth-constrained mobile networks. However, generally we expect IMG senders to be well-connected hosts.
此外，任何互联网主机都可以是内容的发送者，因此也可以是IMG发送者。某些内容源和接收器可能仅偶尔连接到Internet。此外，单个人类用户可以使用许多不同的设备来访问元数据。因此，我们设想，IMG元数据可以由手机、个人数字助理（PDA）、个人计算机、流式视频服务器、机顶盒、摄像机和数字录像机（DVR）等发送和接收，并且数据可以跨任意类型的链路层传输，包括带宽受限的移动网络。但是，通常我们希望IMG发送方是连接良好的主机。
Finally, with many potential senders and receivers, different types of networks, and presumably numerous service providers, IMG metadata may need to be combined, split, filtered, augmented, modified, etc., on their way from the sender(s) to the receiver(s) to provide the ultimate user with a suitable selection of multimedia services according to her preferences, subscriptions, location, and context (e.g., devices, access networks).
最后，由于有许多潜在的发送者和接收者、不同类型的网络以及可能的众多服务提供者，IMG元数据可能需要在从发送者到接收者的过程中进行组合、分割、过滤、扩充、修改等根据最终用户的偏好、订阅、位置和上下文（如设备、接入网络），为其提供合适的多媒体服务选择。
This document defines requirements that Internet Media Guide mechanisms must satisfy in order to deliver IMG metadata to a potentially large audience. Since IMGs can describe many kinds of multimedia content, IMG methods are generally applicable to several scenarios.
本文件定义了互联网媒体指南机制必须满足的要求，以便向潜在的大量受众交付IMG元数据。由于IMG可以描述多种多媒体内容，因此IMG方法通常适用于多种场景。
In considering wide applicability, this document provides the problem statement and discusses existing mechanisms in this area. Then several use case scenarios for IMGs are explained including descriptions of how IMG metadata and IMG delivery mechanisms contribute to these scenarios. Following this, this document provides general requirements that are independent of any transport layer mechanism and application, such as delivery properties, reliability, and IMG descriptions.
考虑到广泛的适用性，本文件提供了问题陈述，并讨论了该领域的现有机制。然后解释了IMG的几个用例场景，包括IMG元数据和IMG交付机制如何对这些场景做出贡献的描述。在此之后，本文档提供了独立于任何传输层机制和应用程序的一般要求，如交付特性、可靠性和IMG描述。
This document reflects investigating work on delivery mechanisms for IMGs and generalizing work on session announcement and initiation protocols, especially in the field of the MMUSIC working group (SAP, SIP [8], SDP).
本文件反映了对IMG交付机制的调查工作，以及对会话公告和启动协议的概括工作，特别是在MMUSIC工作组领域（SAP，SIP[8]，SDP）。
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 used to describe the formation, delivery, and use of IMG metadata. The definition of the IMG is intentionally left imprecise.
互联网媒体指南（IMG）：IMG是一个通用术语，用于描述IMG元数据的形成、交付和使用。IMG的定义故意不精确。
IMG Element: The smallest atomic element of metadata that can be transmitted separately by IMG operations and referenced individually from other IMG elements.
IMG元素：元数据中最小的原子元素，可通过IMG操作单独传输，并可从其他IMG元素中单独引用。
IMG Metadata: A set of metadata consisting of one or more IMG elements. IMG metadata describes the features of multimedia content used to enable selection of and access to media sessions containing content. For example, metadata may consist of the URI, title, airtime, bandwidth needed, file size, text summary, genre, and access restrictions.
IMG元数据：由一个或多个IMG元素组成的一组元数据。IMG元数据描述了用于选择和访问包含内容的媒体会话的多媒体内容的功能。例如，元数据可能包括URI、标题、播放时间、所需带宽、文件大小、文本摘要、类型和访问限制。
IMG Delivery: The process of exchanging IMG metadata in terms of both large-scale and atomic data transfers.
IMG交付：在大规模和原子数据传输方面交换IMG元数据的过程。
IMG Sender: An IMG sender is a logical entity that sends IMG metadata to one or more IMG receivers.
IMG发送方：IMG发送方是一个逻辑实体，它将IMG元数据发送给一个或多个IMG接收方。
IMG Receiver: An IMG receiver is a logical entity that receives IMG metadata from an IMG sender.
IMG接收方：IMG接收方是从IMG发送方接收IMG元数据的逻辑实体。
IMG Transceiver: An IMG transceiver combines an IMG receiver and sender. It may modify received IMG metadata or merge IMG metadata received from several different IMG senders.
IMG收发器：IMG收发器结合了IMG接收器和发送器。它可以修改接收到的IMG元数据或合并从多个不同IMG发送者接收到的IMG元数据。
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).
IMG操作：IMG传输协议的原子操作，用于IMG发送方和IMG接收方之间传递IMG元数据和控制IMG发送方/接收方。
IMG Transport Protocol: A protocol that transports IMG metadata from an IMG sender to IMG receiver(s).
IMG传输协议：将IMG元数据从IMG发送方传输到IMG接收方的协议。
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).
IMG传输会话：在IMG传输协议范围内，IMG发送方和一个或多个IMG接收方之间的关联。IMG传输会话涉及一系列有时间限制的IMG传输协议交互，这些交互将IMG元数据从IMG发送方传递到IMG接收方。
As we enumerate the requirements for IMGs, it will become clear that they are not fully addressed by the existing protocols. The "Framework for the Usage of Internet Media Guides" [9] discusses about these issues in more detail.
当我们列举IMG的要求时，很明显，现有协议并未完全满足这些要求。“互联网媒体指南使用框架”[9]更详细地讨论了这些问题。
The MMUSIC working group has long been investigating content, media and service information delivery mechanisms, and protocols, and has itself produced the Session Announcement Protocol (SAP), the Session Description Protocol (SDP), and the Session Initiation Protocol (SIP). SDP is capable of describing multimedia sessions (i.e., content in a wider sense) by means of limited descriptive information intended for human perception plus transport, scheduling information, and codecs and addresses for setting up media sessions. SIP and SAP are protocols to distribute these session descriptions.
MMUSIC工作组长期以来一直在研究内容、媒体和服务信息交付机制以及协议，并自行制定了会话公告协议（SAP）、会话描述协议（SDP）和会话启动协议（SIP）。SDP能够通过用于人类感知的有限描述信息以及用于设置媒体会话的传输、调度信息、编解码器和地址来描述多媒体会话（即，广义的内容）。SIP和SAP是分发这些会话描述的协议。
However, we perceive a lack of a standard solution for scalable IMG delivery mechanism in the number of receivers with consistency of IMG metadata between an IMG sender and IMG receiver for both bi-directional and unidirectional transport. With increased service dynamics and complexity, there is an increased requirement for updates to these content descriptions.
然而，我们发现，对于双向和单向传输，IMG发送方和IMG接收方之间的IMG元数据一致性，在接收方数量方面缺乏可伸缩IMG交付机制的标准解决方案。随着服务动态性和复杂性的增加，对这些内容描述的更新要求也越来越高。
HTTP [10] is a well-known information retrieval protocol using bi-directional transport and is 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.
HTTP[10]是一种众所周知的使用双向传输的信息检索协议，广泛用于向许多主机提供基于web的内容描述。但是，由于它依赖轮询机制来保持服务器和客户端之间的信息一致，因此它在HTTP客户端的数量方面具有公认的可伸缩性限制。
SAP [3] is an announcement protocol that distributes session descriptions via multicast. It does not support prioritization or fine-grained metadata selection and update notifications, as it places restrictions on metadata payload size and always sends the whole metadata. It requires a wide-area multicast infrastructure for it to be deployable beyond a local area network.
SAP[3]是一种通过多播分发会话描述的公告协议。它不支持优先级排序或细粒度元数据选择和更新通知，因为它限制元数据负载大小，并始终发送整个元数据。它需要一个广域多播基础设施，以便在局域网之外部署。
SIP [8] and SIP-specific event notifications [11] can be used to notify subscribers of the update of IMG metadata for bi-directional transport. However, it is necessary to define an event package for IMGs.
SIP[8]和特定于SIP的事件通知[11]可用于通知订阅者IMG元数据的更新，以进行双向传输。但是，有必要为IMG定义一个事件包。
We also perceive a lack of standard solution for flexible content descriptions to support a multitude of application-specific metadata and associated data models with a different amount of detail and different target audiences.
我们还发现，缺乏灵活内容描述的标准解决方案来支持大量特定于应用程序的元数据和相关数据模型，这些元数据和模型具有不同的详细程度和不同的目标受众。
SDP [2] has a text-encoded syntax to specify multimedia sessions for announcements and invitations. It is primarily intended to describe client capability requirements and enable client application selection. 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.
SDP[2]具有文本编码语法，用于指定公告和邀请的多媒体会话。它主要用于描述客户机功能需求并支持客户机应用程序选择。虽然SDP是可扩展的，但它有一些限制，例如结构化扩展性和从另一个会话的描述中引用多媒体会话属性的能力。
These can mostly be overcome by the XML-based SDPng [7] -- which is intended for both two-way negotiation and unidirectional delivery -- or similar content description mechanisms. Since SDPng addresses multiparty multimedia conferences, it would be necessary to extend the XML schema in order to describe general multimedia content.
这些主要可以通过基于XML的SDPng[7]或类似的内容描述机制来克服，SDPng[7]用于双向协商和单向交付。由于SDPng处理多方多媒体会议，因此有必要扩展XML模式以描述一般的多媒体内容。
IP Datacast is the delivery of IP-based services over broadcast radio. Internet content delivery is therefore unidirectional in this case. However, there can be significant benefits from being able to provide rich media one-to-many services to such receivers.
IP数据广播是通过广播电台提供基于IP的服务。因此，在这种情况下，互联网内容交付是单向的。然而，能够向这些接收者提供富媒体一对多服务会带来巨大的好处。
There are two main classes of receiver in this use case: fixed mains-powered and mobile battery-powered. Both of these are affected by radio phenomena and so robust, or error-resilient, delivery is important. Carouselled metadata transfer (cyclically repeated with a fixed bandwidth) provides a base level of robustness for an IP datacast-based announcement system, although the design of carouselled transfer should enable battery-powered receivers to go through periods of sleep to extend their operational time between charges. Insertion of Forward Error Correction (FEC) data into metadata announcements improves error resilience, and reordering (interleaving) data blocks further increases tolerance to burst errors.
在这个用例中有两类主要的接收器：固定电源供电的和移动电池供电的。这两者都受到无线电现象的影响，因此，稳健或容错的传输非常重要。旋转元数据传输（以固定带宽循环重复）为基于IP数据广播的公告系统提供了基本的健壮性，尽管旋转传输的设计应使电池供电的接收器能够经历睡眠期，以延长充电之间的工作时间。在元数据公告中插入前向纠错（FEC）数据可以提高错误恢复能力，而重新排序（交错）数据块进一步提高了对突发错误的容忍度。
To enable receivers to more accurately specify the metadata they are interested in, the unidirectional delivery may be distributed between several logical channels. This is so that a receiver needs only access the channels of interest and thus can reduce the amount of time, storage, and CPU resources needed for processing the IP data. Also, hierarchical channels enable receivers to subscribe to a (possibly well-known) root multicast channel/group and progressively access only those additional channels based on metadata in parent channels.
为了使接收者能够更准确地指定他们感兴趣的元数据，单向传递可以分布在多个逻辑信道之间。这使得接收机只需要访问感兴趣的信道，从而可以减少处理IP数据所需的时间、存储和CPU资源量。此外，分层信道使接收机能够订阅（可能是众所周知的）根多播信道/组，并基于父信道中的元数据逐步仅访问那些附加信道。
In some cases, the receiver may have multiple access interfaces adding bi-directional communications capability. This enables a multitude of options, but most important, it enables NACK-based reliability and the individual retrieval of missed or not-multicast sets of metadata.
在某些情况下，接收机可以具有多个接入接口，从而增加双向通信能力。这支持多种选择，但最重要的是，它支持基于NACK的可靠性和对丢失或未多播元数据集的单独检索。
Thus, essential IMG features in this case include the following: robust unidirectional delivery (with optional levels of reliability including "plug-in FEC" supported by a transport layer protocol), which implies easily identifiable segmentation of delivery data to make FEC, carousel, interleaving, and other schemes possible; effective identification of metadata sets (probably uniquely) to enable more efficient use of multicast and unicast retrieval over multiple access systems regardless of the parts of metadata and application-specific extensions in use; and prioritization of metadata, which can (for instance) be achieved by spreading it between channels and allocating/distributing bandwidth accordingly.
因此，在这种情况下，基本的IMG特征包括以下内容：健壮的单向传送（具有可选的可靠性级别，包括由传输层协议支持的“插件FEC”），这意味着传送数据的易于识别的分段，以使FEC、旋转传送、交织和其他方案成为可能；有效识别元数据集（可能是唯一的），以便在多址系统上更有效地使用多播和单播检索，而不考虑使用的元数据部分和特定于应用程序的扩展；元数据的优先级，这可以（例如）通过在通道之间传播元数据并相应地分配/分配带宽来实现。
Furthermore, some cases require IMG metadata authentication and some group security/encryption and supporting security message exchanges (out of band from the IMG multicast sessions).
此外，有些情况需要IMG元数据身份验证和一些组安全/加密，并支持安全消息交换（IMG多播会话的带外）。
Dial-up connections tend to be reasonably slow (<56 kbps in any case), and thus large data transfers are less feasible, especially during an active application session (such as a file transfer described by IMG metadata). They can also be intermittent, especially if a user is paying for the connected time, or connected through a less reliable exchange. Thus, this favors locally stored IMG metadata over web-based browsing, especially where parts of the metadata change infrequently. There may be no service provider preference over unicast and multicast transport for small and medium numbers of users as the last-mile dial-up connection limits per-user congestion, and a user may prefer the more reliable option (unicast unless reliable multicast is provided).
拨号连接往往相当慢（在任何情况下都小于56 kbps），因此大数据传输不太可行，尤其是在活动应用程序会话期间（如IMG元数据描述的文件传输）。它们也可能是间歇性的，特别是当用户为连接时间付费或通过不太可靠的交换机连接时。因此，这有利于本地存储的IMG元数据而不是基于web的浏览，尤其是在元数据的某些部分很少更改的情况下。对于中小型用户来说，服务提供商可能不喜欢单播和多播传输，因为每用户拥塞的最后一英里拨号连接限制，用户可能更喜欢更可靠的选项（单播，除非提供可靠的多播）。
Typically, bandwidth is less of an issue to a broadband user and unicast transport, such as using query-response methods, may be typical for a PC user. If a system were only used in this context, with content providers, ISPs, and users having no other requirements, then web-based browsing may be equally suitable. However, broadband users sharing a local area network, especially wireless, may benefit more from local storage features than on-line browsing, especially if they have intermittent Internet access.
通常，带宽对于宽带用户来说不是什么问题，并且单播传输（例如使用查询响应方法）对于PC用户来说可能是典型的。如果系统仅在这种情况下使用，内容提供商、ISP和用户没有其他要求，那么基于web的浏览可能同样适用。然而，共享局域网（尤其是无线局域网）的宽带用户可能会从本地存储功能中获得比在线浏览更多的好处，特别是如果他们具有间歇性互联网接入。
Some services on broadband, such as live media broadcasting, benefit from multicast transport for streaming media because of scalability. In the cases where multicast transport is already available, it is convenient for a sender and receiver to retrieve IMG metadata over multicast transport. Thus, broadband users may be forced to retrieve IMG metadata over multicast if backbone operators require this to keep system-wide bandwidth usage feasible.
由于可扩展性，一些宽带服务（如实时媒体广播）受益于流媒体的多播传输。在多播传输已经可用的情况下，发送方和接收方可以方便地通过多播传输检索IMG元数据。因此，如果骨干网运营商需要通过多播检索IMG元数据以保持系统带宽使用的可行性，宽带用户可能会被迫通过多播检索IMG元数据。
IMGs will be able to support a very wide range of use cases for enabling content/media delivery. The following few sections just touch the surface of what is possible and are intended to provide an understanding of the scope and type of IMG usage. Many more examples may be relevant, for instance, those detailed in [12]. There are several unique features of IMGs that set them apart from related application areas such as Service Location Protocol (SLP) based service location discovery, Lightweight Directory Access Protocol (LDAP) based indexing services, and search engines such as Google. Features unique to IMGs include the following:
IMGs将能够支持非常广泛的用例，以实现内容/媒体交付。以下几节仅触及可能的表面，旨在提供对IMG使用范围和类型的理解。更多的例子可能是相关的，例如[12]中详述的例子。IMGs有几个独特的功能，将其与相关的应用领域区分开来，如基于服务位置协议（SLP）的服务位置发现、基于轻量级目录访问协议（LDAP）的索引服务以及谷歌等搜索引擎。IMGs独有的功能包括：
o IMG metadata is generally time-related
o IMG元数据通常与时间相关
o There are timeliness requirements in the delivery of IMG metadata
o IMG元数据的交付有时效性要求
o IMG metadata may be updated as time elapses or when an event arises
o IMG元数据可能会随着时间推移或事件发生而更新
A sender of audio/video streaming content can use the IMG metadata to describe the scheduling and other properties of audio/video sessions and events within those sessions, such as individual TV and radio programs and segments within those programs. IMG metadata describing audio/video streaming content could be represented in a format
音频/视频流内容的发送者可以使用IMG元数据来描述这些会话中的音频/视频会话和事件的调度和其他属性，例如这些节目中的单个电视和广播节目以及片段。描述音频/视频流内容的IMG元数据可以用一种格式表示
similar to that of a TV guide in newspapers, or an Electronic Program Guide available on digital TV receivers.
类似于报纸上的电视指南，或数字电视接收器上的电子节目指南。
TV and radio programs can be selected for reception either manually by the end-user or automatically based on the content descriptions and the preferences of the user. The received TV and radio content can be either presented in real time or recorded for later consumption. There may be changes in the scheduling of a TV or a radio program, possibly affecting the transmission times of subsequent programs. IMG metadata can be used to notify receivers of such changes, enabling users to be prompted or recording times to be adjusted.
电视和广播节目可以由最终用户手动选择接收，也可以根据内容描述和用户偏好自动选择接收。接收到的电视和广播内容可以实时显示，也可以录制以供以后使用。电视或广播节目的调度可能会发生变化，可能会影响后续节目的传输时间。IMG元数据可用于通知接收者此类更改，从而允许用户得到提示或调整录制时间。
The media coverage of a live event such as a rock concert or a sports event is a special case of regular TV/radio programming. There may be unexpected changes in the scheduling of a live event, or the event may be unscheduled to start with (such as breaking news). In addition to audio/video streams, textual information relevant to the event (e.g., statistics of the players during a football match) may be sent to user terminals. Different transport modes or even different access technologies can be used for the different media: for example, a unidirectional datacast transport could be used for the audio/video streams and an interactive cellular connection for the textual data. IMG metadata should enable terminals to discover the availability of different media used to cover a live event.
对现场活动（如摇滚音乐会或体育赛事）的媒体报道是常规电视/广播节目的特例。直播活动的日程安排可能会发生意外的变化，或者该活动的开始时间可能没有安排（如突发新闻）。除了音频/视频流之外，可以向用户终端发送与事件相关的文本信息（例如，足球比赛期间球员的统计数据）。不同的传输模式或甚至不同的接入技术可用于不同的媒体：例如，单向数据广播传输可用于音频/视频流，交互式蜂窝连接可用于文本数据。IMG元数据应使终端能够发现用于报道现场事件的不同媒体的可用性。
IMG metadata could describe compound sessions or services enabling several alternative interaction modes between the participants. For example, the combination of one-to-many media streaming, unicast messaging, and downloading of presentation material could be useful for distance learning.
IMG元数据可以描述复合会话或服务，从而实现参与者之间的多种可选交互模式。例如，一对多媒体流、单播消息和演示材料下载的组合可能对远程学习有用。
Multiplayer games are an example of real-time multiparty communication sessions that could be advertised using IMGs. A gaming session could be advertised either by a dedicated server or by the terminals of individual users. A user could use IMGs to learn of active multiplayer gaming sessions, or advertise the user's interest in establishing such a session.
多人游戏是可以使用IMG发布的实时多方通信会话的一个示例。游戏会话可以通过专用服务器或单个用户的终端进行广告。用户可以使用IMGs来了解活动的多人游戏会话，或者宣传用户对建立这样一个会话的兴趣。
IMGs support the communication of file delivery session properties, enabling the scheduled delivery or synchronization of files between a number of hosts. The received IMG metadata could be subsequently used by any application (also outside the scope of IMGs), for example, to download a file with a software update. IMG metadata can provide a description to each file in a file delivery session, assisting users or receiving software in selecting individual files for reception.
IMG支持文件传递会话属性的通信，支持在多个主机之间定时传递或同步文件。接收到的IMG元数据随后可被任何应用程序（也不在IMG范围内）使用，例如，下载带有软件更新的文件。IMG元数据可以在文件交付会话中为每个文件提供描述，帮助用户或接收软件选择要接收的单个文件。
For example, when a content provider wants to distribute a large amount of data in file format to thousands of clients, the content provider can use IMG metadata to schedule the delivery effectively.
例如，当内容提供商希望将大量文件格式的数据分发给数千个客户端时，内容提供商可以使用IMG元数据来有效地安排交付。
Since IMG metadata can describe time-related data for each receiver, the content provider can schedule delivery time for each receiver. This can save network bandwidth and delivery capacity of senders. In addition, IMG metadata can be used to consistency check, and thus synchronize, a set of files between a sender host and receiver host, when those files change as time elapses.
由于IMG元数据可以描述每个接收者的时间相关数据，因此内容提供者可以为每个接收者安排交付时间。这可以节省网络带宽和发送方的传递容量。此外，当发送主机和接收主机之间的一组文件随时间变化时，IMG元数据可用于一致性检查，从而同步这些文件。
IMG metadata can be used to describe items of content before the details of their final release are known. A user may be interested in coming content (a new movie or software title where some aspects of the content description are known in advance) and so subscribe to an information service that notifies the user of changes to metadata describing that content. Thus, as the coming release (or pre-releases, e.g., as movie trailers or software demos) become available, the IMG metadata changes and the user is notified of this change. For example, the user could see an announcement of a movie that will be released sometime in the next few months, and configure the user's terminal to receive and record any trailers or promotional material as they become available.
IMG元数据可用于在最终版本的细节已知之前描述内容项。用户可能对即将到来的内容感兴趣（内容描述的某些方面预先已知的新电影或软件标题），因此订阅信息服务，该信息服务通知用户描述该内容的元数据的更改。因此，随着即将发布的版本（或预发布，例如，电影预告片或软件演示）变得可用，IMG元数据将发生变化，并将此变化通知用户。例如，用户可以看到将在未来几个月的某个时候发布的电影的公告，并配置用户的终端以接收和记录任何可用的预告片或宣传材料。
REQ GEN-1: Carrying different kinds of IMG metadata format and different IMG metadata formats in the IMG message body MUST be allowed.
REQ GEN-1：必须允许在IMG消息体中携带不同类型的IMG元数据格式和不同的IMG元数据格式。
REQ GEN-2: Delivery mechanisms SHOULD support many different applications' specific metadata formats to keep the system interoperable with existing applications.
REQ GEN-2：交付机制应支持许多不同应用程序的特定元数据格式，以保持系统与现有应用程序的互操作性。
This provides flexibility in selecting/designing an IMG transport protocol suited to various scenarios.
这为选择/设计适合各种场景的IMG传输协议提供了灵活性。
REQ GEN-3: IMG receivers MUST be allowed to communicate with any number of IMG senders simultaneously.
REQ GEN-3：必须允许IMG接收器同时与任意数量的IMG发送器通信。
This might lead to receiving redundant IMG metadata describing the same items; however, it enables the IMG receiver access to more IMG metadata than may be available from a single IMG sender. This also provides flexibility for the IMG transport protocols and does not preclude a mechanism to solve inconsistency among IMG metadata due to multiple IMG senders. This document assumes that a typical IMG environment will involve many more IMG receivers than IMG senders and that IMG senders are continually connected for the duration of interest (rather than intermittently connected).
这可能导致接收描述相同项目的冗余IMG元数据；但是，它使IMG接收方能够访问比单个IMG发送方可用的更多的IMG元数据。这也为IMG传输协议提供了灵活性，并且不排除由于多个IMG发送者而导致IMG元数据不一致的机制。本文件假设典型的IMG环境将涉及比IMG发送者多得多的IMG接收器，并且IMG发送者在感兴趣的持续时间内持续连接（而不是间歇性连接）。
REQ GEN-4: The IMG delivery mechanisms MUST allow the combination of several IMG operations.
REQ GEN-4：IMG交付机制必须允许多个IMG操作的组合。
This is for the purpose of extending functionality (e.g., several or one protocol(s) to provide all the needed operations). Applications can select an appropriate operation set to fulfill their purpose.
这是为了扩展功能（例如，多个或一个协议以提供所有需要的操作）。应用程序可以选择适当的操作集来实现其目的。
This section describes general performance requirements based on the assumption that the range of IMG usage shall be important. However, note that requirements for delivery properties may vary based on the usage scenario, and thus some limited-use implementations place less importance on some requirements.
本节描述了基于假设IMG使用范围很重要的一般性能要求。但是，请注意，交付属性的要求可能会根据使用场景而有所不同，因此一些有限使用实现对某些要求的重视程度较低。
For example, it is clear that a multicast transport may provide more scalable delivery than a unicast transport; however, scalability requirements do not preclude the unicast transport mechanisms. In this sense, scalability is always important for the protocols irrespective of transport mechanisms.
例如，很明显，多播传输可以提供比单播传输更可伸缩的传送；然而，可伸缩性要求并不排除单播传输机制。从这个意义上讲，无论传输机制如何，可伸缩性对于协议来说总是很重要的。
REQ DEL-1: The IMG system MUST be scalable to large numbers of messages, so as to allow design and use of delivery mechanisms that will not fail in delivering up-to-date information under huge numbers of transactions and massive quantities of IMG metadata.
REQ DEL-1：IMG系统必须可扩展到大量消息，以便设计和使用交付机制，在大量事务和大量IMG元数据的情况下，不会无法交付最新信息。
REQ DEL-2: IMGs SHOULD provide a method to prevent an IMG sender from sending unnecessary IMG metadata that have been stored or deleted in IMG receivers.
REQ DEL-2:IMG应提供一种方法，防止IMG发送方发送已在IMG接收方中存储或删除的不必要的IMG元数据。
REQ DEL-3: The protocol MUST be scalable to very large audience sizes requiring IMG delivery.
REQ DEL-3：协议必须可扩展到需要IMG交付的非常大的受众规模。
REQ DEL-4: The system MUST enable IMG receivers with intermittent access to network resources (connectivity) to receive and adequately maintain sufficient IMG metadata.
REQ DEL-4：系统必须允许间歇性访问网络资源（连接）的IMG接收器接收并充分维护足够的IMG元数据。
This allows intermittent access to save power where there is no need to keep communications links powered up while they are sitting idle. For instance, in this situation, periodic bursts of notifies or a fast cycling update carousel allow hosts to wake up for short periods of time and still be kept up-to-date. This can be beneficial for IMG receivers with sporadic connections to the fixed Internet, but is critical in the battery-powered wireless Internet.
这允许在通信链路处于空闲状态时不需要保持通电的情况下进行间歇性访问以节省电源。例如，在这种情况下，周期性的突发通知或快速循环的更新转盘允许主机在短时间内醒来，并且仍然保持最新状态。这对于偶尔连接到固定互联网的IMG接收器是有益的，但在电池供电的无线互联网中是至关重要的。
The implication of intermittent connectivity is that immediate distribution of changes becomes infeasible and so managing data consistency should be focused on the timely delivery of data.
间歇性连接的含义是，立即分发更改变得不可行，因此管理数据一致性应将重点放在及时交付数据上。
REQ DEL-5: Internet-friendly congestion control MUST be provided for use on the public Internet.
REQ DEL-5：必须提供对互联网友好的拥塞控制，以便在公共互联网上使用。
REQ DEL-6: An IMG entity SHOULD invalidate the IMG metadata item when an IMG metadata item has lifetime information and its lifetime is over. This will lessen the need for notifications of updates from the IMG sender to the IMG receiver to invalidate the item and may help in reducing load.
REQ DEL-6：当IMG元数据项具有生存期信息且其生存期结束时，IMG实体应使IMG元数据项无效。这将减少IMG发送方向IMG接收方发送更新通知以使项目无效的需要，并可能有助于减少负载。
REQ DEL-7: The system MUST be flexible in choosing sender-driven, receiver-driven, or both delivery schemes.
REQ DEL-7：系统必须灵活选择发送方驱动、接收方驱动或两种交付方案。
Sender-driven delivery achieves high scalability without interaction between the IMG sender and receiver.
发送方驱动的交付在IMG发送方和接收方之间没有交互的情况下实现了高可扩展性。
In contrast, receiver-driven delivery provides on-demand delivery for IMG receivers. Since an IMG sender's complete IMG metadata may be a very large amount of data, the IMG receiver needs to be able to access the guide when convenient (e.g., when sufficient network bandwidth is available to the IMG receiver).
相反，接收器驱动的交付为IMG接收器提供按需交付。由于IMG发送者的完整IMG元数据可能是非常大量的数据，因此IMG接收器需要能够在方便时（例如，当IMG接收器有足够的网络带宽可用时）访问指南。
REQ CUS-1: The system MUST allow delivery of customized IMG metadata.
REQ CUS-1：系统必须允许交付定制的IMG元数据。
The IMG receiver may require a subset of all the IMG metadata available according to their preferences (type of content, media description, appropriate age group, etc.) and configuration.
IMG接收器可根据其偏好（内容类型、媒体描述、适当年龄组等）和配置要求所有可用IMG元数据的子集。
The IMG receiver might send its preferences in the IMG operations that can specify user-specific IMG metadata to be delivered. These preferences could consist of filtering rules. When receiving these messages, the IMG sender might respond with appropriate messages carrying a subset of IMG metadata that matches the IMG receiver's preferences.
IMG接收方可以在IMG操作中发送其首选项，该操作可以指定要交付的用户特定IMG元数据。这些首选项可以由筛选规则组成。当接收到这些消息时，IMG发送方可能会使用适当的消息进行响应，这些消息包含与IMG接收方偏好匹配的IMG元数据子集。
This mechanism can reduce the amount of IMG metadata delivered from the IMG sender to IMG receiver, and consequently it can save the resource consumption on the IMG entities and networks. It is typically useful in unicast cases and also beneficial in multicast cases where an IMG sender distributes the same IMG metadata to interested IMG receivers at the same time.
该机制可以减少从IMG发送方到IMG接收方传递的IMG元数据的数量，从而节省IMG实体和网络上的资源消耗。它通常在单播情况下有用，在IMG发送方同时向感兴趣的IMG接收方分发相同的IMG元数据的多播情况下也有用。
For multicast and unicast cases where the IMG sender does not provide customized IMG metadata, the IMG receiver could receive all IMG metadata transmitted on the channels that the IMG receiver has joined. However, it may select and filter the IMG metadata to get customized IMG metadata by its preferences, and thus drop unwanted metadata immediately upon reception.
对于IMG发送方不提供定制IMG元数据的多播和单播情况，IMG接收方可以接收在IMG接收方加入的信道上传输的所有IMG元数据。然而，它可以选择并过滤IMG元数据，以根据其偏好获得定制的IMG元数据，从而在接收到不需要的元数据时立即丢弃。
Customizing metadata might be achieved by changing the IMG descriptions sent and IMG receivers and/or changing the delivery properties (channels used).
定制元数据可以通过更改发送的IMG描述和IMG接收器和/或更改传递属性（使用的通道）来实现。
Note that customization and scalability are only somewhat exclusive. Systems providing an IMG receiver to an IMG sender request-based customization will be generally less scalable to massive IMG receiver populations than those without this return signaling technique. Thus, customization, as with any feature that affects scalability, should be carefully designed for the intended application, and it may
请注意，定制和可伸缩性只是在某种程度上具有排他性。与没有这种返回信令技术的系统相比，向IMG发送者提供基于请求的定制的IMG接收器的系统对于大规模IMG接收器群体的可伸缩性通常较低。因此，与影响可伸缩性的任何特性一样，定制应该针对预期的应用程序仔细设计，并且可能会
not be possible that a one-size-fits-all solution for customization would meet the scalability requirements for all applications and deployment cases.
一个一刀切的定制解决方案不可能满足所有应用程序和部署案例的可伸缩性要求。
IMG metadata tends to change as time elapses; as new content is added, the old IMG metadata stored in the IMG receiver becomes unavailable, and the parameters of the existing IMG metadata are changed.
IMG元数据会随着时间的推移而变化；随着新内容的添加，存储在IMG接收器中的旧IMG元数据将变得不可用，并且现有IMG元数据的参数将更改。
REQ REL-1: The system MUST manage IMG metadata consistency.
REQ REL-1：系统必须管理IMG元数据一致性。
Either the IMG sender can simply make updates available (unsynchronized), or the IMG sender and receiver can interact to keep their copies of the IMG metadata synchronized.
IMG发送方可以简单地使更新可用（不同步），或者IMG发送方和接收方可以交互以保持其IMG元数据副本的同步。
In the unsynchronized model, the IMG sender does not know whether a particular IMG receiver has an up-to-date copy of the IMG metadata.
在非同步模型中，IMG发送方不知道特定IMG接收方是否拥有IMG元数据的最新副本。
In the synchronized model, updating a cached copy of the IMG metadata is necessary to control consistency when the IMG sender or receiver could not communicate for a while. In this case, the IMG sender or receiver may need to confirm its consistency by IMG operations.
在同步模型中，当IMG发送方或接收方暂时无法通信时，需要更新IMG元数据的缓存副本以控制一致性。在这种情况下，IMG发送方或接收方可能需要通过IMG操作确认其一致性。
REQ REL-2: Since IMG metadata can change at any time, IMG receivers SHOULD be notified of such changes.
REQ REL-2：由于IMG元数据可以随时更改，因此应将此类更改通知IMG接收者。
Fulfilling this requirement needs to be compatible with the scalability requirements for the number of IMG receivers and the consistency of metadata.
满足这一要求需要与IMG接收器数量和元数据一致性的可伸缩性要求兼容。
Depending on the size of the IMG metadata, the interested party may want to defer retrieving the actual information. The change notification should be addressed to a logical user (or user group), rather than a host, since users may change devices.
根据IMG元数据的大小，相关方可能希望推迟检索实际信息。更改通知应发送给逻辑用户（或用户组），而不是主机，因为用户可能会更改设备。
Note that depending on the deployment environment and application specifics, the level of acceptable inconsistency varies. Thus, this document does not define inconsistency as specific time and state differences between IMG metadata stored in an IMG sender and IMG metadata stored in an IMG receiver.
请注意，根据部署环境和应用程序的具体情况，可接受的不一致程度会有所不同。因此，本文档未将不一致性定义为存储在IMG发送方中的IMG元数据与存储在IMG接收方中的IMG元数据之间的特定时间和状态差异。
In general, the consistency of metadata for content and media is more important immediately prior to and during the media's session(s). Hosts that forward (or otherwise resend) metadata may not tolerate
一般来说，内容和媒体元数据的一致性在媒体会话之前和会话期间更为重要。转发（或重新发送）元数据的主机可能无法容忍
inconsistencies because delivering out-of-date data is both misleading and bandwidth inefficient.
不一致，因为交付过时的数据会产生误导，而且带宽效率低下。
REQ REL-4: An IMG transport protocol MUST support reliable message exchange.
REQ REL-4：IMG传输协议必须支持可靠的消息交换。
The extent to which this could result in 100% error-free delivery to 100% of IMG receivers is a statistical characteristic of the protocols used. Usage of reliable IMG delivery mechanisms is expected to depend on the extent to which underlying networks provide reliability and, conversely, introduce errors. Note that some deployments of IMG transport protocols may not aim to provide perfect reception to all IMG receivers in all possible cases.
这可能导致100%的IMG接收机实现100%无差错传输的程度是所用协议的统计特征。可靠的IMG传递机制的使用预计将取决于底层网络提供可靠性的程度，反之，会引入错误。请注意，IMG传输协议的某些部署可能并非旨在在所有可能的情况下为所有IMG接收机提供完美的接收。
REQ DES-1: IMG metadata MUST be interoperable over any IMG transport protocol, such that an application receiving the same metadata over any one (or more) of several network connections and/or IMG transport protocols will interpret the metadata in exactly the same way. (This also relates to the 'Independence of IMG Operations from IMG Metadata' requirements.)
REQ DES-1:IMG元数据必须可通过任何IMG传输协议进行互操作，以便通过多个网络连接和/或IMG传输协议中的任何一个（或多个）接收相同元数据的应用程序将以完全相同的方式解释元数据。（这也与“IMG操作与IMG元数据的独立性”要求有关。）
REQ DES-2: IMG delivery MUST enable the carriage of any format of application-specific metadata.
REQ DES-2:IMG交付必须能够传输任何格式的应用程序特定元数据。
Thus, the system will support the description of many kinds of multimedia content, without the need for a single homogeneous metadata syntax for all uses (which would be infeasible anyway). This is essential for environments using IMG systems to support many kinds of multimedia content and to achieve wide applicability.
因此，该系统将支持多种多媒体内容的描述，而无需为所有用途使用单一的同质元数据语法（无论如何这是不可行的）。这对于使用IMG系统来支持多种多媒体内容并实现广泛适用性的环境来说至关重要。
REQ DES-3: Whereas specific applications relying on IMGs will need to select one or more specific application-specific metadata formats (standard, syntax, etc.), the IMG system MUST be independent of this (it may be aware, but it will operate in the same way for all).
REQ DES-3：尽管依赖IMG的特定应用程序需要选择一种或多种特定于应用程序的元数据格式（标准、语法等），但IMG系统必须独立于此（它可能知道，但对所有应用程序都将以相同的方式运行）。
Thus, a metadata transfer envelope format that is uniform across all different application-specific IMG metadata formats is needed. The envelope would reference (point to) or carry (as payload) some application-specific metadata, and the envelope would support the maintenance of the application-specific metadata, which may also serve the metadata relationships determined by the data model(s) used. The envelope would not need to be aware of the data model(s) in use.
因此，需要跨所有不同的应用程序特定IMG元数据格式统一的元数据传输信封格式。信封将引用（指向）或携带（作为有效载荷）一些特定于应用程序的元数据，并且信封将支持特定于应用程序的元数据的维护，该元数据还可以服务于所使用的数据模型确定的元数据关系。信封不需要知道正在使用的数据模型。
REQ DES-4: IMG metadata MUST be structured to enable fragmentation for efficient delivery.
REQ DES-4：IMG元数据的结构必须能够实现有效交付的碎片化。
This is intended to ensure that an IMG sender with more than a trivial knowledge of metadata is able to deliver only part of its (and the global) complete IMG metadata knowledge. (For instance, a trivial quantity of knowledge could be a single SDP description.) In general, the resolution of this fragmentation will be very much dependent on the optimal delivery of a deployment, although some metadata syntaxes will inherently affect the sensible lower limit for a single element/fragment.
这是为了确保一个对元数据了解不多的IMG发送者能够只提供其部分（以及全局）完整的IMG元数据知识。（例如，少量的知识可能是单个SDP描述。）一般来说，此分段的解决方案将在很大程度上取决于部署的最佳交付，尽管某些元数据语法将内在地影响单个元素/分段的合理下限。
REQ DES-5: A metadata transfer envelope MUST be defined to include essential parameters.
REQ DES-5：元数据传输信封必须定义为包含基本参数。
Examples of essential parameters are those that allow the metadata in question to be uniquely identified and updated by new versions of the same metadata.
基本参数的示例是那些允许使用相同元数据的新版本唯一标识和更新相关元数据的参数。
REQ DES-6: It SHALL be possible to deduce the metadata format via the metadata transfer envelope.
REQ DES-6：应能够通过元数据传输信封推断元数据格式。
REQ DES-7: IMG senders SHALL use a metadata transfer envelope for each IMG metadata transfer.
需求DES-7：IMG发送方应为每次IMG元数据传输使用元数据传输信封。
Thus, it will even be possible to describe relationships between syntactically dissimilar application-specific formats within the same body of IMG metadata knowledge. (For instance, a data model could be instantiated using both SDP and SDPng.)
因此，甚至可以在相同的IMG元数据知识体中描述语法上不同的应用程序特定格式之间的关系。（例如，可以同时使用SDP和SDPng实例化数据模型。）
REQ DES-8: IMG metadata SHOULD support the description of differences between an updated version and an old version of IMG metadata when the IMG delivery mechanism carries updated IMG metadata and those differences are considerably little (e.g., by providing a 'delta' of the two versions; this also relates the delivery property requirements for congestion control in Section 5.2.3).
REQ DES-8：当IMG交付机制携带更新的IMG元数据且这些差异相当小时，IMG元数据应支持描述更新版本和旧版本IMG元数据之间的差异（例如，通过提供两个版本的“增量”；这也与第5.2.3节中的拥塞控制交付属性要求有关）。
Internet Media Guides are used to convey information about multimedia resources from one or more IMG senders across one or more intermediaries to one or more IMG receivers. IMG metadata may be pushed to the IMG receivers or interactively retrieved by them. IMGs provide metadata as well as scheduling and rendezvous information about multimedia resources, and so on, and requests for IMG metadata may contain information about the requesting users.
互联网媒体指南用于将有关多媒体资源的信息从一个或多个IMG发送者通过一个或多个中介传递给一个或多个IMG接收者。IMG元数据可以被推送到IMG接收者或由他们交互地检索。IMG提供元数据以及关于多媒体资源的调度和集合信息等，对IMG元数据的请求可能包含关于请求用户的信息。
The information contained in IMG metadata as well as the operations related to IMGs should be secured to avoid forged information, misdirected users, and spoofed IMG senders, for example, and to protect user privacy.
应保护IMG元数据中包含的信息以及与IMG相关的操作，以避免伪造信息、误导用户和欺骗IMG发送者，并保护用户隐私。
The remainder of this section addresses the security requirements for IMGs.
本节其余部分介绍了IMGs的安全要求。
IMG metadata and its parts need to be protected against unauthorized alteration/addition/deletion on the way. Their originator needs to be authenticated.
需要保护IMG元数据及其部分，防止途中未经授权的更改/添加/删除。他们的发起人需要认证。
REQ AUT-1: It MUST be possible to authenticate the originator of a set of IMG metadata.
REQ AUT-1：必须能够验证一组IMG元数据的发起人。
REQ AUT-2: It MUST be possible to authenticate the originator of a subpart of IMG metadata (e.g., a delta or a subset of the information).
REQ AUT-2：必须能够验证IMG元数据子部分（例如，信息的增量或子集）的发起人。
REQ AUT-3: It MUST be possible to validate the integrity of IMG metadata.
REQ AUT-3：必须能够验证IMG元数据的完整性。
REQ AUT-4: It MUST be possible to validate the integrity of a subpart of IMG metadata (e.g., a delta or a subset of the information).
REQ AUT-4：必须能够验证IMG元数据子部分的完整性（例如，信息的增量或子集）。
REQ AUT-5: It MUST be possible to separate or combine individually authenticated pieces of IMG metadata (e.g., in an IMG transceiver) without invalidating the authentication.
REQ AUT-5：必须能够分离或组合单独认证的IMG元数据（例如，在IMG收发器中），而不会使认证无效。
REQ AUT-6: It MUST be possible to validate the integrity of an individually authenticated piece of IMG metadata even after this piece has been separated from other pieces of IMG metadata and combined with other pieces to form new IMG metadata.
REQ AUT-6：必须能够验证单独认证的IMG元数据片段的完整性，即使该片段已与其他IMG元数据片段分离并与其他片段组合以形成新的IMG元数据。
REQ AUT-7: It MUST be possible to authenticate the originator of an IMG operation.
REQ AUT-7：必须能够验证IMG操作的发起人。
REQ AUT-8: It MUST be possible to validate the integrity of any contents of an IMG operation (e.g., the subscription or inquiry information).
REQ AUT-8：必须能够验证IMG操作任何内容的完整性（例如，订阅或查询信息）。
Customized IMG metadata and IMG metadata delivered by notification to individual users may reveal information about the habits and preferences of a user and may thus deserve confidentiality protection, even though the information itself is public.
定制的IMG元数据和通过通知向单个用户交付的IMG元数据可能会泄露有关用户习惯和偏好的信息，因此可能需要保密保护，即使信息本身是公开的。
REQ PRI-1: It MUST be possible to keep user requests to subscribe to or retrieve certain (parts of) IMG metadata confidential.
REQ PRI-1：必须能够对用户订阅或检索IMG元数据的某些（部分）请求保密。
REQ PRI-2: It MUST be possible to keep IMG metadata, pieces of IMG metadata, or pointers to IMG metadata delivered to individual users or groups of users confidential.
REQ PRI-2：必须能够对交付给单个用户或用户组的IMG元数据、IMG元数据片段或指向IMG元数据的指针保密。
REQ PRI-3: It SHOULD be possible to ensure this confidentiality end-to-end, that is, to prevent intermediaries (such as IMG transceivers) from accessing the contained information.
REQ PRI-3：应能够确保端到端的保密性，即防止中介机构（如IMG收发器）访问包含的信息。
Some IMG metadata may be freely available, while access to other IMG metadata may be restricted to closed user groups (e.g., paying subscribers). Also, different parts of IMG metadata may be protected at different levels: for example, metadata describing a media session may be freely accessible, while rendezvous information to actually access the media session may require authorization.
一些IMG元数据可以免费获得，而对其他IMG元数据的访问可能仅限于封闭的用户组（例如付费订阅者）。此外，IMG元数据的不同部分可以在不同的级别受到保护：例如，描述媒体会话的元数据可以自由访问，而实际访问媒体会话的集合信息可能需要授权。
REQ ACC-1: It MUST be possible to authorize user access to IMG metadata.
REQ ACC-1：必须能够授权用户访问IMG元数据。
REQ ACC-2: It MUST be possible to authorize access of users to pieces of IMG metadata (delta information, subparts, pointers).
REQ ACC-2：必须能够授权用户访问IMG元数据（增量信息、子部分、指针）。
REQ ACC-3: It MUST be possible to require different authorization for different parts of the same IMG metadata.
REQ ACC-3：同一IMG元数据的不同部分必须能够要求不同的授权。
REQ ACC-4: It MUST be possible to access selected IMG metadata anonymously.
REQ ACC-4：必须能够匿名访问选定的IMG元数据。
REQ ACC-5: It MUST be possible for an IMG receiver to choose not to receive (parts of) IMG metadata in order to avoid being identified by the IMG sender.
REQ ACC-5：IMG接收方必须能够选择不接收（部分）IMG元数据，以避免被IMG发送方识别。
REQ ACC-6: It SHOULD be possible for an IMG transceiver to select suitable authorization methods that are compatible between both IMG senders and IMG receivers it interacts with.
REQ ACC-6：IMG收发器应能够选择与之交互的IMG发送方和IMG接收方之间兼容的适当授权方法。
REQ ACC-7: It MAY be possible for IMG senders to require certain authorization that cannot be modified by intermediaries.
REQ ACC-7：IMG发送者可能需要某些中间人无法修改的授权。
Retrieving or distributing IMG metadata may require state in the IMG senders, transceivers, and/or receivers for the respective IMG transport sessions. Attackers may create large numbers of sessions with any of the above IMG entities to disrupt regular operation.
检索或分发IMG元数据可能需要IMG发送方、收发机和/或接收方中的状态，以用于各自的IMG传输会话。攻击者可与上述任何IMG实体创建大量会话，以中断正常操作。
REQ DOS-1: IMG operations SHOULD be authenticated.
REQ DOS-1：应验证IMG操作。
REQ DOS-2: It SHOULD be possible to avoid DoS attacks that build up session state in IMG entities to exhaust their resources.
REQ DOS-2：应该可以避免在IMG实体中建立会话状态以耗尽其资源的DOS攻击。
REQ DOS-3: It SHOULD be possible to avoid DoS attacks that exhaust resources of IMG entities by flooding them with IMG metadata.
REQ DOS-3：应该可以通过使用IMG元数据来避免耗尽IMG实体资源的DOS攻击。
As an example, two potential solutions that may be considered are running an IMG entity in stateless mode or identification and discarding of malicious packets by an IMG entity.
例如，可以考虑的两个潜在解决方案是以无状态模式运行IMG实体，或者由IMG实体识别和丢弃恶意数据包。
IMG metadata disseminated by an IMG sender or an IMG transceiver may be updated, be deleted, or lose validity over time for some other reasons. Replaying outdated IMG metadata needs to be prevented.
IMG发送方或IMG收发器传播的IMG元数据可能会随着时间的推移由于某些其他原因而被更新、删除或失去有效性。需要防止重放过时的IMG元数据。
Furthermore, replay attacks may also apply to IMG operations (rather than just their payload). Replaying operations also needs to be prevented.
此外，重放攻击也可能适用于IMG操作（而不仅仅是其有效负载）。还需要防止重放操作。
REQ REP-1: IMG metadata MUST be protected against partial or full replacement of newer ("current") versions by older ones.
REQ REP-1:IMG元数据必须受到保护，以防止较新（“当前”）版本被较旧版本部分或全部替换。
In a system with multiple senders, it may not be feasible to prevent some senders from delivering older versions of metadata than others - as a result of imperfect sender-sender data consistency. Thus, replay attacks and delivery of inconsistent data require that an IMG receiver verifies that the IMG metadata is valid and reliable by using some security mechanism(s) (e.g., authorization, authentication, or integrity).
在具有多个发送者的系统中，由于发送者数据一致性不完善，阻止某些发送者传递比其他发送者旧的元数据版本可能是不可行的。因此，重播攻击和不一致数据的传递要求IMG接收方通过使用某种安全机制（例如授权、身份验证或完整性）验证IMG元数据是否有效和可靠。
REQ REP-2: Mechanisms MUST be provided to mitigate replay attacks on the IMG operations.
REQ REP-2：必须提供缓解IMG操作重播攻击的机制。
The level of threat from replay attacks varies very much depending on system scale and how well defined or open it is. Thus, mitigating replay attacks may lead to different solutions for different systems, independent of the basic delivery method and metadata definitions. A system with multiple senders presents a more challenging scenario for handling replay attacks. As an example, bundling metadata with a security mechanism is one potential solution.
重放攻击的威胁级别因系统规模和定义良好或开放程度的不同而变化很大。因此，减轻重播攻击可能会为不同的系统带来不同的解决方案，而与基本的交付方法和元数据定义无关。具有多个发送方的系统在处理重播攻击时呈现出更具挑战性的场景。例如，将元数据与安全机制绑定是一个潜在的解决方案。
[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] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[3] Handley，M.，Perkins，C.，和E.Whelan，“会话公告协议”，RFC 29742000年10月。
[4] Session Directory, ftp://ftp.ee.lbl.gov/conferencing/sd/
[4] Session Directory, ftp://ftp.ee.lbl.gov/conferencing/sd/
[5] Session Directory Tool, http://www-
mice.cs.ucl.ac.uk/multimedia/software/sdr/
[5] Session Directory Tool, http://www-
mice.cs.ucl.ac.uk/multimedia/software/sdr/
[6] Digital Video Broadcasting Project, http://www.dvb.org/
[6] Digital Video Broadcasting Project, http://www.dvb.org/
[7] Kutscher, D., Ott, J., and C. Bormann, "Session description and capability negotiation", Work in Progress, February 2005.
[7] Kutscher，D.，Ott，J.，和C.Bormann，“会话描述和能力协商”，正在进行的工作，2005年2月。
[8] 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.
[8] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[9] Nomura, Y., Walsh, R., Luoma, J-P., Asaeda, H., and H. Schulzrinne, "Framework for the Usage of Internet Media Guides (IMG)", RFC 4435, April 2006.
[9] 野村，Y.，沃尔什，R.，骆马，J-P.，Asaeda，H.，和H.Schulzrinne，“互联网媒体指南（IMG）使用框架”，RFC 44352006年4月。
[10] 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.
[10] 菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC2616，1999年6月。
[11] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[11] Roach，A.B.，“会话启动协议（SIP）-特定事件通知”，RFC3265，2002年6月。
[12] Quinn, B. and K. Almeroth, "IP Multicast Applications: Challenges and Solutions", RFC 3170, September 2001.
[12] Quinn，B.和K.Almeroth，“IP多播应用：挑战和解决方案”，RFC3170，2001年9月。
The authors would like to thank Hitoshi Asaeda, Gonzalo Camarillo, Jean-Pierre Evain, Dirk Kutscher, Petri Koskelainen, Colin Perkins, Toni Paila, and Magnus Westerlund for their excellent comments and ideas on this work.
作者要感谢Asaeda Hitoshi、Gonzalo Camarillo、Jean-Pierre Evain、Dirk Kutscher、Petri Koskelainen、Colin Perkins、Toni Paila和Magnus Westerlund对这项工作的出色评论和想法。
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
Joerg Ott Helsinki University of Technology Networking Laboratory PO Box 3000 FIN-02015 TKK Finland
赫尔辛基工业大学网络实验室PO盒3000 FIN 02015 TKK芬兰
EMail: jo@netlab.tkk.fi
EMail: jo@netlab.tkk.fi
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）提供。