[要約] RFC 4473は、インターネットメディアガイド（IMG）の要件を定めたものであり、IMGの目的は、ユーザーに対してメディアコンテンツの情報を提供することです。
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).
Copyright（c）The Internet Society（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以外のトランスポート（レガシーTVチャンネルアドレス）もサポートするという点で、説明がより精巧になっています。これは、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.
インターネットメディアガイド（IMG）には、SDP、SDPNG [7]、または同様のセッション説明形式を使用して表現されたマルチメディアセッションの説明の構造化されたコレクションがあります。これは、一連のマルチメディアサービス（テレビ番組のスケジュール、コンテンツ配信スケジュールなど）のセットを説明するために使用されますが、Webページを含む他のネットワークリソースも参照する場合があります。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メタデータをさまざまな方法で配布するためのフレームワークが必要です。マルチキャストが利用できない場合、ユニキャストベースのプッシュも必要です。
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.
さらに、Webページと同様に、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送信者になります。一部のコンテンツソースとシンクは、散発的にのみインターネットに接続される場合があります。また、単一の人間のユーザーが多くの異なるデバイスを使用してメタデータにアクセスする場合があります。したがって、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).
このドキュメントは、特に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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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メタデータ：1つ以上の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メタデータを1つ以上の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送信者と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]は、双方向輸送を使用したよく知られた情報検索プロトコルであり、多くのホストに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メタデータの更新を加入者に通知できます。ただし、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はMultiparty Multimedia Conferencesに対処するため、一般的なマルチメディアコンテンツを説明するために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 DataCastは、放送ラジオを介したIPベースのサービスの配信です。したがって、この場合、インターネットコンテンツの配信は一方向です。ただし、そのようなレシーバーに豊富なメディアを1対多数のサービスを提供できることから、大きなメリットがあります。
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つの主要なクラスがあります。固定主電源搭載とモバイルバッテリー駆動です。これらはどちらも無線現象の影響を受け、非常に堅牢な、または誤差抵抗性の配信が重要です。Carouselledメタデータ転送（固定帯域幅で周期的に繰り返される）は、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ベースの信頼性と、Metadataの逃したまたは非教師のセットの個々の検索を可能にすることです。
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」を含むオプションの信頼性レベルを含む）。インターリーブ、および可能な他のスキーム。メタデータセットの効果的な識別（おそらくユニークに）、メタデータの部分と使用中のアプリケーション固有の拡張機能に関係なく、複数のアクセスシステム上のマルチキャストとユニキャストの検索をより効率的に使用できるようにします。メタデータの優先順位付けは、チャネル間に拡散し、それに応じて帯域幅を割り当てる/分散することで（たとえば）達成できます。
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.
通常、帯域幅はブロードバンドユーザーにとって問題ではなく、クエリ応答方法の使用など、Unicast Transportは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]で詳述されている例など、さらに多くの例が関連する場合があります。IMGSには、サービスロケーションプロトコル（SLP）ベースのサービスロケーションの発見、LightWeight Directory Access Protocol（LDAP）ベースのインデックス作成サービス、Googleなどの検索エンジンなどの関連アプリケーションエリアと区別されるいくつかのユニークな機能があります。IMGに固有の機能には、以下が含まれます。
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 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.
テレビおよびラジオ番組は、エンドユーザーが手動でレセプションに選択するか、ユーザーのコンテンツの説明と好みに基づいて自動的に選択できます。受信したテレビとラジオのコンテンツは、リアルタイムで提示するか、その後の消費のために記録することができます。テレビやラジオ番組のスケジューリングに変更があり、後続のプログラムの送信時間に影響を与える可能性があります。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.
ロックコンサートやスポーツイベントなどのライブイベントのメディア報道は、通常のテレビ/ラジオ番組の特別なケースです。ライブイベントのスケジューリングに予期せぬ変更があるかもしれませんし、イベントが最初から予定されていない場合があります（Breaking Newsなど）。オーディオ/ビデオストリームに加えて、イベントに関連するテキスト情報（たとえば、サッカーの試合中のプレイヤーの統計）をユーザー端末に送信する場合があります。さまざまなトランスポートモードまたは異なるアクセステクノロジーをさまざまなメディアに使用できます。たとえば、オーディオ/ビデオストリームには一方向のデータキャストトランスポンドを使用し、テキストデータのインタラクティブなセルラー接続を使用できます。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を使用して宣伝できるリアルタイムマルチパーティ通信セッションの例です。ゲームセッションは、専用サーバーまたは個々のユーザーの端末によって宣伝できます。ユーザーはIMGを使用して、アクティブなマルチプレイヤーゲームセッションを学習したり、そのようなセッションを確立することにユーザーの関心を宣伝したりできます。
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つのプロトコル）。アプリケーションは、目的を満たすために適切な操作セットを選択できます。
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.
これにより、断続的にアクセスして、通信リンクをアイドル状態に保つ必要がない場合に電力を節約できます。たとえば、この状況では、通知の定期的なバーストまたは速いサイクリングアップデートCarouselにより、ホストは短時間目を覚まし、最新の状態に保つことができます。これは、固定インターネットへの散発的な接続を備えた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輸送プロトコルのいずれか（またはそれ以上）にわたって同じメタデータを受信するアプリケーションは、メタデータをまったく同じ方法で解釈します。。（これは、「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メタデータの古いバージョンの違いの説明をサポートする必要があり、それらの違いはかなり少ない（例えば、「デルタ」を提供することにより2つのバージョン。これは、セクション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.
インターネットメディアガイドは、マルチメディアリソースに関する情報を、1つ以上の仲介業者を介した1つ以上のIMG送信者から1つまたは複数の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メタデータに含まれる情報と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メタデータのサブパートのオリジネーター（たとえば、DeltaまたはSubset of the Subset）を認証することが可能である必要があります。
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メタデータConfidentialをサブスクライブまたは取得するためにユーザー要求を維持することが可能である必要があります。
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メタデータのさまざまな部分をさまざまなレベルで保護することができます。たとえば、メディアセッションを説明するメタデータは自由にアクセスできますが、実際にメディアセッションにアクセスするためのRendezvous情報は許可を必要とする場合があります。
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.
例として、考慮される可能性のある2つの潜在的なソリューションは、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メタデータが何らかのセキュリティメカニズム（s）（承認、認証、または整合性）を使用して有効で信頼できることを確認する必要があります。
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] 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。and 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 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.、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：SESSION INTIATION Protocol"、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.、Walsh、R.、Luoma、J-P。、Asaeda、H。、およびH. Schulzrinne、「インターネットメディアガイドの使用のためのフレームワーク（IMG）」、RFC 4435、2006年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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、 "HyperText Transfer Protocol-HTTP/1.1"、RFC 2616、1999年6月。
[11] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[11] Roach、A.B。、「セッション開始プロトコル（SIP）特異的イベント通知」、RFC 3265、2002年6月。
[12] Quinn, B. and K. Almeroth, "IP Multicast Applications: Challenges and Solutions", RFC 3170, September 2001.
[12] Quinn、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.
著者は、浅田島、ゴンザロ・カマリロ、ジャン・ピエール・イヴェイン、ダーク・クッツチャー、ペトリ・コスケレイン、コリン・パーキンス、トニ・パイラ、マグナス・ウェスターランドに、この作品に関する優れたコメントとアイデアに感謝したいと思います。
Authors' Addresses
著者のアドレス
Yuji Nomura Fujitsu Laboratories Ltd. 4-1-1 Kamikodanaka, Nakahara-ku, Kawasaki 211-8588 Japan
Yuji Nomura Fujitsu Laboratories Ltd. 4-1-1 Kamikodanaka、Nakahara-Ku、川崎211-8588日本
EMail: nom@flab.fujitsu.co.jp
Rod Walsh Nokia Research Center P.O. Box 100, FIN-33721 Tampere Finland
ロッドウォルシュノキアリサーチセンターP.O.ボックス100、フィン-33721タンペレフィンランド
EMail: rod.walsh@nokia.com
Juha-Pekka Luoma Nokia Research Center P.O. Box 100, FIN-33721 Tampere Finland
Juha-Pekka Luoma Nokia Research Center P.O.ボックス100、フィン-33721タンペレフィンランド
EMail: juha-pekka.luoma@nokia.com
Joerg Ott Helsinki University of Technology Networking Laboratory PO Box 3000 FIN-02015 TKK Finland
Joerg Ott Helsinki工科大学ネットワーキング研究所PO Box 3000 FIN-02015 TKKフィンランド
EMail: jo@netlab.tkk.fi
Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA
コンピューターサイエンスコロンビア大学のヘニングシュルツリン部1214アムステルダムアベニューニューヨーク、ニューヨーク10027 USA
EMail: schulzrinne@cs.columbia.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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）によって提供されます。