Network Working Group S. Casner
Request for Comments: 4855 Packet Design
Obsoletes: 3555 February 2007
Category: Standards Track
Media Type Registration of RTP Payload Formats
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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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
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.
RFC 4288 [1]は、中央レジストリとしてインターネット割り当て番号機関（IANA）を使用してメディアタイプ仕様と登録手続きを定義します。その文書は、特定のアプリケーション環境や輸送モードの独立した一般的な要件をカバーしています。この文書では、[2]は、RTPペイロードフォーマットを識別するために、RFC 3550、リアルタイムトランスポートプロトコル（RTP）と共に使用するためのメディアタイプの登録のための特定の要件を定義します。
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"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119 [3]に記載され、この仕様に準拠した実装の要求レベルを示すものと解釈されます。
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:
メディアタイプは、[1] RFC 4288に記載のものと同じ手順に従うと、そのRFCのセクション10に示した登録テンプレートを使用するようにRTPペイロードタイプを登録します。特定のペイロードフォーマットは、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].
オプションのパラメータ：ほとんどのオーディオペイロード形式は、送信に含まれる音声チャンネルの数を指定するには、オプションの「チャンネル」パラメータを持つことができます。 [4] RFC 3551に指定されているデフォルトのチャネルの順序です。任意のペイロードフォーマットが、最も可能性の高いオーディオフォーマットは、また、「PTIMEは」パケット内のメディアで表されるミリ秒単位で時間の推奨される長さを指定するために、及び/又は「maxptime」メディアの最大量を指定するオプションのパラメータを含むことができます各パケットにカプセル化することができ、ミリ秒単位の時間として表さ。 「PTIME」および「maxptime」パラメータは、セッション記述プロトコル（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 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.
符号化の考慮事項：[1]のセクション4.8に記載されているようにほとんどのRTPペイロードフォーマットはバイナリ又はフレームデータを含みます。適切なエンコーディングの考慮事項に留意しなければなりません。
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タイムスタンプクロックレート（又は複数のサンプリングレートのオーディオ符号化のための複数のレート）を含まなければなりません。
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フレーミングに依存し、したがってメディアタイプのみ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:
タイプが既に（例えば、MIMEメールやHTTP）は、非RTPプロトコルに転送するために登録されているか否かに応じて、いくつかの異なるケースが発生する可能性があります。
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.
必要に応じてオプションのパラメータを定義することができ、それは明確にパラメータが適用されます転送のどのモード（複数可）を明記しなければなりません。
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
RTPは、非RTPプロトコルに使用するためのC）既存のメディアタイプを更新
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トランスポートを介して送信される場合、これらのみを使用することを述べなければなりません。
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
サブタイプ名：例
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.
オプションのパラメータ：チャネル：1にインターリーブされたオーディオストリームの数、いずれかのステレオのためのモノための1又は2、及びデフォルトが省略された場合。インターリーブは右チャンネルに続いて左チャンネルで、フレーム単位での間で行われます。
ptime: recommended length of time in milliseconds represented
by the media in a packet (see RFC 4566).
maxptime: maximum amount of media that can be encapsulated in each packet, expressed as time in milliseconds (see RFC 4566).
maxptime：各パケットにカプセル化することができる媒体の最大量は、（RFC 4566を参照）をミリ秒単位での時間で表されます。
Encoding considerations: This media type is framed binary data (see RFC 4288, Section 4.8).
エンコードの考慮事項：このメディアタイプは、（RFC 4288、セクション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メールアドレスは、詳細のために連絡する：フレッド・オーディオ<fred@example.com>
Intended usage: COMMON
意図している用法：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（RFC 3550）を介した転送のために定義されています。他のフレーミングプロトコル内の転送は、この時点で定義されていません。
Author: Fred Audio
著者：フレッド・オーディオ
Change controller: IETF Audio/Video Transport working group delegated from the IESG.
変更コントローラ：IESGから委任IETFオーディオ/ビデオ輸送ワーキンググループ。
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を介して転送されたときに含まれていないファイルの先頭のマジックナンバーまたは他のヘッダを含むかもしれません。
A second requirement for sharing a media subtype name is that the sets of required parameters must be the same for both methods.
メディアサブタイプ名を共有するための第二の要件は、必要なパラメータのセットが両方の方法で同じでなければならないことです。
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転送方法について同じことができない場合のために、データフォーマットは別のタイプとして登録されなければなりません。このような共通のルートに加えて接尾辞を使用することなどによって、サブタイプ名が関連することが推奨されます。接尾辞は、RTP転送方式のためのサブタイプ名に適用されるような場合のために、接尾辞「+ RTPは、」提案されます。
The representation of a media type is specified in the syntax of the Content-Type header field in RFC 2045 [6] as follows:
メディアタイプの表現は、RFC 2045のContent-Typeヘッダフィールドの構文で指定されている[6]を次のように
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」はタイプおよびサブタイプを横切って適用することができる一般的な定義（上記）を有します。パラメータのフォーマットは、RFC 2045で指定されています
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.
属性は、パラメータ名であり、許容値は、各パラメータに指定されています。 RFC 2045には値が存在し、それがその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:
メディアタイプ文字列で搬送される情報は、[5]、一般にRTPセッションを記述するために使用されるセッション記述プロトコル（SDP）内のフィールドに特定のマッピングを有します。次のようにマッピングは次のとおりです。
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.
一般的な（およびオプション）のパラメータ "PTIME" Oおよび "maxptime" SDPの "= PTIME" を行って、 "A = maxptime" は、それぞれ、属性。
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「=の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
M =オーディオ49170 RTP / AVP 97 = rtpmap：97 L16 / 2分の48000 A =のfmtp：97の重点= 50-15 = 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プロファイル[4]で定義されたペイロードフォーマット（符号化）の名前は、一般的に大文字で示されていることに留意されたいです。メディアサブタイプ名は、一般的に小文字で示されています。これらの名前は、両方の場所で大文字と小文字を区別しません。同様に、パラメータ名は大文字と小文字を区別しないメディアタイプストリングおよびSDPのA =のfmtp属性にデフォルトマッピングの両方です。
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.
RFC 4288に改訂されたメディアタイプ登録手続きに準拠するために、この文書の更新RFC 3555 [1]。 RFC 3555のに対し、今、使用上の制約の下で指定された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.
RFC 3555は、オーディオおよびビデオ会議のためのRTPプロファイルで定義されたRTPペイロード形式のメディアタイプ登録を含め、RFC 3551 [4]。これらのメディアタイプの登録は、この文書から削除されました。それらのいくつかは、別のコンパニオンRFC 4856に組み込まれている[8]、独自のペイロードフォーマット仕様RFCの改訂に登録されている、またはあることが意図されているものを除外します。
Philipp Hoschka is a co-author of RFC 3555; his contributions to the foundation of this document are appreciated.
フィリップHoschkaは、RFC 3555の共著者です。このドキュメントの基盤への彼の貢献は高く評価されています。
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いくつかのオーディオとビデオのエンコーディングは、ステガノグラフィーを使用してデータを隠すために最適です。
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.
RTP仕様O、RFC 3550には、機密性が必要とされる暗号化の使用を含む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.
そのため、各メディアタイプの登録は、そのタイプの使用に適用されるセキュリティ上の考慮事項を述べるために必要とされます。このセクションの残りの部分は、一般に、メディアタイプ登録手続きを指定するRFC 4288 [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.
すべての登録のセキュリティの考慮事項のセクションでは、継続的な評価と修正の対象であり、特に、RFC 4288に記述メカニズム、第6章「メディアタイプのコメント」を使用することによって延長することができます。
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複雑なメディアタイプは、受信者のファイルや他のリソースに対するアクションを提起ディレクティブの規定を含んでいてもよいです。多くの場合、引当金は、壊滅的な影響を与えることが無制限の方法で任意のアクションを指定するにはオリジネーターのために作られています。そのような指示の例およびそれらがどのようにメディアタイプ登録に記載されるべきである[7] RFC 2046内のアプリケーション/追記メディアタイプの登録を参照してください。
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。すべてのメディアタイプは、彼らが圧縮を採用し、彼らがしなければ、彼らはこのような攻撃を避けるように注意する必要がどのような手順話し合う必要があるかどうかを必ず明記してください。
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メディアタイプは、セキュリティ保証のいくつかの並べ替えを必要としますが、必要なセキュリティ機構そのものを提供していないアプリケーションを対象とされる可能性があります。例えば、メディアタイプが順番に外部の機密性サービスを必要とするか、または唯一の安全な環境内での使用のために設計されている機密の医療情報の保存のために定義することができます。
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ペイロードフォーマットを登録するための要件と手順を指定することです。いいえ登録はここで定義されていません。
[1] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December, 2005.
[1]解放され、N.とJ. Klensin、 "メディアタイプの仕様と登録手順" を、BCP 13、RFC 4288、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. Jacobson氏、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、RFC 3550、2003年7月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[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プロフィール"、RFC 3551、2003年7月。
[5] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[5]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "SDP：セッション記述プロトコル"、RFC 4566、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）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、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：メディアタイプ"、RFC 2046、1996年11月。
[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プロファイルにおけるペイロード形式のメディアタイプ登録」、RFC 4856、2007年2月を。
Author's Address
著者のアドレス
Stephen L. Casner Packet Design 3400 Hillview Avenue, Building 3 Palo Alto, CA 94304 United States
スティーブンL. Casnerパケットデザイン3400ヒルビュー・アベニュー、3パロアルト、CA 94304米国の構築
Phone: +1 650 739-1843 EMail: casner@acm.org
電話：+1 650 739-1843 Eメール：casner@acm.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。