RFC4473 日本語訳
4473 Requirements for Internet Media Guides (IMGs). Y. Nomura, R.Walsh, J-P. Luoma, J. Ott, H. Schulzrinne. May 2006. (Format: TXT=53864 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group Y. Nomura
Request for Comments: 4473 Fujitsu Labs
Category: Informational R. Walsh
J-P. Luoma
Nokia
J. Ott
Helsinki University of Technology
H. Schulzrinne
Columbia University
May 2006
コメントを求めるワーキンググループY.野村の要求をネットワークでつないでください: 4473年の富士通研究室カテゴリ: 情報のR.ウォルシュJ-P。 技術H.Schulzrinneコロンビア大学2006年5月のLuomaノキアJ.オットヘルシンキ大学
Requirements for 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 memo specifies requirements for a framework and protocols for accessing and updating Internet Media Guide (IMG) information for media-on-demand and multicast applications. These requirements are designed to guide choice and development of IMG protocols for efficient and scalable delivery.
このメモはフレームワークのための要件とメディア要求次第とマルチキャストアプリケーションのためのインターネットメディアガイド(IMG)情報にアクセスして、アップデートするためのプロトコルを指定します。 これらの要件は、効率的でスケーラブルな配送のためにIMGプロトコルの選択と開発を誘導するように設計されています。
Nomura, et al. Informational [Page 1] RFC 4473 Requirements for Internet Media Guides (IMGs) May 2006
野村、他 インターネットメディアのための情報[1ページ]のRFC4473要件は2006年5月に(IMGs)を誘導します。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Background and Motivation ..................................3
1.2. Scope of This Document .....................................4
2. Terminology .....................................................5
2.1. New Terms ..................................................5
3. Problem Statement ...............................................6
4. Use Cases Requiring IMGs ........................................7
4.1. Connectivity-based Use Cases ...............................7
4.1.1. IP Datacast to a Wireless Receiver ..................7
4.1.2. Regular Fixed Dial-up Internet Connection ...........8
4.1.3. Broadband Always-on Fixed Internet Connection .......9
4.2. Content-orientated Use Cases ...............................9
4.2.1. TV and Radio Program Delivery .......................9
4.2.2. Media Coverage of a Live Event .....................10
4.2.3. Distance Learning ..................................10
4.2.4. Multiplayer Gaming .................................10
4.2.5. File Distribution ..................................11
4.2.6. Coming-release and Pre-released Content ............11
5. Requirements ...................................................11
5.1. General Requirements ......................................11
5.1.1. Independence of IMG Operations from IMG Metadata ...11
5.1.2. Multiple IMG Senders ...............................12
5.1.3. Modularity .........................................12
5.2. Delivery Properties .......................................12
5.2.1. Scalability ........................................13
5.2.2. Support for Intermittent Connectivity ..............13
5.2.3. Congestion Control .................................13
5.2.4. Sender- and Receiver-Driven Delivery ...............13
5.3. Customized IMGs ...........................................14
5.4. Reliability ...............................................15
5.4.1. Managing Consistency ...............................15
5.4.2. Reliable Message Exchange ..........................16
5.5. IMG Descriptions ..........................................16
6. Security Considerations ........................................17
6.1. IMG Authentication and Integrity ..........................18
6.2. Privacy ...................................................19
6.3. Access Control for IMGs ...................................19
6.4. Denial-of-Service (DOS) Attacks ...........................20
6.5. Replay Attacks ............................................20
7. Normative References ...........................................21
8. Informative References .........................................21
9. Acknowledgements ...............................................22
1. 序論…3 1.1. バックグラウンドと動機…3 1.2. このドキュメントの範囲…4 2. 用語…5 2.1. 新学期…5 3. 問題声明…6 4. IMGsを必要とするケースを使用してください…7 4.1. 接続性ベースの使用は…をケースに入れます…7 4.1.1. ワイヤレスの受信機へのIP Datacast…7 4.1.2. レギュラーの固定ダイヤルアップインターネット接続…8 4.1.3. 広帯域のいつもオンな固定インターネット接続…9 4.2. 内容で指向された使用は…をケースに入れます…9 4.2.1. テレビとラジオは配送をプログラムします…9 4.2.2. ライブイベントのメディア報道…10 4.2.3. 学習を遠ざけてください…10 4.2.4. マルチプレーヤーゲーミング…10 4.2.5. 分配をファイルしてください…11 4.2.6. 次のリリースとプレリリースされた内容…11 5. 要件…11 5.1. 一般要件…11 5.1.1. IMGメタデータからのIMG操作からの独立…11 5.1.2. 複数のIMG Senders…12 5.1.3. モジュール方式…12 5.2. 配送の特性…12 5.2.1. スケーラビリティ…13 5.2.2. 間欠接続性のために、サポートします。13 5.2.3. 混雑コントロール…13 5.2.4. 送付者と受信機駆動の配送…13 5.3. IMGsをカスタム設計します…14 5.4. 信頼性…15 5.4.1. 一貫性を管理します…15 5.4.2. 信頼できる交換処理…16 5.5. IMG記述…16 6. セキュリティ問題…17 6.1. IMG認証と保全…18 6.2. プライバシー…19 6.3. IMGsのためにコントロールにアクセスしてください…19 6.4. サービス妨害(DOS)は攻撃されます…20 6.5. 反射攻撃…20 7. 標準の参照…21 8. 有益な参照…21 9. 承認…22
Nomura, et al. Informational [Page 2] RFC 4473 Requirements for Internet Media Guides (IMGs) May 2006
野村、他 インターネットメディアのための情報[2ページ]のRFC4473要件は2006年5月に(IMGs)を誘導します。
1. Introduction
1. 序論
1.1. Background and Motivation
1.1. バックグラウンドと動機
For some ten years, multicast-based (multimedia) conferences (including IETF working group sessions) as well as broadcasts of lectures/seminars, concerts, and other events have been used in the Internet, more precisely, on the MBONE. Schedules and descriptions for such multimedia sessions as well as the transport addresses, codecs, and their parameters have been described using the Session Description Protocol (SDP) [2] as a rudimentary (but as of then largely sufficient) means. Descriptions have been disseminated using the Session Announcement Protocol (SAP) [3] and Session Directory Tools such as SD [4] or SDR [5]; descriptions have also been put up on web pages, sent by electronic mail, etc.
およそ10年間、講演/セミナーの放送と同様にマルチキャストを拠点とする(マルチメディア)会議(IETFワーキンググループセッションを含んでいる)、コンサート、および他のイベントは、よりまさにMBONEの上のインターネットで使用されています。 また、輸送が扱うようなマルチメディアセッション、コーデック、およびそれらのパラメタのためのスケジュールと記述は、初歩的な(しかし次に、主に十分現在)手段としてSession記述プロトコル(SDP)[2]を使用することで説明されます。 記述はサウスダコタ[4]かSDR[5]などのSession Announcementプロトコル(SAP)[3]とSessionディレクトリToolsを使用する播種性のです。 また、電子メールなどによって送られたウェブページで記述を提供しました。
Recently, interest has grown to expand -- or better: to generalize -- the applicability of these kinds of session descriptions. Descriptions are becoming more elaborate in terms of included metadata, more generic regarding the types of media sessions, and possibly also support other transports than just IP (e.g., legacy TV channel addresses). This peers well with the DVB (Digital Video Broadcasting) [6] Organization's increased activities towards IP- based communications over satellite, cable, and terrestrial radio networks, also considering IP as the basis for TV broadcasts and further services. The program/content descriptions are referred to as Internet Media Guides (IMGs) and can be viewed as a generalization of Electronic Program Guides (EPGs) and multimedia session descriptions.
最近、関心は、よりよく広がるようになりました: 総合してください--これらの種類のセッション記述の適用性。 記述は、メディアセッションのタイプに関して含まれているメタデータ、より多くのジェネリックで、より入念になっていて、また、ことによるとまさしくIP(例えば、レガシーテレビのチャンネル・アドレス)以外の輸送をサポートします。 これは衛星、ケーブル、および地球のラジオ放送網の上をDVB(デジタルVideo Broadcasting)[6]組織のより一層の営みで上手にIPのベースのコミュニケーションに向かってじっと見ます、また、IPがテレビ放送とさらなるサービスの基礎であるとみなして。 プログラム/内容記述をインターネットメディアガイド(IMGs)と呼んで、Electronic Programガイド(EPGs)とマルチメディアセッション記述の一般化として見なすことができます。
An Internet Media Guide (IMG) has a structured collection of multimedia session descriptions expressed using SDP, SDPng [7], or some similar session description format. This is used to describe a set of multimedia services (e.g., television program schedules, content delivery schedules) but may also refer to other networked resources including web pages. IMGs provide the envelope for metadata formats and session descriptions defined elsewhere with the aim of facilitating structuring, versioning, referencing, distributing, and maintaining (caching, updating) such information.
インターネットメディアガイド(IMG)は、SDP、SDPng[7]、または何らかの同様のセッション記述形式を使用することでマルチメディアセッション記述の構造化された収集を言い表させます。 これは、1セットのマルチメディアサービス(例えば、テレビ番組スケジュール、内容物配送スケジュール)について説明するのに使用されますが、また、ウェブページを含む他のネットワークでつながれたリソースを示すかもしれません。 IMGsはほかの場所で構造化するのを容易にする目的で定義されたメタデータ書式とセッション記述のための封筒を提供します、そのような情報にversioningして、参照をつけて、分配して、保守して(キャッシュしていて、アップデートしている)。
The IMG metadata may be delivered to a potentially large audience, who uses it to join a subset of the sessions described, and who may need to be notified of changes to this information. Hence, a framework for distributing IMG metadata in various different ways is needed to accommodate the needs of different audiences: For traditional broadcast-style scenarios, multicast-based (push) distribution of IMG metadata needs to be supported. Where no multicast is available, unicast-based push is required, too.
IMGメタデータは潜在的に大きい聴衆に提供されるかもしれません。(その聴衆は、説明されたセッションの部分集合を接合するのにそれを使用して、この情報への変化について通知される必要があるかもしれません)。 したがって、様々な異なった方法でIMGメタデータを分配するためのフレームワークが異なった聴衆の必要性を収容するのに必要です: 伝統的な放送スタイルシナリオのために、IMGメタデータのマルチキャストベースの(プッシュ)分配は、サポートされる必要があります。 また、どんなマルチキャストも利用可能でないところでは、ユニキャストベースのプッシュが必要です。
Nomura, et al. Informational [Page 3] RFC 4473 Requirements for Internet Media Guides (IMGs) May 2006
野村、他 インターネットメディアのための情報[3ページ]のRFC4473要件は2006年5月に(IMGs)を誘導します。
Furthermore, IMG metadata may need to be retrieved interactively, similar to web pages (e.g., after rebooting a system or when a user is browsing after network connectivity has been re-established). Finally, IMG metadata may be updated as time elapses because content described in the guide may be changed: for example, the airtime of an event such as a concert or sports event may change, possibly affecting the airtime of subsequent media. This may be done by polling the IMG sender as well as by asynchronous change notifications.
その上、IMGメタデータは、インタラクティブに検索される必要があるかもしれません、ウェブページと同様です(例えば、システムを再起動した後かネットワークの接続性が復職した後にユーザがブラウズしているときに時)。 最終的に、ガイドで説明された内容を変えるかもしれないので時間が経過するとき、IMGメタデータをアップデートするかもしれません: 例えば、コンサートかスポーツ大会などのイベントの放送時間は変化するかもしれません、ことによるとその後のメディアの放送時間に影響して。 IMG送付者に投票して、非同期な変更届出書はこれをするかもしれません。
Furthermore, any Internet host can be a sender of content and thus an IMG sender. Some of the content sources and sinks may only be connected to the Internet sporadically. Also, a single human user may use many different devices to access metadata. Thus, we envision that IMG metadata can be sent and received by, among others, cellular phones, Personal Digital Assistants (PDAs), personal computers, streaming video servers, set-top boxes, video cameras, and Digital Video Recorders (DVRs), and that the data be carried across arbitrary types of link layers, including bandwidth-constrained mobile networks. However, generally we expect IMG senders to be well- connected hosts.
その上、どんなインターネット・ホストも、内容の送付者とその結果、IMG送付者であるかもしれません。 満足しているソースといくつかの流し台が散発的にインターネットに接続されるだけであるかもしれません。 また、独身の人間のユーザは、メタデータにアクセスするのに多くの異なったデバイスを使用するかもしれません。 したがって、私たちは送ることができて、特に携帯電話によって受け取られたそのIMGメタデータ、パーソナルDigital Assistants(PDA)、パーソナルコンピュータ、ストリーミング・ビデオサーバ、セットトップボックス、ビデオカメラ、およびDigital Video Recorders(DVRs)を思い描きます、そして、データが任意のタイプのリンクの向こう側に運ばれるのは層にされます、帯域幅で制約つきなモバイルネットワークを含んでいて。 しかしながら、一般に私たちは、IMG送付者がよく接続されたホストであると予想します。
Finally, with many potential senders and receivers, different types of networks, and presumably numerous service providers, IMG metadata may need to be combined, split, filtered, augmented, modified, etc., on their way from the sender(s) to the receiver(s) to provide the ultimate user with a suitable selection of multimedia services according to her preferences, subscriptions, location, and context (e.g., devices, access networks).
最終的に多くの潜在的送付者と受信機による異なったタイプのネットワーク、およびおそらく多数のサービスプロバイダー、IMGメタデータは結合されて、分けられて、フィルターにかけられて、増大して、変更されるなど必要があるかもしれなくて、彼女によると、送付者から提供する受信機への途中では、マルチメディアの適当な品揃えの究極のユーザは好み、購読、位置、および文脈(例えば、デバイス、アクセスネットワーク)を修理します。
1.2. Scope of This Document
1.2. このドキュメントの範囲
This document defines requirements that Internet Media Guide mechanisms must satisfy in order to deliver IMG metadata to a potentially large audience. Since IMGs can describe many kinds of multimedia content, IMG methods are generally applicable to several scenarios.
このドキュメントはインターネットメディアガイドメカニズムに潜在的に大きい聴衆にIMGメタデータを提供するために満足させられなければならないという要件を定義します。 IMGsが多くの種類のマルチメディアコンテントについて説明できるので、一般に、IMGメソッドはいくつかのシナリオに適切です。
In considering wide applicability, this document provides the problem statement and discusses existing mechanisms in this area. Then several use case scenarios for IMGs are explained including descriptions of how IMG metadata and IMG delivery mechanisms contribute to these scenarios. Following this, this document provides general requirements that are independent of any transport layer mechanism and application, such as delivery properties, reliability, and IMG descriptions.
広い適用性を考える際に、このドキュメントは、問題声明を提供して、この領域で既存のメカニズムについて議論します。 そして、IMGメタデータとIMG排紙機構がどうこれらのシナリオに貢献するかに関する記述を含んでいて、IMGsが説明されるので、数個がケースシナリオを使用します。 これに続いて、このドキュメントはどんなトランスポート層メカニズムとアプリケーションからも独立している一般的な要件を提供します、配送の特性や、信頼性や、IMG記述などのように。
Nomura, et al. Informational [Page 4] RFC 4473 Requirements for Internet Media Guides (IMGs) May 2006
野村、他 インターネットメディアのための情報[4ページ]のRFC4473要件は2006年5月に(IMGs)を誘導します。
This document reflects investigating work on delivery mechanisms for IMGs and generalizing work on session announcement and initiation protocols, especially in the field of the MMUSIC working group (SAP, SIP [8], SDP).
このドキュメントはIMGsのために排紙機構で仕事を調査して、セッション発表と開始プロトコルで仕事を一般化しながら、反射します、特にMMUSICワーキンググループ(SAP、SIP[8]、SDP)の分野で。
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]で説明されるように本書では解釈されることであるべきですか?
2.1. New Terms
2.1. 新学期
Internet Media Guide (IMG): IMG is a generic term used to describe
the formation, delivery, and use of IMG metadata. The
definition of the IMG is intentionally left imprecise.
インターネットメディアは(IMG)を誘導します: IMGはIMGメタデータの構成、配送、および使用について説明するために費やされた総称です。 IMGの定義は故意に不正確なままにされます。
IMG Element: The smallest atomic element of metadata that can be
transmitted separately by IMG operations and referenced
individually from other IMG elements.
IMG要素: 別々にIMG操作で伝えて、他のIMG要素から個別に参照をつけることができるメタデータの最もわずかな原子。
IMG Metadata: A set of metadata consisting of one or more IMG
elements. IMG metadata describes the features of multimedia
content used to enable selection of and access to media
sessions containing content. For example, metadata may consist
of the URI, title, airtime, bandwidth needed, file size, text
summary, genre, and access restrictions.
IMGメタデータ: 1つ以上のIMG要素のメタデータの成ることのセット。 IMGメタデータはメディアセッションへの内容を含む選択とアクセスを可能にするのに使用されるマルチメディアコンテントの特徴について説明します。 例えば、メタデータはURI、タイトル、放送時間、必要である帯域幅、ファイルサイズ、テキスト概要、ジャンル、およびアクセス制限から成るかもしれません。
IMG Delivery: The process of exchanging IMG metadata in terms of both
large-scale and atomic data transfers.
IMG配送: 大規模なものと同様に原子のデータ転送でIMGメタデータを交換するプロセス。
IMG Sender: An IMG sender is a logical entity that sends IMG metadata
to one or more IMG receivers.
IMG送付者: IMG送付者は1台以上のIMG受信機にIMGメタデータを送る論理的な実体です。
IMG Receiver: An IMG receiver is a logical entity that receives IMG
metadata from an IMG sender.
IMG受信機: IMG受信機はIMG送付者からIMGメタデータを受け取る論理的な実体です。
IMG Transceiver: An IMG transceiver combines an IMG receiver and
sender. It may modify received IMG metadata or merge IMG
metadata received from several different IMG senders.
IMGトランシーバー: IMGトランシーバーはIMG受信機と送付者を結合します。 それは、受信されたIMGメタデータを変更するか、または数人の異なったIMG送付者から受け取られたIMGメタデータを合併するかもしれません。
IMG Operation: An atomic operation of an IMG transport protocol, used
between IMG sender(s) and IMG receiver(s) for the delivery of
IMG metadata and for the control of IMG sender(s)/receiver(s).
IMG操作: IMGメタデータの配送とIMG送付者/受信機のコントロールにIMG送付者とIMG受信機の間で使用されるIMGトランスポート・プロトコルの原子操作。
IMG Transport Protocol: A protocol that transports IMG metadata from
an IMG sender to IMG receiver(s).
IMGはプロトコルを輸送します: IMG送付者からIMG受信機までIMGメタデータを輸送するプロトコル。
Nomura, et al. Informational [Page 5] RFC 4473 Requirements for Internet Media Guides (IMGs) May 2006
野村、他 インターネットメディアのための情報[5ページ]のRFC4473要件は2006年5月に(IMGs)を誘導します。
IMG Transport Session: An association between an IMG sender and one
or more IMG receivers within the scope of an IMG transport
protocol. An IMG transport session involves a time-bound
series of IMG transport protocol interactions that provide
delivery of IMG metadata from the IMG sender to the IMG
receiver(s).
IMGはセッションを輸送します: IMGトランスポート・プロトコルの範囲の中のIMG送付者と1台以上のIMG受信機との仲間。 IMG輸送セッションはIMGメタデータのIMG送付者からIMG受信機までの配送を提供する時間行きのシリーズのIMGトランスポート・プロトコル相互作用にかかわります。
3. Problem Statement
3. 問題声明
As we enumerate the requirements for IMGs, it will become clear that they are not fully addressed by the existing protocols. The "Framework for the Usage of Internet Media Guides" [9] discusses about these issues in more detail.
私たちがIMGsのための要件を列挙するとき、彼らが既存のプロトコルによって完全に扱われるというわけではないのは明確になるでしょう。 「インターネットメディアガイドの使用法のためのフレームワーク」[9]はこれらの問題に関してさらに詳細に議論します。
The MMUSIC working group has long been investigating content, media and service information delivery mechanisms, and protocols, and has itself produced the Session Announcement Protocol (SAP), the Session Description Protocol (SDP), and the Session Initiation Protocol (SIP). SDP is capable of describing multimedia sessions (i.e., content in a wider sense) by means of limited descriptive information intended for human perception plus transport, scheduling information, and codecs and addresses for setting up media sessions. SIP and SAP are protocols to distribute these session descriptions.
MMUSICワーキンググループは、長い間内容、メディア、サービス情報送達メカニズム、およびプロトコルを調査していて、それ自体を生産させます。Session Announcementプロトコル(SAP)、Session記述プロトコル(SDP)、およびSession Initiationプロトコル(SIP)。 SDPは人間の知覚と輸送のために意図する限られた描写的である情報によってマルチメディアセッション(すなわち、より広い意味における内容)について説明できます、メディアセッションをセットアップするための情報、コーデック、およびアドレスの計画をして。 SIPとSAPはこれらのセッション記述を広げるプロトコルです。
However, we perceive a lack of a standard solution for scalable IMG delivery mechanism in the number of receivers with consistency of IMG metadata between an IMG sender and IMG receiver for both bi- directional and unidirectional transport. With increased service dynamics and complexity, there is an increased requirement for updates to these content descriptions.
しかしながら、私たちは両方のためのIMG送付者とIMG受信機の間のIMGメタデータの一貫性が2方向上の受信機と単方向の輸送の数におけるスケーラブルなIMG排紙機構の標準液の不足を知覚します。 増強されたサービス力学と複雑さと共に、これらの満足している記述へのアップデートのための増強された要件があります。
HTTP [10] is a well-known information retrieval protocol using bi- directional transport and is widely used to deliver web-based content descriptions to many hosts. However, it has well-recognized limitations of scalability in the number of HTTP clients since it relies on the polling mechanism to keep information consistent between the server and client.
HTTP[10]は、両性愛者の方向の輸送を使用するよく知られる情報検索プロトコルであり、ウェブベースの満足している記述を多くのホストに提供するのに広く使用されます。 しかしながら、それには、HTTPクライアントの数における、スケーラビリティのよく認識された制限が、サーバとクライアントの間で一貫しているように情報を保つために世論調査メカニズムを当てにするので、あります。
SAP [3] is an announcement protocol that distributes session descriptions via multicast. It does not support prioritization or fine-grained metadata selection and update notifications, as it places restrictions on metadata payload size and always sends the whole metadata. It requires a wide-area multicast infrastructure for it to be deployable beyond a local area network.
SAP[3]はマルチキャストでセッション記述を広げる発表プロトコルです。 それは、優先順位づけかきめ細かに粒状のメタデータ選択をサポートして、通知をアップデートしません、メタデータペイロードサイズに関して制限を課して、いつも全体のメタデータを送るとき。 それがローカル・エリア・ネットワークを超えて配布可能であることが広い領域マルチキャストインフラストラクチャを必要とします。
Nomura, et al. Informational [Page 6] RFC 4473 Requirements for Internet Media Guides (IMGs) May 2006
野村、他 インターネットメディアのための情報[6ページ]のRFC4473要件は2006年5月に(IMGs)を誘導します。
SIP [8] and SIP-specific event notifications [11] can be used to notify subscribers of the update of IMG metadata for bi-directional transport. However, it is necessary to define an event package for IMGs.
双方向の輸送のためにIMGメタデータのアップデートについて加入者に通知するのにSIP[8]とSIP特有のイベント通知[11]を使用できます。 しかしながら、IMGsのためにイベントパッケージを定義するのが必要です。
We also perceive a lack of standard solution for flexible content descriptions to support a multitude of application-specific metadata and associated data models with a different amount of detail and different target audiences.
また、私たちは、フレキシブルな満足している記述の標準液の不足が異なった量の詳細と異なった対象者と共にアプリケーション特有のメタデータと関連データモデルの多数をサポートすると知覚します。
SDP [2] has a text-encoded syntax to specify multimedia sessions for announcements and invitations. It is primarily intended to describe client capability requirements and enable client application selection. Although SDP is extensible, it has limitations such as structured extensibility and capability to reference properties of a multimedia session from the description of another session.
SDP[2]には、発表と招待状のためのマルチメディアセッションを指定するテキストでコード化された構文があります。 それは、クライアント信用要求事項について説明して、クライアントアプリケーション選択を可能にすることを主として意図します。 SDPは広げることができますが、それは別のセッションの記述からのマルチメディアセッションの参照の特性に構造化された伸展性や能力などの制限を持っています。
These can mostly be overcome by the XML-based SDPng [7] -- which is intended for both two-way negotiation and unidirectional delivery -- or similar content description mechanisms. Since SDPng addresses multiparty multimedia conferences, it would be necessary to extend the XML schema in order to describe general multimedia content.
XMLベースのSDPng[7]か同様の満足している記述メカニズムがこれらにほとんど打ち勝つことができます。([7]は両用交渉と単方向の配送の両方のために意図します)。SDPngが、「マルチ-パーティー」マルチメディアが会議であると扱うので、XML図式を広げるのが一般的なマルチメディアコンテントについて説明するのに必要でしょう。
4. Use Cases Requiring IMGs
4. IMGsを必要とするケースを使用してください。
4.1. Connectivity-based Use Cases
4.1. 接続性ベースの使用はケースに入れます。
4.1.1. IP Datacast to a Wireless Receiver
4.1.1. ワイヤレスの受信機へのIP Datacast
IP Datacast is the delivery of IP-based services over broadcast radio. Internet content delivery is therefore unidirectional in this case. However, there can be significant benefits from being able to provide rich media one-to-many services to such receivers.
IP Datacastは放送ラジオの上のIPベースのサービスの配送です。 したがって、この場合インターネット内容物配送は単方向です。 しかしながら、存在からのそのような受信機に対する多くへの1つのサービスをリッチメディアに提供できる重要な利益があることができます。
There are two main classes of receiver in this use case: fixed mains-powered and mobile battery-powered. Both of these are affected by radio phenomena and so robust, or error-resilient, delivery is important. Carouselled metadata transfer (cyclically repeated with a fixed bandwidth) provides a base level of robustness for an IP datacast-based announcement system, although the design of carouselled transfer should enable battery-powered receivers to go through periods of sleep to extend their operational time between charges. Insertion of Forward Error Correction (FEC) data into metadata announcements improves error resilience, and reordering (interleaving) data blocks further increases tolerance to burst errors.
この使用での受信機の主なクラスがケースに入れる2があります: メインによる動力付きであって携帯電話のバッテリーによる動力付きで、修理されています。 これらの両方がラジオ現象で影響を受けます、そして、とても強健であるか、誤り立ち直りの早い配送は重要です。 Carouselledメタデータ転送(固定帯域幅で周期的に繰り返される)はIPのdatacastベースの発表システムに基準面の丈夫さを供給します、carouselled転送のデザインが、バッテリーによる動力付きの受信機が充電の間で彼らの操作上の時間を延ばすために睡眠の一区切りに直面しているのを可能にするべきですが。 メタデータ発表へのForward Error Correction(FEC)データの挿入は誤り弾力を改良します、そして、再命令(インターリービング)データ・ブロックはさらにバースト誤りに寛容を増強します。
Nomura, et al. Informational [Page 7] RFC 4473 Requirements for Internet Media Guides (IMGs) May 2006
野村、他 インターネットメディアのための情報[7ページ]のRFC4473要件は2006年5月に(IMGs)を誘導します。
To enable receivers to more accurately specify the metadata they are interested in, the unidirectional delivery may be distributed between several logical channels. This is so that a receiver needs only access the channels of interest and thus can reduce the amount of time, storage, and CPU resources needed for processing the IP data. Also, hierarchical channels enable receivers to subscribe to a (possibly well-known) root multicast channel/group and progressively access only those additional channels based on metadata in parent channels.
受信機が、より正確にそれらが興味を持っているメタデータを指定するのを可能にするために、単方向の配送はいくつかの論理チャネルの間に広げられるかもしれません。 これは、必要性がチャンネルにアクセスするだけである受信機がIPデータを処理するのに必要である時間、ストレージ、およびCPUリソースを関心があって、その結果、減らすことができるためのそうです。 また、階層的なチャンネルは、受信機が(ことによるとよく知られる)の根のマルチキャストチャンネル/グループに加入して、次第に親チャンネルによるメタデータに基づくそれらの追加チャンネルだけにアクセスするのを可能にします。
In some cases, the receiver may have multiple access interfaces adding bi-directional communications capability. This enables a multitude of options, but most important, it enables NACK-based reliability and the individual retrieval of missed or not-multicast sets of metadata.
いくつかの場合、受信機には、双方向のコミュニケーション能力を加える複数のアクセスインタフェースがあるかもしれません。 これはオプションの多数を可能にしますが、最も重要であることで、それはナックベースの信頼性と逃されることの個々の検索かメタデータのマルチキャストでないセットを可能にします。
Thus, essential IMG features in this case include the following: robust unidirectional delivery (with optional levels of reliability including "plug-in FEC" supported by a transport layer protocol), which implies easily identifiable segmentation of delivery data to make FEC, carousel, interleaving, and other schemes possible; effective identification of metadata sets (probably uniquely) to enable more efficient use of multicast and unicast retrieval over multiple access systems regardless of the parts of metadata and application-specific extensions in use; and prioritization of metadata, which can (for instance) be achieved by spreading it between channels and allocating/distributing bandwidth accordingly.
したがって、不可欠のIMGの特徴はこの場合以下を含んでいます: 体力を要している単方向の配送(任意のレベルの信頼性がトランスポート層プロトコルによってサポートされた「プラグインFEC」を含んでいる)(それは、FEC、回転木馬、インターリービング、および他の体系を可能にするように配送データの容易に身元保証可能な分割を含意します)。 メタデータセットの有効な識別、(たぶん、唯一)、メタデータと使用中のアプリケーション特有の拡大の部品にかかわらず複数のアクセスシステムの上のマルチキャストとユニキャスト検索の、より効率的な使用を可能にするために。 そして、メタデータの優先順位づけ。(例えば) (それに従って、帯域幅をチャンネルの間にそれを広げて、割り当てるか、または分配することによって、それを達成できます)。
Furthermore, some cases require IMG metadata authentication and some group security/encryption and supporting security message exchanges (out of band from the IMG multicast sessions).
その上、いくつかのケースが、IMGメタデータ認証と、何らかのグループセキュリティ/暗号化とセキュリティ交換処理をサポートするのを(IMGマルチキャストセッションからのバンドからの)必要とします。
4.1.2. Regular Fixed Dial-up Internet Connection
4.1.2. レギュラーの固定ダイヤルアップインターネット接続
Dial-up connections tend to be reasonably slow (<56 kbps in any case), and thus large data transfers are less feasible, especially during an active application session (such as a file transfer described by IMG metadata). They can also be intermittent, especially if a user is paying for the connected time, or connected through a less reliable exchange. Thus, this favors locally stored IMG metadata over web-based browsing, especially where parts of the metadata change infrequently. There may be no service provider preference over unicast and multicast transport for small and medium numbers of users as the last-mile dial-up connection limits per-user congestion, and a user may prefer the more reliable option (unicast unless reliable multicast is provided).
ダイアルアップ接続は、合理的に遅い(どんな場合でも<56キロビット毎秒)傾向があります、そして、その結果、大きいデータ転送はそれほど可能ではありません、特に選考中の応募者セッション(IMGメタデータによって説明されたファイル転送などの)の間。 また、それらも間欠である場合があります、特に、ユーザが関連時間に支払うか、またはそれほど信頼できない交換を通して接されるなら。 したがって、これはウェブベースのブラウジングより局所的に保存されたIMGメタデータを好んで、特にどこがメタデータ変化をまれに離れさせるか。 最後のマイルダイアルアップ接続が1ユーザあたりの混雑を制限するのでユニキャストとマルチキャスト輸送の上にサービスプロバイダー好みが全く小さくて中くらいの数のユーザのためにないかもしれなくて、ユーザが、より信頼できるオプションを好むかもしれない、(ユニキャスト、信頼できるマルチキャストが提供されない、)
Nomura, et al. Informational [Page 8] RFC 4473 Requirements for Internet Media Guides (IMGs) May 2006
野村、他 インターネットメディアのための情報[8ページ]のRFC4473要件は2006年5月に(IMGs)を誘導します。
4.1.3. Broadband Always-on Fixed Internet Connection
4.1.3. 広帯域のいつもオンな固定インターネット接続
Typically, bandwidth is less of an issue to a broadband user and unicast transport, such as using query-response methods, may be typical for a PC user. If a system were only used in this context, with content providers, ISPs, and users having no other requirements, then web-based browsing may be equally suitable. However, broadband users sharing a local area network, especially wireless, may benefit more from local storage features than on-line browsing, especially if they have intermittent Internet access.
広帯域のユーザには、帯域幅は問題で通常、少ないです、そして、PCユーザにとって、質問応答メソッドを使用などなどのユニキャスト輸送は典型であるかもしれません。 システムが他の要件を全く持っていないコンテンツプロバイダー、ISP、およびユーザと共にこのような関係においては使用されただけであるなら、ウェブベースのブラウジングは等しく適当であるかもしれません。 しかしながら、ローカル・エリア・ネットワークを共有している広帯域の特にワイヤレスであることのユーザはオンラインブラウジングより地方のストレージ機能から利益を得るかもしれません、特にそれらに間欠インターネット・アクセスがあるなら。
Some services on broadband, such as live media broadcasting, benefit from multicast transport for streaming media because of scalability. In the cases where multicast transport is already available, it is convenient for a sender and receiver to retrieve IMG metadata over multicast transport. Thus, broadband users may be forced to retrieve IMG metadata over multicast if backbone operators require this to keep system-wide bandwidth usage feasible.
ライブメディア放送などのブロードバンドにおけるいくつかのサービスがスケーラビリティでストリーミング・メディアのためにマルチキャスト輸送の利益を得ます。 マルチキャスト輸送が既に利用可能である場合では、送付者と受信機に、マルチキャスト輸送の上でIMGメタデータを検索するのは都合がよいです。 したがって、バックボーンオペレータがシステム全体の帯域幅用法を可能に保つためにこれを必要とするなら、広帯域のユーザはマルチキャストの上でやむを得ずIMGメタデータを検索するかもしれません。
4.2. Content-orientated Use Cases
4.2. 内容で指向された使用はケースに入れます。
IMGs will be able to support a very wide range of use cases for enabling content/media delivery. The following few sections just touch the surface of what is possible and are intended to provide an understanding of the scope and type of IMG usage. Many more examples may be relevant, for instance, those detailed in [12]. There are several unique features of IMGs that set them apart from related application areas such as Service Location Protocol (SLP) based service location discovery, Lightweight Directory Access Protocol (LDAP) based indexing services, and search engines such as Google. Features unique to IMGs include the following:
IMGsは、内容/メディア配送を可能にするために非常に広範囲の使用がケースであるとサポートすることができるでしょう。 以下の数セクションがただ何が可能であり、範囲の理解とIMG用法のタイプを提供することを意図するかに関する表面に接触します。 例えば、ものは、[12]でずっと多くの例が関連しているかもしれないのを詳しく述べました。 Service Locationのプロトコルの(SLP)ベースのサービス位置の発見などの関連出願部、サービスに索引をつけながら基づくライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)、およびGoogleなどのサーチエンジンと彼らを区別して目立たせるIMGsのいくつかのユニークな特徴があります。 IMGsにユニークな特徴は以下を含んでいます:
o IMG metadata is generally time-related
o 一般に、IMGメタデータは時間関連です。
o There are timeliness requirements in the delivery of IMG
metadata
o IMGメタデータの配送にはタイムリー要件があります。
o IMG metadata may be updated as time elapses or when an event
arises
o 時間が経過するか、またはイベントが起こるときに時IMGメタデータをアップデートするかもしれません。
4.2.1. TV and Radio Program Delivery
4.2.1. テレビとラジオ番組配送
A sender of audio/video streaming content can use the IMG metadata to describe the scheduling and other properties of audio/video sessions and events within those sessions, such as individual TV and radio programs and segments within those programs. IMG metadata describing audio/video streaming content could be represented in a format
オーディオ/ビデオ・ストリーミング内容の送付者はそれらのセッション以内にオーディオ/ビデオセッションとイベントのスケジューリングと他の特性について説明するのにIMGメタデータを使用できます、それらのプログラムの中の個々のテレビや、ラジオ番組やセグメントのように。形式でオーディオ/ビデオ・ストリーミング内容について説明するIMGメタデータは表すことができました。
Nomura, et al. Informational [Page 9] RFC 4473 Requirements for Internet Media Guides (IMGs) May 2006
野村、他 インターネットメディアのための情報[9ページ]のRFC4473要件は2006年5月に(IMGs)を誘導します。
similar to that of a TV guide in newspapers, or an Electronic Program Guide available on digital TV receivers.
新聞、またはデジタルテレビ受信機で利用可能なElectronic Programガイドのテレビのガイドのものと同様です。
TV and radio programs can be selected for reception either manually by the end-user or automatically based on the content descriptions and the preferences of the user. The received TV and radio content can be either presented in real time or recorded for later consumption. There may be changes in the scheduling of a TV or a radio program, possibly affecting the transmission times of subsequent programs. IMG metadata can be used to notify receivers of such changes, enabling users to be prompted or recording times to be adjusted.
テレビとラジオ番組は、レセプションのためにエンドユーザによって手動で選択されるか、または自動的に満足している記述とユーザの好みに基づくことができます。 容認されたテレビとラジオ内容をリアルタイムで、提示するか、または後の消費で記録できます。 テレビかラジオ番組のスケジューリングにおける変化があるかもしれません、ことによるとその後のプログラムのトランスミッション倍に影響して。そのような変化の受信機に通知するのにIMGメタデータを使用できます、ユーザが調整されるためにうながされるか、または回を記録しているのを可能にして。
4.2.2. Media Coverage of a Live Event
4.2.2. ライブイベントのメディア報道
The media coverage of a live event such as a rock concert or a sports event is a special case of regular TV/radio programming. There may be unexpected changes in the scheduling of a live event, or the event may be unscheduled to start with (such as breaking news). In addition to audio/video streams, textual information relevant to the event (e.g., statistics of the players during a football match) may be sent to user terminals. Different transport modes or even different access technologies can be used for the different media: for example, a unidirectional datacast transport could be used for the audio/video streams and an interactive cellular connection for the textual data. IMG metadata should enable terminals to discover the availability of different media used to cover a live event.
ロックコンサートかスポーツ大会などのライブイベントのメディア報道は定期的なテレビ/ラジオの番組編成の特別なケースです。 ライブイベントのスケジューリングには意外な変化があるかもしれませんか、またはイベントは、始めるために予定外であるかもしれません(急報などの)。 オーディオ/ビデオストリームに加えて、イベント(例えば、フットボールの試合の間のプレーヤーの統計)に関連している文字情報をユーザ端末に送るかもしれません。 異なったメディアに異なった交通機関か異なったアクセス技術さえ使用できます: 例えば、オーディオ/ビデオストリームと原文のデータのための対話的なセル接続に単方向のdatacast輸送を使用できました。 IMGメタデータは、異なったメディアの有用性が使用したと発見する端末がライブイベントをカバーするのを可能にするべきです。
4.2.3. Distance Learning
4.2.3. 通信教育
IMG metadata could describe compound sessions or services enabling several alternative interaction modes between the participants. For example, the combination of one-to-many media streaming, unicast messaging, and downloading of presentation material could be useful for distance learning.
IMGメタデータは関係者の間のいくつかの代替の相互作用モードを可能にする合成セッションかサービスについて説明するかもしれません。 例えば、プレゼンテーションの材料の多くへの1つのメディアストリーミング、ユニキャストメッセージング、およびダウンロードの組み合わせは通信教育の役に立つかもしれません。
4.2.4. Multiplayer Gaming
4.2.4. マルチプレーヤーゲーミング
Multiplayer games are an example of real-time multiparty communication sessions that could be advertised using IMGs. A gaming session could be advertised either by a dedicated server or by the terminals of individual users. A user could use IMGs to learn of active multiplayer gaming sessions, or advertise the user's interest in establishing such a session.
多人数プレイゲームはIMGsを使用することで広告に掲載できるだろうリアルタイムの「マルチ-パーティー」コミュニケーションセッションに関する例です。 専用サーバか個々のユーザの端末はゲーミングセッションの広告を出すことができました。 ユーザは、活発なマルチプレーヤーゲーミングセッションを知るのにIMGsを使用するか、またはそのようなセッションを確立することへのユーザの関心の広告を出すことができました。
Nomura, et al. Informational [Page 10] RFC 4473 Requirements for Internet Media Guides (IMGs) May 2006
野村、他 インターネットメディアのための情報[10ページ]のRFC4473要件は2006年5月に(IMGs)を誘導します。
4.2.5. File Distribution
4.2.5. ファイル分配
IMGs support the communication of file delivery session properties, enabling the scheduled delivery or synchronization of files between a number of hosts. The received IMG metadata could be subsequently used by any application (also outside the scope of IMGs), for example, to download a file with a software update. IMG metadata can provide a description to each file in a file delivery session, assisting users or receiving software in selecting individual files for reception.
IMGsはファイル配送セッションの特性に関するコミュニケーションを支持します、多くのホストの間のファイルの予定されている配送か同期を可能にして。 例えば、どんなアプリケーション(IMGsの範囲の外でも)でも次に、ソフトウェアアップデートと共にファイルをダウンロードするのに受信されたIMGメタデータを使用できるでしょう。 IMGメタデータはファイル配送セッションのときに各ファイルに記述を供給できます、ユーザかソフトウェアを受け取るのをレセプションのための個々のファイルを選択するのに助けて。
For example, when a content provider wants to distribute a large amount of data in file format to thousands of clients, the content provider can use IMG metadata to schedule the delivery effectively.
コンテンツプロバイダーがファイル形式における多量のデータを何千人ものクライアントに分配したがっているとき、例えば、コンテンツプロバイダーは、有効に配送の計画をするのにIMGメタデータを使用できます。
Since IMG metadata can describe time-related data for each receiver, the content provider can schedule delivery time for each receiver. This can save network bandwidth and delivery capacity of senders. In addition, IMG metadata can be used to consistency check, and thus synchronize, a set of files between a sender host and receiver host, when those files change as time elapses.
IMGメタデータが各受信機のための時間関連のデータについて説明できるので、コンテンツプロバイダーは各受信機のための納期の計画をすることができます。これは送付者のネットワーク回線容量と配送能力を節約できます。 さらに、IMGメタデータは、一貫性チェックに使用されて、その結果、同期できて、送付者ホストと受信機の間の1セットのファイルはホストです、時間が経過するのに応じてそれらのファイルが変化すると。
4.2.6. Coming-release and Pre-released Content
4.2.6. 次のリリースとプレリリースされた内容
IMG metadata can be used to describe items of content before the details of their final release are known. A user may be interested in coming content (a new movie or software title where some aspects of the content description are known in advance) and so subscribe to an information service that notifies the user of changes to metadata describing that content. Thus, as the coming release (or pre- releases, e.g., as movie trailers or software demos) become available, the IMG metadata changes and the user is notified of this change. For example, the user could see an announcement of a movie that will be released sometime in the next few months, and configure the user's terminal to receive and record any trailers or promotional material as they become available.
彼らの最終的なリリースの詳細が知られている前に内容の項目について説明するのにIMGメタデータを使用できます。 ユーザは、満足するように(満足している記述のいくつかの局面があらかじめ知られている新作映画かソフトウェアタイトル)なるのに関心があるので、メタデータへの変化がその内容について説明するのについてユーザに通知する情報サービスに加入するかもしれません。 IMGメタデータは変化します、そして、したがって、来たるリリース(または、例えば、映画の予告編かソフトウェアデモとしてのプレリリース)として、利用可能になってください、そして、ユーザはこの変化について通知されます。 例えば、ユーザは、この数カ月でいつかリリースされる映画の発表を見て、利用可能になるとき、どんなトレーラや宣伝の材料も受けて、記録するためにユーザの端末を構成できました。
5. Requirements
5. 要件
5.1. General Requirements
5.1. 一般要件
5.1.1. Independence of IMG Operations from IMG Metadata
5.1.1. IMGメタデータからのIMG操作からの独立
REQ GEN-1: Carrying different kinds of IMG metadata format and different IMG metadata formats in the IMG message body MUST be allowed.
REQ、-1に情報を得てください: IMGメッセージボディーで異種のIMGメタデータ形式と異なったIMGメタデータ形式を運ぶのを許さなければなりません。
Nomura, et al. Informational [Page 11] RFC 4473 Requirements for Internet Media Guides (IMGs) May 2006
野村、他 インターネットメディアのための情報[11ページ]のRFC4473要件は2006年5月に(IMGs)を誘導します。
REQ GEN-2: Delivery mechanisms SHOULD support many different applications' specific metadata formats to keep the system interoperable with existing applications.
REQ、-2に情報を得てください: 排紙機構SHOULDは、既存のアプリケーションで共同利用できるようにシステムを保つために多くの異なったアプリケーションの特定のメタデータ形式を支持します。
This provides flexibility in selecting/designing an IMG transport protocol suited to various scenarios.
これは様々なシナリオに合うIMGトランスポート・プロトコルを選択するか、または設計するのに柔軟性を提供します。
5.1.2. Multiple IMG Senders
5.1.2. 複数のIMG Senders
REQ GEN-3: IMG receivers MUST be allowed to communicate with any number of IMG senders simultaneously.
REQ、-3に情報を得てください: IMG受信機に同時に、いろいろなIMG送付者とコミュニケートさせなければなりません。
This might lead to receiving redundant IMG metadata describing the same items; however, it enables the IMG receiver access to more IMG metadata than may be available from a single IMG sender. This also provides flexibility for the IMG transport protocols and does not preclude a mechanism to solve inconsistency among IMG metadata due to multiple IMG senders. This document assumes that a typical IMG environment will involve many more IMG receivers than IMG senders and that IMG senders are continually connected for the duration of interest (rather than intermittently connected).
これは、同じ項目について説明する余分なIMGメタデータを受け取るのに通じるかもしれません。 しかしながら、それは独身のIMG送付者から利用可能であるかもしれないより多くのIMGメタデータへのIMG受信機アクセスを可能にします。 これは、また、IMGトランスポート・プロトコルに柔軟性を提供して、複数のIMG送付者のためIMGメタデータの中で矛盾を解決するためにメカニズムを排除しません。 このドキュメントは典型的なIMG環境がIMG送付者よりずっと多くのIMG受信機にかかわって、IMG送付者が興味がある持続時間(断続的に接続されているよりむしろ)のために絶えず接されると仮定します。
5.1.3. Modularity
5.1.3. モジュール方式
REQ GEN-4: The IMG delivery mechanisms MUST allow the combination of several IMG operations.
REQ、-4に情報を得てください: IMG排紙機構はいくつかのIMG操作の組み合わせを許さなければなりません。
This is for the purpose of extending functionality (e.g., several or one protocol(s) to provide all the needed operations). Applications can select an appropriate operation set to fulfill their purpose.
これは機能性(例えば、すべての必要な操作を提供する数個か1つのプロトコル)を広げる目的のためのものです。 アプリケーションは、適切な操作セットが目的に適うのを選択できます。
5.2. Delivery Properties
5.2. 配送の特性
This section describes general performance requirements based on the assumption that the range of IMG usage shall be important. However, note that requirements for delivery properties may vary based on the usage scenario, and thus some limited-use implementations place less importance on some requirements.
このセクションはIMG用法の範囲が重要になるという仮定に基づく一般的能力要件について説明します。 しかしながら、配送の特性のための要件が用法シナリオ、およびその結果、いくつかの限られた使用実現場所に基づいていくつかの要件に関する、より少ない重要性を変えるかもしれないことに注意してください。
For example, it is clear that a multicast transport may provide more scalable delivery than a unicast transport; however, scalability requirements do not preclude the unicast transport mechanisms. In this sense, scalability is always important for the protocols irrespective of transport mechanisms.
例えば、マルチキャスト輸送がユニキャスト輸送よりスケーラブルな配送を提供するのは、明確です。 しかしながら、スケーラビリティ要件はユニキャスト移送機構を排除しません。この意味で、プロトコルに、スケーラビリティは移送機構の如何にかかわらずいつも重要です。
Nomura, et al. Informational [Page 12] RFC 4473 Requirements for Internet Media Guides (IMGs) May 2006
野村、他 インターネットメディアのための情報[12ページ]のRFC4473要件は2006年5月に(IMGs)を誘導します。
5.2.1. Scalability
5.2.1. スケーラビリティ
REQ DEL-1: The IMG system MUST be scalable to large numbers of messages, so as to allow design and use of delivery mechanisms that will not fail in delivering up-to-date information under huge numbers of transactions and massive quantities of IMG metadata.
REQデル-1: IMGシステムは多くのメッセージにスケーラブルであるに違いありません、巨大な数の取引と大規模な量のIMGメタデータの下に最新情報を送る際に失敗しない排紙機構のデザインと使用を許すために。
REQ DEL-2: IMGs SHOULD provide a method to prevent an IMG sender from sending unnecessary IMG metadata that have been stored or deleted in IMG receivers.
REQデル-2: IMGs SHOULDはそれが不要なIMGメタデータであったのを送るのから格納されるか、またはIMG受信機で削除されたIMG送付者を防ぐ方法を提供します。
REQ DEL-3: The protocol MUST be scalable to very large audience sizes requiring IMG delivery.
REQデル-3: プロトコルはIMG配送を必要とする非常に大きい聴衆サイズにスケーラブルであるに違いありません。
5.2.2. Support for Intermittent Connectivity
5.2.2. 間欠接続性のサポート
REQ DEL-4: The system MUST enable IMG receivers with intermittent access to network resources (connectivity) to receive and adequately maintain sufficient IMG metadata.
REQデル-4: システムは、ネットワーク資源(接続性)への間欠アクセスがあるIMG受信機が受信して、適切に十分なIMGメタデータを維持するのを可能にしなければなりません。
This allows intermittent access to save power where there is no need to keep communications links powered up while they are sitting idle. For instance, in this situation, periodic bursts of notifies or a fast cycling update carousel allow hosts to wake up for short periods of time and still be kept up-to-date. This can be beneficial for IMG receivers with sporadic connections to the fixed Internet, but is critical in the battery-powered wireless Internet.
これで、間欠アクセスはそれらがぽかんとしている間にリンクが動かしたコミュニケーションを維持する必要は全くないところでパワーを節約できます。 例えば、この状況における周期的な炸裂、通知、または、アップデート回転木馬を循環させるとホストが短い期間に目覚めて、まだ最新に保たれているのが許容される断食。 これは、IMG受信機に固定インターネットに過疎の接続に有益である場合がありますが、バッテリーによる動力付きの無線のインターネットで批判的です。
The implication of intermittent connectivity is that immediate distribution of changes becomes infeasible and so managing data consistency should be focused on the timely delivery of data.
間欠接続性の含意は変化の即座の分配が実行不可能でしたがって、管理するようになるのでデータの一貫性がデータのタイムリーな配送に焦点を合わせられるべきであるということです。
5.2.3. Congestion Control
5.2.3. 輻輳制御
REQ DEL-5: Internet-friendly congestion control MUST be provided for use on the public Internet.
REQデル-5: 公共のインターネットにおける使用にインターネットに優しい輻輳制御を提供しなければなりません。
REQ DEL-6: An IMG entity SHOULD invalidate the IMG metadata item when an IMG metadata item has lifetime information and its lifetime is over. This will lessen the need for notifications of updates from the IMG sender to the IMG receiver to invalidate the item and may help in reducing load.
REQデル-6: IMGメタデータの品目に生涯情報があるとき、IMG実体SHOULDはIMGメタデータの品目を無効にします、そして、寿命は終わっています。これは、アップデートのIMG送付者からIMG受信機までの通知が項目を無効にする必要性を少なくして、負荷を減少させるのを手伝うかもしれません。
5.2.4. Sender- and Receiver-Driven Delivery
5.2.4. 送付者と受信機駆動の配送
REQ DEL-7: The system MUST be flexible in choosing sender-driven, receiver-driven, or both delivery schemes.
REQデル-7: システムが選ぶことで送付者が駆動であって、受信機駆動であることでフレキシブルであるに違いない、または、両方の配送計画。
Nomura, et al. Informational [Page 13] RFC 4473 Requirements for Internet Media Guides (IMGs) May 2006
野村、他 インターネットメディアのための情報[13ページ]のRFC4473要件は2006年5月に(IMGs)を誘導します。
Sender-driven delivery achieves high scalability without interaction between the IMG sender and receiver.
送付者駆動の配送はIMG送付者と受信機との相互作用なしで高いスケーラビリティを実現します。
In contrast, receiver-driven delivery provides on-demand delivery for IMG receivers. Since an IMG sender's complete IMG metadata may be a very large amount of data, the IMG receiver needs to be able to access the guide when convenient (e.g., when sufficient network bandwidth is available to the IMG receiver).
対照的に、受信機駆動の配送はIMG受信機のための要求次第の配送を提供します。 IMG送付者の完全なIMGメタデータが非常に多量のデータであるかもしれないので、IMG受信機は、便利であるときに(例えば、十分なネットワーク回線容量はいつIMG受信機に利用可能ですか)、ガイドにアクセスできる必要があります。
5.3. Customized IMGs
5.3. カスタム設計されたIMGs
REQ CUS-1: The system MUST allow delivery of customized IMG metadata.
REQ Cu-1: システムはカスタム設計されたIMGメタデータの配送を許さなければなりません。
The IMG receiver may require a subset of all the IMG metadata available according to their preferences (type of content, media description, appropriate age group, etc.) and configuration.
IMG受信機はそれらの好み(内容のタイプ、メディア記述、適切な年齢層など)と構成に従って利用可能なすべてのIMGメタデータの部分集合を必要とするかもしれません。
The IMG receiver might send its preferences in the IMG operations that can specify user-specific IMG metadata to be delivered. These preferences could consist of filtering rules. When receiving these messages, the IMG sender might respond with appropriate messages carrying a subset of IMG metadata that matches the IMG receiver's preferences.
IMG受信機は送られるユーザ特有のIMGメタデータを指定できるIMG操作における好みを送るかもしれません。 これらの好みは規則をフィルターにかけるのから成ることができました。 これらのメッセージを受け取るとき、適切なメッセージがIMG受信機の好みに合っているIMGメタデータの部分集合を運んでいて、IMG送付者は応じるかもしれません。
This mechanism can reduce the amount of IMG metadata delivered from the IMG sender to IMG receiver, and consequently it can save the resource consumption on the IMG entities and networks. It is typically useful in unicast cases and also beneficial in multicast cases where an IMG sender distributes the same IMG metadata to interested IMG receivers at the same time.
このメカニズムはIMG送付者からIMG受信機まで送られたIMGメタデータの量を減少させることができます、そして、その結果、それはIMG実体とネットワークにおけるリソース消費を節約できます。 それも、ユニキャスト場合で通常役に立ってまた、IMG送付者が同時に関心があるIMG受信機に同じIMGメタデータを分配するマルチキャスト場合で有益です。
For multicast and unicast cases where the IMG sender does not provide customized IMG metadata, the IMG receiver could receive all IMG metadata transmitted on the channels that the IMG receiver has joined. However, it may select and filter the IMG metadata to get customized IMG metadata by its preferences, and thus drop unwanted metadata immediately upon reception.
IMG送付者がカスタム設計されたIMGメタデータを提供しないマルチキャストとユニキャストケースのために、IMG受信機はIMG受信機が加わったチャンネルで伝えられたすべてのIMGメタデータを受け取るかもしれません。 しかしながら、それは、好みでカスタム設計されたIMGメタデータを得て、その結果、すぐレセプションで求められていないメタデータを落とすためにIMGメタデータを選択して、フィルターにかけるかもしれません。
Customizing metadata might be achieved by changing the IMG descriptions sent and IMG receivers and/or changing the delivery properties (channels used).
IMG記述が送った変化とIMG受信機、そして/または、配送資産を変えることによって(使用されるチャンネル)、カスタム設計メタデータは達成されるかもしれません。
Note that customization and scalability are only somewhat exclusive. Systems providing an IMG receiver to an IMG sender request-based customization will be generally less scalable to massive IMG receiver populations than those without this return signaling technique. Thus, customization, as with any feature that affects scalability, should be carefully designed for the intended application, and it may
改造とスケーラビリティがいくらかだけ排他的であることに注意してください。 一般に、IMGの送付者の要求ベースの改造にIMG受信機を提供するシステムはこのリターンシグナリングのテクニックのないそれらほど大規模なIMG受信機人口にスケーラブルにならないでしょう。 したがって、何か特徴がスケーラビリティに影響する場合、改造は意図しているアプリケーションのために入念に設計されるべきです、そして、それはそのように設計されるかもしれません。
Nomura, et al. Informational [Page 14] RFC 4473 Requirements for Internet Media Guides (IMGs) May 2006
野村、他 インターネットメディアのための情報[14ページ]のRFC4473要件は2006年5月に(IMGs)を誘導します。
not be possible that a one-size-fits-all solution for customization would meet the scalability requirements for all applications and deployment cases.
改造のフリーサイズの解決策がすべてのアプリケーションと展開ケースのためのスケーラビリティ必要条件を満たすのを可能であってください。
5.4. Reliability
5.4. 信頼性
5.4.1. Managing Consistency
5.4.1. 一貫性を管理します。
IMG metadata tends to change as time elapses; as new content is added, the old IMG metadata stored in the IMG receiver becomes unavailable, and the parameters of the existing IMG metadata are changed.
IMGメタデータは、時間が経過するのに応じて変化する傾向があります。 新しい内容が加えられるとき、IMG受信機に格納された古いIMGメタデータは入手できなくなります、そして、既存のIMGメタデータのパラメタを変えます。
REQ REL-1: The system MUST manage IMG metadata consistency.
REQ REL-1: システムはIMGメタデータの一貫性を管理しなければなりません。
Either the IMG sender can simply make updates available (unsynchronized), or the IMG sender and receiver can interact to keep their copies of the IMG metadata synchronized.
IMG送付者が単にアップデートを利用可能に(非連動します)することができますか、またはIMG送付者と受信機は、それらのIMGメタデータのコピーを同期させ続けるために相互作用できます。
In the unsynchronized model, the IMG sender does not know whether a particular IMG receiver has an up-to-date copy of the IMG metadata.
非連動しているモデルで、IMG送付者は、特定のIMG受信機にはIMGメタデータの最新のコピーがあるかどうかを知りません。
In the synchronized model, updating a cached copy of the IMG metadata is necessary to control consistency when the IMG sender or receiver could not communicate for a while. In this case, the IMG sender or receiver may need to confirm its consistency by IMG operations.
連動しているモデルでは、IMGメタデータのキャッシュされたコピーをアップデートするのが、IMG送付者か受信機がしばらく交信できなかったとき、一貫性を制御するのに必要です。 この場合、IMG送付者か受信機が、IMG操作で一貫性を確認する必要があるかもしれません。
REQ REL-2: Since IMG metadata can change at any time, IMG receivers SHOULD be notified of such changes.
REQ REL-2: IMGメタデータ以来、そのような変化についていつでも変化、IMG受信機SHOULDに通知できますか?
Fulfilling this requirement needs to be compatible with the scalability requirements for the number of IMG receivers and the consistency of metadata.
この要件を実現させるのは、IMG受信機の数とメタデータの一貫性のためのスケーラビリティ要件と互換性がある必要があります。
Depending on the size of the IMG metadata, the interested party may want to defer retrieving the actual information. The change notification should be addressed to a logical user (or user group), rather than a host, since users may change devices.
IMGメタデータのサイズ、関心があること実際の情報を検索するパーティーが延期したがっているかもしれないによります。 変更届出書はホストよりむしろ論理的なユーザ(または、ユーザ・グループ)に記述されるべきです、ユーザがデバイスを切り替えるかもしれないので。
Note that depending on the deployment environment and application specifics, the level of acceptable inconsistency varies. Thus, this document does not define inconsistency as specific time and state differences between IMG metadata stored in an IMG sender and IMG metadata stored in an IMG receiver.
展開環境とアプリケーション詳細によって、許容できる矛盾のレベルが異なることに注意してください。 したがって、このドキュメントはIMG送付者に格納されたIMGメタデータとIMG受信機に格納されたIMGメタデータの特定の時間と州の差と矛盾を定義しません。
In general, the consistency of metadata for content and media is more important immediately prior to and during the media's session(s). Hosts that forward (or otherwise resend) metadata may not tolerate
一般に、内容とメディアのためのメタデータの一貫性はすぐに、セッションの前とメディアのセッションの間、より重要です。 前方にそれを接待する、(そうでなければ、再送、)、メタデータは許容しないかもしれません。
Nomura, et al. Informational [Page 15] RFC 4473 Requirements for Internet Media Guides (IMGs) May 2006
野村、他 インターネットメディアのための情報[15ページ]のRFC4473要件は2006年5月に(IMGs)を誘導します。
inconsistencies because delivering out-of-date data is both misleading and bandwidth inefficient.
矛盾、時代遅れなデータを送るのが紛らわしくて、かつ帯域幅効率が悪いので。
5.4.2. Reliable Message Exchange
5.4.2. 信頼できる交換処理
REQ REL-4: An IMG transport protocol MUST support reliable message exchange.
REQ REL-4: IMGトランスポート・プロトコルは信頼できる交換処理を支持しなければなりません。
The extent to which this could result in 100% error-free delivery to 100% of IMG receivers is a statistical characteristic of the protocols used. Usage of reliable IMG delivery mechanisms is expected to depend on the extent to which underlying networks provide reliability and, conversely, introduce errors. Note that some deployments of IMG transport protocols may not aim to provide perfect reception to all IMG receivers in all possible cases.
これが100%のIMG受信機への100%のエラーのない配送をもたらすことができた範囲は使用されるプロトコルの統計的な特性です。 信頼できるIMG排紙機構の用法が基本的なネットワークが信頼性を提供して、逆に誤りを取り入れる範囲に依存すると予想されます。 IMGトランスポート・プロトコルのいくつかの展開が、すべての可能な場合におけるすべてのIMG受信機に完全なレセプションを供給することを目指さないかもしれないことに注意してください。
5.5. IMG Descriptions
5.5. IMG記述
REQ DES-1: IMG metadata MUST be interoperable over any IMG transport protocol, such that an application receiving the same metadata over any one (or more) of several network connections and/or IMG transport protocols will interpret the metadata in exactly the same way. (This also relates to the 'Independence of IMG Operations from IMG Metadata' requirements.)
REQデス-1: IMGメタデータはどんなIMGトランスポート・プロトコルの上でも共同利用できるに違いありません、数人のネットワーク接続、そして/または、IMGトランスポート・プロトコルのどれか(さらに)の上に同じメタデータを受け取るアプリケーションがまさに同じようにメタデータを解釈するように。 (また、これは'IMG MetadataからのIMG Operationsからの独立'に要件について話します。)
REQ DES-2: IMG delivery MUST enable the carriage of any format of application-specific metadata.
REQデス-2: IMG配送はアプリケーション特有のメタデータのどんな形式のキャリッジも可能にしなければなりません。
Thus, the system will support the description of many kinds of multimedia content, without the need for a single homogeneous metadata syntax for all uses (which would be infeasible anyway). This is essential for environments using IMG systems to support many kinds of multimedia content and to achieve wide applicability.
したがって、システムは多くの種類のマルチメディアコンテントの記述を支持するでしょう、すべての用途(とにかく実行不可能である)のためのただ一つの同次のメタデータ構文の必要性なしで。 環境に、これは多くの種類のマルチメディアコンテントを支持して、広い適用性を達成するのにIMGシステムを使用するのにおいて不可欠です。
REQ DES-3: Whereas specific applications relying on IMGs will need to select one or more specific application-specific metadata formats (standard, syntax, etc.), the IMG system MUST be independent of this (it may be aware, but it will operate in the same way for all).
REQデス-3: IMGsを当てにする特定のアプリケーションは、1つ以上の特定のアプリケーション特有のメタデータ形式(規格、構文など)を選択する必要があるでしょうが、IMGシステムはこれから独立しているに違いありません(意識しているかもしれませんが、同様に、それはすべてのために作動するでしょう)。
Thus, a metadata transfer envelope format that is uniform across all different application-specific IMG metadata formats is needed. The envelope would reference (point to) or carry (as payload) some application-specific metadata, and the envelope would support the maintenance of the application-specific metadata, which may also serve the metadata relationships determined by the data model(s) used. The envelope would not need to be aware of the data model(s) in use.
したがって、すべての異なったアプリケーション特有のIMGメタデータ形式の向こう側に一定のメタデータ転送封筒形式が必要です。 封筒は、何らかのアプリケーション特有のメタデータを参照をつけるか(示します)、または運ぶでしょう、そして、(ペイロードとして)封筒はアプリケーション特有のメタデータの維持を支えるでしょう。(また、メタデータはモデルが使用したデータで決定しているメタデータ関係に役立つかもしれません)。 封筒はデータモデルを使用中に意識している必要はないでしょう。
Nomura, et al. Informational [Page 16] RFC 4473 Requirements for Internet Media Guides (IMGs) May 2006
野村、他 インターネットメディアのための情報[16ページ]のRFC4473要件は2006年5月に(IMGs)を誘導します。
REQ DES-4: IMG metadata MUST be structured to enable fragmentation for efficient delivery.
REQデス-4: 効率的な配送のための断片化を可能にするためにIMGメタデータを構造化しなければなりません。
This is intended to ensure that an IMG sender with more than a trivial knowledge of metadata is able to deliver only part of its (and the global) complete IMG metadata knowledge. (For instance, a trivial quantity of knowledge could be a single SDP description.) In general, the resolution of this fragmentation will be very much dependent on the optimal delivery of a deployment, although some metadata syntaxes will inherently affect the sensible lower limit for a single element/fragment.
これが、メタデータに関する1以上の些細な知識をもっているIMG送付者が(そして、グローバル)完全なIMGメタデータ知識の一部しか届けることができないのを保証することを意図します。 (例えば、些細な量の知識がただ一つのSDP記述であるかもしれません。) 一般に、この断片化の解決は展開の最適の配送にたいへん依存するようになるでしょう、いくつかのメタデータ構文が本来ただ一つの要素/断片のための分別がある下限に影響するでしょうが。
REQ DES-5: A metadata transfer envelope MUST be defined to include essential parameters.
REQデス-5: 不可欠のパラメタを含むようにメタデータ転送封筒を定義しなければなりません。
Examples of essential parameters are those that allow the metadata in question to be uniquely identified and updated by new versions of the same metadata.
不可欠のパラメタに関する例は同じメタデータの新しいバージョンで問題のメタデータを唯一特定して、アップデートするのを許容するものです。
REQ DES-6: It SHALL be possible to deduce the metadata format via the metadata transfer envelope.
REQデス-6: それ、SHALL、メタデータ転送封筒を通してメタデータ形式を推論するのにおいて、可能であってください。
REQ DES-7: IMG senders SHALL use a metadata transfer envelope for each IMG metadata transfer.
REQデス-7: IMG送付者SHALLはそれぞれのIMGメタデータ転送にメタデータ転送封筒を使用します。
Thus, it will even be possible to describe relationships between syntactically dissimilar application-specific formats within the same body of IMG metadata knowledge. (For instance, a data model could be instantiated using both SDP and SDPng.)
したがって、IMGメタデータ知識の同じボディーの中のシンタクス上異なったアプリケーション特有の形式の間の関係について説明するのは可能でさえあるでしょう。 (例えば、SDPとSDPngの両方を使用することでデータモデルを例示できるでしょう。)
REQ DES-8: IMG metadata SHOULD support the description of differences between an updated version and an old version of IMG metadata when the IMG delivery mechanism carries updated IMG metadata and those differences are considerably little (e.g., by providing a 'delta' of the two versions; this also relates the delivery property requirements for congestion control in Section 5.2.3).
REQデス-8: IMG排紙機構がアップデートされたIMGメタデータを運んで、それらの違いがかなり小さいときに(例えば、2つのバージョンの'デルタ'を提供することによって; また、これはセクション5.2.3における輻輳制御のための配送特性の要件について話します)、IMGメタデータSHOULDはアップデートされたバージョンとIMGメタデータの古いバージョンの違いの記述を支持します。
6. Security Considerations
6. セキュリティ問題
Internet Media Guides are used to convey information about multimedia resources from one or more IMG senders across one or more intermediaries to one or more IMG receivers. IMG metadata may be pushed to the IMG receivers or interactively retrieved by them. IMGs provide metadata as well as scheduling and rendezvous information about multimedia resources, and so on, and requests for IMG metadata may contain information about the requesting users.
インターネットメディアガイドは、マルチメディアリソースに関して1人以上の仲介者の向こう側の1人以上のIMG送付者から1台以上のIMG受信機まで情報を伝達するのに使用されます。 IMGメタデータは、IMG受信機に押されるか、またはそれらによってインタラクティブに検索されるかもしれません。 IMGsはなどスケジューリングと同様にメタデータを提供して、マルチメディアリソースに関して情報を集合させます、そして、IMGメタデータに関する要求は要求しているユーザの情報を含むかもしれません。
Nomura, et al. Informational [Page 17] RFC 4473 Requirements for Internet Media Guides (IMGs) May 2006
野村、他 インターネットメディアのための情報[17ページ]のRFC4473要件は2006年5月に(IMGs)を誘導します。
The information contained in IMG metadata as well as the operations related to IMGs should be secured to avoid forged information, misdirected users, and spoofed IMG senders, for example, and to protect user privacy.
例えば、偽造情報、的外れのユーザ、およびだまされたIMG送付者を避けて、ユーザプライバシーを保護するためにIMGsに関連する操作と同様にIMGメタデータに含まれた情報を保証するべきです。
The remainder of this section addresses the security requirements for IMGs.
このセクションの残りはIMGsのためのセキュリティ要件を記述します。
6.1. IMG Authentication and Integrity
6.1. IMG認証と保全
IMG metadata and its parts need to be protected against unauthorized alteration/addition/deletion on the way. Their originator needs to be authenticated.
IMGメタデータとその部品は、途中での権限のない変更/添加/削除に対して保護される必要があります。 彼らの創始者は、認証される必要があります。
REQ AUT-1: It MUST be possible to authenticate the originator of a set of IMG metadata.
REQ AUT-1: 1セットのIMGメタデータの創始者を認証するのは可能であるに違いありません。
REQ AUT-2: It MUST be possible to authenticate the originator of a subpart of IMG metadata (e.g., a delta or a subset of the information).
REQ AUT-2: IMGメタデータ(例えば、デルタか情報の部分集合)の下位区分の創始者を認証するのは可能であるに違いありません。
REQ AUT-3: It MUST be possible to validate the integrity of IMG metadata.
REQ AUT-3: IMGメタデータの保全を有効にするのは可能であるに違いありません。
REQ AUT-4: It MUST be possible to validate the integrity of a subpart of IMG metadata (e.g., a delta or a subset of the information).
REQ AUT-4: IMGメタデータ(例えば、デルタか情報の部分集合)の下位区分の保全を有効にするのは可能であるに違いありません。
REQ AUT-5: It MUST be possible to separate or combine individually authenticated pieces of IMG metadata (e.g., in an IMG transceiver) without invalidating the authentication.
REQ AUT-5: 認証を無効にしないで個別に認証された片のIMGメタデータ(例えば、IMGトランシーバーの)を切り離すか、または結合するのが可能であるに違いありません。
REQ AUT-6: It MUST be possible to validate the integrity of an individually authenticated piece of IMG metadata even after this piece has been separated from other pieces of IMG metadata and combined with other pieces to form new IMG metadata.
REQ AUT-6: この断片が他のIMGメタデータと切り離されて、新しいIMGメタデータを形成するために他の断片に結合された後にさえ個別に認証された片のIMGメタデータの保全を有効にするのは可能であるに違いありません。
REQ AUT-7: It MUST be possible to authenticate the originator of an IMG operation.
REQ AUT-7: IMG操作の創始者を認証するのは可能であるに違いありません。
REQ AUT-8: It MUST be possible to validate the integrity of any contents of an IMG operation (e.g., the subscription or inquiry information).
REQ AUT-8: IMG操作(例えば、購読か問い合せ情報)のどんなコンテンツの保全も有効にするのは可能であるに違いありません。
Nomura, et al. Informational [Page 18] RFC 4473 Requirements for Internet Media Guides (IMGs) May 2006
野村、他 インターネットメディアのための情報[18ページ]のRFC4473要件は2006年5月に(IMGs)を誘導します。
6.2. Privacy
6.2. プライバシー
Customized IMG metadata and IMG metadata delivered by notification to individual users may reveal information about the habits and preferences of a user and may thus deserve confidentiality protection, even though the information itself is public.
個々のユーザへの通知で送られたカスタム設計されたIMGメタデータとIMGメタデータは、ユーザの習慣と好みの情報を明らかにして、その結果、秘密性保護に値するかもしれません、情報自体は公共ですが。
REQ PRI-1: It MUST be possible to keep user requests to subscribe to or retrieve certain (parts of) IMG metadata confidential.
REQ PRI-1: 加入するか、または検索するユーザ要求を確かに保つのが可能であるに違いない、(離れている、)、IMGメタデータ秘密です。
REQ PRI-2: It MUST be possible to keep IMG metadata, pieces of IMG metadata, or pointers to IMG metadata delivered to individual users or groups of users confidential.
REQ PRI-2: IMGメタデータ、IMGメタデータの断片、または個々のユーザに送られたIMGメタデータへのポインタを保つのが可能であるに違いないか、またはユーザのグループは秘密です。
REQ PRI-3: It SHOULD be possible to ensure this confidentiality end- to-end, that is, to prevent intermediaries (such as IMG transceivers) from accessing the contained information.
REQ PRI-3: それ、SHOULD、この秘密性の終わりから終わりに確実にするのにおいて可能であることで、仲介者(IMGトランシーバーなどの)が含まれた情報にアクセスするのを防ぐためにそれがいるということになってください。
6.3. Access Control for IMGs
6.3. IMGsのためのアクセス管理
Some IMG metadata may be freely available, while access to other IMG metadata may be restricted to closed user groups (e.g., paying subscribers). Also, different parts of IMG metadata may be protected at different levels: for example, metadata describing a media session may be freely accessible, while rendezvous information to actually access the media session may require authorization.
何らかのIMGメタデータが自由に利用可能であるかもしれません、他のIMGメタデータへのアクセスはクローズド・ユーザ・グループ(例えば、加入者に支払う)に制限されるかもしれませんが。 また、IMGメタデータの異なった部分は異なったレベルで保護されるかもしれません: 例えば、メディアセッションについて説明するメタデータは自由にアクセス可能であるかもしれません、実際にメディアセッションにアクセスするランデブー情報が認可を必要とするかもしれませんが。
REQ ACC-1: It MUST be possible to authorize user access to IMG metadata.
REQ ACC-1: IMGメタデータへのユーザアクセスを認可するのは可能であるに違いありません。
REQ ACC-2: It MUST be possible to authorize access of users to pieces of IMG metadata (delta information, subparts, pointers).
REQ ACC-2: IMGメタデータ(デルタ情報、下位区分、ポインタ)の断片へのユーザのアクセスを認可するのは可能であるに違いありません。
REQ ACC-3: It MUST be possible to require different authorization for different parts of the same IMG metadata.
REQ ACC-3: 同じIMGメタデータの異なった部分のための異なった認可を必要とするのは可能であるに違いありません。
REQ ACC-4: It MUST be possible to access selected IMG metadata anonymously.
REQ ACC-4: 匿名で選択されたIMGメタデータにアクセスするのは可能であるに違いありません。
REQ ACC-5: It MUST be possible for an IMG receiver to choose not to receive (parts of) IMG metadata in order to avoid being identified by the IMG sender.
REQ ACC-5: IMG受信機が、受信しないのを選ぶのが、可能であるに違いない、(離れている、)、IMGメタデータ、IMG送付者によって特定されるのを避けてください。
REQ ACC-6: It SHOULD be possible for an IMG transceiver to select suitable authorization methods that are compatible between both IMG senders and IMG receivers it interacts with.
REQ ACC-6: それ、SHOULD、IMGトランシーバーがIMG送付者とそれが対話するIMG受信機の両方の間で互換性がある適当な認可方法を選択するのにおいて、可能であってください。
Nomura, et al. Informational [Page 19] RFC 4473 Requirements for Internet Media Guides (IMGs) May 2006
野村、他 インターネットメディアのための情報[19ページ]のRFC4473要件は2006年5月に(IMGs)を誘導します。
REQ ACC-7: It MAY be possible for IMG senders to require certain authorization that cannot be modified by intermediaries.
REQ ACC-7: IMG送付者が仲介者が変更できないある認可を必要とするのは、可能であるかもしれません。
6.4. Denial-of-Service (DOS) Attacks
6.4. サービスの否定(DOS)攻撃
Retrieving or distributing IMG metadata may require state in the IMG senders, transceivers, and/or receivers for the respective IMG transport sessions. Attackers may create large numbers of sessions with any of the above IMG entities to disrupt regular operation.
IMGメタデータを検索するか、または分配するのがそれぞれのIMG輸送セッションのためにIMG送付者、トランシーバー、そして/または、受信機で状態を必要とするかもしれません。 攻撃者は、正常な操業を中断するために上のIMG実体のどれかとの多くのセッションを作成するかもしれません。
REQ DOS-1: IMG operations SHOULD be authenticated.
REQ DOS-1: IMG操作SHOULD、認証されてください。
REQ DOS-2: It SHOULD be possible to avoid DoS attacks that build up session state in IMG entities to exhaust their resources.
REQ DOS-2: それ、SHOULD、あらゆる手段を尽くすためにIMG実体でセッション状態を確立するDoS攻撃を避けるのにおいて、可能であってください。
REQ DOS-3: It SHOULD be possible to avoid DoS attacks that exhaust resources of IMG entities by flooding them with IMG metadata.
REQ DOS-3: それ、SHOULD、IMG実体のリソースがIMGメタデータでそれらをあふれさせることによってくたくたになるDoS攻撃を避けるのにおいて、可能であってください。
As an example, two potential solutions that may be considered are running an IMG entity in stateless mode or identification and discarding of malicious packets by an IMG entity.
例として、2つの潜在的解決策が、国がないモードか識別でIMG実体を走らせて、IMG実体で悪意があるパケットを捨てていますそれが考えられるかもしれない。
6.5. Replay Attacks
6.5. 反射攻撃
IMG metadata disseminated by an IMG sender or an IMG transceiver may be updated, be deleted, or lose validity over time for some other reasons. Replaying outdated IMG metadata needs to be prevented.
IMG送付者かIMGトランシーバーによって広められたIMGメタデータは、時間がたつにつれて、ある他の理由でアップデートするか、削除されるか、または正当性を失うかもしれません。 時代遅れのIMGメタデータを再演するのは、防がれる必要があります。
Furthermore, replay attacks may also apply to IMG operations (rather than just their payload). Replaying operations also needs to be prevented.
その上、また、反射攻撃はIMG操作(まさしくそれらのペイロードよりむしろ)に適用されるかもしれません。 また、操作を再演するのは、防がれる必要があります。
REQ REP-1: IMG metadata MUST be protected against partial or full
replacement of newer ("current") versions by older ones.
REQレップ-1: より古いもので、より新しい(「現在」の)バージョンの部分的であるか完全な交換に対してIMGメタデータを保護しなければなりません。
In a system with multiple senders, it may not be feasible to prevent some senders from delivering older versions of metadata than others - as a result of imperfect sender-sender data consistency. Thus, replay attacks and delivery of inconsistent data require that an IMG receiver verifies that the IMG metadata is valid and reliable by using some security mechanism(s) (e.g., authorization, authentication, or integrity).
複数の送付者とのシステムでは、何人かの送付者がメタデータの旧式のバージョンを送るのを防ぐのは不完全な送付者送付者データの一貫性の結果、他のものほど可能でないかもしれません。 したがって、矛盾したデータの反射攻撃と配送は、IMG受信機が、IMGメタデータが何らかのセキュリティー対策(例えば、認可、認証、または保全)を使用することによって有効であって、信頼できることを確かめるのを必要とします。
REQ REP-2: Mechanisms MUST be provided to mitigate replay attacks on the IMG operations.
REQレップ-2: IMG操作のときに反射攻撃を緩和するためにメカニズムを提供しなければなりません。
Nomura, et al. Informational [Page 20] RFC 4473 Requirements for Internet Media Guides (IMGs) May 2006
野村、他 インターネットメディアのための情報[20ページ]のRFC4473要件は2006年5月に(IMGs)を誘導します。
The level of threat from replay attacks varies very much depending on system scale and how well defined or open it is. Thus, mitigating replay attacks may lead to different solutions for different systems, independent of the basic delivery method and metadata definitions. A system with multiple senders presents a more challenging scenario for handling replay attacks. As an example, bundling metadata with a security mechanism is one potential solution.
反射攻撃からの脅威のレベルはシステムスケールにどれくらいよく定義された非常に多くの依存か戸外を変えます。 したがって、反射攻撃を緩和するのは異系統の異なった解答に通じるかもしれません、基本的な発送方法とメタデータ定義の如何にかかわらず。 複数の送付者とのシステムは取り扱い反射攻撃のために、よりやりがいがあるシナリオを提示します。 例として、セキュリティー対策でメタデータを束ねるのは、1つの潜在的解決策です。
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] Handley, M., Perkins, C., and E. Whelan, "Session Announcement
Protocol", RFC 2974, October 2000.
[3] ハンドレーとM.とパーキンス、C.とE.ウィーラン、「セッション発表プロトコル」、RFC2974、2000年10月。
[4] Session Directory, ftp://ftp.ee.lbl.gov/conferencing/sd/
[4] セッションディレクトリ、 ftp://ftp.ee.lbl.gov/conferencing/sd/
[5] Session Directory Tool, http://www-
mice.cs.ucl.ac.uk/multimedia/software/sdr/
[5] セッションディレクトリTool、 http://www- mice.cs.ucl.ac.uk/multimedia/software/sdr/
[6] Digital Video Broadcasting Project, http://www.dvb.org/
[6] プロジェクト、 http://www.dvb.org/ を放送するデジタルビデオ
[7] Kutscher, D., Ott, J., and C. Bormann, "Session description and
capability negotiation", Work in Progress, February 2005.
[7] クッチャー、D.、オット、J.、C.ボルマン、および「セッション記述と能力交渉」、Progress、2月2005日のWork
[8] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[8] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[9] Nomura, Y., Walsh, R., Luoma, J-P., Asaeda, H., and H.
Schulzrinne, "Framework for the Usage of Internet Media Guides
(IMG)", RFC 4435, April 2006.
[9] 野村、Y.、ウォルシュ、R.、Luoma、J-P.、Asaeda、H.、およびH.Schulzrinne、「インターネットメディアの用法のための枠組みは(IMG)を誘導します」、RFC4435、2006年4月。
[10] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[10] フィールディング、R.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月。」
[11] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[11] ローチ、A.B.、「セッション開始プロトコル(一口)特定のイベント通知」、RFC3265、2002年6月。
[12] Quinn, B. and K. Almeroth, "IP Multicast Applications:
Challenges and Solutions", RFC 3170, September 2001.
[12] クイン、B.、およびK.Almeroth、「IPマルチキャストアプリケーション:」 「挑戦と解答」、RFC3170、9月2001日
Nomura, et al. Informational [Page 21] RFC 4473 Requirements for Internet Media Guides (IMGs) May 2006
野村、他 インターネットメディアのための情報[21ページ]のRFC4473要件は2006年5月に(IMGs)を誘導します。
9. Acknowledgements
9. 承認
The authors would like to thank Hitoshi Asaeda, Gonzalo Camarillo, Jean-Pierre Evain, Dirk Kutscher, Petri Koskelainen, Colin Perkins, Toni Paila, and Magnus Westerlund for their excellent comments and ideas on this work.
作者はこの仕事に関する彼らの素晴らしいコメントと考えについて等Asaeda、ゴンサロ・キャマリロ、ジャンピエールEvain、Dirkクッチャー、ペトリKoskelainen、コリン・パーキンス、トニーPaila、およびマグヌスWesterlundに感謝したがっています。
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
Joerg Ott Helsinki University of Technology Networking Laboratory PO Box 3000 FIN-02015 TKK Finland
技術ネットワーク研究所私書箱3000フィン-02015TKKフィンランドのヨルクオットヘルシンキ大学
EMail: jo@netlab.tkk.fi
メール: jo@netlab.tkk.fi
Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA
コンピュータサイエンスコロンビア大学1214アムステルダムAvenueニューヨーク10027ニューヨーク(米国)のヘニングSchulzrinne部
EMail: schulzrinne@cs.columbia.edu
メール: schulzrinne@cs.columbia.edu
Nomura, et al. Informational [Page 22] RFC 4473 Requirements for Internet Media Guides (IMGs) May 2006
野村、他 インターネットメディアのための情報[22ページ]のRFC4473要件は2006年5月に(IMGs)を誘導します。
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 23]
野村、他 情報[23ページ]
一覧
スポンサーリンク
