[要約] RFC 4855は、RTPペイロード形式のメディアタイプ登録に関する規格です。その目的は、新しいメディアタイプを定義し、RTPで使用するためのペイロード形式を識別することです。
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
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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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）を中央レジストリとして使用するメディアタイプの仕様と登録手順を定義します。このドキュメントは、特定のアプリケーション環境と輸送モードに依存しない一般的な要件をカバーしています。このドキュメントでは、RTPペイロード形式を特定するために、リアルタイムトランスポートプロトコル（RTP）、RFC 3550 [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 [3] and indicate requirement levels for implementations compliant with this specification.
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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:
RTPペイロードタイプをメディアタイプとして登録すると、RFC 4288 [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].
オプションのパラメーター：ほとんどのオーディオペイロードフォーマットには、オプションの「チャネル」パラメーターがあり、送信に含まれるオーディオチャネルの数を指定できます。デフォルトのチャネル順序は、RFC 3551 [4]で指定されているとおりです。任意のペイロード形式、しかしおそらくオーディオ形式は、パケット内のメディアが表すミリ秒単位で推奨される時間を指定するオプションのパラメーター「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.
特定のペイロード形式には、追加のオプションパラメーターがある場合があります。[1]のセクション4.3で許可されているように、新しいパラメーターは以前に定義されたRTPメディアタイプに追加される場合がありますが、新しいパラメーターは既存の機能を変更してはならず、既存の実装が操作を損なうことなく追加のパラメーターを無視することができなければなりません。
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で説明されているように、バイナリまたはフレームデータが含まれます。適切なエンコーディングの考慮事項に注意する必要があります。
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:
タイプが既に非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.
オプションのパラメーターは、必要に応じて定義される場合があり、パラメーターが適用される転送モードに明確に記載する必要があります。
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トランスポートを介して送信される場合にのみ使用されることを明確に述べる必要があります。
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またはステレオの場合は2、省略されている場合はデフォルトです。インターリーブは、フレームごとのフレームベースで行われ、左チャネルに続いて右チャネルが続きます。
ptime: recommended length of time in milliseconds represented by the media in a packet (see RFC 4566).
PTIME：パケット内のメディアが表すミリ秒で推奨される時間の長さ（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>
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（RFC 3550）を介した転送に対してのみ定義されます。この時点では、他のフレーミングプロトコル内の転送は定義されていません。
Author: Fred Audio
著者：フレッドオーディオ
Change controller: IETF Audio/Video Transport working group delegated from the IESG.
Change Controller：IETFオーディオ/ビデオトランスポートワーキンググループは、IESGから委任されました。
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.
メディアサブタイプ名を共有するための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転送方法で同じにできない場合、データ形式は個別のタイプとして登録する必要があります。共通のルートと接尾辞を使用するなど、サブタイプ名を関連することをお勧めします。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 [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:
メディアタイプの文字列に掲載されている情報には、セッション説明プロトコル（SDP）[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」属性になります。
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
m=audio 49170 RTP/AVP 97
a=rtpmap:97 L16/48000/2
a=fmtp:97 emphasis=50-15
a=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 3555を更新して、RFC 4288の改訂されたメディアタイプの登録手順に準拠しています[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ペイロード形式のメディアタイプ登録が含まれています。RFC3551[4]。これらのメディアタイプの登録は、このドキュメントから削除されました。それらのいくつかは、独立したコンパニオンRFC 4856 [8]に組み立てられており、独自のペイロード形式仕様RFCの改訂に登録されている、または意図されているものを除外しています。
Philipp Hoschka is a co-author of RFC 3555; his contributions to the foundation of this document are appreciated.
Philipp 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.
o RTP仕様である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 複雑なメディアタイプには、受信者のファイルまたはその他のリソースに関するアクションを制定する指令に関する規定が含まれる場合があります。多くの場合、発信者が無制限の方法で任意のアクションを指定するための規定がなされ、その後、壊滅的な効果がある可能性があります。このような指令の例と、メディアタイプの登録で説明する方法については、RFC 2046 [7]のアプリケーション/PostScriptメディアタイプの登録を参照してください。
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 複雑なメディアタイプには、受信者に直接有害ではないが、後続の攻撃を促進するか、何らかの方法で受信者のプライバシーに違反する情報の開示をもたらす可能性があるという指示の規定が含まれる場合があります。繰り返しますが、アプリケーション/PostScriptメディアタイプの登録は、そのような指令の処理方法を示しています。
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] Freed、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.、Frederick、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、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プロファイル」、RFC 3551、2003年7月。
[5] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[5] Handley、M.、Jacobson、V。、およびC. Perkins、「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] Freed、N。およびN. Borenstein、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[7] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[7] Freed、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
Stephen L. Casner Packet Design 3400 Hillview Avenue、Building 3 Palo Alto、CA 94304米国
Phone: +1 650 739-1843
EMail: casner@acm.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、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は、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。