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)
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
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.
いくつかの10年の間、マルチキャストベース（マルチメディア）（IETFワーキンググループセッションを含む）の会議だけでなく、講演会/セミナー、コンサート、その他のイベントの放送はMBONEに、より正確には、インターネットで使用されています。スケジュール及び記述、マルチメディアセッションのためだけでなく、トランスポート・アドレス、コーデック、およびそれらのパラメータは、セッション記述プロトコル（SDP）を使用して記載されている[2]基本的なとして（しかし、その後のような大部分十分）を意味します。記述は、セッションアナウンスメントプロトコル（SAP）を使用して、播種されている[3]や、SDなどのセッションディレクトリツール[4]又はSDR [5]。説明はまた、電子メールで送信され、Webページ上などに設置されています
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（デジタルビデオ放送）も、テレビ放送、さらにサービスの基礎としてIPを考慮し、衛星、ケーブル、および地上無線ネットワーク上でIPベースの通信に向かって[6]組織の増加活動とうまくピア。プログラム/コンテンツの記述は、インターネットメディアガイド（IMGS）と呼ばれ、電子番組ガイド（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.
インターネットメディアガイド（IMG）は、マルチメディアセッション記述の構造化されたコレクションは、SDP、SDPng [7]、またはいくつかの同様のセッション記述形式を用いて表現しています。これは、マルチメディアサービス（例えば、テレビ番組スケジュール、コンテンツ配信スケジュール）のセットを記述するために使用されるだけでなく、Webページを含む他のネットワークリソースを参照することができます。 IMGSは、バージョニングを構造化を容易に参照し、配布、及び（キャッシング、更新）このような情報を維持する目的で他の場所で定義されたメタデータフォーマットおよびセッション記述のためのエンベロープを提供します。
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メタデータのマルチキャストベース（プッシュ）分布をサポートする必要があります。マルチキャストが利用できない場合は、ユニキャストベースのプッシュも必要です。
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メタデータは、（システムを再起動するか、ネットワーク接続が再確立された後にユーザが閲覧しているときの後、例えば）ウェブページと同様に、対話形式で検索する必要があるかもしれません。例えば、コンサートやスポーツイベントなどのイベントの放送時間が変更される可能性があり、おそらく後続のメディアの放送時間に影響を与える：ガイドで説明した内容が変更される可能性があるため、最終的に、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送信者であることができます。コンテンツソースとシンクの中には、散発的にしかインターネットに接続することができます。また、シングル人間のユーザは、メタデータにアクセスするために多くの異なるデバイスを使用することができます。したがって、我々は、他の人、携帯電話、携帯情報端末（PDA）、パソコン、ビデオストリーミングサーバ、セットトップボックス、ビデオカメラ、デジタルビデオレコーダ（DVR）の中で、IMGメタデータが送信され、受信することができることを想像しますそのデータは、帯域幅に制約のあるモバイルネットワークを含むリンク層の任意のタイプ、横切って運ばれます。しかし、一般的に我々は、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メタデータは、送信側（S）からへの途中で、等、改変、増強、濾過し、分割、合成する必要があるかもしれません彼女の好み、サブスクリプション、位置、およびコンテキスト（例えば、デバイス、アクセス・ネットワーク）に応じてマルチメディアサービスを適切に選択して究極ユーザに提供する受信機（複数可）。
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メタデータを提供するために満たさなければならない要件を定義します。 IMGSは、マルチメディアコンテンツの多くの種類を記述することができるので、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.
幅広い適用性を検討するには、この文書では、問題文を提供し、この分野での既存のメカニズムについて説明します。その後IMGSのためのいくつかのユースケースシナリオは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).
この文書は、特にMMUSICワーキンググループ（SAP、SIP [8]、SDP）の分野において、IMGSの送達メカニズムに関する作業を調査し、セッション告知及び開始プロトコルに作業を一般反映します。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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送信者（S）/レシーバ（S）の制御のためにIMG送信者（S）と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のセンダおよび1つまたは複数の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.
私たちはIMGSの要件を列挙したように、彼らは完全に既存のプロトコルによって対処されていないことが明らかになります。 「インターネットメディアガイドの利用のためのフレームワークは、」[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]は、双方向トランスポートを使用して、周知の情報検索プロトコルであり、広く多くのホストにウェブベースのコンテンツ記述を送達するために使用されます。それは、サーバとクライアントの間で一貫性のある情報を保持するためにポーリングメカニズムに依存しているので、しかし、それは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メタデータの更新を加入者に通知するために使用することができます。しかし、IMGSのためのイベントパッケージを定義する必要があります。
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は、マルチパーティマルチメディア会議に対処するため、一般的なマルチメディアコンテンツを記述するために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.
固定電源から電力を供給し、モバイルバッテリ駆動：このユースケースでは受信機の2つの主なクラスがあります。これらの両方は、ラジオ現象の影響を受けているので、堅牢、またはエラー・弾力、配信が重要です。カルーセル転送の設計の間、それらの動作時間を延長するために、睡眠の周期を通過する電池式受信機を有効にするべきである（周期的固定帯域を用いて繰り返し）カルーセルメタデータ転送は、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メタデータによって記述されたファイル転送など）は、特にアクティブ・アプリケーション・セッション中に、より少ない可能です。彼らはまた、ユーザが接続されている時間のために支払う、または信頼性の低い交換を通じて接続されている場合は特に、断続的にすることができます。したがって、これは、まれに、Webベースのブラウザ上でメタデータの変更の特にどこの部分をローカルに保存されているIMGメタデータを優先する。そこラストマイルダイヤルアップ接続の制限、ユーザごとの渋滞等のユーザの中小番号のユニキャストおよびマルチキャストトランスポートを介して何のサービスプロバイダ優先しなくてもよい、かつ信頼性の高いマルチキャストが提供されない限り、ユーザは、より信頼性の高いオプション（ユニキャストを好むかもしれません）。
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のメタデータを取得することを強制することができます。
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]に詳述されたもの、例えば、関連する可能性があります。こうしたサービスロケーションプロトコル（SLP）ベースのサービスの場所の発見、LDAP（Lightweight Directory Access Protocol）をベースのインデックスサービス、Googleなどの検索エンジンなどの関連アプリケーション分野は一線を画すIMGSのいくつかのユニークな特徴があります。 IMGSにユニークな特長は次のとおりです。
o IMG metadata is generally time-related
O IMGメタデータは、一般的に、時間関連のあります
o There are timeliness requirements in the delivery of IMG metadata
Oイメージメタデータの配信における適時性の要件があります。
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 similar to that of a TV guide in newspapers, or an Electronic Program Guide available on digital TV receivers.
オーディオ/ビデオストリーミングコンテンツの送信者は、それらのプログラムの中にスケジューリングや、個々のテレビやラジオ番組やセグメントとそれらのセッション内のオーディオ/ビデオセッションやイベントの他の特性を記述するためにIMGメタデータを使用することができます。オーディオ/ビデオストリーミングコンテンツを記述したIMGメタデータは、デジタルテレビ受信機で利用可能な新聞のテレビガイド、または電子番組ガイドと同様の形式で表すことができます。
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.
TVおよびラジオ番組は、コンテンツの記述とユーザの嗜好に基づいて自動的にエンドユーザによって手動受信のために選択され、またはすることができます。受信したTVやラジオコンテンツは、いずれかをリアルタイムで提示以降の消費のために記録することができます。おそらく、その後のプログラムの送信時間に影響を与え、テレビやラジオ番組のスケジュールの変更があるかもしれません。 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.
そのようなロックコンサートやスポーツイベントなどのライブイベントのメディアの報道は、通常のTV /ラジオ番組の特別な場合です。そこライブイベントのスケジューリングで予期しない変更であってもよいし、またはイベントは、（ニュース速報など）で開始する予定外することができます。イベントに関連するオーディオ/ビデオ・ストリーム、テキスト情報に加えて（例えば、サッカーの試合中の選手の統計）がユーザ端末に送信することができます。異なる輸送モード、あるいは異なるアクセス技術は、異なるメディアに使用することができます。たとえば、一方向のデータキャスト・トランスポートは、オーディオ/ビデオストリームおよびテキストデータのための対話型のセルラー接続を使用することができます。 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メタデータは、参加者の間でいくつかの代替対話モードを有効にする化合物のセッションまたはサービスを記述することができます。例えば、1対多のメディアストリーミング、ユニキャスト・メッセージング、およびプレゼンテーション資料のダウンロードの組み合わせは、遠隔学習のために有用である可能性があります。
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.
マルチプレイヤーゲームはIMGSを使って宣伝することができ、リアルタイムのマルチパーティ通信セッションの一例です。ゲームセッションは、専用サーバーまたは個々のユーザの端末のいずれかによって宣伝することができます。ユーザーがアクティブなマルチプレーヤゲームセッションを知る、あるいは、そのようなセッションを確立する上でのユーザーの関心を宣伝するために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.
IMGSは、ホストの数との間のファイルの納品予定や同期を有効にすると、ファイル配信セッションプロパティの通信をサポートします。受信されたIMGメタデータは、その後、ソフトウェアアップデートを使用してファイルをダウンロードするために、例えば、（またIMGSの範囲外の）任意のアプリケーションによって使用することができます。 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.
これは、（すべての必要な操作を提供するために、例えば、いくつかのまたは1つのプロトコル（S））の機能を拡張するためのものです。アプリケーションは、その目的を達成するために設定し、適切な操作を選択することができます。
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：IMGSは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 not be possible that a one-size-fits-all solution for customization would meet the scalability requirements for all applications and deployment cases.
カスタマイズと拡張性が幾分排他的であることに注意してください。 IMG送信者要求ベースのカスタマイズにIMG受信機を提供するシステムは、このリターンシグナリング技術なしのものよりも大量のIMG受信集団に一般にあまりスケーラブルであろう。このように、カスタマイズは、拡張性に影響を与える機能と同じように、慎重に意図された用途のために設計されなければならない、とカスタマイズのための万能ソリューションは、すべてのアプリケーションおよび展開例のためのスケーラビリティ要件を満たすであろうと、それができない場合があります。
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.
このIMG受信機の100％〜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トランスポートプロトコルのいずれか1つ（または複数）上に同じメタデータを受信するアプリケーションは、まったく同じ方法でメタデータを解釈するよう。 （これはまた、要求「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：IMGSに依存する特定のアプリケーションは、1つまたは複数の特定のアプリケーション固有のメタデータ・フォーマット（標準、構文など）を選択する必要があります一方、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.
REQ 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受信機への1人のまたは複数の仲介者間で一つ以上のIMGの送信者からのマルチメディアリソースに関する情報を伝えるために使用されています。 IMGメタデータは、IMG受信機にプッシュまたは対話的にそれらによって取得できます。 IMGSは、マルチメディアリソースに関するメタデータだけでなく、スケジューリングとランデブー情報を提供する、というように、と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メタデータだけでなく、IMGSに関連する業務に含まれる情報は、例えば偽造情報、見当違いのユーザー、および偽装された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 ACCOUNT-4：それは匿名で選択した画像のメタデータにアクセスすることは可能でなければなりません。
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：これは、DoS攻撃は、IMGメタデータとそれらをあふれさせることにより、IMG実体の排気リソースを攻撃を避けることが可能であるべきです。
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つの潜在的解決策です。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[2]ハンドレー、M.およびV. Jacobsonの "SDP：セッション記述プロトコル"、RFC 2327、1998年4月。
[3] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[3]ハンドレー、M.、パーキンス、C.、およびE.ウィーラン、 "セッション告知プロトコル"、RFC 2974、2000年10月。
[4] Session Directory, ftp://ftp.ee.lbl.gov/conferencing/sd/
[4]セッションディレクトリ、ftp://ftp.ee.lbl.gov/conferencing/sd/
[5] Session Directory Tool, http://www-mice.cs.ucl.ac.uk/multimedia/software/sdr/
[5]セッションディレクトリツール、http://www-mice.cs.ucl.ac.uk/multimedia/software/sdr/
[6] Digital Video Broadcasting Project, http://www.dvb.org/
[6]デジタルビデオ放送プロジェクト、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.、オット、J.、およびC.ボルマン、 "セッション記述と能力交渉"、進歩、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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "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.、Luoma、J-P。、Asaeda、H.、およびH. Schulzrinneと、RFC 4435、2006年4月 "インターネットメディアガイド（IMG）の使用のための枠組み"。
[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.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。
[11] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[11]ローチ、A.B.、 "セッション開始プロトコル（SIP）特異的イベント通知"、RFC 3265、2002年6月。
[12] Quinn, B. and K. Almeroth, "IP Multicast Applications: Challenges and Solutions", RFC 3170, September 2001.
[12]クイン、B.およびK. Almeroth、 "IPマルチキャストアプリケーション：課題と解決策"、RFC 3170、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、ゴンサロ・カマリロ、ジャン=ピエール・Evain、ディルクKutscher、ペトリKoskelainen、コリンパーキンス、トニーPaila、およびマグヌスウェスターに感謝したいと思います。
Authors' Addresses
著者のアドレス
Yuji Nomura Fujitsu Laboratories Ltd. 4-1-1 Kamikodanaka, Nakahara-ku, Kawasaki 211-8588 Japan
ゆじ のむら ふじつ ぁぼらとりえｓ Ｌｔｄ。 ４ー１ー１ かみこだなか、 なかはらーく、 かわさき ２１１ー８５８８ じゃぱん
EMail: nom@flab.fujitsu.co.jp
メールアドレス：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
メールアドレス：rod.walsh@nokia.com
Juha-Pekka Luoma Nokia Research Center P.O. Box 100, FIN-33721 Tampere Finland
ユハ・ペッカLuomaノキア・リサーチセンター私書箱ボックス100、FIN-33721タンペレフィンランド
EMail: juha-pekka.luoma@nokia.com
メールアドレス：juha-pekka.luoma@nokia.com
Joerg Ott Helsinki University of Technology Networking Laboratory PO Box 3000 FIN-02015 TKK Finland
イェルク・オットヘルシンキ工科大学のネットワーキング研究所私書箱3000 FIN-02015 TKKフィンランド
EMail: jo@netlab.tkk.fi
メールアドレス：jo@netlab.tkk.fi
Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA
コンピュータサイエンスコロンビア大学1214アムステルダムAvenueニューヨークのヘニングSchulzrinneと部長、NY 10027 USA
EMail: schulzrinne@cs.columbia.edu
メールアドレス：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。