Network Working Group Y. Nomura
Request for Comments: 4435 Fujitsu Labs.
Category: Informational R. Walsh
J-P. Luoma
Nokia
H. Asaeda
Keio University
H. Schulzrinne
Columbia University
April 2006
A Framework for the Usage of Internet Media Guides (IMGs)
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This document defines a framework for the delivery of Internet Media Guides (IMGs). An IMG is a structured collection of multimedia session descriptions expressed using the Session Description Protocol (SDP), SDPng, or some similar session description format. This document describes a generalized model for IMG delivery mechanisms, the use of existing protocols, and the need for additional work to create an IMG delivery infrastructure.
このドキュメントはインターネットメディアガイド（IMGS）を送達するためのフレームワークを定義します。 IMGは、マルチメディアセッション記述の構造化されたコレクションは、セッション記述プロトコル（SDP）、SDPng、またはいくつかの同様のセッション記述形式を使用して発現されます。この文書では、IMGの配信メカニズムのための一般化モデル、既存のプロトコルの使用、およびIMG配信インフラストラクチャを作成するための追加作業の必要性を説明しています。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................3
2.1. New Terms ..................................................4
3. IMG Common Framework Model ......................................5
3.1. IMG Data Types .............................................5
3.1.1. Complete IMG Description ............................5
3.1.2. Delta IMG Description ...............................6
3.1.3. IMG Pointer .........................................6
3.2. IMG Entities ...............................................6
3.3. Operation Set for IMG Delivery .............................7
3.3.1. IMG ANNOUNCE ........................................7
3.3.2. IMG QUERY ...........................................8
3.3.3. IMG RESOLVE .........................................8
3.3.4. IMG SUBSCRIBE .......................................8
3.3.5. IMG NOTIFY ..........................................9
3.3.6. Binding between IMG Operations and Data Types .......9
3.4. Overview of Protocol Operations ...........................10
4. Deployment Scenarios for IMG Entities ..........................10
4.1. Intermediary Cases ........................................10
4.2. One-to-Many Unidirectional Multicast ......................12
4.3. One-to-One Bidirectional Unicast ..........................12
4.4. Combined Operations with Common Metadata ..................13
5. Applicability of Existing Protocols to the Proposed
Framework Model ................................................14
5.1. Existing Standard Fitting the IMG Framework Model .........14
5.2. IMG Mechanism Needs Which Are Not Met by Existing
Standards .................................................15
5.2.1. A Multicast Transport Protocol .....................16
5.2.2. Usage of Unicast Transport Protocols ...............16
5.2.3. IMG Envelope .......................................17
5.2.4. Metadata Data Model ................................18
6. Security Considerations ........................................18
7. Normative References ...........................................19
8. Informative References .........................................19
9. Acknowledgements ...............................................20
Internet Media Guides (IMGs) provide and deliver structured collections of multimedia descriptions expressed using SDP [2], SDPng [3], or other description formats. They are used to describe sets of multimedia services (e.g., television program schedules, content delivery schedules) and refer to other networked resources including web pages. IMGs provide an envelope for metadata formats and session descriptions defined elsewhere with the aim of facilitating structuring, versioning, referencing, distributing, and maintaining (caching, updating) such information.
インターネットメディアガイド（IMGS）マルチメディア記述の構造化されたコレクションを提供し、送達は、SDPを用いて表現[2]、SDPng [3]、又は他の記述形式。彼らは、マルチメディアサービス（例えば、テレビ番組スケジュール、コンテンツ配信スケジュール）のセットを記述し、Webページを含む他のネットワークリソースを参照するために使用されています。 IMGSは、バージョニングを構造化を容易に参照し、配布、及び（キャッシング、更新）このような情報を維持する目的で他の場所で定義されたメタデータフォーマットおよびセッション記述のためのエンベロープを提供します。
IMG metadata may be delivered to a potentially large audience, which uses it to join a subset of the sessions described and which may need to be notified of changes to the IMG metadata. Hence, a framework for distributing IMG metadata in various different ways is needed to accommodate the needs of different audiences: For traditional broadcast-style scenarios, multicast-based (push) distribution of IMG metadata needs to be supported. Where no multicast is available, unicast-based push is required.
IMGメタデータは、説明のセッションのサブセットに参加すると、IMGメタデータへの変更を通知する必要があるかもしれないそれを使用して、潜在的に多数の視聴者に配信することができます。したがって、様々な異なる方法でIMGメタデータを配信するためのフレームワークは、異なる視聴者のニーズに対応するために必要とされる：従来の放送形式のシナリオでは、IMGメタデータのマルチキャストベース（プッシュ）分布をサポートする必要があります。マルチキャストが利用できない場合は、ユニキャストベースのプッシュが必要です。
This document defines a common framework model for IMG delivery mechanisms and their deployment in network entities. There are three fundamental components in the IMG framework model: data types, operation sets, and entities. These components specify a set of framework guidelines for efficient delivery and description of IMG metadata. The data types give generalized means to deliver and manage the consistency of application-specific IMG metadata. IMG operations cover broadcast, multicast distribution, event notification upon change, unicast-based push, and interactive retrievals similar to web pages.
この文書では、IMGの配信メカニズムとネットワーク・エンティティでの展開のための共通のフレームワークモデルを定義します。データ型、操作セット、およびエンティティ：IMGフレームワークモデルの3つの基本コンポーネントがあります。これらのコンポーネントは、IMGメタデータの効率的な送達および説明のためのフレームワークのガイドラインのセットを指定します。データ型は、アプリケーション固有のIMGメタデータの一貫性を提供し、管理するための一般的な手段を与えます。 IMG操作は、ブロードキャスト、マルチキャスト配信、変更時にイベント通知、ユニキャストベースのプッシュ、およびWebページに似た対話的な回収のをカバーしています。
Since we envision that any Internet host can be a sender and receiver of IMG metadata, a host involved in IMG operations performs one or more of the roles defined as the entities in the IMG framework model. The requirements for IMG delivery mechanisms and descriptions can be found in the IMG requirements document [4].
我々は、任意のインターネットホストはIMGメタデータの送信側と受信側とすることができることを想定しているので、IMG操作に関与する宿主は、IMGフレームワークモデル内のエンティティとして定義された役割の一つ以上を実行します。 IMGの送達機構および説明のための要件は、IMG要件文書に見出すことができる[4]。
This document outlines the use of existing protocols to create an IMG delivery infrastructure. It aims to organize existing protocols into a common model and show their capabilities and limitations from the viewpoint of IMG delivery functions.
この文書では、IMG配信インフラストラクチャを作成するために、既存のプロトコルの使用を概説します。これは、一般的なモデルに既存のプロトコルを整理し、IMG配信機能の観点から、彼らの能力と限界を表示することを目指しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[1]。
Internet Media Guide (IMG): IMG is a generic term to describe the formation, delivery, and use of IMG metadata. The definition of the IMG is intentionally left imprecise [4].
インターネットメディアガイド（IMG）：IMGが形成、配信、およびIMGメタデータの使用を記述するための一般的な用語です。 IMGの定義は意図的に不正確に残されている[4]。
IMG Element: The smallest atomic element of metadata that can be transmitted separately by IMG operations and referenced individually from other IMG elements [4].
IMG要素：IMG操作で別々に送信され、他のIMG要素[4]から個別に参照することができるメタデータの最小原子素子。
IMG Metadata: A set of metadata consisting of one or more IMG elements. IMG metadata describes the features of multimedia content used to enable selection of and access to media sessions containing content. For example, metadata may consist of a media object's URI, title, airtime, bandwidth needed, file size, text summary, genre, and access restrictions [4].
IMGメタデータ：一つ以上のIMG元素からなるメタデータのセット。 IMGメタデータを選択し、コンテンツを含むメディア・セッションへのアクセスを可能にするために使用されるマルチメディアコンテンツの機能について説明します。例えば、メタデータは、メディアオブジェクトのURI、タイトル、放送時間、必要な帯域幅、ファイルサイズ、テキスト要約、ジャンル、およびアクセス制限で構成することができる[4]。
IMG Description: A collection of IMG metadata with a data type indicating a self-contained set or a subset of IMG metadata, or a reference to IMG metadata.
IMG説明：自己完結型のセットまたはIMGメタデータのサブセット、またはIMGメタデータへの参照を示すデータ型を持つIMGメタデータのコレクション。
IMG Delivery: The process of exchanging IMG metadata both in terms of large-scale and atomic data transfers [4].
IMG配信：大規模の用語および原子データ転送の両方IMGメタデータを交換する工程[4]。
IMG Sender: An IMG sender is a logical entity that sends IMG metadata to one or more IMG receivers [4].
IMG送信者：IMG送付者は、1つの以上のIMG受信機にIMGメタデータを送信する論理エンティティである[4]。
IMG Receiver: An IMG receiver is a logical entity that receives IMG metadata from an IMG sender [4].
IMG受信機：IMG受信機は、[4] 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 a several different IMG senders [4].
IMGトランシーバ：IMGトランシーバは、IMG受信機と送信者を兼ね備えています。これは、[4]受信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) [4].
IMG操作：IMGトランスポートプロトコルのアトミック操作、IMGメタデータの配信のためとIMG送信者（S）/レシーバ（S）の制御のためにIMG送信者（S）とIMG受信機（複数可）との間で使用される[4]。
IMG Transport Protocol: A protocol that transports IMG metadata from an IMG sender to IMG receiver(s) [4].
IMGトランスポートプロトコル：IMG受信機（複数可）にIMG送付者からIMGメタデータを搬送するプロトコル[4]。
IMG Transport Session: An association between an IMG sender and one or more IMG receivers within the scope of an IMG transport protocol. An IMG transport session involves a time-bound series of IMG transport protocol interactions that provide delivery of IMG metadata from the IMG sender to the IMG receiver(s) [4].
IMGトランスポートセッション：IMGトランスポートプロトコルの範囲内でIMGのセンダおよび1つまたは複数のIMG受信機との間の関連付け。 IMG輸送セッションはIMG受信機（複数可）にIMG送付者からIMGメタデータの送達を提供IMGトランスポートプロトコル相互作用の時系列結合を含む[4]。
IMG Transfer: A transfer of IMG metadata from an IMG sender to IMG receiver(s).
IMG転送：IMG受信機（複数可）への画像の送信者からの画像メタデータの転送。
Two common elements are found in all existing IMG candidate cases: the need to describe the services and the need to deliver the descriptions. In some cases, the descriptions provide multicast addresses and thus are part of the transport configuration. In other cases, descriptions are specific to the media application and may be meant for either human or machine consumption. Thus, the technologies can be roughly divided into three areas:
サービスを記述する必要があると説明を提供する必要性：二つの共通の要素は、既存のすべてのIMG候補例に記載されています。いくつかのケースでは、記述は、マルチキャストアドレスを提供し、従って輸送構成の一部です。他の場合には、記述は、メディアアプリケーションに固有のものであり、いずれかの人間または機械の消費のために意図されてもよいです。したがって、技術は、大きく3つの領域に分割することができます。
o Application-specific Metadata: data describing the content of services and media which are both specific to certain applications and generally human readable.
Oアプリケーション固有のメタデータ：特定のアプリケーションに固有の、一般的人間可読の両方であるサービスおよびメディアのコンテンツを記述するデータ。
o Delivery Descriptions: the descriptions (metadata) that are essential to enable (e.g., multicast) delivery. These include framing (headers) for application-specific metadata, the metadata element identification and structure, and fundamental session data.
O配信説明：（例えば、マルチキャスト）の送達を可能にするのに不可欠である記述（メタデータ）。これらは、アプリケーション固有のメタデータ、メタデータ要素の識別および構造、および基本的なセッションデータのフレーミング（ヘッダ）が挙げられます。
o Delivery Protocols: the methods and protocols to exchange descriptions between the senders and the receivers. An IMG transport protocol consists of two functions: carrying IMG metadata from an IMG sender to an IMG receiver and controlling an IMG transport protocol. These functions are not always exclusive; therefore, some messages may combine control messages and metadata carriage functions to reduce the amount of the messaging.
O配信プロトコル：送信側と受信側の間の記述を交換するための方法およびプロトコル。 IMGトランスポートプロトコルは、2つの機能からなる：IMG受信機にIMG送付者からIMGメタデータを搬送し、IMGトランスポートプロトコルを制御します。これらの機能は、常に排他的ではありません。そのため、一部のメッセージは、メッセージの量を減らすために、制御メッセージとメタデータのキャリッジの機能を組み合わせることができます。
A data model is needed to precisely define the terminology and relationships between sets, supersets, and subsets of metadata. A precise data model is essential for the implementation of IMGs, although it is not within the scope of this framework and requires a separate specification. However, there are three IMG data types in general: Complete IMG Descriptions, Delta IMG Descriptions, and IMG Pointers.
データモデルは正確セット、スーパーセット、およびメタデータのサブセットとの間の用語との関係を定義するために必要とされます。それは、この枠組みの範囲内ではなく、別々の仕様を必要とするが、正確なデータモデルは、IMGSの実装のために必須です。完全IMGの説明、デルタIMGの説明、およびIMGポインタ：しかし、一般的には3つのIMGデータタイプがあります。
A Complete IMG Description provides a self-contained set of metadata for one media object or service, i.e., it does not need additional information from any other IMG element. This is not to be confused with "complete IMG metadata", which, although vaguely defined here, represents the complete IMG metadata database of an IMG sender (or related group of IMG senders -- potentially the complete Internet IMG knowledge). An IMG sender will generally deliver only subsets of metadata from its complete database in a particular IMG transport session.
完全IMG説明、すなわち、それは他のIMG要素から追加情報を必要としない、あるメディア・オブジェクトまたはサービスのメタデータの自己完結型のセットを提供します。これは、漠然とここで定義されているが、「完全IMGメタデータ」と混同されるべきではなく、IMG送信者の完全なIMGメタデータ・データベース（ - 潜在的に完全なインターネットIMG知識またはIMGの送信者の関連する基）を表します。 IMGの送信者は、一般的に、特定のIMG輸送セッションでその完全なデータベースからのメタデータのサブセットのみをお届けします。
A Delta IMG Description provides only part of a Complete IMG Description, defining the difference from a previous version of the Complete IMG Description. Delta IMG Descriptions may be used to reduce network resource usage, for instance, when data consistency is essential and small and frequent changes occur to IMG elements. Thus, this description does not represent a complete set of metadata until it is combined with other metadata that may already exist or arrive in the future.
デルタIMG説明完了IMG説明の以前のバージョンとの差を規定する、完全IMG説明の一部のみを提供します。デルタIMGの説明は、データの整合性が不可欠と小さく、頻繁な変更がIMG要素に発生した場合、例えば、ネットワークリソースの使用を低減するために使用されてもよいです。それが既に存在するまたは将来到着する他のメタデータと組み合わされるまで、このように、この説明は、メタデータの完全なセットを表すものではありません。
An IMG Pointer identifies or locates metadata. This may be used to separately obtain metadata (Complete or Delta IMG Descriptions) or perform another IMG management function such as data expiry (and erasure). The IMG Pointer may be used to reference IMG metadata elements within the IMG transport session and across IMG transport sessions. This pointer type does not include IMG metadata per se (although it may also appear as a data field in Complete or Delta IMG Descriptions).
IMGのポインタを識別またはメタデータを検索します。これは、別々のメタデータ（完全またはデルタIMG記述）を得るか、そのようなデータの有効期限（消去）等の他のIMGの管理機能を実行するために使用されてもよいです。 IMGポインタIMG輸送セッション内およびIMG輸送セッション間IMGメタデータ要素を参照するために使用することができます。このポインタ型は、IMGメタデータ自体を（それはまた、完全またはデルタIMG記述データフィールドとして表示されるかもしれないが）含まれていません。
There are several fundamental IMG entities that indicate the capability to perform certain roles. An Internet host involved in IMG operations may adopt one or more of these roles, which are defined in more detail in Section 3.3.
特定の役割を実行する能力を示すいくつかの基本的なIMG実体があります。 IMG操作に関与するインターネットホストは、3.3節でより詳細に定義されているこれらの役割の一つ以上を採用することができます。
IMG Announcer: sends IMG ANNOUNCE
IMGアナウンサーは：IMGはANNOUNCE送信します
IMG Listener: receives IMG ANNOUNCE
IMGリスナー：IMGはANNOUNCE受け取ります
IMG Querier: sends IMG QUERY and receives IMG RESOLVE
IMGクエリア：IMG QUERYを送信し、IMGのRESOLVEを受け取ります
IMG Resolver: receives IMG QUERY then sends IMG RESOLVE
IMGリゾルバは：IMG QUERYは、その後のIMG RESOLVEを送り受け取ります
IMG Subscriber: sends IMG SUBSCRIBE then receives IMG NOTIFY
IMGの加入者は：IMG NOTIFYを受け、その後IMG SUBSCRIBEを送信します
IMG Notifier: receives IMG SUBSCRIBE then sends IMG NOTIFY
IMG Notifierは：IMG NOTIFYを送信し、その後IMG SUBSCRIBEを受けます
Figure 1 shows the relationship between IMG entities and the IMG sender and receiver.
図1は、IMGエンティティとIMGの送信者と受信者との関係を示しています。
+--------------------------------------------------------+
| IMG Sender |
+------------------+------------------+------------------+
| IMG Announcer | IMG Notifier | IMG Resolver |
+------------------+------------------+------------------+
| ^ ^
message | | |
direction v v v
+------------------+------------------+------------------+
| IMG Listener | IMG Subscriber | IMG Querier |
+------------------+------------------+------------------+
| IMG Receiver |
+------------------+------------------+------------------+
Figure 1: Relationship between IMG Entities, Senders, and Receivers
図1：IMGエンティティ、送信者、およびレシーバとの関係
A finite set of operations both meets the IMG requirements [4] and fits the roles of existing protocols. These are crystallized in the next few sections.
操作の有限集合は、両方の[4] IMG要件を満たし、既存のプロトコルの役割に適合する。これらは、次のいくつかのセクションで結晶化されています。
When an IMG receiver participates in unidirectional communications (e.g., over satellite, terrestrial radio, and wired multicast networks), an IMG receiver may not need to send any IMG message to an IMG sender prior to IMG metadata delivery. In this case, an IMG sender can initiate unsolicited distribution for IMG metadata and an IMG sender is the only entity that can maintain the distribution (this includes scenarios with multiple and cooperative IMG senders). This operation is useful when there are large numbers of IMG receivers or the IMG receivers do not have a guaranteed uplink connection to the IMG sender. The IMG sender may also include authentication data in the ANNOUNCE operation so that IMG receivers may check the authenticity of the metadata. This operation can carry any of the IMG data types.
IMG受信機が単方向通信に参加する場合（例えば、衛星、地上無線、有線マルチキャストネットワーク上）、IMG受信機はIMGメタデータの配信に先立ってIMGの送信者に任意IMGメッセージを送信する必要はないかもしれません。この場合には、IMG送付者はIMGメタデータとIMGの送信者の迷惑配信を開始することができる（これは複数の協調IMGの送信者とのシナリオを含む）分布を維持することができる唯一のエンティティです。 IMGの送信者に保証されたアップリンク接続していないIMG受信機やIMG受信機が多数ある場合は、この操作は有効です。 IMG受信機は、メタデータの正当性をチェックできるように、IMGの送信者はまた、ANNOUNCE操作で認証データを含むことができます。この操作は、IMGデータタイプのいずれかを運ぶことができます。
There is no restriction to prevent IMG ANNOUNCE from being used in an asynchronous solicited manner, where a separate operation (possibly out of band) enables IMG receivers to subscribe/register to the IMG ANNOUNCE operation.
IMGは、（おそらく帯域外）別の操作をサブスクライブするIMG受信を可能に非同期要請方法で使用されるのANNOUNCE防止するために制限がない/動作をANNOUNCE IMGに登録します。
If an IMG receiver needs to obtain IMG metadata, an IMG receiver can use an IMG QUERY operation and initiate a receiver-driven IMG transport session. The IMG receiver expects a synchronous response to the subsequent request from the IMG sender. This operation can be used where a bidirectional transport network is available between the IMG sender and receiver. Some IMG receivers may want to obtain IMG metadata when network connectivity is available or just to avoid caching unsolicited IMG metadata. The IMG receiver must indicate the extent and data type of metadata wanted in some message in the operation. The extent indicates the number and grouping of metadata descriptions. In some cases, it may be feasible to request an IMG sender's complete metadata collection.
IMG受信機はIMGメタデータを取得する必要がある場合、IMG受信機はIMG照会操作を使用して、受信機駆動型IMG輸送セッションを開始することができます。 IMG受信機はIMGの送信者からの後続の要求に対する同期応答を期待します。この操作は、双方向伝送ネットワークは、IMGの送信側と受信側の間で利用可能である場合に使用することができます。ネットワーク接続が利用可能であるか、単に迷惑IMGメタデータをキャッシュ避けるためと、一部のIMG受信機はIMGメタデータを取得することができます。メタデータの範囲やデータタイプを指定する必要がありIMG受信機は、動作中、いくつかのメッセージに望んでいました。エクステントは、メタデータの記述の数とグループ化を示しています。いくつかのケースでは、IMGの送信者の完全なメタデータの収集を依頼することは可能かもしれません。
An IMG sender synchronously responds, and sends IMG metadata, to an IMG QUERY that has been sent by an IMG receiver. This operation can be used where a bidirectional transport network is available between the IMG sender and receiver. If the IMG QUERY specifies a subset of IMG metadata (extent and data type) that is available to the IMG sender, the IMG sender can resolve the query; otherwise, it should indicate that it is not able to resolve the query. The IMG sender may authenticate the IMG receiver during the QUERY operation to determine if the IMG receiver is authorized to receive that metadata. The sender may also include authentication data in the RESOLVE operation so that IMG receivers may check the authenticity of the metadata. This operation may carry any of the IMG data types.
IMGの送信者は、同期応答し、IMG受信機によって送信されてきたのIMG QUERYに、IMGメタデータを送信します。この操作は、双方向伝送ネットワークは、IMGの送信側と受信側の間で利用可能である場合に使用することができます。 IMG QUERYは、IMGの送信者に利用可能であるIMGメタデータ（エクステントおよびデータ・タイプ）のサブセットを指定する場合は、IMGの送信者は、クエリを解決することができます。そうでない場合は、クエリを解決できないことを示す必要があります。 IMG送付者は、IMG受信機がそのメタデータを受信することを許可されているかどうかを判断するために照会操作中にIMG受信機を認証してもよいです。 IMG受信機は、メタデータの正当性をチェックできるように、送信者はまた、RESOLVE操作で認証データを含むことができます。この操作は、IMGのデータ型のいずれかを運ぶことができます。
If an IMG receiver wants to be notified when the IMG metadata it holds becomes stale, the IMG receiver can use the IMG SUBSCRIBE operation in advance in order to solicit IMG NOTIFY messages from an IMG sender.
それが保持しているIMGメタデータが古くなったときにIMG受信機が通知されることを希望する場合は、IMG受信機はIMGは、IMGの送信者からのメッセージをNOTIFY勧誘するために、IMGは、事前に操作をSUBSCRIBE使用することができます。
This operation may provide the IMG sender with specific details of which metadata or notification services it is interested in the case where the IMG sender offers more than the simplest "all data" service. This operation implicitly provides the functionality of unsubscribing to inform an IMG sender that an IMG receiver wishes to stop getting certain (or all) notifications. It should be noted that unsubscription may be provided implicitly by the expiry (timeout) of a subscription before it is renewed.
この操作は、IMGの送信者は、最も単純な「全てのデータ」サービス以上のものを提供しています場合に興味があるメタデータや通知サービスの具体的な詳細とIMGの送信者を提供することができます。この操作は、暗黙のうちにIMG受信機が特定の（またはすべて）のお知らせを停止するには、希望するIMGの送信者に通知するために退会の機能を提供します。更新される前に、解除のは、サブスクリプションの有効期限（タイムアウト）によって暗黙的に提供されてもよいことに留意すべきです。
Since the IMG receiver does not know when metadata will be updated and the notify message will arrive, this operation does not synchronize with the notify messages. The IMG receiver may wait for notify messages for a long time. The IMG sender may authenticate the IMG receiver to check whether an IMG SUBSCRIBE operation is from an authorized IMG receiver.
メタデータが更新され、通知メッセージが到着するIMG受信機が認識していないので、この操作は、通知メッセージを同期しません。 IMG受信機は、長い時間のためにメッセージを通知を待つことができます。 IMG送付者はIMG操作が許可IMG受信機からのものであるSUBSCRIBEかどうかを確認するためにIMG受信機を認証してもよいです。
An IMG NOTIFY is used asynchronously in response to an earlier IMG SUBSCRIBE. An IMG NOTIFY operation indicates that updated IMG metadata is available or part of the existing IMG metadata is stale. An IMG NOTIFY may be delivered more than once during the time an IMG SUBSCRIBE is active. This operation may carry any of the IMG data types. The IMG sender may also include authentication data in the IMG NOTIFY operation so that IMG receivers may check the authenticity of the messages.
IMGは、SUBSCRIBE以前のIMGに応じて非同期的に使用されているNOTIFY。 IMGは、操作が更新されIMGメタデータが入手可能であるか、または既存のIMGメタデータの一部が古くなっていることを示しているNOTIFY。 IMG NOTIFYはIMGがアクティブであるSUBSCRIBE時間の間複数回送達されてもよいです。この操作は、IMGのデータ型のいずれかを運ぶことができます。 IMGの送信者はまた、IMG受信機は、メッセージの正当性をチェックできるように、IMGでの認証データが操作をNOTIFY挙げられます。
There is a need to provide a binding between the various IMG operations and IMG data types to allow management of each discrete set of IMG metadata transferred using an IMG operation. This binding must be independent of any particular metadata syntax used to represent a set of IMG metadata, as well as be compatible with any IMG transport protocol. The binding must uniquely identify the set of IMG metadata delivered within an IMG transfer, regardless of the metadata syntax used. The uniqueness may only be needed within the domains the metadata is used, but this must enable globally unique identification to support Internet usage. Care should be taken that scope- and domain-specific identifiers do not leak outside the scope; using globally unique identifiers such as URLs avoids these problems.
IMG操作を使用して転送IMGメタデータの各離散集合の管理を可能にするために、様々なIMG操作とIMGのデータ型との間の結合を提供する必要があります。このIMGメタデータのセットを表し、ならびに任意IMGトランスポートプロトコルと互換性があるように使用される任意の特定のメタデータの構文とは独立でなければならない結合。結合一意に関係なく使用されるメタデータ構文の、IMG転送内送達IMGメタデータのセットを識別しなければなりません。一意性は、メタデータのみが使用されているドメイン内で必要とされるが、これはインターネットの利用をサポートするために、グローバルに固有の識別を有効にする必要があります。ケアscope-とドメイン固有の識別子がスコープ外に漏れないように注意しなければなりません。 URLなどのグローバル一意識別子を使用すると、これらの問題を回避することができます。
The binding must provide versioning to the transferred IMG metadata so that changes can be easily handled and stale data identified, and give temporal validity of the transferred IMG metadata. It must invalidate the IMG metadata by indicating an expiry time, and may optionally provide a time (presumably in the future) from when the IMG metadata becomes valid. The temporal validity of a metadata object may need to be updated later. Furthermore, the binding must be independent of any specific metadata syntax used for the IMG metadata, in the sense that no useful syntax should be excluded.
結合は、変更が容易に取り扱うことができ、古いデータを識別するように転送IMGメタデータにバージョン管理を提供し、転送IMGメタデータの時間的な妥当性を与えなければなりません。これは、有効期限を示すことによって、IMGメタデータを無効化しなければならない、および任意にIMGメタデータが有効となったときから（おそらく将来の）時間を提供してもよいです。メタデータオブジェクトの時間的な有効性は、後に更新する必要があります。さらに、結合は、有用な構文は除外すべきではないという意味で、IMGメタデータのために使用される任意の特定のメタデータ構文の独立していなければなりません。
Figure 2 gives an overview of the relationship between transport cases, IMG operations, and IMG data types. It is not a protocol stack. Generalized multicast point-to-multipoint (P-to-M) and unicast point-to-point (P-to-P) transports are shown.
図2は、輸送ケース、IMG操作、及びIMGのデータ型の間の関係の概要を示します。これは、プロトコル・スタックではありません。一般的なトランスポートが示されているポイント・ツー・マルチポイント（P-に-M）とユニキャストのポイントツーポイント（P-に-P）マルチキャスト。
+--------------------------------------------------+
IMG | |
Data Types | Complete Desc., Delta Desc., Pointer |
| |
+-------------------+----------------+-------------+
IMG | IMG ANNOUNCE | IMG SUBSCRIBE | IMG QUERY |
Operations | | IMG NOTIFY | IMG RESOLVE |
+--------------+----+----------------+-------------+
IMG | | |
Transport | P-to-M | P-to-P |
| | |
+--------------+-----------------------------------+
Figure 2: IMG Transport, IMG Operations, and IMG Data Types
図2：IMG交通、IMGオペレーション、およびIMGデータ型
This section provides some basic deployment scenarios for IMG entities that illustrate common threads from protocols to use cases. For the purposes of clarity, this document presents the simple dataflow from an IMG sender to an IMG receiver, as shown in Figure 3.
このセクションでは、例を使用するプロトコルから共通のスレッドを示してIMGエンティティのためのいくつかの基本的な展開シナリオを提供します。図3に示すように、明確にするために、この文書は、IMG受信機にIMG送付者からの単純なデータフローを示します。
+-------------+ +---------------+
| IMG Sender | | IMG Receiver |
| |--------------->| |
+-------------+ +---------------+
Figure 3: A Simple IMG Sender to IMG Receiver Relationship
図3：IMGレシーバ関係にシンプルなIMG送信者
Some IMG metadata may be distributed to a large number of IMG receivers, for example, when public metadata is distributed to all IMG receivers of a certain group. This kind of IMG metadata may be distributed from one IMG sender to multiple IMG receivers (Figure 4) or may be relayed across a set of IMG transceivers that receive the IMG metadata, possibly filter or modify its content, and then forward it.
公共メタデータは、特定のグループのすべてのIMG受信機に配信されたときに、いくつかのIMGメタデータは、例えば、IMG受信機の多数に配布することができます。 IMGメタデータのこの種は、複数のIMG受信機（図4）の1つのIMG送付者から配布され得るか、または、IMGメタデータを受信するIMGトランシーバのセットにわたって中継おそらくはそのコンテンツをフィルタリング又は変更し、それを転送することができます。
+----------+ +----------+
| IMG | | IMG |
| Sender |---- ---->| Receiver |
+----------+ \ / +----------+
\ /
. \ +-----------+ / .
. -->|IMG |----- .
. -->|Transceiver| \ .
/ +-----------+ \
+----------+ / \ +----------+
| IMG | / ---->| IMG |
| Sender |---- | Receiver |
+----------+ +----------+
Figure 4: A Relay Network with an IMG Transceiver
図4：IMGトランシーバと中継ネットワーク
IMG senders and receivers are logical functions, and it is possible for some or all hosts in a system to perform both roles, as, for instance, in many-to-many communications or where a transceiver is used to combine or aggregate IMG metadata for some IMG receivers. An IMG receiver may be allowed to receive IMG metadata from any number of IMG senders.
例えば、多対多通信の場合やトランシーバがためIMGメタデータを結合または集約するために使用される、ように、IMGの送信側と受信側は論理関数であり、それは両方の役割を実行するためにシステム内の一部またはすべてのホストのために可能ですいくつかのIMG受信機。 IMG受信機はIMG送信者の任意の数からIMGメタデータを受信できるようにしてもよいです。
IMG metadata is used to find, obtain, manage, and play media content. IMG metadata may be modified during IMG transfer. For example, a server may use IMGs to retrieve media content via unicast and then make it available at scheduled times via multicast, thus requiring a change of the corresponding metadata. IMG transceivers may add or delete information or aggregate IMG metadata from different IMG senders. For example, a rating service may add its own content ratings or recommendations to existing metadata. An implication of changing (or aggregating) IMG metadata from one or more IMG senders is that the original authenticity is lost. Thus, it may be beneficial to sign fragments so that the intermediary can replace a fragment without changing the authenticity of the remainder. For example, smaller fragments may be appropriate for more volatile parts, and larger ones may be appropriate for stable parts.
IMGメタデータは、見つけ取得、管理、およびメディアコンテンツを再生するために使用されます。 IMGメタデータは、IMGの転送中に変更されてもよいです。例えば、サーバは、このように、対応するメタデータの変更を必要とする、ユニキャストを介してメディアコンテンツを取得し、マルチキャストを介して、スケジュールされた時間でそれを使用できるようにIMGSを使用してもよいです。 IMGトランシーバは、情報または異なるIMGの送信者からの集計IMGメタデータを追加または削除することがあります。例えば、レーティングサービスは、独自のコンテンツを評価したり、既存のメタデータへの勧告を追加することができます。一つ以上のIMGの送信者からIMGメタデータを変更（または凝集）の含意は、元の信憑性が失われることです。これにより、中間剰余の真正性を変えることなく、断片を交換することができるように断片に署名することが有益であり得ます。例えば、より小さな断片は、より揮発性の部分のために適切であり得る、より大きなものは安定した部品のために適切であり得ます。
The one-to-many unidirectional multicast case implies many IMG receivers and one or more IMG senders implementing IMG announcer and IMG listener operations as shown in Figure 5.
一対多一方向マルチキャストの場合は、図5に示すようにIMGアナウンサーとIMGリスナー動作を実現多くのIMG受信機および1つまたは複数のIMGの送信者を意味しています。
Unidirectional +----------+
---------------> | IMG |
downlink | Listener |
------------->| 1 |
/ +----------+
+-----------+ / .
| IMG |-------- .
| Announcer | \ .
+-----------+ \ +----------+
------------->| IMG |
| Listener |
| # |
+----------+
Figure 5: IMG Unidirectional Multicast Distribution Example
図5：IMG一方向マルチキャスト配信例
Note, as defined in the IMG requirement REL-4 [4], an IMG transport protocol MUST support reliable message exchange. This includes the one-to-many unidirectional multicast case; however, the mechanism to provide this is beyond the scope of this document.
REL-4 [4]、IMGトランスポートプロトコルが信頼できるメッセージ交換をサポートしなければならないIMG要件で定義されるように、注意してください。これは、1対多の単方向マルチキャストのケースと、しかし、これを提供するメカニズムはこのドキュメントの範囲を超えています。
In the one-to-one bidirectional unicast case, both query/resolve (Figure 6) and subscribe/notify (Figure 7) message exchange operations are feasible.
一対一の双方向のユニキャストの場合には、クエリ/リゾルブ（図6）の両方とSUBSCRIBE / NOTIFY（図7）のメッセージ交換操作が可能です。
+----------+ +----------+
| IMG | | IMG |
| Resolver | | Querier |
+----------+ +----------+
| |
|<----------IMG QUERY -----------|
| |
|----------IMG RESOLVE---------->|
| |
Figure 6: Query/Resolve Sequence Example
図6：クエリ/解決シーケンスの例
+----------+ +------------+
| IMG | | IMG |
| Notifier | | Subscriber |
+----------+ +------------+
| |
|<---------IMG SUBSCRIBE---------|
: :
(time passes)
: :
|-----------IMG NOTIFY---------->|
: :
(time passes)
: :
|-----------IMG NOTIFY---------->|
| |
Figure 7: Subscribe/Notify Sequence Example
図7：購読/通知シーケンスの例
As shown in Figure 8, a common data model for multiple protocol operations allows a diverse range of IMG senders and receivers to provide consistent and interoperable sets of IMG metadata.
図8に示すように、複数のプロトコル操作のための共通のデータモデルは、IMGの送信者と受信者の多様な範囲をIMGメタデータの一貫性と相互運用セットを提供することを可能にします。
IMG Metadata IMG Senders IMG Receivers
IMGメタデータIMG差出人IMGレシーバ
+--------------+
+-----------+ ---->| IMG Listener |
| IMG | / +--------------+
/| Announcer |-----
+-------------+ / +-----------+ \ +--------------+
| IMG |-+ / ---->| IMG Listener |
| description | |-+ / | - - - - - - -|
| metadata 1 | | | / +-----------+ /--->| IMG Querier |
+-------------+ | | -----| IMG |<----/ +--------------+
+-------------+ | \ | Resolver |
+-------------+ \ +-----------+<----\ +--------------+
\ \--->| IMG Querier |
\ +-----------+ | - - - - - - -|
\| IMG |<--------->| IMG |
| Notifier | | Subscriber |
+-----------+ +--------------+
Figure 8: Combined System with Common Metadata
図8：共通メタデータと組み合わせるシステム
SDP: The SDP format [2] could be used to describe session-level parameters (e.g., scheduling, addressing, and the use of media codecs) to be included in Complete IMG Descriptions. Although there are extension points in SDP allowing the format to be extended, there are limitations in the flexibility of this extension mechanism. However, SDP syntax cannot provide IMG Descriptions and IMG Pointers without significant overhead. It is expected that the information conveyed by SDP is just a small subset of IMG metadata; thus, the use of SDP for other than session parameters may not be reasonable.
SDP：SDPフォーマットは、[2]セッションレベルのパラメータ（例えば、スケジューリング、アドレッシング、およびメディア・コーデックの使用）完全IMGの説明に含まれるを記述するために使用することができます。フォーマットが拡張されることを可能にするSDPにおける拡張ポイントがあるが、この拡張機構の柔軟性に限界があります。しかし、SDP構文は大きなオーバーヘッドなしIMGの説明とIMGポインタを提供することはできません。 SDPによって搬送される情報は、IMGメタデータのほんの一部であることが予想されます。従って、セッションパラメータ以外のためのSDPを使用することは合理的ではないかもしれません。
SDPng [3]: Similar to SDP, this format could also be used for representing session-level parameters of IMG metadata. Compared to SDP, the XML-based format of SDPng should be much more flexible and allow extensions and integration with other description formats.
SDPng [3]：SDPと同様に、このフォーマットは、IMGメタデータのセッション・レベルのパラメータを表すために使用することができます。 SDPと比較して、SDPngのXMLベースのフォーマットは、はるかに柔軟でかつ他の記述形式とエクステンションとの統合を可能にするはずです。
MPEG-7: Descriptions based on the MPEG-7 standard [5] could provide application-specific metadata describing the properties of multimedia content beyond parameters carried in SDP or SDPng descriptions. MPEG-7 provides a machine-readable format of representing content categories and attributes, helping end-users or receiving software in choosing content for reception. MPEG-7 is based on XML, so it is well suited to be combined with other XML-based formats such as SDPng.
MPEG-7：MPEG-7規格に基づいて説明する[5] SDPまたはSDPng説明で運ばパラメータを超えたマルチメディアコンテンツの特性を記述したアプリケーション固有のメタデータを提供することができます。 MPEG-7は、コンテンツカテゴリ及び属性を表すエンドユーザを助けるまたは受信のためのコンテンツを選択する際にソフトウェアを受信する機械読み取り可能なフォーマットを提供します。 MPEG-7は、XMLに基づいており、そのようなSDPngのような他のXMLベースのフォーマットと組み合わせることに適しています。
TV-Anytime: The TV-Anytime Forum [6] provides descriptions based on XML schema for TV-specific program guides. TV-Anytime uses the MPEG-7 User description profile to a limited extent, only for user preferences and usage history, and also a TV-Anytime-specific data model for other schema. These are optimized to describe broadcast schedules, on-demand program guides and program events.
たTV-Anytime：たTV-Anytimeフォーラム[6]テレビ固有の番組ガイドのためのXMLスキーマに基づいて説明します。たTV-Anytimeは、ユーザの好みや使用履歴のため、限られた範囲にMPEG-7のユーザ記述プロファイルを使用し、また、他のスキーマのたTV-Anytime固有のデータモデル。これらは、放送スケジュール、オンデマンド番組ガイドおよびプログラムイベントを記述するために最適化されています。
HTTP: The HTTP protocol [7] can be used as a bidirectional unicast IMG transport protocol. Being a request-reply-oriented protocol, HTTP is well suited for implementing synchronous operations such as QUERY, RESOLVE, and even SUBSCRIBE. However, HTTP does not provide asynchronous operations such as ANNOUNCE and NOTIFY and to implement asynchronous operations using HTTP, IMG receivers should poll the IMG sender periodically. Thus, by itself, HTTP is not sufficient to fulfill all of the IMG requirements [4] in a unicast deployment.
HTTP：HTTPプロトコル[7]の双方向ユニキャストIMGトランスポートプロトコルとして使用することができます。要求 - 応答指向プロトコルであり、HTTPを解決するには、そのようなクエリとの同期動作を実現するのに適している、ともSUBSCRIBE。しかし、HTTPは、ANNOUNCEとNOTIFYと、IMG受信機は定期的にIMGの送信者をポーリングすべきであるHTTPを使用して非同期操作を実装するための非同期操作を提供していません。したがって、それ自体で、HTTPは、ユニキャスト配備の[4] IMG要件の全てを満たすには不十分です。
Session Announcement Protocol (SAP): The announcement mechanism provided by SAP [8] provides unidirectional delivery of session discovery information. Although SDP is the default payload format of SAP, the use of a MIME type identifier for the payload allows arbitrary payload formats to be used in SAP messages. Thus, SAP could be used to implement the multicast and unicast IMG ANNOUNCE and IMG NOTIFY operations.
セッション告知プロトコル（SAP）：SAPによって提供されるアナウンス機構[8]セッション・ディスカバリ情報の一方向の送達を提供します。 SDPは、SAPのデフォルトのペイロードフォーマットであるが、ペイロードのMIMEタイプ識別子の使用は、任意のペイロードフォーマットはSAPメッセージで使用されることを可能にします。したがって、SAPは、マルチキャストとユニキャストIMG ANNOUNCEとIMG操作をNOTIFYを実装するために使用することができます。
However, SAP lacks scalable and efficient reliability, extensibility for payload size, and congestion control, and only one description is allowed per SAP message due to lack of payload segmentation.
しかし、SAPは、スケーラブルかつ効率的な信頼性、ペイロードサイズの拡張、および輻輳制御を欠き、そして唯一の説明は起因ペイロードセグメント化の欠如にSAPメッセージごとに許可されています。
In principle, SAP could be extended to get around its limitations. However, the amount of changes needed in SAP to address all of the above limitations would effectively result in a new protocol. Due to these limitations, the use of SAP as an IMG transport protocol is not recommended.
原則として、SAPは、その制限を回避するために拡張することができます。しかし、上記の制限のすべてに対処するためにSAPに必要な変更の量は、効果的に新しいプロトコルになるでしょう。これらの制限のために、IMGトランスポートプロトコルとしてSAPを使用することは推奨されません。
SIP: The SIP-specific event mechanism described in RFC 3265 [9] provides a way to implement IMG SUBSCRIBE and IMG NOTIFY operations via a bidirectional unicast connection. However, there are scalability problems with this approach, as RFC 3265 currently does not consider multicast.
SIP：RFC 3265に記載のSIP固有のイベント機構は、[9] IMGは、SUBSCRIBEとIMGは、双方向ユニキャスト接続を介して操作をNOTIFY実装する方法を提供します。 RFC 3265は、現在のマルチキャストを考慮していないようしかし、このアプローチにはスケーラビリティの問題が、あります。
Real Time Streaming Protocol (RTSP): The RTSP protocol [10] defines a retrieval-and-update notification mechanism, named DESCRIBE and ANNOUNCE, for the description of a presentation or media object in order to initialize a streaming session. These methods are a subset of the entire streaming control operations in RTSP; thus, these could not be available for individual mechanisms. However, the DESCRIBE method in RTSP could be used to instantiate IMG QUERY, IMG RESOLVE, and IMG SUBSCRIBE, and the RTSP ANNOUNCE could be used to instantiate an IMG NOTIFY for a streaming session controlled by RTSP.
リアルタイムストリーミングプロトコル（RTSP）：RTSPプロトコル[10]は、ストリーミングセッションを初期化するために、プレゼンテーションまたはメディアオブジェクトの説明については、記述しANNOUNCE名前、検索、及び更新の通知メカニズムを定義します。これらの方法は、RTSP全体ストリーミング制御動作のサブセットです。したがって、これらは、個々のメカニズムのために利用可能であることができませんでした。しかし、RTSP DESCRIBEにおける方法はIMG QUERY、IMGのRESOLVEをインスタンス化するために使用することができ、及びIMGはSUBSCRIBE、およびRTSP ANNOUNCEがRTSPによって制御されるストリーミングセッションのためのNOTIFY IMGをインスタンス化するために使用することができます。
Several needs result from the IMG requirements, framework model, and existing relevant mechanisms as already shown in this document. Four specific groupings of work are readily apparent: (a) specification of an adequate multicast- and unidirectional-capable announcement protocol; (b) specification of the use of existing unicast protocols to enable unicast subscribe and announcement/notification functionality; (c) specification of the metadata envelope that is common to, and independent of, the application metadata syntax(es) used; and (d) agreement on basic metadata models to enable interoperability testing of the above. The following sections describe each of these.
いくつかのニーズは、すでにこの文書に示されているIMG要件、フレームワークモデル、および既存の関連するメカニズムに起因します。ワークの4つの特定のグループは、容易に明らかである：（a）に十分なマルチキャストの一方向対応アナウンスメントプロトコルの仕様。 （b）は、サブスクライブと発表/通知機能ユニキャスト有効にするために、既存のユニキャストプロトコルの使用の仕様。 （C）に共通しているメタデータ・エンベロープの仕様、及び使用される、アプリケーションのメタデータの構文（ES）の独立しました。上記の相互運用性テストを可能にするための基本的なメタデータモデルのと、（d）合意。次のセクションでは、これらのそれぞれについて説明します。
SAP is currently the only open standard protocol suited to the unidirectional/multicast delivery of IMG metadata. As discussed, it fails to meet the IMG requirements in many ways and, since it is not designed to be extensible, we recognize that a new multicast transport protocol for announcements needs to be specified to meet IMG needs. This protocol will be essential to IMG delivery for unidirectional and multicast deployments.
SAPは現在、IMGメタデータのマルチキャスト/一方向の配信に適した唯一のオープンな標準プロトコルです。議論拡張できるように設計されていないので、それは、多くの方法でIMGの要件を満たすために失敗したように、我々は発表のための新しいマルチキャストトランスポートプロトコルは、IMGのニーズを満たすために指定する必要があることを認識しています。このプロトコルは、単方向およびマルチキャストの展開のためのIMGの配信に不可欠となります。
The Asynchronous Layered Coding (ALC) [11] protocol from the IETF Reliable Multicast Transport (RMT) working group is very interesting as it fulfills many of the requirements, is extensible, and has the ability to 'plug-in' both FEC (Forward Error Correction, for reliability) and CC (Congestion Control) functional blocks. It is specifically designed for unidirectional multicast object transport. ALC is not fully specified, although the RMT working group had a fully specified protocol using ALC called FLUTE (File Delivery over Unidirectional Transport) [12]. FLUTE seems to be the only fully specified transport and open specification on which a new IMG announcement protocol could be designed. Thus, we recommend that ALC and FLUTE be the starting points for this protocol's design.
（ALC）をコード非同期階層[11] IETF高信頼マルチキャストトランスポート（RMT）ワーキンググループからプロトコルが、それは要件の多くを満たすように、非常に興味深い拡張可能であり、「プラグイン」する能力の両方FEC（フォワードを有します信頼性のためのエラー訂正、）およびCC（輻輳制御）機能ブロック。これは特に、単方向マルチキャスト物の輸送のために設計されています。 RMTワーキンググループは、ALCと呼ばれるFLUTE（単方向トランスポート上でファイル配信）[12]を使用して、完全に指定されたプロトコルを持っていたものの、ALCは完全には、指定されていません。 FLUTEは唯一の完全に指定されたトランスポートと新しいIMG発表プロトコルを設計することができた上でオープンな仕様のようです。したがって、我々は、ALCとFLUTEは、このプロトコルの設計のための出発点にすることをお勧めします。
Developing a new protocol from scratch, or attempting to improve SAP, is also feasible, although it would involve repeating many of the design processes and decisions already made by the IETF for ALC. In particular, any announcement protocol must feature sufficient scalability, flexibility, and reliability to meet IMG needs. Also, the IMG ANNOUNCE operation must be supported and IMG NOTIFY capability could be investigated for both hybrid unicast-multicast and unidirectional unicast systems.
最初から新しいプロトコルを開発する、またはSAPを改善しようと、それはすでにALCのためにIETFによって作られた設計プロセスと意思決定の多くを繰り返す伴うだろうが、また可能です。具体的には、任意の告知プロトコルは、IMGのニーズを満たすのに十分な拡張性、柔軟性、および信頼性を備えていなければなりません。また、IMG ANNOUNCE操作がサポートされなければならず、IMGは、能力がハイブリッドユニキャスト、マルチキャスト及び一方向ユニキャストシステムの両方のために調査することができるNOTIFY。
A thorough description of the use of existing unicast protocols is essential for the use of IMGs in a unicast point-to-point environment. Such a specification has not been published, although several usable unicast transport protocols and specifications can be harnessed for this (SIP [13], SIP events [9], HTTP [7], etc.). In particular, both IMG SUBSCRIBE-NOTIFY and IMG QUERY-RESOLVE operation pairs must be enabled. We anticipate that the IMG QUERY-RESOLVE operation can be achieved using HTTP, although other transport protocol options may be beneficial to consider too.
既存のユニキャストプロトコルの使用の完全な説明は、ユニキャストポイントツーポイント環境でのIMGSの使用のために不可欠です。いくつかの使用可能なユニキャストトランスポートプロトコル及び仕様は、この（SIP [13]、SIPイベント[9]、HTTP [7]、等）のために利用することができるが、そのような仕様は、公開されていません。具体的には、両方のIMGは、SUBSCRIBE、NOTIFYとIMG QUERY-RESOLVE動作ペアを有効にする必要があります。私たちは、他のトランスポートプロトコルオプションがあまりにも考慮することが有益であり得るが、IMG QUERY-RESOLVE操作は、HTTPを使用して達成することができることを期待しています。
An IMG envelope provides the binding between IMG operations and data types. Such a binding can be realized by defining a common minimal set of information needed to manage IMG metadata transfers, and by including this information with any set of IMG metadata delivered to IMG receivers.
IMGエンベロープは、IMG操作とデータ型との間の結合を提供します。そのような結合は、IMGメタデータ転送を管理するために必要な情報の共通の最小セットを定義すること、およびIMG受信機に配信IMGメタデータの任意のセットを用いて、この情報を含めることによって実現することができます。
Four options for IMG metadata transfer envelope delivery are feasible:
IMGメタデータ転送エンベロープの配信のための4つのオプションが可能です。
1. Embedding in a transport protocol header. This can be done with either header extensions of existing protocols, or newly defined header fields of a new (or new version of a) transport protocol. However, multiple methods for the variety of transport protocols would hinder interoperability and transport protocol independence.
1.トランスポートプロトコルヘッダに埋め込みます。これは、既存のプロトコルのヘッダ拡張、またはトランスポートプロトコル新しい（または新しいバージョン）の新たに定義されたヘッダフィールドのいずれかで行うことができます。しかし、トランスポートプロトコルのさまざまな複数の方法は、相互運用性と、トランスポートプロトコルの独立性を妨げます。
2. A separate envelope object, which points to the IMG metadata 'object', delivered in-band with the metadata transport protocol session. This might complicate delivery as the envelope and 'service' metadata objects would have to be bound, e.g., by pairing some kind of transport object numbers (analogous to port number pairs sometimes used for RTP and RTCP [14]). This would also enable schemes that deliver envelope and metadata 'objects' by different media, also using more than a single transport protocol.
2. IMGメタデータ「オブジェクト」を指す別個エンベロープオブジェクトは、メタデータ・トランスポート・プロトコル・セッションと帯域内送達しました。エンベロープおよび「サービスのメタデータオブジェクトは（時にはRTPとRTCPのために使用されるポート番号の組に類似[14]）トランスポート・オブジェクト数のいくつかの種類を組み合わせることで、例えば、結合しなければならないので、これは配送を複雑かもしれません。これもまた、単一のトランスポートプロトコルよりも多くを使用して、異なるメディアでエンベロープとメタデータの「オブジェクト」を提供するスキームを可能にします。
3. A metadata wrapper that points to and/or embeds the service metadata into its 'super-syntax'. For example, XML would enable embedding generic text objects.
3.を指すおよび/またはその「スーパー構文」内にサービスメタデータを埋め込むメタデータラッパー。例えば、XMLは、汎用テキストオブジェクトを埋め込む可能になります。
4. Embedding in the metadata itself. However, this requires a new field in many metadata syntaxes and would not be feasible if a useful syntax were not capable of extensibility in this way. It also introduces a larger 'implementation interpretation' variety, which would hinder interoperability. Thus, this option is not recommended.
4.メタデータ自体に埋め込みます。しかし、これは多くのメタデータ構文に新しいフィールドを必要とし、便利な構文はこのように拡張することができなかった場合には実現可能ではないであろう。また、相互運用性を妨げる大きな「実装の解釈」多様性を紹介します。したがって、このオプションは推奨されません。
It is likely that more than one of these options will fulfill the needs of IMGs, so the selection, and possibly optimization, is left for subsequent specification and feedback from implementation experience. Such a specification is essential for IMG delivery.
これらのオプションの2つ以上がIMGSのニーズを満たすだろうと思われるので、選択、そしておそらく最適化は、実装経験から、その後の仕様とフィードバックのために残されています。このような仕様は、IMGの配信のために不可欠です。
When there are superset/subset relations between IMG Descriptions, it is assumed that the IMG Descriptions of the subset inherit the parameters of the superset. Thus, an IMG metadata transfer envelope carrying the IMG Descriptions of a superset may implicitly define parameters of IMG Descriptions belonging to its subset. The relations between IMG Descriptions may span from one envelope to another according to a data model definition.
IMGの説明とのサブセット/スーパーセット関係があるとき、一部のIMGの説明がスーパーセットのパラメータを継承するものとします。従って、スーパーセットのIMGの説明を運ぶIMGメタデータ転送エンベロープは、暗黙的に、そのサブセットに属するIMG記述のパラメータを定義することができます。 IMGの説明との関係は、データモデルの定義による一のエンベロープから別のものに及ぶことができます。
A structured data model would allow reuse and extension of the set of metadata and may enable use of multiple syntaxes (SDP, MPEG-7, etc.) as part of the same body of IMG metadata.
構造化データ・モデルは、再利用およびメタデータのセットの拡張を可能にし、IMGメタデータの同一の本体の一部として複数の構文（SDP、MPEG-7など）の使用を可能にすることができます。
For the successful deployment of IMGs in various environments, further work may be needed to define metadata and data models for application-specific requirements. Existing (and future) work on these would need to be mapped to the IMG data types and use of the IMG transfer envelope concept as described above.
様々な環境でのIMGSの展開を成功するために、更なる作業は、アプリケーション固有の要件については、メタデータとデータモデルを定義するために必要な場合があります。これらの既存の（および将来の）仕事は、上述したようにIMG転送エンベロープの概念のIMGデータの種類と使用にマッピングする必要があります。
This document is a framework for the delivery of IMG metadata and thus further discussion on the definition data models for IMGs is beyond its scope.
この文書では、IMGメタデータの配信のためのフレームワークであるとIMGSの定義データモデルの一層の議論は、その範囲を超えています。
The IMG framework is developed from the IMG requirements document [4], and so the selection of specific protocols and mechanism for use with the IMG framework must also take into account the security considerations of the IMG requirements document. This framework document does not mandate the use of specific protocols. However, an IMG specification would inherit the security considerations of specific protocols used.
IMGフレームワークは、IMG要件ドキュメント[4]から開発され、その特定のプロトコルおよびIMGフレームワークで使用するためのメカニズムの選択も考慮にIMG要件ドキュメントのセキュリティの考慮事項を取る必要があります。このフレームワーク文書は、特定のプロトコルの使用を強制しません。しかし、IMGの仕様は、使用される特定のプロトコルのセキュリティ上の配慮を継承します。
Protocol instantiations that are used to provide IMG operations will have very different security considerations depending on their scope and purpose. However, there are several general issues that are valuable to consider and, in some cases, provide technical solutions for. These are described below.
IMG操作を提供するために使用されているプロトコルのインスタンスは、その範囲や目的に応じて非常に異なるセキュリティの考慮事項があります。しかし、考えると、いくつかのケースでは、のための技術的なソリューションを提供するために価値があるいくつかの一般的な問題があります。これらは、以下に記載されています。
Individual and group privacy: Customized IMG metadata may reveal information about the habits and preferences of a user and may thus deserve confidentiality protection, even if the original information were public. Protecting this metadata against snooping requires the same actions and measures as for other point-to-point and multicast Internet communications. Naturally, the risk of snooping depends on the amount of individual or group personalization the IMG metadata contains.
個人およびグループのプライバシー：カスタマイズされたIMGメタデータは、ユーザーの習慣や嗜好に関する情報を明らかにすることができるので、元の情報は、公開した場合でも、機密性保護に値することがあります。スヌーピングに対して、このメタデータを保護することは、他のポイントツーポイントおよびマルチキャストインターネット通信の場合と同じ行動や対策が必要です。当然のことながら、スヌーピングのリスクはIMGメタデータが含まれている個人またはグループパーソナライゼーションの量に依存します。
IMG authenticity: In some cases, the IMG receiver needs to be assured of the sender or origin of IMG metadata or its modification history. This can prevent denial-of-service or hijacking attempts that give an
IMGの信憑性は：いくつかのケースでは、IMG受信機はIMGメタデータやその変更履歴の送信者または起源を保証する必要があります。これは与えるサービス拒否やハイジャックの試みを防ぐことができます
IMG receiver incorrect information in or about the metadata, thus preventing successful access of the media or directing the IMG receiver to the incorrect media possibly with tasteless material.
IMG受信機やメタデータに関する誤った情報、ため、メディアの成功したアクセスを防止または無味材料で、おそらく間違ったメディアにIMG受信機を演出。
IMG receiver authorization: Some or all of any IMG sender's metadata may be private or valuable enough to allow access to only certain IMG receivers and thus make it worth authenticating users. Encrypting the data is also a reasonable step, especially where group communications methods results in unavoidable snooping opportunities for unauthorized nodes.
IMG受信機の承認：すべてのIMGの送信者のメタデータの一部またはすべてが唯一の特定のIMG受信機へのアクセスを可能にするプライベートまたは十分な価値があるので、それだけの価値がユーザーを認証を行うことができます。データを暗号化することも合理的なステップ、不正ノードに対する不可避スヌーピング機会に特にグループ通信方式の結果です。
Unidirectional specifics: A difficulty that is faced by unidirectional delivery operations is that many protocols providing application-level security are based on bidirectional communications. The application of these security protocols in case of strictly unidirectional links is not considered in the present document.
一方向仕様：一方向配信操作によって直面する困難は、アプリケーションレベルのセキュリティを提供する多くのプロトコルは、双方向通信に基づいていることです。厳密に単方向リンクの場合、これらのセキュリティプロトコルのアプリケーションが、本文書では考慮されていません。
Malicious code: Currently, IMGs are not envisaged to deliver executable code at any stage. However, as some IMG transport protocols may be capable of delivering arbitrary files, it is RECOMMENDED that the IMG operations do not have write access to the system or any other critical areas.
悪意のあるコード：現在のところ、IMGSは、いずれかの段階で実行可能なコードを提供することが想定されていません。いくつかのIMGトランスポートプロトコルは、任意のファイルを提供することが可能であるようしかし、IMG操作は、システムや他の重要な領域への書き込みアクセス権を持っていないことをお勧めします。
[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] Kutscher, D., Ott, J., and C. Bormann, "Session description and capability negotiation", Work in Progress, October 2003.
[3] Kutscher、D.、オット、J.、およびC.ボルマン、 "セッション記述と能力交渉"、進歩、2003年10月に作業。
[4] Nomura, Y., Walsh, R., Luoma, J-P., Ott, J., and H. Schulzrinne, "Requirements for Internet Media Guides", Work in Progress, December 2005.
[4]野村、Y.、ウォルシュ、R.、Luoma、J-P。、オット、J.、およびH. Schulzrinneと、 "インターネットメディアガイドのための要件"、進歩、2005年12月に働いています。
[5] "Multimedia content description interface -- Part 1: Systems", ISO/IEC 15938-1, July 2002.
[5] "マルチメディアコンテンツ記述インタフェース - 第1部：システム"、ISO / IEC 15938から1、2002年7月。
[6] TV-Anytime Forum, "Broadcast and On-line Services: Search, select, and rightful use of content on personal storage systems ("TV-Anytime Phase 1"); Part 2: System description," ETSI-TS 102 822-2: System Description, V1.1.1, October 2003.
〔6〕たTV-Anytimeフォーラム、「放送とオンラインサービス：検索、選択、およびパーソナルストレージシステム上のコンテンツの正当な使用（」たTV-Anytimeフェーズ1「）;パート2：システムの説明、」ETSI-TS 102 822から2：システムの説明、V1.1.1、2003年10月。
[7] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[7]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。
[8] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[8]ハンドレー、M.、パーキンス、C.、およびE.ウィーラン、 "セッション告知プロトコル"、RFC 2974、2000年10月。
[9] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[9]ローチ、A.、 "セッション開始プロトコル（SIP）特異的イベント通知"、RFC 3265、2002年6月。
[10] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[10] SchulzrinneとH.とラオとA.、およびR. Lanphier、 "リアルタイムのストリーミングプロトコル（RTSP）"、RFC 2326、1998年4月。
[11] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., and J. Crowcroft, "Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC 3450, December 2002.
[11]ルビー、M.、Gemmell、J.、Vicisano、L.、リゾー、L.、およびJ.クロウクロフト、RFC 3450 "非同期階層は（ALC）プロトコルインスタンス化コーディング"、2002年12月。
[12] Paila, T., Luby, M., Lehtonen, R., Roca, V., and R. Walsh, "FLUTE - File Delivery over Unidirectional Transport", RFC 3926, October 2004.
[12] Paila、T.、ルビー、M.、Lehtonenの、R.、ロカ、V.、およびR.ウォルシュ、 "FLUTE - 単方向トランスポート上でファイル配信"、RFC 3926、2004年10月。
[13] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[13]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[14] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[14] Schulzrinneと、H.、Casner、S.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。
The authors would like to thank Spencer Dawkins, Jean-Pierre Evain, Ted Hardie, Petri Koskelainen, Joerg Ott, Colin Perkins, Toni Paila, and Magnus Westerlund for their excellent ideas and input to this document.
作者はこのドキュメントへの彼らの優れたアイデアや入力のためのスペンサードーキンスジャン=ピエール・Evain、テッドハーディー、ペトリ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
Hitoshi Asaeda Keio University Graduate School of Media and Governance 5322 Endo, Fujisawa, 252-8520 Kanagawa, Japan
ひとし あさえだ けいお うにゔぇｒしｔｙ Ｇらづあて Ｓちょおｌ おｆ めぢあ あんｄ ごゔぇｒなんせ ５３２２ えんど、 ふじさわ、 ２５２ー８５２０ かながわ、 じゃぱん
EMail: asaeda@wide.ad.jp
メールアドレス：asaeda@wide.ad.jp
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）によって提供されます。