RFC4855 日本語訳
4855 Media Type Registration of RTP Payload Formats. S. Casner. February 2007. (Format: TXT=24404 bytes) (Obsoletes RFC3555) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Casner Request for Comments: 4855 Packet Design Obsoletes: 3555 February 2007 Category: Standards Track
Casnerがコメントのために要求するワーキンググループS.をネットワークでつないでください: 4855年のパケットデザインは以下を時代遅れにします。 3555 2007年2月のカテゴリ: 標準化過程
Media Type Registration of RTP Payload Formats
メディアはRTP有効搭載量形式の登録をタイプします。
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
Abstract
要約
This document specifies the procedure to register RTP payload formats as audio, video, or other media subtype names. This is useful in a text-based format description or control protocol to identify the type of an RTP transmission.
このドキュメントは、オーディオ、ビデオ、または他のメディア「副-タイプ」名としてRTPペイロード形式を示すために手順を指定します。 これはRTPトランスミッションのタイプを特定するテキストベースの書式の記述か制御プロトコルで役に立ちます。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Terminology ................................................2
2. Procedure For Registering Media Types for RTP Payload Types .....2
2.1. Example Media Type Registration ............................4
2.2. Restrictions on Sharing a Subtype Name .....................5
3. Mapping to SDP Parameters .......................................6
4. Changes from RFC 3555 ...........................................7
5. Security Considerations .........................................8
6. IANA Considerations .............................................9
7. References .....................................................10
7.1. Normative References ......................................10
7.2. Informative References ....................................10
1. 序論…2 1.1. 用語…2 2. RTP有効搭載量タイプのためにメディアタイプを示すための手順…2 2.1. 例のメディアは登録をタイプします…4 2.2. Subtype名を共有するときの制限…5 3. SDPパラメタに写像します。6 4. RFC3555からの変化…7 5. セキュリティ問題…8 6. IANA問題…9 7. 参照…10 7.1. 標準の参照…10 7.2. 有益な参照…10
Casner Standards Track [Page 1] RFC 4855 Media Type Reg. of RTP Payload Formats February 2007
Casner標準化過程[1ページ]RFC4855メディアはレッジをタイプします。RTPでは、有効搭載量は2007年2月をフォーマットします。
1. Introduction
1. 序論
RFC 4288 [1] defines media type specification and registration procedures that use the Internet Assigned Numbers Authority (IANA) as a central registry. That document covers general requirements independent of particular application environments and transport modes. This document defines the specific requirements for registration of media types for use with the Real-time Transport Protocol (RTP), RFC 3550 [2], to identify RTP payload formats.
RFC4288[1]は中央の登録としてインターネットAssigned民数記Authority(IANA)を使用するメディアタイプ仕様と登録手順を定義します。 そのドキュメントは特定用途環境と交通機関の如何にかかわらず一般的な要件をカバーしています。 このドキュメントは、RTPペイロード形式を特定するためにレアル-時間Transportプロトコル(RTP)、RFC3550[2]で使用のためのメディアタイプの登録のための決められた一定の要求を定義します。
1.1. Terminology
1.1. 用語
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 [3] and indicate requirement levels for implementations compliant with this specification.
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは中でRFC2119[3]について説明して、この仕様による対応することの実装のために要件レベルを示すとき本書では解釈されることであるべきですか?
2. Procedure For Registering Media Types for RTP Payload Types
2. RTP有効搭載量タイプのためにメディアタイプを示すための手順
Registering an RTP payload type as a media type follows the same procedures as described in RFC 4288 [1] and uses the registration template shown in Section 10 of that RFC. To specify how the particular payload format is transported over RTP, some additional information is required in the following sections of that template:
RTPペイロードを示して、メディアタイプがRFC4288[1]で説明されるのと同じ手順に従って、そのRFCのセクション10で見せられた登録テンプレートを使用するとき、タイプしてください。 特定のペイロード形式がRTPの上でどう輸送されるかを指定するために、何らかの追加情報がそのテンプレートの以下のセクションで必要です:
Required parameters:
If the payload format does not have a fixed RTP timestamp
clock rate, then a "rate" parameter is required to specify the
RTP timestamp clock rate. A particular payload format may
have additional required parameters.
必要なパラメタ: ペイロード形式に固定RTPタイムスタンプクロックレートがないなら、「レート」パラメタが、RTPタイムスタンプクロックレートを指定するのに必要です。 特定のペイロード形式には、追加必要なパラメタがあるかもしれません。
Optional parameters:
Most audio payload formats can have an optional "channels"
parameter to specify the number of audio channels included in
the transmission. The default channel order is as specified
in RFC 3551 [4]. Any payload format, but most likely audio
formats, may also include the optional parameters "ptime" to
specify the recommended length of time in milliseconds
represented by the media in a packet, and/or "maxptime" to
specify the maximum amount of media that can be encapsulated
in each packet, expressed as time in milliseconds. The
"ptime" and "maxptime" parameters are defined in the Session
Description Protocol (SDP) [5].
任意のパラメタ: トランスミッションに音声チャンネルの数を含んでいて、ほとんどのオーディオペイロード形式が指定する任意の「チャンネル」パラメタを持つことができます。 デフォルトチャンネル注文がRFC3551[4]で指定されるようにあります。 また、どんなペイロード形式(たぶんオーディオ形式だけ)も、時間としてミリセカンドで言い表された各パケットでカプセル化することができる最大の量のメディアを指定するお勧めの長さのパケットにメディアによって表されたミリセカンド、そして/または、"maxptime"の時間を指定するために"ptime"という任意のパラメタを含むかもしれません。 "ptime"と"maxptime"パラメタはSession記述プロトコル(SDP)[5]で定義されます。
A particular payload format may have additional optional
parameters. As allowed in Section 4.3 of [1], new parameters
MAY be added to RTP media types that have been previously
特定のペイロード形式には、追加任意のパラメタがあるかもしれません。 [1]のセクション4.3に許容されていて、新しいパラメタが以前にそうであるRTPメディアタイプに追加されるかもしれないので
Casner Standards Track [Page 2] RFC 4855 Media Type Reg. of RTP Payload Formats February 2007
Casner標準化過程[2ページ]RFC4855メディアはレッジをタイプします。RTPでは、有効搭載量は2007年2月をフォーマットします。
defined, but the new parameters MUST NOT change existing
functionality and it MUST be possible for existing
implementations to ignore the additional parameters without
impairing operation.
定義されています、新しいパラメタだけが既存の機能性を変えてはいけません、そして、既存の実装に、操作を損なわないで追加パラメタを無視するのは可能であるに違いありません。
Encoding considerations:
Most RTP payload formats include binary or framed data as
described in Section 4.8 of [1]. The appropriate encoding
considerations MUST be noted.
問題をコード化します: ほとんどのRTPペイロード形式が[1]のセクション4.8で説明されるように2進の、または、縁どられたデータを含んでいます。 適切なコード化問題に注意しなければなりません。
Published specification:
A description of the media encoding and a specification of the
payload format must be provided, usually by reference to an
RTP payload format specification RFC. That RFC may be
separate, or the media type registration may be incorporated
into the payload format specification RFC. The payload format
specification MUST include the RTP timestamp clock rate (or
multiple rates for audio encodings with multiple sampling
rates).
広められた仕様: メディアコード化の記述とペイロード形式の仕様を提供しなければなりません、通常RTPペイロード書式仕様RFCの参照で。 RFCが別々であるかもしれないか、またはメディアが登録をタイプするのがペイロード書式仕様RFCに組み入れられるかもしれません。 ペイロード書式仕様はRTPタイムスタンプクロックレート(または、複数の標本抽出率があるオーディオencodingsにおいて複数のレート)を含まなければなりません。
A reference to a further description of the data compression
format itself should be provided, if available.
データ圧縮形式自体のさらなる記述の参照は、提供していて、利用可能であるべきです。
Restrictions on usage:
The fact that the media type is defined for transfer via RTP
MUST be noted, in particular, if the transfer depends on RTP
framing and hence the media type is only defined for transfer
via RTP.
用法における制限: RTP MUSTを通して定義されるメディアが転送のためにタイプする事実が注意されて、転送がRTP縁どりとしたがって、メディアによる場合にだけ、特に、タイプは転送のためにRTPを通して定義されます。
Depending on whether or not the type has already been registered for transfer with a non-RTP protocol (e.g., MIME mail or http), several different cases can occur:
非RTPプロトコル(例えば、MIMEメールかhttp)でタイプが転送のために既に示されたかどうかによって、数個の異なったケースが現れることができます:
a) Not yet registered as a media type
a) メディアタイプとしてまだ登録されていません。
A new registration should be constructed using the media type
registration template. The registration may specify transfer
via other means in addition to RTP if that is feasible and
desired. The appropriate encoding considerations must be
specified, and the restrictions on usage must specify whether
the type is only defined for transfer via RTP or via other
modes as well.
新規登録は、メディアタイプ登録テンプレートを使用することで構成されるべきです。 それが可能であって、必要であるなら、登録はRTPに加えた他の手段で転送を指定するかもしれません。 適切なコード化問題を指定しなければなりません、そして、用法における制限はまた、タイプが転送のためにRTPを通して他のモードで定義されるだけであるかどうか指定しなければなりません。
Optional parameters may be defined as needed, and it must be
clearly stated to which mode(s) of transfer the parameters
apply.
任意のパラメタは必要に応じて定義されるかもしれません、そして、明確に、パラメタが適用されると転送のどの方法に述べなければならないか。
Casner Standards Track [Page 3] RFC 4855 Media Type Reg. of RTP Payload Formats February 2007
Casner標準化過程[3ページ]RFC4855メディアはレッジをタイプします。RTPでは、有効搭載量は2007年2月をフォーマットします。
b) Media type exists for a non-RTP protocol
b) メディアタイプは非RTPプロトコルのために存在しています。
The restrictions on usage of the existing type should be
changed, if present, or added, if not, to indicate that the
type can also be transferred via RTP.
また、RTPを通してタイプを移すことができるのを示すために既存のタイプの使用法における制限を存在しているなら変えるべきであるか、またはそうでなければ、加えるべきです。
RTP-specific parameters may be added, and it must be clearly
stated that these are only to be used when the media type is
transmitted via RTP transport.
RTP特有のパラメタは言い足されるかもしれません、そして、明確に、メディアタイプがRTP輸送で伝えられるとき、これらが単に使用されることになっていると述べなければなりません。
c) Update an existing media type for RTP to be used for a non-RTP
protocol
c) 既存のメディアタイプをアップデートして、RTPは非RTPプロトコルに使用されてください。
The restrictions on usage of the existing type should be
changed to indicate that the type can also be transferred via a
non-RTP protocol (e.g., SMTP, HTTP).
また、非RTPプロトコル(例えば、SMTP、HTTP)でタイプを移すことができるのを示すために既存のタイプの使用法における制限を変えるべきです。
Non-RTP-specific parameters can be added, and it must be
clearly stated that these are only to be used when the media
type is transmitted via a non-RTP transport.
非RTPの詳細パラメタを言い足すことができます、そして、明確に、メディアタイプが非RTP輸送で伝えられるとき、これらが単に使用されることになっていると述べなければなりません。
2.1. Example Media Type Registration
2.1. 例のメディアは登録をタイプします。
The following sample registration of a fake media type audio/example provides examples for some of the required text. References to RFC nnnn would be replaced by references to the RFC that contains the payload format specification and the media type registration.
以下はオーディオ/例が必要なテキストのいくつかに関する例を提供するにせのメディアタイプの登録を抽出します。 RFC nnnnの参照をペイロード書式仕様を含むRFCの参照に取り替えるでしょう、そして、メディアは登録をタイプします。
Type name: audio
型名: オーディオ
Subtype name: example
Subtypeは以下を命名します。 例
Required parameters:
rate: RTP timestamp clock rate, which is equal to the sampling
rate. The typical rate is 8000; other rates may be specified.
必要なパラメタ: 以下を評価してください。 RTPタイムスタンプクロックレート。(そのクロックレートは標本抽出率と等しいです)。 典型的なレートは8000です。 他のレートは指定されるかもしれません。
Optional parameters:
channels: number of interleaved audio streams, either 1 for
mono or 2 for stereo, and defaults to 1 if omitted.
Interleaving takes place between on a frame-by-frame basis,
with the left channel followed by the right channel.
任意のパラメタ: チャンネル: 省略されるなら、はさみ込まれたオーディオの数は、ステレオのためのモノタイプか2のために1を流れさせて、1にデフォルトを流れさせます。 左のチャンネルが正しいチャンネルによってついて来られている状態で、インターリービングは間にフレームごとのベースで行われます。
ptime: recommended length of time in milliseconds represented
by the media in a packet (see RFC 4566).
ptime: パケット(RFC4566を見る)にメディアによって表されたミリセカンドで表現されるお勧めの長さの時間。
maxptime: maximum amount of media that can be encapsulated in
each packet, expressed as time in milliseconds (see RFC 4566).
maxptime: ミリセカンド(RFC4566を見ます)で時間として言い表された各パケットでカプセル化することができる最大の量のメディア。
Casner Standards Track [Page 4] RFC 4855 Media Type Reg. of RTP Payload Formats February 2007
Casner標準化過程[4ページ]RFC4855メディアはレッジをタイプします。RTPでは、有効搭載量は2007年2月をフォーマットします。
Encoding considerations:
This media type is framed binary data (see RFC 4288, Section
4.8).
問題をコード化します: このメディアタイプは縁どられたバイナリ・データ(RFC4288、セクション4.8を見る)です。
Security considerations: See Section n of RFC nnnn
セキュリティ問題: RFC nnnnのセクションnを見てください。
Interoperability considerations:
Some receivers may only be capable of receiving single-channel
audio.
相互運用性問題: いくつかの受信機が単独のチャンネルオーディオを受けることができるだけであるかもしれません。
Published specification: RFC nnnn
広められた仕様: RFC nnnn
Applications that use this media type:
Audio and video streaming and conferencing tools.
このメディアタイプを使用するアプリケーション: オーディオ、ビデオ・ストリーミング、および会議ツール。
Additional information: none
追加情報: なし
Person & email address to contact for further information:
Fred Audio <fred@example.com>
詳細のために連絡する人とEメールアドレス: フレッド Audio <fred@example.com 、gt。
Intended usage: COMMON
意図している用法: 一般的
Restrictions on usage:
This media type depends on RTP framing, and hence is only
defined for transfer via RTP (RFC 3550). Transfer within
other framing protocols is not defined at this time.
用法における制限: このメディアタイプは、RTP縁どりによって、したがって、転送のためにRTP(RFC3550)を通して定義されるだけです。 他の縁どりプロトコルの中の転送はこのとき、定義されません。
Author:
Fred Audio
以下を書いてください。 フレッドAudio
Change controller:
IETF Audio/Video Transport working group delegated from the
IESG.
コントローラを変えてください: IESGから代表として派遣されたIETF Audio/ビデオTransportワーキンググループ。
2.2. Restrictions on Sharing a Subtype Name
2.2. Subtype名を共有するときの制限
The same media subtype name MUST NOT be shared for RTP and non-RTP (file-based) transfer methods unless the data format is the same for both methods. The data format is considered to be the same if the file format is equivalent to a concatenated sequence of payloads from RTP packets not including the RTP header or any RTP payload-format header.
両方のメソッドには、データの形式が同じでない場合、同じメディア「副-タイプ」名はRTPと非RTPのために共有された(ファイルベースの)転写法であるはずがありません。 ファイル形式がRTPヘッダーかどんなRTPペイロード形式ヘッダーも含まないRTPパケットからのペイロードの連結された系列に同等であるなら、データの形式が同じであると考えられます。
The file format MAY include a magic number or other header at the start of the file that is not included when the data is transferred via RTP.
ファイル形式はRTPを通してデータを移すとき含んでいないファイルの始めにマジックナンバーか他のヘッダーを含むかもしれません。
Casner Standards Track [Page 5] RFC 4855 Media Type Reg. of RTP Payload Formats February 2007
Casner標準化過程[5ページ]RFC4855メディアはレッジをタイプします。RTPでは、有効搭載量は2007年2月をフォーマットします。
A second requirement for sharing a media subtype name is that the sets of required parameters must be the same for both methods.
メディア「副-タイプ」名を共有するための2番目の要件は両方のメソッドに、必要なパラメタのセットが同じであるに違いないということです。
For cases where the data format or required parameters cannot be the same for RTP and non-RTP transfer methods, the data formats MUST be registered as separate types. It is RECOMMENDED that the subtype names be related, such as by using a common root plus a suffix. For those cases where a suffix is applied in the subtype name for the RTP transfer method, the suffix "+rtp" is suggested.
RTPに、データの形式か必要なパラメタが同じであるはずがないケースと非RTP転写法において、別々のタイプとしてデータ形式を示さなければなりません。 「副-タイプ」名が共通根と接尾語を使用するのなどように関係づけられるのは、RECOMMENDEDです。 「接尾語が」 + RTP転写法、接尾語rtpのために「副-タイプ」名で適用されるそれらのケース」は示されます。
3. Mapping to SDP Parameters
3. パラメタをSDPに写像します。
The representation of a media type is specified in the syntax of the Content-Type header field in RFC 2045 [6] as follows:
メディアタイプの表現は[6] 以下のRFC2045でコンテントタイプヘッダーフィールドの構文で指定されます:
type "/" subtype *(";" parameter)
」 「タイプ」/「副-タイプ」*(「」、;、パラメタ)
Parameters may be required for a particular type or subtype or they may be optional. For media types that represent RTP payload formats, the parameters "rate", "channels", "ptime", and "maxptime" have general definitions (given above) that may apply across types and subtypes. The format for a parameter is specified in RFC 2045 as
パラメタが特定のタイプか「副-タイプ」に必要であるかもしれません、またはそれらは任意であるかもしれません。 RTPペイロード書式を表すメディアタイプのために、「チャンネル(ptime)」と「評価する」というパラメタと"maxptime"には、タイプと血液型亜型の向こう側に適用されるかもしれない一般的な定義(上に与える)があります。 パラメタのための形式はRFC2045で指定されます。
attribute "=" value
属性「=」価値
where attribute is the parameter name and the permissible values are specified for each parameter. RFC 2045 specifies that a value MUST be present and that the value MUST be a quoted string if it contains any of the special characters listed in that RFC.
属性がどこのパラメタ名であるか、そして、許容値は各パラメタに指定されます。 RFC2045は値が存在していなければならなくて、そのRFCに記載された特殊文字のどれかを含んでいるなら値が引用文字列でなければならないと指定します。
The information carried in the media type string has a specific mapping to fields in the Session Description Protocol (SDP) [5], which is commonly used to describe RTP sessions. The mapping is as follows:
タイプが結ぶメディアで運ばれた情報はSession記述プロトコル(SDP)[5]に特定のマッピングを分野に持っています。([5]は、RTPセッションについて説明するのに一般的に使用されます)。 マッピングは以下の通りです:
o The media type (e.g., audio) goes in SDP "m=" as the media
name.
o メディアタイプ(例えば、オーディオ)はメディア名としてSDP「m=」に行きます。
o The media subtype (payload format) goes in SDP "a=rtpmap" as
the encoding name.
o メディア「副-タイプ」(ペイロード形式)はコード化名としてSDP"a=rtpmap"に入ります。
o The general (possibly optional) parameters "rate" and
"channels" also go in "a=rtpmap" as clock rate and encoding
parameters, respectively.
o 一般的な(ことによると任意の)パラメタは「評価します」、そして、また、「チャンネル」はクロックレートとしての"a=rtpmap"とそれぞれパラメタをコード化する際に行きます。
o The general (and optional) parameters "ptime" and "maxptime" go
in the SDP "a=ptime" and "a=maxptime" attributes, respectively.
o 一般的で(任意)のパラメタの"ptime"と"maxptime"はそれぞれSDP"a=ptime"と"a=maxptime"属性に入ります。
Casner Standards Track [Page 6] RFC 4855 Media Type Reg. of RTP Payload Formats February 2007
Casner標準化過程[6ページ]RFC4855メディアはレッジをタイプします。RTPでは、有効搭載量は2007年2月をフォーマットします。
o Any payload-format-specific parameters go in the SDP "a=fmtp"
attribute. The set of allowed parameters is defined by the RFC
that specifies the payload format and MUST NOT be extended by
the media type registration without a corresponding revision of
the payload format specification. The format and syntax of
these parameters may also be defined by the payload format
specification, but it is suggested that the parameters be
copied directly from the media type string as a semicolon
separated list of parameter=value pairs. For payload formats
that specify some other syntax for the fmtp parameters, the
registration of that payload format as a media type must
specify what the parameters are in MIME format and how to map
them to the "a=fmtp" attribute.
o どんなペイロード形式詳細パラメタもSDP"a=fmtp"属性に入ります。 許容パラメタのセットを、ペイロード形式を指定するRFCが定義して、ペイロード書式仕様の対応する改正なしでメディアタイプ登録で広げてはいけません。 また、これらのパラメタの書式と構文はペイロード書式仕様によって定義されるかもしれませんが、パラメタ=価値のセミコロンの切り離されたリストが対にされるのでパラメタが直接タイプが結ぶメディアからコピーされることが提案されます。 fmtpパラメタにある他の構文を指定するペイロード形式として、メディアタイプとしてのそのペイロード形式の登録はパラメタがMIME形式において何であるか、そして、どのように"a=fmtp"属性にそれらを写像するかを指定しなければなりません。
An example mapping is as follows:
例のマッピングは以下の通りです:
audio/L16; rate=48000; channels=2; ptime=5; emphasis=50-15
オーディオ/L16。 =が48000であると評定してください。 =2にチャネルを開設します。 ptime=5。 強調は50-15と等しいです。
m=audio 49170 RTP/AVP 97
a=rtpmap:97 L16/48000/2
a=fmtp:97 emphasis=50-15
a=ptime:5
オーディオの49170RTP/AVP97m=a=rtpmap: 97L16/48000/2 a=fmtp: 97強調=50-15a=ptime: 5
Note that the payload format (encoding) names defined in the RTP Profile [4] are commonly shown in upper case. Media subtype names are commonly shown in lower case. These names are case-insensitive in both places. Similarly, parameter names are case-insensitive both in media type strings and in the default mapping to the SDP a=fmtp attribute.
RTP Profile[4]で定義されたペイロード形式(コード化する)名が大文字で一般的に示されることに注意してください。 メディア「副-タイプ」名は小文字で一般的に示されます。 これらの名前は両方の場所で大文字と小文字を区別しないです。 同様に、パラメタ名はタイプが結ぶメディアとデフォルトマッピングでSDP a=fmtp属性に大文字と小文字を区別しないです。
4. Changes from RFC 3555
4. RFC3555からの変化
This document updates RFC 3555 to conform to the revised media type registration procedures in RFC 4288 [1]. Whereas RFC 3555 required the encoding considerations to specify transfer via RTP, that is now specified under restrictions on usage. This document also specifies the conditions under which new optional parameters may be added to a previously defined RTP media type and adds a new Section 2.2 to clarify the requirements for sharing a media type among RTP and non- RTP transfer methods.
このドキュメントは、RFC4288[1]でタイプ登録手順を改訂されたメディアに従わせるためにRFC3555をアップデートします。 RFC3555はRTPを通して転送を指定するためにコード化問題を必要としましたが、それは現在、用法で制限で指定されます。 このドキュメントは、また、新しい任意のパラメタが以前に定義されたRTPメディアタイプに追加されるかもしれない状態を指定して、RTPと非RTPの転写法の中でメディアタイプを共有するための要件をはっきりさせるために新しいセクション2.2を加えます。
RFC 3555 included media type registrations for the RTP payload formats defined in the RTP Profile for Audio and Video Conferences, RFC 3551 [4]. Those media type registrations have been removed from this document. Some of them have been assembled into a separate companion RFC 4856 [8], leaving out those that have been, or are intended to be, registered in revisions of their own payload format specification RFCs.
RFC3555の含まれているメディアはAudioとVideoコンファレンス(RFC3551[4])のためにRTP Profileで定義されたRTPペイロード書式のための登録証明書をタイプします。 このドキュメントからそれらのメディアタイプ登録証明書を取り除きました。 それらのいくつかが別々の仲間RFC4856[8]に組み立てられました、それら自身のペイロード書式仕様RFCsの改正であるか、意図していて、または登録されたものを省いて。
Casner Standards Track [Page 7] RFC 4855 Media Type Reg. of RTP Payload Formats February 2007
Casner標準化過程[7ページ]RFC4855メディアはレッジをタイプします。RTPでは、有効搭載量は2007年2月をフォーマットします。
Philipp Hoschka is a co-author of RFC 3555; his contributions to the foundation of this document are appreciated.
フィリップHoschkaはRFC3555の共著者です。 このドキュメントの基礎への彼の貢献に感謝します。
5. Security Considerations
5. セキュリティ問題
The media type registration procedure specified in this memo does not impose any security considerations on its own. Also, registrations conforming to this procedure do not themselves impose security risks. However, use of the media type being registered could very well impose security risks:
登録手順がこのメモで指定したメディアタイプはどんなセキュリティ問題もそれ自身のものに課しません。 また、この手順に従うのが自分たちにするというわけではない登録証明書はセキュリティ危険を課します。 しかしながら、示されるメディアタイプの使用はセキュリティ危険を非常によく課すかもしれません:
o Any media type that contains "active content" imposes the risk
of malicious side-effects unless execution of that content is
adequately constrained.
o その内容の実行が適切に抑制されない場合、「アクティブな内容」を含むどんなメディアタイプも悪意がある副作用の危険を課します。
o Several audio and video encodings are perfect for hiding data
using steganography.
o ステガノグラフィを使用することでデータを隠すのに、数個のオーディオとビデオencodingsが完全です。
o The RTP specification, RFC 3550, provides security
considerations for the transport of audio and video data over
RTP, including the use of encryption where confidentiality is
required.
o RTP仕様(RFC3550)はRTPの上でオーディオとビデオ・データの輸送にセキュリティ問題を提供します、秘密性が必要であるところに暗号化の使用を含んでいて。
Therefore, each media type registration is required to state any security considerations that apply to the use of that type. The remainder of this section is copied from RFC 4288 [1], which specifies media type registration procedures in general.
したがって、それぞれのメディアタイプ登録が、そのタイプの使用に適用されるどんなセキュリティ問題も述べるのに必要です。 このセクションの残りはRFC4288[1]からコピーされます。([1]はメディアタイプのために一般に、登録手順を指定します)。
An analysis of security issues MUST be done for all types registered in the standards tree. A similar analysis for media types registered in the vendor or personal trees is encouraged but not required. However, regardless of what security analysis has or has not been done, all descriptions of security issues MUST be as accurate as possible regardless of registration tree. In particular, a statement that there are "no security issues associated with this type" MUST NOT be confused with "the security issues associated with this type have not been assessed".
規格木に示されたすべてのタイプのために安全保障問題の分析をしなければなりません。 ベンダーで示されたメディアタイプか個人的な木のための同様の分析は、奨励されますが、必要ではありません。 しかしながら、証券分析が持っているか、または行われていない何にかかわらず、安全保障問題のすべての記述が登録木にかかわらずできるだけ正確でなければならないか。 特に、「このタイプに関連している安全保障問題がありません」があるという声明は「このタイプに関連している安全保障問題は評価されていないこと」に混乱してはいけません。
There is absolutely no requirement that media types registered in any tree be secure or completely free from risks. Nevertheless, all known security risks MUST be identified in the registration of a media type, again regardless of registration tree.
どんな木にも示されたメディアタイプが安全であるか、または完全に無料であるという要件は全くリスクから絶対に来ていません。 それにもかかわらず、再び登録木にかかわらずメディアタイプの登録ですべての知られているセキュリティ危険を特定しなければなりません。
The security considerations section of all registrations is subject to continuing evaluation and modification, and in particular MAY be extended by use of the "comments on media types" mechanism described in RFC 4288, Section 6.
登録証明書を条件としているすべてのセキュリティ問題部は、評価と変更を続けて、RFC4288(セクション6)で説明された「メディアタイプのコメント」メカニズムの使用で特に広げられるかもしれません。
Casner Standards Track [Page 8] RFC 4855 Media Type Reg. of RTP Payload Formats February 2007
Casner標準化過程[8ページ]RFC4855メディアはレッジをタイプします。RTPでは、有効搭載量は2007年2月をフォーマットします。
Some of the issues that should be looked at in a security analysis of a media type are:
それがメディアタイプの証券分析で見られるべきである問題のいくつかは以下の通りです。
o Complex media types may include provisions for directives that
institute actions on a recipient's files or other resources.
In many cases, provision is made for originators to specify
arbitrary actions in an unrestricted fashion that may then have
devastating effects. See the registration of the
application/postscript media type in RFC 2046 [7] for an
example of such directives and how they should be described in
a media type registration.
o 複雑なメディアタイプは受取人のファイルか他のリソースへの動作を設ける指示のための条項を入れるかもしれません。 多くの場合、創始者が次に破壊的な効果を持っているかもしれない無制限なファッションで勝手な行動を指定するのを設備をします。 アプリケーション/追伸メディアタイプの登録がそのような指示とそれらがメディアでどのように説明されるべきであるかに関する例のためのRFC2046[7]に登録をタイプするのを見てください。
o All registrations MUST state whether or not they employ such
"active content", and if they do, they MUST state what steps
have been taken to protect users of the media type from harm.
o 害からメディアタイプのユーザを保護するために彼らがそのような「アクティブな内容」を使って、そうするなら、踏まれるものを述べなければならないか否かに関係なく、登録証明書が述べなければならないすべてを取りました。
o Complex media types may include provisions for directives that
institute actions that, while not directly harmful to the
recipient, may result in disclosure of information that either
facilitates a subsequent attack or else violates a recipient's
privacy in some way. Again, the registration of the
application/postscript media type illustrates how such
directives can be handled.
o 複雑なメディアタイプは受取人には直接有害でない間にどちらかがその後の攻撃を容易にするか、または何らかの方法で受取人のプライバシーに違反するという情報の公開をもたらすかもしれない動作を設ける指示のための条項を入れるかもしれません。 一方、アプリケーション/追伸メディアタイプの登録はどうそのような指示を扱うことができるかを例証します。
o A media type that employs compression may provide an
opportunity for sending a small amount of data that, when
received and evaluated, expands enormously to consume all of
the recipient's resources. All media types SHOULD state
whether or not they employ compression, and if they do they
should discuss what steps need to be taken to avoid such
attacks.
o 圧縮を使うメディアタイプは受け取られて、評価されると途方もないほど広がる少量のデータを送るのに受取人のリソースのすべてを消費する機会を与えるかもしれません。 彼らが圧縮を使って、そうするなら踏まれるものについて議論するべきであるか否かに関係なく、SHOULDが述べるすべてのメディアタイプが、そのような攻撃を避けるために取られる必要があります。
o A media type might be targeted for applications that require
some sort of security assurance but not provide the necessary
security mechanisms themselves. For example, a media type
could be defined for storage of confidential medical
information that in turn requires an external confidentiality
service or is designed for use only within a secure
environment.
o メディアタイプはある種の安全保証を必要としますが、必要なセキュリティー対策自体を提供しないアプリケーションのために狙うかもしれません。 例えば、メディアタイプは、順番に外部の秘密性サービスを必要とする秘密の医療情報のストレージのために定義できたか、または使用のために安全な環境だけの中で設計されています。
6. IANA Considerations
6. IANA問題
The purpose of this document is to specify the requirements and procedures for registering RTP payload formats in the IANA media type registry. No registrations are defined here.
このドキュメントの目的が要件を指定することであり、IANAメディアでRTPペイロード形式を示すための手順は登録をタイプします。 登録証明書は全くここで定義されません。
Casner Standards Track [Page 9] RFC 4855 Media Type Reg. of RTP Payload Formats February 2007
Casner標準化過程[9ページ]RFC4855メディアはレッジをタイプします。RTPでは、有効搭載量は2007年2月をフォーマットします。
7. References
7. 参照
7.1. Normative References
7.1. 引用規格
[1] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December, 2005.
解放された[1]とN.とJ.Klensin、「メディアは仕様と登録手順をタイプする」BCP13、RFC4288、2005年12月。
[2] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP:
A Transport Protocol for Real-Time Applications", RFC 3550, July
2003.
[2]Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、RFC3550、2003年7月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[4] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
Conferences with Minimal Control", RFC 3551, July 2003.
[4]SchulzrinneとH.とS.Casner、「最小量のコントロールがあるオーディオとテレビ会議システムのためのRTPプロフィール」、RFC3551、2003年7月。
[5] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[5] ハンドレー、M.、ジェーコブソン、V.、およびC.パーキンス、「SDP:」 「セッション記述プロトコル」、RFC4566、2006年7月。
[6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
解放された[6]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。
[7] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, November
1996.
解放された[7]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は2を分けます」。 「メディアタイプ」、RFC2046、1996年11月。
7.2. Informative References
7.2. 有益な参照
[8] Casner, S., "Media Type Registration of Payload Formats in the
RTP Profile for Audio and Video Conferences", RFC 4856, February
2007.
[8] Casner、S.、「メディアはオーディオとテレビ会議システムのためのRTPプロフィールでの有効搭載量形式の登録をタイプします」、RFC4856、2007年2月。
Author's Address
作者のアドレス
Stephen L. Casner Packet Design 3400 Hillview Avenue, Building 3 Palo Alto, CA 94304 United States
スティーブンL.CasnerパケットDesign3400Hillviewアベニュー、Building3パロアルト、カリフォルニア94304合衆国
Phone: +1 650 739-1843 EMail: casner@acm.org
以下に電話をしてください。 +1 650 739-1843 メールしてください: casner@acm.org
Casner Standards Track [Page 10] RFC 4855 Media Type Reg. of RTP Payload Formats February 2007
Casner標準化過程[10ページ]RFC4855メディアはレッジをタイプします。RTPでは、有効搭載量は2007年2月をフォーマットします。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
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, THE IETF TRUST 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
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 currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Casner Standards Track [Page 11]
Casner標準化過程[11ページ]
一覧
スポンサーリンク
