RFC4435 日本語訳
4435 A Framework for the Usage of Internet Media Guides (IMGs). Y.Nomura, R. Walsh, J-P. Luoma, H. Asaeda, H. Schulzrinne. April 2006. (Format: TXT=51687 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループY.野村の要求をネットワークでつないでください: 4435の富士通研究室。 カテゴリ: 情報のR.ウォルシュJ-P。 LuomaノキアH.Asaeda慶応義塾大学H.Schulzrinneコロンビア大学2006年4月
A Framework for the Usage of Internet Media Guides (IMGs)
インターネットメディアガイドの使用法のための枠組み(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).
Copyright(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はSession記述プロトコル(SDP)、SDPng、または何らかの同様のセッション記述形式を使用することで言い表されたマルチメディアセッション記述の構造化された収集です。 このドキュメントはIMG排紙機構のための一般化されたモデル、既存のプロトコルの使用、および追加仕事がIMG配送インフラストラクチャを作成する必要性について説明します。
Nomura, et al. Informational [Page 1] RFC 4435 IMG Framework April 2006
野村、他 [1ページ]情報のRFC4435IMG枠組みの2006年4月
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
1. 序論…3 2. 用語…3 2.1. 新学期…4 3. IMGの一般的な枠組みのモデル…5 3.1. IMGデータ型…5 3.1.1. IMG記述を終了してください…5 3.1.2. デルタIMG記述…6 3.1.3. IMGポインタ…6 3.2. IMG実体…6 3.3. 操作はIMG配送のためにセットしました…7 3.3.1. IMGは発表します…7 3.3.2. IMG質問…8 3.3.3. IMG決心…8 3.3.4. IMGは申し込みます…8 3.3.5. IMGは通知します…9 3.3.6. IMG操作とデータ型の間で付きます…9 3.4. プロトコル操作の概観…10 4. IMG実体のための展開シナリオ…10 4.1. 仲介者事件…10 4.2. 多くへの1つの単方向のマルチキャスト…12 4.3. 1〜1つの双方向のユニキャスト…12 4.4. 一般的なメタデータに操作を結合します…13 5. 提案された枠組みのモデルへの既存のプロトコルの適用性…14 5.1. IMG枠組みのモデルに合う既存の規格…14 5.2. 既存の規格によって満たされないIMGメカニズム需要…15 5.2.1. マルチキャストトランスポート・プロトコル…16 5.2.2. ユニキャストトランスポート・プロトコルの用法…16 5.2.3. IMG封筒…17 5.2.4. メタデータデータはモデル化されます…18 6. セキュリティ問題…18 7. 標準の参照…19 8. 有益な参照…19 9. 承認…20
Nomura, et al. Informational [Page 2] RFC 4435 IMG Framework April 2006
野村、他 [2ページ]情報のRFC4435IMG枠組みの2006年4月
1. Introduction
1. 序論
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]、または他の記述形式を使用することで言い表されたマルチメディア記述の収集を構造化しました。 それらは、マルチメディアサービス(例えば、テレビ番組スケジュール、内容物配送スケジュール)のセットについて説明して、ウェブページを含む他のネットワークでつながれたリソースを示すのに使用されます。 IMGsはほかの場所で構造化するのを容易にする目的で定義されたメタデータ書式とセッション記述のための封筒を提供します、そのような情報にversioningして、参照をつけて、分配して、保守して(キャッシュしていて、アップデートしている)。
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個の基本要素があります: データ型、操作セット、および実体。 これらのコンポーネントは効率的な配送のための1セットの枠組みのガイドラインとIMGメタデータの記述を指定します。 データ型はアプリケーション特有のIMGメタデータの一貫性を送って、管理する一般化された手段を与えます。 IMG操作は放送、マルチキャスト分配、変化に関するイベント通知、ユニキャストベースのプッシュ、およびウェブページと同様のインタラクティブretrievalsをカバーしています。
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配送機能の観点からそれらの能力と限界を示すことを目指します。
2. Terminology
2. 用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[1]で説明されるように本書では解釈されることであるべきですか?
Nomura, et al. Informational [Page 3] RFC 4435 IMG Framework April 2006
野村、他 [3ページ]情報のRFC4435IMG枠組みの2006年4月
2.1. New Terms
2.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メタデータ: 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配送: ともに大規模で原子のデータ転送[4]でIMGメタデータを交換する過程。
IMG Sender: An IMG sender is a logical entity that sends IMG metadata
to one or more IMG receivers [4].
IMG送付者: IMG送付者は1台以上のIMG受信機[4]にIMGメタデータを送る論理的な実体です。
IMG Receiver: An IMG receiver is a logical entity that receives IMG
metadata from an IMG sender [4].
IMG受信機: IMG受信機はIMG送付者[4]から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受信機と送付者を結合します。 それは、受信されたIMGメタデータを変更するか、または数人の異なったIMG送付者[4]から受け取られた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送付者/受信機[4]のコントロールにIMG送付者とIMG受信機の間で使用されるIMGトランスポート・プロトコルの原子操作。
IMG Transport Protocol: A protocol that transports IMG metadata from
an IMG sender to IMG receiver(s) [4].
IMGはプロトコルを輸送します: IMG送付者からIMG受信機[4]までIMGメタデータを輸送するプロトコル。
IMG Transport Session: An association between an IMG sender and one
or more IMG receivers within the scope of an IMG transport
protocol. An IMG transport session involves a time-bound series
of IMG transport protocol interactions that provide delivery of
IMG metadata from the IMG sender to the IMG receiver(s) [4].
IMGはセッションを輸送します: IMGトランスポート・プロトコルの範囲の中のIMG送付者と1台以上のIMG受信機との仲間。 IMG輸送セッションはIMGメタデータのIMG送付者からIMG受信機[4]までの配送を提供する時間行きのシリーズのIMGトランスポート・プロトコル相互作用にかかわります。
Nomura, et al. Informational [Page 4] RFC 4435 IMG Framework April 2006
野村、他 [4ページ]情報のRFC4435IMG枠組みの2006年4月
IMG Transfer: A transfer of IMG metadata from an IMG sender to IMG
receiver(s).
IMGは移します: IMGメタデータのIMG送付者からIMG受信機までの転送。
3. IMG Common Framework Model
3. 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:
2つの一般的な要素がすべての既存の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輸送を制御するのは議定書を作ります。 これらの機能はいつも唯一であるというわけではありません。 したがって、いくつかのメッセージが、メッセージングの量を減少させるためにコントロールメッセージとメタデータキャリッジ機能を結合するかもしれません。
3.1. IMG Data Types
3.1. 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の実現に不可欠であり、別々の仕様を必要とします。 しかしながら、一般に、3つのIMGデータ型があります: IMG記述、デルタIMG記述、およびIMGポインタを終了してください。
3.1.1. Complete IMG Description
3.1.1. 完全な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,
Complete IMG記述は1つのメディア物かサービスに自己充足的なセットのメタデータを供給します、すなわち、それがいかなる他のIMG要素からの追加情報も必要としません。 「完全なIMGメタデータ」にこれを混乱させてはいけない、どれ、ここでばく然と定義されますが
Nomura, et al. Informational [Page 5] RFC 4435 IMG Framework April 2006
野村、他 [5ページ]情報のRFC4435IMG枠組みの2006年4月
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輸送セッションのときに完全なデータベースからメタデータの唯一の部分集合を救い出すでしょう。
3.1.2. Delta IMG Description
3.1.2. デルタ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記述はComplete IMG記述の一部だけを提供します、Complete IMG記述の旧バージョンから違いを定義して。 データの一貫性が不可欠であり、小さくて頻繁な変化がIMG要素の心に浮かぶとき、デルタIMG記述は、例えば、ネットワーク資源用法を減少させるのに使用されるかもしれません。 したがって、それが既に存在しているか、または将来到着するかもしれない他のメタデータに結合されるまで、この記述は完全なセットのメタデータを表しません。
3.1.3. IMG Pointer
3.1.3. 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 Pointerはメタデータの特定するか、または場所を見つけます。 これは、別々に、メタデータ(完全であるかデルタのIMG記述)を得るか、またはデータ満期(そして、消去)などの別のIMG管理機能を実行するのに使用されるかもしれません。 IMG PointerはIMG輸送セッション以内とIMG輸送セッションの向こう側に参照IMGメタデータ要素まで使用されるかもしれません。 このポインター型はそういうものとしてIMGメタデータを入れません(また、Completeのデータ・フィールドかデルタのIMG記述として現れるかもしれませんが)。
3.2. IMG Entities
3.2. 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 ANNOUNCEを送ります。
IMG Listener: receives IMG ANNOUNCE
IMGリスナー: IMG ANNOUNCEを受けます。
IMG Querier: sends IMG QUERY and receives IMG RESOLVE
IMG Querier: IMG QUERYを送って、IMG RESOLVEを受けます。
IMG Resolver: receives IMG QUERY then sends IMG RESOLVE
IMGレゾルバ: その時がIMG RESOLVEを送るIMG QUERYを受けます。
IMG Subscriber: sends IMG SUBSCRIBE then receives IMG NOTIFY
IMG加入者: 発信、そして、IMG SUBSCRIBEはIMG NOTIFYを受けます。
IMG Notifier: receives IMG SUBSCRIBE then sends IMG NOTIFY
IMG Notifier: その時がIMG NOTIFYを送るIMG SUBSCRIBEを受けます。
Nomura, et al. Informational [Page 6] RFC 4435 IMG Framework April 2006
野村、他 [6ページ]情報のRFC4435IMG枠組みの2006年4月
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 |
+------------------+------------------+------------------+
+--------------------------------------------------------+ | IMG送付者| +------------------+------------------+------------------+ | IMGアナウンサー| IMG Notifier| IMGレゾルバ| +------------------+------------------+------------------+ | ^ ^メッセージ| | | 指示v v対+------------------+------------------+------------------+ | IMGリスナー| IMG加入者| IMG Querier| +------------------+------------------+------------------+ | IMG受信機| +------------------+------------------+------------------+
Figure 1: Relationship between IMG Entities, Senders, and Receivers
図1: IMG実体と、送付者と、受信機との関係
3.3. Operation Set for IMG Delivery
3.3. 操作は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.
1つの有限集合の操作は、IMG必要条件[4]を満たして、既存のプロトコルの役割に合います。 これらは次の数セクションで結晶します。
3.3.1. IMG ANNOUNCE
3.3.1. 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 ANNOUNCEが別々の操作(ことによるとバンドからの)がIMG受信機がIMG ANNOUNCE操作に申し込むか、または登録されるのを可能にする非同期な請求された方法で使用されるのを防ぐために、制限は全くありません。
Nomura, et al. Informational [Page 7] RFC 4435 IMG Framework April 2006
野村、他 [7ページ]情報のRFC4435IMG枠組みの2006年4月
3.3.2. IMG QUERY
3.3.2. 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 QUERY操作を使用して、受信機駆動のIMG輸送セッションを開始できます。 IMG受信機はIMG送付者からのその後の要求への同期応答を予想します。 双方向の転送ネットワークがIMG送付者と受信機の間で入手できるところでこの操作を使用できます。いくつかのIMG受信機が、ネットワークの接続性が利用可能であるときに、IMGメタデータを得たいか、またはまさしく求められていないIMGメタデータをキャッシュするのを避けたがっているかもしれません。 IMG受信機は操作における何らかのメッセージで欲しかったメタデータに関する範囲とデータ型を示さなければなりません。 範囲はメタデータ記述の数と組分けを示します。 いくつかの場合、IMG送付者の完全なメタデータ収集を要求するのは可能であるかもしれません。
3.3.3. IMG RESOLVE
3.3.3. 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 QUERYに。双方向の転送ネットワークがIMG送付者と受信機の間で入手できるところでこの操作は使用できます。IMG QUERYがIMG送付者にとって、利用可能なIMGメタデータ(範囲とデータ型)の部分集合を指定するなら、IMG送付者は質問を決議できます。 さもなければ、それは、質問を決議できないのを示すべきです。 IMG送付者は、IMG受信機がそのメタデータを受け取るのが認可されるかどうか決定するためにQUERY操作の間、IMG受信機を認証するかもしれません。 また、送付者は、IMG受信機がメタデータの信憑性をチェックできるように、RESOLVE操作で認証データを入れるかもしれません。 この操作はIMGデータ型のいずれも運ぶかもしれません。
3.3.4. IMG SUBSCRIBE
3.3.4. 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送付者に知らせるためにそれとなく外すことの機能性を提供します。 それが更新される前に購読の満期(タイムアウト)によって非購読がそれとなく提供されるかもしれないことに注意されるべきです。
Nomura, et al. Informational [Page 8] RFC 4435 IMG Framework April 2006
野村、他 [8ページ]情報のRFC4435IMG枠組みの2006年4月
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 SUBSCRIBE操作が認可されたIMG受信機から来ているかをチェックするためにIMG受信機を認証するかもしれません。
3.3.5. IMG NOTIFY
3.3.5. 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 NOTIFYは以前のIMG SUBSCRIBEに対応して非同期に使用されます。 IMG NOTIFY操作が、アップデートされたIMGメタデータが利用可能であることを示すか、または既存のIMGメタデータの部分は聞き古したです。 IMG SUBSCRIBEがアクティブである時の一度以上をIMG NOTIFYに渡すかもしれません。 この操作はIMGデータ型のいずれも運ぶかもしれません。 また、IMG送付者は、IMG受信機がメッセージの信憑性をチェックできるように、IMG NOTIFY操作で認証データを入れるかもしれません。
3.3.6. Binding between IMG Operations and Data Types
3.3.6. 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データ型の間に結合を提供する必要があります。 この結合は、1セットの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メタデータにversioningしながら提供されなければならないので、聞き古したデータは、わたっているIMGメタデータの時の正当性を特定して、与えます。 それは、満期時間を示すことによってIMGメタデータを無効にしなければならなくて、任意に、IMGメタデータがなる時から有効な時間(おそらく未来の)を提供するかもしれません。 メタデータ物の時の正当性は、後でアップデートする必要があるかもしれません。 その上、結合はIMGメタデータに使用されるどんな特定のメタデータ構文からも独立しているに違いありません、どんな役に立つ構文も除くべきでないという意味で。
Nomura, et al. Informational [Page 9] RFC 4435 IMG Framework April 2006
野村、他 [9ページ]情報のRFC4435IMG枠組みの2006年4月
3.4. Overview of Protocol Operations
3.4. プロトコル操作の概観
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 |
| | |
+--------------+-----------------------------------+
+--------------------------------------------------+ IMG| | データ型| Descを完成してください、デルタDesc、ポインタ| | | +-------------------+----------------+-------------+ IMG| IMGは発表します。| IMGは申し込みます。| IMG質問| 操作| | IMGは通知します。| IMG決心| +--------------+----+----------------+-------------+ IMG| | | 輸送| PからM| PからP| | | | +--------------+-----------------------------------+
Figure 2: IMG Transport, IMG Operations, and IMG Data Types
図2: IMG輸送、IMG操作、およびIMGデータ型
4. Deployment Scenarios for IMG Entities
4. 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実体にいくつかの基本的な展開シナリオを提供します。 明快の目的のために、このドキュメントはIMG送付者からIMG受信機まで簡単なデータフローを提示します、図3に示されるように。
+-------------+ +---------------+
| IMG Sender | | IMG Receiver |
| |--------------->| |
+-------------+ +---------------+
+-------------+ +---------------+ | IMG送付者| | IMG受信機| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| +-------------+ +---------------+
Figure 3: A Simple IMG Sender to IMG Receiver Relationship
図3: IMG受信機関係への純真なIMG送付者
4.1. Intermediary Cases
4.1. 仲介者事件
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メタデータを受け取って、ことによると内容をフィルターにかけるか、または変更して、次にそれを進める1セットのIMGトランシーバーの向こう側にリレーされるかもしれません。
Nomura, et al. Informational [Page 10] RFC 4435 IMG Framework April 2006
野村、他 [10ページ]情報のRFC4435IMG枠組みの2006年4月
+----------+ +----------+
| IMG | | IMG |
| Sender |---- ---->| Receiver |
+----------+ \ / +----------+
\ /
. \ +-----------+ / .
. -->|IMG |----- .
. -->|Transceiver| \ .
/ +-----------+ \
+----------+ / \ +----------+
| IMG | / ---->| IMG |
| Sender |---- | Receiver |
+----------+ +----------+
+----------+ +----------+ | IMG| | IMG| | 送付者|---- ---->| 受信機| +----------+ \ / +----------+ \ / . \ +-----------+ / . . -->|IMG|----- . . -->|トランシーバー| \ . / +-----------+ \ +----------+ / \ +----------+ | IMG| / ---->| IMG| | 送付者|---- | 受信機| +----------+ +----------+
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メタデータを加えるか、または削除するかもしれません。 例えば、格付けのサービスはそれ自身の満足している格付けか推薦を既存のメタデータに追加するかもしれません。 1人以上のIMG送付者からの変化(または、集合)IMGメタデータの含意はオリジナルの信憑性が無くなるということです。 したがって、断片に署名するのは、仲介者が残りの信憑性を変えないで断片を置き換えることができるくらい有益であるかもしれません。 例えば、より揮発性の部分に、より小さい断片は適切であるかもしれません、そして、安定した部分に、より大きい適切であるかもしれません。
Nomura, et al. Informational [Page 11] RFC 4435 IMG Framework April 2006
野村、他 [11ページ]情報のRFC4435IMGフレームワーク2006年4月
4.2. One-to-Many Unidirectional Multicast
4.2. 多くへの1つの単方向のマルチキャスト
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 |
| # |
+----------+
単方向+----------+ --------------->| IMG| ダウンリンク| リスナー| ------------->| 1 | / +----------+ +-----------+ / . | IMG|-------- . | アナウンサー| \ . +-----------+ \ +----------+ ------------->| IMG| | リスナー| | # | +----------+
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つの単方向のマルチキャストケースを含んでいます。 しかしながら、これを提供するメカニズムはこのドキュメントの範囲を超えています。
4.3. One-to-One Bidirectional Unicast
4.3. 1〜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つの双方向のユニキャストでは、ケースは可能です両方が、(図7)交換処理操作を質問するか、決議して(6について計算します)、申し込むか、または通知する。
+----------+ +----------+
| IMG | | IMG |
| Resolver | | Querier |
+----------+ +----------+
| |
|<----------IMG QUERY -----------|
| |
|----------IMG RESOLVE---------->|
| |
+----------+ +----------+ | IMG| | IMG| | レゾルバ| | Querier| +----------+ +----------+ | | | <、-、-、-、-、-、-、-、-、--IMG質問-----------| | | |----------IMG決心---------->|、|、|
Figure 6: Query/Resolve Sequence Example
図6: 系列の例を質問するか、または決議してください。
Nomura, et al. Informational [Page 12] RFC 4435 IMG Framework April 2006
野村、他 [12ページ]情報のRFC4435IMGフレームワーク2006年4月
+----------+ +------------+
| IMG | | IMG |
| Notifier | | Subscriber |
+----------+ +------------+
| |
|<---------IMG SUBSCRIBE---------|
: :
(time passes)
: :
|-----------IMG NOTIFY---------->|
: :
(time passes)
: :
|-----------IMG NOTIFY---------->|
| |
+----------+ +------------+ | IMG| | IMG| | Notifier| | 加入者| +----------+ +------------+ | | | <、-、-、-、-、-、-、-、--IMGは申し込みます。---------| : : (時間パス) : : |-----------IMGは通知します。---------->| : : (時間パス) : : |-----------IMGは通知します。---------->|、|、|
Figure 7: Subscribe/Notify Sequence Example
図7: 系列の例に申し込むか、または通知してください。
4.4. Combined Operations with Common Metadata
4.4. 一般的なメタデータとの結合した操作
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 |
+-----------+ +--------------+
+--------------+ +-----------+ ---->| IMGリスナー| | IMG| / +--------------+ /| アナウンサー|----- +-------------+ / +-----------+ \ +--------------+ | IMG|-+ / ---->| IMGリスナー| | 記述| |-+ / | - - - - - - -| | メタデータ1| | | / +-----------+ /--->| IMG Querier| +-------------+ | | -----| IMG| <、-、-、--/ +--------------+ +-------------+ | \ | レゾルバ| +-------------+ \ +-----------+ <。----\ +--------------+ \ \--->| IMG Querier| \ +-----------+ | - - - - - - -| \| IMG| <、-、-、-、-、-、-、-、--、>| IMG| | Notifier| | 加入者| +-----------+ +--------------+
Figure 8: Combined System with Common Metadata
エイト環: 一般的なメタデータがある混合構造
Nomura, et al. Informational [Page 13] RFC 4435 IMG Framework April 2006
野村、他 [13ページ]情報のRFC4435IMGフレームワーク2006年4月
5. Applicability of Existing Protocols to the Proposed Framework Model
5. 提案されたフレームワークモデルへの既存のプロトコルの適用性
5.1. Existing Standards Fitting the IMG Framework Model
5.1. IMGフレームワークモデルに合う既存の規格
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: Complete IMG記述に含まれるように、セッションレベルパラメタ(メディアコーデックの例えば、スケジューリング、アドレシング、および使用)について説明するのにSDP形式[2]を使用できました。 拡大ポイントが形式が広げられるのを許容するSDPにありますが、制限がこの拡張機能の柔軟性にあります。 しかしながら、SDP構文は重要なオーバーヘッドなしでIMG記述とIMG Pointersを提供できません。 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.
いつでもテレビ: いつでもテレビのForum[6]はXML図式に基づく記述をテレビ具体的計画ガイドに供給します。 特定であるときはいつも、いつでもテレビは限られた程度でMPEG-7User記述プロフィールを使用します、ユーザー選択、用法歴史、およびaのためだけにもテレビ、データは他の図式のためにモデル化されます。 これらは、放送スケジュール、要求次第のプログラムガイド、およびプログラム事象について説明するために最適化されます。
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: 双方向のユニキャストIMGトランスポート・プロトコルとしてHTTPプロトコル[7]を使用できます。 要求回答指向のプロトコルであり、HTTPは、QUERY、RESOLVEなどの同期操作を実装するのによく適していて同等です。登録。 しかしながら、HTTPはANNOUNCEやNOTIFYなどの非同期動作を提供しません、そして、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
セッション発表プロトコル(SAP): SAP[8]によって提供された発表メカニズムはセッション発見情報の単方向の配送を提供します。 MIMEの種類識別子のペイロードの使用は、SDPがSAPのデフォルトペイロード形式であることを許容しますが
Nomura, et al. Informational [Page 14] RFC 4435 IMG Framework April 2006
野村、他 [14ページ]情報のRFC4435IMGフレームワーク2006年4月
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メッセージで使用されるべき任意のペイロード形式。 したがって、マルチキャストとユニキャストがIMG ANNOUNCEとIMG NOTIFY操作であると実装するのにSAPを使用できました。
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はスケーラブルで効率的な信頼性、ペイロードサイズのための伸展性、および輻輳制御を欠いています、そして、1つの記述だけがペイロード分割の不足のため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.
一口: RFC3265[9]で説明されたSIP特有のイベントメカニズムはIMG SUBSCRIBEとIMG NOTIFYが操作であると双方向のユニキャスト接続で実装する方法を提供します。 しかしながら、RFC3265が現在マルチキャストを考えないとき、このアプローチに関するスケーラビリティ問題があります。
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とANNOUNCEという検索とアップデート通知メカニズムを定義します。 これらのメソッドはRTSPの全体のストリーミングの制御機能の部分集合です。 したがって、これらは個々のメカニズムに利用可能であったはずがありません。しかしながら、IMG QUERY、IMG RESOLVE、およびIMG SUBSCRIBEを例示するのにRTSPのDESCRIBEメソッドを使用できました、そして、RTSPによって制御されたストリーミングのセッションのためにIMG NOTIFYを例示するのにRTSP ANNOUNCEは使用できました。
5.2. IMG Mechanism Needs Which Are Not Met by Existing Standards
5.2. 既存の規格によって満たされない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) そして、基本のメタデータの協定は、上記での相互運用性テストを可能にするためにモデル化されます。 以下のセクションはそれぞれのこれらについて説明します。
Nomura, et al. Informational [Page 15] RFC 4435 IMG Framework April 2006
野村、他 [15ページ]情報のRFC4435IMGフレームワーク2006年4月
5.2.1. A Multicast Transport Protocol
5.2.1. マルチキャストトランスポート・プロトコル
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 Reliable Multicast Transport(RMT)ワーキンググループからのAsynchronous Layered Coding(ALC)[11]プロトコルは、要件の多くを実現させるとき非常におもしろく、広げることができて、'の'プラグイン両方FEC(信頼性のための前進のError Correction)とCC(混雑Control)機能ブロックに能力を持っています。 それは単方向のマルチキャストオブジェクト輸送のために明確に設計されています。 ALCは完全に指定されるというわけではありません、RMTワーキンググループには、完全に指定されたプロトコルがFLUTE(Unidirectional Transportの上のファイルDelivery)[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能力は調査できました。
5.2.2. Usage of Unicast Transport Protocols
5.2.2. ユニキャストトランスポート・プロトコルの用法
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操作組の両方を可能にしなければなりません。 私たちは、HTTPを使用することでIMG QUERY-RESOLVE操作を達成できると予期します、他のトランスポート・プロトコルオプションがまた、考えるのに有益であるかもしれませんが。
Nomura, et al. Informational [Page 16] RFC 4435 IMG Framework April 2006
野村、他 [16ページ]情報のRFC4435IMGフレームワーク2006年4月
5.2.3. IMG Envelope
5.2.3. 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のヘッダーフィールドのどちらかが新たに定義されていた状態で、これができます。(または、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. '超構文'にサービスメタデータを示す、そして/または、埋め込むメタデータラッパー。 例えば、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.
これらのオプションの1つ以上が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
IMG記述の間にスーパーセット/部分集合関係があるとき、部分集合のIMG記述がスーパーセットのパラメタを引き継ぐと思われます。 その結果スーパーセットのIMG記述を運ぶとそれとなく定義されるかもしれないIMGメタデータ転送封筒
Nomura, et al. Informational [Page 17] RFC 4435 IMG Framework April 2006
野村、他 [17ページ]情報のRFC4435IMGフレームワーク2006年4月
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記述の関係は1個の封筒から別の封筒までわたるかもしれません。
5.2.4. Metadata Data Model
5.2.4. メタデータデータモデル
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の定義データモデルのさらなる議論は範囲を超えています。
6. Security Considerations
6. セキュリティ問題
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メタデータかその変更歴史の送付者か発生源を保証される必要があります。 これはサービスの否定かそれが与えるハイジャック試みを防ぐことができます。
Nomura, et al. Informational [Page 18] RFC 4435 IMG Framework April 2006
野村、他 [18ページ]情報のRFC4435IMGフレームワーク2006年4月
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操作でシステムかいかなる他の重要な領域へのアクセスも書かないRECOMMENDEDです。
7. Normative References
7. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
8. Informative References
8. 有益な参照
[2] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[2] ハンドレー、M.、およびV.ジェーコブソン、「SDP:」 「セッション記述プロトコル」、RFC2327、1998年4月。
[3] Kutscher, D., Ott, J., and C. Bormann, "Session description and
capability negotiation", Work in Progress, October 2003.
[3] クッチャー、D.、オット、J.、C.ボルマン、および「セッション記述と能力交渉」、Progress、10月2003日のWork
[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.、J-P.とオット、J.とH.Schulzrinne、「インターネットメディアガイドのための要件」というLuomaは進行中(2005年12月)で働いています。
[5] "Multimedia content description interface -- Part 1: Systems",
ISO/IEC 15938-1, July 2002.
[5]、「マルチメディアコンテント記述、インタフェース--第1部:、」 「システム」、ISO/IEC15938-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] いつでもテレビのフォーラム、「放送とパソコン通信:」 検索、個人的なストレージシステムにおける内容の選んで、正しい使用、(「いつでもテレビのフェーズ1インチ)」、。 第2部: 「システム記述」、ETSI-TS102 822-2: システム記述、V1.1.1、2003年10月。
Nomura, et al. Informational [Page 19] RFC 4435 IMG Framework April 2006
野村、他 [19ページ]情報のRFC4435IMGフレームワーク2006年4月
[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.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月。」
[8] Handley, M., Perkins, C., and E. Whelan, "Session Announcement
Protocol", RFC 2974, October 2000.
[8] ハンドレーとM.とパーキンス、C.とE.ウィーラン、「セッション発表プロトコル」、RFC2974、2000年10月。
[9] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[9] ローチ、A.、「セッション開始プロトコル(一口)特定のイベント通知」、RFC3265、2002年6月。
[10] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998.
1998年4月の[10]SchulzrinneとH.とラオ、A.とR.Lanphier、「リアルタイムのストリーミングのプロトコル(RTSP)」RFC2326。
[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.、リゾー、L.、およびJ.クロウクロフト、「非同期な層にされたコード化(ALC)は具体化について議定書の中で述べます」、RFC3450、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.、レヒトネン、R.、ロカ、V.、およびR.ウォルシュ、「フルート--単方向の輸送の上の配送をファイルしてください」、RFC3926、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.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、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:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、STD64、RFC3550、2003年7月。
9. Acknowledgements
9. 承認
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、およびマグヌスWesterlundに感謝したがっています。
Nomura, et al. Informational [Page 20] RFC 4435 IMG Framework April 2006
野村、他 [20ページ]情報のRFC4435IMGフレームワーク2006年4月
Authors' Addresses
作者のアドレス
Yuji Nomura Fujitsu Laboratories Ltd. 4-1-1 Kamikodanaka, Nakahara-ku, Kawasaki 211-8588 Japan
Kamikodanaka、Yuji野村富士通研究所4-1-1中原区、日本川崎211-8588
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、フィン-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、フィン-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
メディアの等Asaeda慶応義塾大学大学院とGovernance5322遠藤、藤沢、神奈川、252-8520日本
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ニューヨーク10027ニューヨーク(米国)のヘニングSchulzrinne部
EMail: schulzrinne@cs.columbia.edu
メール: schulzrinne@cs.columbia.edu
Nomura, et al. Informational [Page 21] RFC 4435 IMG Framework April 2006
野村、他 [21ページ]情報のRFC4435IMG枠組みの2006年4月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Nomura, et al. Informational [Page 22]
野村、他 情報[22ページ]
一覧
スポンサーリンク
