[要約] RFC 4435は、インターネットメディアガイド（IMG）の使用に関するフレームワークを提供しています。その目的は、IMGの効果的な利用と相互運用性の向上を促進することです。
Network Working Group Y. Nomura
Request for Comments: 4435 Fujitsu Labs.
Category: Informational R. Walsh
J-P. Luoma
Nokia
H. Asaeda
Keio University
H. Schulzrinne
Columbia University
April 2006
A Framework for the Usage of Internet Media Guides (IMGs)
インターネットメディアガイドの使用のためのフレームワーク（IMG）
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
This document defines a framework for the delivery of Internet Media Guides (IMGs). An IMG is a structured collection of multimedia session descriptions expressed using the Session Description Protocol (SDP), SDPng, or some similar session description format. This document describes a generalized model for IMG delivery mechanisms, the use of existing protocols, and the need for additional work to create an IMG delivery infrastructure.
このドキュメントでは、インターネットメディアガイド（IMG）の配信のためのフレームワークを定義しています。IMGは、セッション説明プロトコル（SDP）、SDPNG、または同様のセッション説明形式を使用して表現されたマルチメディアセッションの説明の構造化されたコレクションです。このドキュメントでは、IMGデリバリーメカニズムの一般化モデル、既存のプロトコルの使用、およびIMG配信インフラストラクチャを作成するための追加作業の必要性について説明します。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................3
2.1. New Terms ..................................................4
3. IMG Common Framework Model ......................................5
3.1. IMG Data Types .............................................5
3.1.1. Complete IMG Description ............................5
3.1.2. Delta IMG Description ...............................6
3.1.3. IMG Pointer .........................................6
3.2. IMG Entities ...............................................6
3.3. Operation Set for IMG Delivery .............................7
3.3.1. IMG ANNOUNCE ........................................7
3.3.2. IMG QUERY ...........................................8
3.3.3. IMG RESOLVE .........................................8
3.3.4. IMG SUBSCRIBE .......................................8
3.3.5. IMG NOTIFY ..........................................9
3.3.6. Binding between IMG Operations and Data Types .......9
3.4. Overview of Protocol Operations ...........................10
4. Deployment Scenarios for IMG Entities ..........................10
4.1. Intermediary Cases ........................................10
4.2. One-to-Many Unidirectional Multicast ......................12
4.3. One-to-One Bidirectional Unicast ..........................12
4.4. Combined Operations with Common Metadata ..................13
5. Applicability of Existing Protocols to the Proposed
Framework Model ................................................14
5.1. Existing Standard Fitting the IMG Framework Model .........14
5.2. IMG Mechanism Needs Which Are Not Met by Existing
Standards .................................................15
5.2.1. A Multicast Transport Protocol .....................16
5.2.2. Usage of Unicast Transport Protocols ...............16
5.2.3. IMG Envelope .......................................17
5.2.4. Metadata Data Model ................................18
6. Security Considerations ........................................18
7. Normative References ...........................................19
8. Informative References .........................................19
9. Acknowledgements ...............................................20
Internet Media Guides (IMGs) provide and deliver structured collections of multimedia descriptions expressed using SDP [2], SDPng [3], or other description formats. They are used to describe sets of multimedia services (e.g., television program schedules, content delivery schedules) and refer to other networked resources including web pages. IMGs provide an envelope for metadata formats and session descriptions defined elsewhere with the aim of facilitating structuring, versioning, referencing, distributing, and maintaining (caching, updating) such information.
インターネットメディアガイド（IMG）は、SDP [2]、SDPNG [3]、またはその他の説明形式を使用して表現されたマルチメディア説明の構造化コレクションを提供および提供します。それらは、マルチメディアサービスのセット（テレビ番組のスケジュール、コンテンツ配信スケジュールなど）を説明し、Webページを含む他のネットワークリソースを参照するために使用されます。IMGは、構造化、バージョン、参照、配布、およびそのような情報の維持（キャッシュ、更新）を促進する目的で、他の場所で定義されたメタデータ形式とセッションの説明の封筒を提供します。
IMG metadata may be delivered to a potentially large audience, which uses it to join a subset of the sessions described and which may need to be notified of changes to the IMG metadata. Hence, a framework for distributing IMG metadata in various different ways is needed to accommodate the needs of different audiences: For traditional broadcast-style scenarios, multicast-based (push) distribution of IMG metadata needs to be supported. Where no multicast is available, unicast-based push is required.
IMGメタデータは、潜在的に大勢のオーディエンスに配信される場合があります。これは、説明されているセッションのサブセットに参加するために使用し、IMGメタデータの変更を通知する必要がある場合があります。したがって、さまざまな視聴者のニーズに対応するために、IMGメタデータをさまざまな方法で配布するためのフレームワークが必要です。マルチキャストが利用できない場合、ユニキャストベースのプッシュが必要です。
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フレームワークモデルのエンティティとして定義された役割の1つ以上を実行します。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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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 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メタデータ：1つ以上の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 Sender: An IMG sender is a logical entity that sends IMG metadata to one or more IMG receivers [4].
IMG送信者：IMG送信者は、IMGメタデータを1つ以上のIMGレシーバーに送信する論理的エンティティです[4]。
IMG Receiver: An IMG receiver is a logical entity that receives IMG metadata from an IMG sender [4].
IMGレシーバー：IMGレシーバーは、IMG送信者からIMGメタデータを受信する論理的エンティティです[4]。
IMG Transceiver: An IMG transceiver combines an IMG receiver and sender. It may modify received IMG metadata or merge IMG metadata received from a several different IMG senders [4].
IMGトランシーバー：IMGトランシーバーは、IMGレシーバーと送信者を組み合わせます。受信したIMGメタデータを変更するか、いくつかの異なるIMG送信者から受け取ったIMGメタデータをマージする場合があります[4]。
IMG Operation: An atomic operation of an IMG transport protocol, used between IMG sender(s) and IMG receiver(s) for the delivery of IMG metadata and for the control of IMG sender(s)/receiver(s) [4].
IMG操作：IMG送信者とIMGレシーバーの間でIMGメタデータの配信とIMG送信者/受信機の制御に使用されるIMG輸送プロトコルの原子動作。
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 Transfer: A transfer of IMG metadata from an IMG sender to IMG receiver(s).
IMG転送：IMG送信者からIMGレシーバーへのIMGメタデータの転送。
Two common elements are found in all existing IMG candidate cases: the need to describe the services and the need to deliver the descriptions. In some cases, the descriptions provide multicast addresses and thus are part of the transport configuration. In other cases, descriptions are specific to the media application and may be meant for either human or machine consumption. Thus, the technologies can be roughly divided into three areas:
すべての既存のIMG候補のケースには、サービスを説明する必要性と説明を提供する必要性という2つの一般的な要素があります。場合によっては、説明がマルチキャストアドレスを提供するため、輸送構成の一部です。それ以外の場合、説明はメディアアプリケーションに固有であり、人間または機械の消費を対象としている場合があります。したがって、テクノロジーは大まかに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トランスポートプロトコルは、IMG送信者からIMGレシーバーにIMGメタデータを運ぶこととIMG輸送プロトコルの制御という2つの機能で構成されています。これらの機能は常に排他的ではありません。したがって、一部のメッセージは、コントロールメッセージとメタデータキャリッジ関数を組み合わせて、メッセージングの量を減らす場合があります。
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.
メタデータのセット、スーパーセット、およびサブセット間の用語と関係を正確に定義するには、データモデルが必要です。IMGの実装には正確なデータモデルが不可欠ですが、このフレームワークの範囲内ではなく、個別の仕様が必要です。ただし、一般的に3つのIMGデータ型があります。完全なIMG説明、Delta IMGの説明、IMGポインターです。
A Complete IMG Description provides a self-contained set of metadata for one media object or service, i.e., it does not need additional information from any other IMG element. This is not to be confused with "complete IMG metadata", which, although vaguely defined here, 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説明は、1つのメディアオブジェクトまたはサービスに自己完結型メタデータのセットを提供します。つまり、他の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.
Delta IMGの説明は、完全なIMG説明の一部の一部のみを提供し、以前のバージョンの完全なIMG説明の違いを定義します。たとえば、データの一貫性が不可欠であり、IMG要素に小さな変化が発生する場合、ネットワークリソースの使用量を削減するためにDelta 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ポインターは、メタデータを識別または見つけます。これは、メタデータ（完全またはDelta 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運用に関与するインターネットホストは、これらの役割の1つ以上を採用する場合があります。これらの役割は、セクション3.3でより詳細に定義されています。
IMG Announcer: sends IMG ANNOUNCE
IMGアナウンサー：IMGアナウンスを送信します
IMG Listener: receives IMG ANNOUNCE
IMGリスナー：IMGアナウンスを受信します
IMG Querier: sends IMG QUERY and receives IMG RESOLVE
IMG Querier：IMGクエリを送信してIMG Resolveを受信します
IMG Resolver: receives IMG QUERY then sends IMG RESOLVE
IMG Resolver：IMGクエリを受信してからIMG Resolveを送信します
IMG Subscriber: sends IMG SUBSCRIBE then receives IMG NOTIFY
IMGサブスクライバー：IMGサブスクライブを送信してからIMG Notifyを受信します
IMG Notifier: receives IMG SUBSCRIBE then sends IMG NOTIFY Figure 1 shows the relationship between IMG entities and the IMG sender and receiver.
IMG Notifier：IMGサブスクライブを受信してから、IMG通知を送信します図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.
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.
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レシーバーは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レシーバーから送信したIMGクエリに送信します。この操作は、IMG送信者と受信機の間で双方向輸送ネットワークが利用可能な場合に使用できます。IMGクエリが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送信者からのメッセージに通知することを求めます。
This operation may provide the IMG sender with specific details of which metadata or notification services it is interested in the case where the IMG sender offers more than the simplest "all data" service. This operation implicitly provides the functionality of unsubscribing to inform an IMG sender that an IMG receiver wishes to stop getting certain (or all) notifications. It should be noted that unsubscription may be provided implicitly by the expiry (timeout) of a subscription before it is renewed.
この操作は、IMG送信者に、IMG送信者が最も単純な「すべてのデータ」サービス以上のものを提供する場合に関心があるメタデータまたは通知サービスの特定の詳細を提供する場合があります。この操作は、IMG受信者が特定の（またはすべての）通知の取得を停止したいことをIMG送信者に通知するために、登録解除の機能を暗黙的に提供します。サブスクリプションが更新される前に、サブスクリプションの有効期限（タイムアウト）によって暗黙的に提供される可能性があることに注意する必要があります。
Since the IMG receiver does not know when metadata will be updated and the notify message will arrive, this operation does not synchronize with the notify messages. The IMG receiver may wait for notify messages for a long time. The IMG sender may authenticate the IMG receiver to check whether an IMG SUBSCRIBE operation is from an authorized IMG receiver.
IMGレシーバーは、メタデータがいつ更新され、Notifyメッセージが到着するかを知らないため、この操作はNotifyメッセージと同期しません。IMGレシーバーは、長い間通知メッセージを待つ場合があります。IMG送信者は、IMGレシーバーを認証して、IMGサブスクライブ操作が承認されたIMGレシーバーからのものであるかどうかを確認できます。
An IMG NOTIFY is used asynchronously in response to an earlier IMG SUBSCRIBE. An IMG NOTIFY operation indicates that updated IMG metadata is available or part of the existing IMG metadata is stale. An IMG NOTIFY may be delivered more than once during the time an IMG SUBSCRIBE is active. This operation may carry any of the IMG data types. The IMG sender may also include authentication data in the IMG NOTIFY operation so that IMG receivers may check the authenticity of the messages.
IMG通知は、以前のIMG購読に応じて非同期に使用されます。IMG通知操作は、更新されたIMGメタデータが利用可能であるか、既存のIMGメタデータの一部が古くなっていることを示しています。IMGのサブスクライブがアクティブになっている間、IMG通知は複数回配信される場合があります。この操作は、IMGデータ型を搭載する場合があります。IMG送信者には、IMGレシーバーがメッセージの信頼性を確認できるように、IMG通知操作に認証データを含めることもできます。
There is a need to provide a binding between the various IMG operations and IMG data types to allow management of each discrete set of IMG metadata transferred using an IMG operation. This binding must be independent of any particular metadata syntax used to represent a set of IMG metadata, as well as be compatible with any IMG transport protocol. The binding must uniquely identify the set of IMG metadata delivered within an IMG transfer, regardless of the metadata syntax used. The uniqueness may only be needed within the domains the metadata is used, but this must enable globally unique identification to support Internet usage. Care should be taken that scope- and domain-specific identifiers do not leak outside the scope; using globally unique identifiers such as URLs avoids these problems.
さまざまなIMG操作とIMGデータ型の間にバインディングを提供して、IMG操作を使用して転送されたIMGメタデータの各セットの管理を可能にする必要があります。この結合は、IMGメタデータのセットを表すために使用される特定のメタデータの構文と同様に、IMG輸送プロトコルと互換性がある必要があります。バインディングは、使用するメタデータの構文に関係なく、IMG転送内で提供されるIMGメタデータのセットを一意に識別する必要があります。一意性は、メタデータが使用されるドメイン内でのみ必要になる場合がありますが、これにより、インターネットの使用をサポートするためにグローバルに一意の識別を可能にする必要があります。範囲とドメイン固有の識別子がスコープの外側に漏れないことに注意する必要があります。URLなどのグローバルに一意の識別子を使用すると、これらの問題は回避されます。
The binding must provide versioning to the transferred IMG metadata so that changes can be easily handled and stale data identified, and give temporal validity of the transferred IMG metadata. It must invalidate the IMG metadata by indicating an expiry time, and may optionally provide a time (presumably in the future) from when the IMG metadata becomes valid. The temporal validity of a metadata object may need to be updated later. Furthermore, the binding must be independent of any specific metadata syntax used for the IMG metadata, in the sense that no useful syntax should be excluded.
バインディングは、転送されたIMGメタデータにバージョンを提供して、変更を簡単に処理し、古いデータを特定できるようにし、転送されたIMGメタデータの時間的妥当性を与える必要があります。有効期限を示すことによりIMGメタデータを無効にする必要があり、IMGメタデータが有効になったときから、オプションで時間（おそらく将来）を提供する場合があります。メタデータオブジェクトの時間的妥当性は、後で更新する必要がある場合があります。さらに、結合は、有用な構文を除外すべきではないという意味で、IMGメタデータに使用される特定のメタデータ構文とは無関係でなければなりません。
Figure 2 gives an overview of the relationship between transport cases, IMG operations, and IMG data types. It is not a protocol stack. Generalized multicast point-to-multipoint (P-to-M) and unicast point-to-point (P-to-P) transports are shown.
図2は、輸送ケース、IMG操作、およびIMGデータ型の関係の概要を示しています。プロトコルスタックではありません。一般化されたマルチキャストポイントツーマルチポイント（P-to-M）およびユニキャストポイントツーポイント（P-to-P）トランスポートが示されています。
+--------------------------------------------------+
IMG | |
Data Types | Complete Desc., Delta Desc., Pointer |
| |
+-------------------+----------------+-------------+
IMG | IMG ANNOUNCE | IMG SUBSCRIBE | IMG QUERY |
Operations | | IMG NOTIFY | IMG RESOLVE |
+--------------+----+----------------+-------------+
IMG | | |
Transport | P-to-M | P-to-P |
| | |
+--------------+-----------------------------------+
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メタデータは、1つのIMG送信者から複数のIMG受信機に分布している場合（図4）、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転送中に変更される場合があります。たとえば、サーバーはIMGを使用してUnicastを介してメディアコンテンツを取得し、マルチキャストを介してスケジュールされた時間に利用可能にするため、対応するメタデータを変更する必要があります。IMGトランシーバーは、さまざまなIMG送信者から情報を追加または削除したり、IMGメタデータを集約したりする場合があります。たとえば、格付けサービスは、既存のメタデータに独自のコンテンツ評価または推奨事項を追加する場合があります。IMGメタデータを1つ以上の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.
1対多くの単方向マルチキャストケースは、図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.
IMG要件REL-4 [4]で定義されているように、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.
1対1の双方向ユニキャストケースでは、クエリ/解決（図6）と購読/通知（図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 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は、クエリ、解決、さらには購読などの同期操作を実装するのに適しています。ただし、HTTPは、HTTPを使用して非同期操作を発表および通知し、実装するなどの非同期操作を提供しません。IMG受信機はIMG送信者に定期的にポーリングする必要があります。したがって、HTTP自体は、ユニキャスト展開ですべてのIMG要件[4]を満たすのに十分ではありません。
Session Announcement Protocol (SAP): The announcement mechanism provided by SAP [8] provides unidirectional delivery of session discovery information. Although SDP is the default payload format of SAP, the use of a MIME type identifier for the payload allows 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アナウンスを実装し、IMG通知オペレーションを通知できます。
However, SAP lacks scalable and efficient reliability, extensibility for payload size, and congestion control, and only one description is allowed per SAP message due to lack of payload segmentation.
ただし、SAPにはスケーラブルで効率的な信頼性、ペイロードサイズの拡張性、および渋滞制御が欠けており、ペイロードセグメンテーションの欠如によりSAPメッセージごとに1つの説明のみが許可されています。
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 [9]で説明されているSIP固有のイベントメカニズムは、IMGサブスクライブを実装し、IMGが双方向ユニキャスト接続を介して操作を通知する方法を提供します。ただし、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]は、ストリーミングセッションを初期化するためのプレゼンテーションまたはメディアオブジェクトの説明について、Describe and Announceという名前の検索およびアップデート通知メカニズムを定義します。これらの方法は、RTSPのストリーミング制御操作全体のサブセットです。したがって、これらは個々のメカニズムで利用できませんでした。ただし、RTSPの描写方法を使用してIMGクエリ、IMG Resolve、およびIMGサブスクライブをインスタンス化することができ、RTSPアナウンスを使用して、RTSPによって制御されるストリーミングセッションのIMG通知をインスタンス化できます。
Several needs result from the IMG requirements, framework model, and existing relevant mechanisms as already shown in this document. Four specific groupings of work are readily apparent: (a) specification of an adequate multicast- and unidirectional-capable announcement protocol; (b) specification of the use of existing unicast protocols to enable unicast subscribe and announcement/notification functionality; (c) specification of the metadata envelope that is common to, and independent of, the application metadata syntax(es) used; and (d) agreement on basic metadata models to enable interoperability testing of the above. The following sections describe each of these.
このドキュメントに既に示されているように、いくつかのニーズがIMG要件、フレームワークモデル、および既存の関連メカニズムから生じます。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.
IETF信頼性の高いマルチキャストトランスポート（RMT）ワーキンググループからの非同期層コーディング（ALC）[11]プロトコルは、多くの要件を満たし、拡張可能であり、両方のFEC（フォワードイン）を「プラグイン」する能力があるため、非常に興味深いものです（信頼性のためのエラー補正）およびCC（混雑制御）機能ブロック。一方向のマルチキャストオブジェクトトランスポート用に特別に設計されています。ALCは完全に指定されていませんが、RMTワーキンググループは、フルートと呼ばれるALC（単方向輸送を介したファイル配信）を使用した完全に指定されたプロトコルを持っていました[12]。フルートは、新しいIMGアナウンスプロトコルを設計できる唯一の完全に指定されたトランスポートとオープン仕様のようです。したがって、ALCとフルートがこのプロトコルの設計の出発点になることをお勧めします。
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アナウンス操作をサポートする必要があり、IMG通知機能をハイブリッドユニキャストマルチキャストと単方向ユニキャストシステムの両方について調査できます。
A thorough description of the use of existing unicast protocols is essential for the use of IMGs in a unicast point-to-point environment. Such a specification has not been published, although several usable unicast transport protocols and specifications can be harnessed for this (SIP [13], SIP events [9], HTTP [7], etc.). In particular, both IMG SUBSCRIBE-NOTIFY and IMG QUERY-RESOLVE operation pairs must be enabled. We anticipate that the IMG QUERY-RESOLVE operation can be achieved using HTTP, although other transport protocol options may be beneficial to consider too.
既存のユニキャストプロトコルの使用に関する徹底的な説明は、ユニキャストポイントツーポイント環境でのIMGの使用に不可欠です。このような仕様は公開されていませんが、いくつかの使用可能なユニキャスト輸送プロトコルと仕様をこのために活用できます（SIP [13]、SIPイベント[9]、HTTP [7]など）。特に、IMG Subscribe-NotifyとIMGクエリ再配置操作ペアの両方を有効にする必要があります。HTTPを使用してIMGクエリリゾルブ操作を実現できると予想されますが、他の輸送プロトコルオプションも考慮することが有益です。
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. 輸送プロトコルヘッダーに埋め込みます。これは、既存のプロトコルのヘッダー拡張機能、または新しい（またはaの新しいバージョン）トランスポートプロトコルの新たに定義されたヘッダーフィールドのいずれかで実行できます。ただし、さまざまな輸送プロトコルの複数の方法は、相互運用性と輸送プロトコルの独立性を妨げます。
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. サービスメタデータを「Super-syntax」に指し、および/または埋め込むメタデータラッパー。たとえば、XMLは一般的なテキストオブジェクトを埋め込むことができます。
4. Embedding in the metadata itself. However, this requires a new field in many metadata syntaxes and would not be feasible if a useful syntax were not capable of extensibility in this way. It also introduces a larger 'implementation interpretation' variety, which would hinder interoperability. Thus, this option is not recommended.
4. メタデータ自体に埋め込む。ただし、これには多くのメタデータ構文で新しいフィールドが必要であり、有用な構文がこの方法で拡張性を拡大できない場合、実行可能ではありません。また、より大きな「実装解釈」の多様性を導入し、相互運用性を妨げます。したがって、このオプションは推奨されません。
It is likely that more than one of these options will fulfill the needs of IMGs, so the selection, and possibly optimization, is left for subsequent specification and feedback from implementation experience. Such a specification is essential for IMG delivery.
これらのオプションの複数がIMGのニーズを満たす可能性が高いため、選択と最適化は、その後の仕様と実装エクスペリエンスからのフィードバックのために残されています。このような仕様は、IMG配信に不可欠です。
When there are superset/subset relations between IMG Descriptions, it is assumed that the IMG Descriptions of the subset inherit the parameters of the superset. Thus, an IMG metadata transfer envelope carrying the IMG Descriptions of a superset may implicitly define 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.
さまざまな環境でのIMGの展開を成功させるには、アプリケーション固有の要件のメタデータとデータモデルを定義するためにさらに作業が必要になる場合があります。これらに関する既存の（および将来の）作業は、上記のようにIMG転送エンベロープの概念のIMGデータ型と使用にマッピングする必要があります。
This document is a framework for the delivery of IMG metadata and thus further discussion on the definition data models for IMGs is beyond its scope.
このドキュメントは、IMGメタデータの配信のためのフレームワークであるため、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 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メタデータまたはその変更履歴の送信者または起源を保証する必要があります。これにより、メタデータ内またはメタデータに関するIMGレシーバーに誤った情報を提供するサービスの拒否またはハイジャックの試みを防ぐことができ、したがって、メディアへのアクセスの成功を妨げたり、IMGレシーバーを不正な材料で誤ったメディアに指示したりすることができます。
IMG receiver authorization: Some or all of any IMG sender's metadata may be private or valuable enough to allow access to only certain IMG receivers and thus make it worth authenticating users. Encrypting the data is also a reasonable step, especially where group communications methods results in unavoidable snooping opportunities for unauthorized nodes.
IMGレシーバーの承認：IMG送信者のメタデータの一部またはすべては、特定のIMGレシーバーのみにアクセスできるようにするのに十分なプライベートまたは価値があるため、ユーザーを認証する価値があります。データの暗号化も合理的なステップです。特に、グループ通信方法により、不正なノードの避けられないスヌーピングの機会が生じる場合です。
Unidirectional specifics: A difficulty that is faced by unidirectional delivery operations is that many protocols providing application-level security are based on bidirectional communications. The application of these security protocols in case of strictly unidirectional links is not considered in the present document.
単方向の詳細：単方向の配信操作が直面する難しさは、アプリケーションレベルのセキュリティを提供する多くのプロトコルが双方向通信に基づいていることです。現在のドキュメントでは、厳密に単方向リンクの場合のこれらのセキュリティプロトコルの適用は考慮されていません。
Malicious code: Currently, IMGs are not envisaged to deliver executable code at any stage. However, as some IMG transport protocols may be capable of delivering arbitrary files, it is RECOMMENDED that the IMG operations do not have write access to the system or any other critical areas.
悪意のあるコード：現在、IMGはどの段階でも実行可能コードを配信することは想定されていません。ただし、一部のIMGトランスポートプロトコルは任意のファイルを配信できる可能性があるため、IMG操作にはシステムまたはその他の重要な領域への書き込みアクセスがないことをお勧めします。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[2] Handley、M。and V. Jacobson、「SDP：セッション説明プロトコル」、RFC 2327、1998年4月。
[3] Kutscher, D., Ott, J., and C. Bormann, "Session description and capability negotiation", Work in Progress, October 2003.
[3] Kutscher、D.、Ott、J。、およびC. Bormann、「セッションの説明と能力交渉」、2003年10月の作業。
[4] Nomura, Y., Walsh, R., Luoma, J-P., Ott, J., and H. Schulzrinne, "Requirements for Internet Media Guides", Work in Progress, December 2005.
[4] Nomura、Y.、Walsh、R.、Luoma、J-P。、Ott、J。、およびH. Schulzrinne、「Internet Media Guidesの要件」、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-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] 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月。
[8] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[8] Handley、M.、Perkins、C。、およびE. Whelan、「セッションアナウンスプロトコル」、RFC 2974、2000年10月。
[9] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[9] Roach、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.、Rao、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] Luby、M.、Gemmell、J.、Vicisano、L.、Rizzo、L。、およびJ. Crowcroft、「非同期層コーディング（ALC）プロトコルインスタンス化」、RFC 3450、2002年12月。
[12] Paila, T., Luby, M., Lehtonen, R., Roca, V., and R. Walsh, "FLUTE - File Delivery over Unidirectional Transport", RFC 3926, October 2004.
[12] Paila、T.、Luby、M.、Lehtonen、R.、Roca、V。、およびR. Walsh、「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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INIATIATION Protocol"、RFC 3261、2002年6月。
[14] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[14] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、STD 64、RFC 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.
著者は、スペンサー・ドーキンス、ジャン・ピエール・エヴィン、テッド・ハーディ、ペトリ・コスケレイン、ジョーグ・オット、コリン・パーキンス、トニ・パイラ、マグナス・ウェスターランドの優れたアイデアとこの文書への入力に感謝したいと思います。
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
Hitoshi Asaeda Keio University Graduate School of Media and Governance 5322 Endo, Fujisawa, 252-8520 Kanagawa, Japan
asaeda keio大学メディアおよびガバナンス大学大学院5322 Endo、藤沢、252-8520 Kanagawa、日本
EMail: asaeda@wide.ad.jp
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）によって提供されます。