[要約] RFC 3389は、RTPのためのComfort Noise（CN）ペイロードに関する仕様です。CNは、通信の間に静寂を提供するために使用されます。このRFCの目的は、CNの使用方法とパケットのフォーマットを定義することです。
Network Working Group R. Zopf
Request for Comments: 3389 Lucent Technologies
Category: Standards Track September 2002
Real-time Transport Protocol (RTP) Payload for Comfort Noise (CN)
リアルタイム転送プロトコル（RTP）ペイロード（コンフォートノイズ（CN）用）
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 Internet Society (2002). All Rights Reserved.
Copyright（C）The Internet Society（2002）。全著作権所有。
Abstract
概要
This document describes a Real-time Transport Protocol (RTP) payload format for transporting comfort noise (CN). The CN payload type is primarily for use with audio codecs that do not support comfort noise as part of the codec itself such as ITU-T Recommendations G.711, G.726, G.727, G.728, and G.722.
このドキュメントでは、コンフォートノイズ（CN）を転送するためのリアルタイム転送プロトコル（RTP）ペイロード形式について説明します。 CNペイロードタイプは主に、ITU-T勧告G.711、G.726、G.727、G.728、G.722などのコーデック自体の一部としてコンフォートノイズをサポートしないオーディオコーデックで使用するためのものです。
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 [7].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC-2119 [7]で説明されているように解釈されます。
This document describes a RTP [1] payload format for transporting comfort noise. The payload format is based on Appendix II of ITU-T Recommendation G.711 [8] which defines a comfort noise payload format (or bit-stream) for ITU-T G.711 [2] use in packet-based multimedia communication systems. The payload format is generic and may also be used with other audio codecs without built-in Discontinuous Transmission (DTX) capability such as ITU-T Recommendations G.726 [3], G.727 [4], G.728 [5], and G.722 [6]. The payload format provides a minimum interoperability specification for communication of comfort noise parameters. The comfort noise analysis and synthesis as well as the Voice Activity Detection (VAD) and DTX algorithms are unspecified and left implementation-specific.
このドキュメントでは、コンフォートノイズを転送するためのRTP [1]ペイロード形式について説明します。ペイロードフォーマットは、ITU-T勧告G.711 [8]の付録IIに基づいており、パケットベースのマルチメディア通信システムで使用されるITU-T G.711 [2]のコンフォートノイズペイロードフォーマット（またはビットストリーム）を定義しています。 。ペイロード形式は一般的であり、ITU-T勧告G.726 [3]、G.727 [4]、G.728 [5]などの組み込みの不連続伝送（DTX）機能のない他のオーディオコーデックでも使用できます。 、およびG.722 [6]。ペイロード形式は、コンフォートノイズパラメータの通信のための最小限の相互運用性仕様を提供します。コンフォートノイズの分析と合成、およびVoice Activity Detection（VAD）アルゴリズムとDTXアルゴリズムは指定されておらず、実装固有です。
However, an example solution for G.711 has been tested and is described in the Appendix [8]. It uses the VAD and DTX of G.729 Annex B [9] and a comfort noise generation algorithm (CNG) which is provided in the Appendix for information.
ただし、G.711のソリューション例がテストされ、付録[8]で説明されています。 G.729 Annex B [9]のVADおよびDTXと、詳細については付録で提供されるコンフォートノイズ生成アルゴリズム（CNG）を使用します。
The comfort noise payload, which is also known as a Silence Insertion Descriptor (SID) frame, consists of a single octet description of the noise level and MAY contain spectral information in subsequent octets. An earlier version of the CN payload format consisting only of the noise level byte was defined in draft revisions of the RFC 1890. The extended payload format defined in this document should be backward compatible with implementations of the earlier version assuming that only the first byte is interpreted and any additional spectral information bytes are ignored.
Silence Insertion Descriptor（SID）フレームとも呼ばれるコンフォートノイズペイロードは、ノイズレベルの単一のオクテット記述で構成され、後続のオクテットにスペクトル情報を含めることができます（MAY）。ノイズレベルバイトのみで構成される以前のバージョンのCNペイロードフォーマットは、RFC 1890のドラフトリビジョンで定義されていました。このドキュメントで定義されている拡張ペイロードフォーマットは、最初のバイトのみが解釈され、追加のスペクトル情報バイトは無視されます。
The comfort noise payload consists of a description of the noise level and spectral information in the form of reflection coefficients for an all-pole model of the noise. The inclusion of spectral information is OPTIONAL and the model order (number of coefficients) is left unspecified. The encoder may choose an appropriate model order based on such considerations as quality, complexity, expected environmental noise, and signal bandwidth. The model order is not explicitly transmitted since the number of coefficients can be derived from the length of the payload at the receiver. The decoder may reduce the model order by setting higher order reflection coefficients to zero if desired to reduce complexity or for other reasons.
コンフォートノイズペイロードは、ノイズの全極モデルの反射係数の形式でのノイズレベルとスペクトル情報の記述で構成されます。スペクトル情報を含めることはオプションであり、モデルの次数（係数の数）は指定されません。エンコーダは、品質、複雑さ、予想される環境ノイズ、信号帯域幅などの考慮事項に基づいて、適切なモデル次数を選択できます。係数の数は受信機のペイロードの長さから導出できるため、モデルの次数は明示的に送信されません。デコーダは、複雑さを軽減するため、またはその他の理由で必要な場合、高次の反射係数をゼロに設定することでモデルの次数を削減できます。
The magnitude of the noise level is packed into the least significant bits of the noise-level byte with the most significant bit unused and always set to 0 as shown below in Figure 1. The least significant bit of the noise level magnitude is packed into the least significant bit of the byte.
ノイズレベルの大きさは、ノイズレベルバイトの最下位ビットにパックされます。最上位ビットは未使用で、図1に示すように常に0に設定されます。ノイズレベルの大きさの最下位ビットは、バイトの最下位ビット。
The noise level is expressed in -dBov, with values from 0 to 127 representing 0 to -127 dBov. dBov is the level relative to the overload of the system. (Note: Representation relative to the overload point of a system is particularly useful for digital implementations, since one does not need to know the relative calibration of the analog circuitry.) For example, in the case of a u-law system, the reference would be a square wave with values +/- 8031, and this square wave represents 0dBov. This translates into 6.18dBm0.
ノイズレベルは-dBovで表され、0〜127の値は0〜-127 dBovを表します。 dBovは、システムの過負荷に関連するレベルです。 （注：アナログ回路の相対的なキャリブレーションを知る必要がないため、システムの過負荷ポイントに対する表現はデジタル実装に特に役立ちます。）たとえば、u-lawシステムの場合、リファレンス+/- 8031の値を持つ方形波になります。この方形波は0dBovを表します。これは6.18dBm0に変換されます。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|0| level |
+-+-+-+-+-+-+-+-+
Figure 1: Noise Level Packing
図1：ノイズレベルパッキング
The spectral information is transmitted using reflection coefficients [8]. Each reflection coefficient can have values between -1 and 1 and is quantized uniformly using 8 bits. The quantized value is represented by the 8 bit index N, where N=0..,254, and index N=255 is reserved for future use. Each index N is packed into a separate byte with the MSB first. The quantized value of each reflection coefficient, k_i, can be obtained from its corresponding index using:
スペクトル情報は、反射係数を使用して送信されます[8]。各反射係数は-1から1までの値を持つことができ、8ビットを使用して均一に量子化されます。量子化された値は、8ビットのインデックスNで表されます。N= 0 ..、254であり、インデックスN = 255は将来の使用のために予約されています。各インデックスNは、MSBが最初の個別のバイトにパックされます。各反射係数の量子化された値k_iは、次を使用して対応するインデックスから取得できます。
k_i(N_i) = 258*(N_i-127) for N_i = 0...254; -1 < k_i < 1
-------------
32768
The first byte of the payload MUST contain the noise level as shown in Figure 1. Quantized reflection coefficients are packed in subsequent bytes in ascending order as in Figure 2 where M is the model order. The total length of the payload is M+1 bytes. Note that a 0th order model (i.e., no spectral envelope information) reduces to transmitting only the energy level.
図1に示すように、ペイロードの最初のバイトにはノイズレベルが含まれている必要があります。量子化された反射係数は、図2のように昇順で後続のバイトにパックされます。ペイロードの全長はM + 1バイトです。 0次モデル（つまり、スペクトルエンベロープ情報なし）は、エネルギーレベルのみを送信するように減少することに注意してください。
Byte 1 2 3 ... M+1
+-----+-----+-----+-----+-----+
|level| N1 | N2 | ... | NM |
+-----+-----+-----+-----+-----+
Figure 2: CN Payload Packing Format
図2：CNペイロードのパッキング形式
The RTP header for the comfort noise packet SHOULD be constructed as if the comfort noise were an independent codec. Thus, the RTP timestamp designates the beginning of the comfort noise period. When this payload format is used under the RTP profile specified in RFC 1890 [10], a static payload type of 13 is assigned for RTP timestamp clock rate of 8,000 Hz; if other rates are needed, they MUST be defined through dynamic payload types. The RTP packet SHOULD NOT have the marker bit set.
コンフォートノイズパケットのRTPヘッダーは、コンフォートノイズが独立したコーデックであるかのように構築する必要があります。したがって、RTPタイムスタンプはコンフォートノイズ期間の開始を示します。このペイロード形式がRFC 1890 [10]で指定されたRTPプロファイルで使用される場合、13の静的ペイロードタイプが8,000 HzのRTPタイムスタンプクロックレートに割り当てられます。他のレートが必要な場合は、動的ペイロードタイプを通じて定義する必要があります。 RTPパケットには、マーカービットが設定されている必要があります（SHOULD NOT）。
Each RTP packet containing comfort noise MUST contain exactly one CN payload per channel. This is required since the CN payload has a variable length. If multiple audio channels are used, each channel MUST use the same spectral model order 'M'.
コンフォートノイズを含む各RTPパケットには、チャネルごとに正確に1つのCNペイロードが含まれている必要があります。 CNペイロードは可変長であるため、これは必須です。複数のオーディオチャネルが使用される場合、各チャネルは同じスペクトルモデル次数「M」を使用する必要があります。
An audio codec with DTX capabilities generally includes VAD, DTX, and CNG algorithms. The job of the VAD is to discriminate between active and inactive voice segments in the input signal. During inactive voice segments, the role of the CNG is to sufficiently describe the ambient noise while minimizing the transmission rate. A CN payload (or SID frame) containing a description of the noise is sent to the receiver to drive the CNG. The DTX algorithm determines when a CN payload is transmitted. During active voice segments, packets of the voice codec are transmitted and indicated in the RTP header by the static or dynamic payload type for that codec. At the beginning of an inactive voice segment (silence period), a CN packet is transmitted in the same RTP stream and indicated by the CN payload type. The CN packet update rate is left implementation specific. For example, the CN packet may be sent periodically or only when there is a significant change in the background noise characteristics. The CNG algorithm at the receiver uses the information in the CN payload to update its noise generation model and then produce an appropriate amount of comfort noise.
DTX機能を備えたオーディオコーデックには、通常、VAD、DTX、CNGアルゴリズムが含まれています。 VADの役割は、入力信号内のアクティブな音声セグメントと非アクティブな音声セグメントを区別することです。非アクティブな音声セグメントの間、CNGの役割は、伝送速度を最小限に抑えながら、周囲のノイズを十分に説明することです。ノイズの説明を含むCNペイロード（またはSIDフレーム）は、CNGを駆動するために受信機に送信されます。 DTXアルゴリズムは、CNペイロードが送信されるタイミングを決定します。アクティブな音声セグメントの間、音声コーデックのパケットが送信され、そのコーデックの静的または動的なペイロードタイプによってRTPヘッダーに示されます。非アクティブな音声セグメントの開始時に（沈黙期間）、CNパケットは同じRTPストリームで送信され、CNペイロードタイプで示されます。 CNパケットの更新率は、実装固有です。たとえば、CNパケットは定期的に、またはバックグラウンドノイズ特性に大きな変化があった場合にのみ送信されます。受信側のCNGアルゴリズムは、CNペイロードの情報を使用してノイズ生成モデルを更新し、適切な量のコンフォートノイズを生成します。
The CN payload format provides a minimum interoperability specification for communication of comfort noise parameters. The comfort noise analysis and synthesis as well as the VAD and DTX algorithms are unspecified and left implementation-specific. However, an example solution for G.711 has been tested and is described in Appendix II of ITU-T Recommendation G.711 [8]. It uses the VAD and DTX of G.729 Annex B [9] and a comfort noise generation algorithm (CNG), which is provided in the Appendix for information. Additional guidelines for use such as the factors affecting system performance in the design of the VAD/DTX/CNG algorithms are described in the Appendix.
CNペイロード形式は、コンフォートノイズパラメータの通信のための最小限の相互運用性仕様を提供します。コンフォートノイズの分析と合成、およびVADとDTXのアルゴリズムは指定されておらず、実装固有です。ただし、G.711のソリューション例がテストされ、ITU-T勧告G.711 [8]の付録IIで説明されています。 G.729 Annex B [9]のVADおよびDTXと、詳細については付録で提供されているコンフォートノイズ生成アルゴリズム（CNG）を使用します。付録では、VAD / DTX / CNGアルゴリズムの設計でシステムパフォーマンスに影響を与える要因などの使用に関する追加のガイドラインについて説明します。
When using the Session Description Protocol (SDP) [11] to specify RTP payload information, the use of comfort noise is indicated by the inclusion of a payload type for CN on the media description line. When using CN with the RTP/AVP profile [10] and a codec whose RTP timestamp clock rate is 8000 Hz, such as G.711 (PCMU, static payload type 0), the static payload type 13 for CN can be used:
セッション記述プロトコル（SDP）[11]を使用してRTPペイロード情報を指定する場合、コンフォートノイズの使用は、メディア記述行にCNのペイロードタイプを含めることで示されます。 G.711（PCMU、静的ペイロードタイプ0）などのRTP / AVPプロファイル[10]およびRTPタイムスタンプクロックレートが8000 HzのコーデックでCNを使用する場合、CNの静的ペイロードタイプ13を使用できます。
m=audio 49230 RTP/AVP 0 13
m =オーディオ49230 RTP / AVP 0 13
When using CN with a codec that has a different RTP timestamp clock rate, a dynamic payload type mapping (rtpmap attribute) is required.
RTPタイムスタンプクロックレートが異なるコーデックでCNを使用する場合、動的ペイロードタイプマッピング（rtpmap属性）が必要です。
This example shows CN used with the G.722.1 codec (see RFC 3047 [12]):
この例は、G.722.1コーデックで使用されるCNを示しています（RFC 3047 [12]を参照）。
m=audio 49230 RTP/AVP 101 102
a=rtpmap:101 G7221/16000
a=fmtp:121 bitrate=24000
a=rtpmap:102 CN/16000
Omission of a payload type for CN on the media description line implies that this comfort noise payload format will not be used, but it does not imply that silence will not be suppressed. RTP allows discontinuous transmission (silence suppression) on any audio payload format. The receiver can detect silence suppression on the first packet received after the silence by observing that the RTP timestamp is not contiguous with the end of the interval covered by the previous packet even though the RTP sequence number has incremented only by one. The RTP marker bit is also normally set on such a packet.
メディア記述行でCNのペイロードタイプを省略した場合、このコンフォートノイズペイロードフォーマットは使用されませんが、無音が抑制されないことを意味するわけではありません。 RTPでは、任意のオーディオペイロード形式で不連続伝送（無音圧縮）が可能です。受信者は、RTPシーケンス番号が1だけ増加した場合でも、RTPタイムスタンプが前のパケットがカバーするインターバルの終了と連続していないことを観察することにより、無音の後に受信した最初のパケットの無音抑止を検出できます。通常、RTPマーカービットもこのようなパケットに設定されます。
This section defines a new RTP payload name and associated MIME type, CN (audio/CN). The payload format specified in this document is also assigned payload type 13 in the RTP Payload Types table of the RTP Parameters registry maintained by the Internet Assigned Numbers Authority (IANA).
このセクションでは、新しいRTPペイロード名と関連するMIMEタイプCN（audio / CN）を定義します。このドキュメントで指定されているペイロード形式には、Internet Assigned Numbers Authority（IANA）によって管理されているRTPパラメータレジストリのRTP Payload Typesテーブルでペイロードタイプ13も割り当てられています。
MIME media type name: audio
MIMEメディアタイプ名：オーディオ
MIME subtype name: CN
MIMEサブタイプ名：CN
Required parameters: None
必須パラメーター：なし
Optional parameters: rate: specifies the RTP timestamp clock rate, which is usually (but not always) equal to the sampling rate. This parameter should have the same value as the codec used in conjunction with comfort noise. The default value is 8000.
オプションのパラメーター：rate：RTPタイムスタンプのクロックレートを指定します。これは通常（常にではありませんが）サンプリングレートと同じです。このパラメーターは、コンフォートノイズと共に使用されるコーデックと同じ値にする必要があります。デフォルト値は8000です。
Encoding considerations: This type is only defined for transfer via RTP [RFC 1889].
エンコーディングに関する考慮事項：このタイプは、RTP [RFC 1889]を介した転送に対してのみ定義されます。
Security considerations: see Section 7 "Security Considerations".
セキュリティに関する考慮事項：セクション7「セキュリティに関する考慮事項」を参照してください。
Interoperability considerations: none
相互運用性に関する考慮事項：なし
Published specification: This document and Appendix II of ITU-T Recommendation G.711
公開された仕様：このドキュメントとITU-T勧告G.711の付録II
Applications which use this media type: Audio and video streaming and conferencing tools.
このメディアタイプを使用するアプリケーション：オーディオとビデオのストリーミングおよび会議ツール。
Additional information: none
追加情報：なし
Person & email address to contact for further information: Robert Zopf zopf@lucent.com
詳細について連絡する人とメールアドレス：Robert Zopf zopf@lucent.com
Intended usage: COMMON
使用目的：COMMON
Author/Change controller: Author: Robert Zopf Change controller: IETF AVT Working Group
著者/変更コントローラー：作成者：Robert Zopf変更コントローラー：IETF AVTワーキンググループ
RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [1]. This implies that confidentiality of the media streams is achieved by encryption. Because the payload format is arranged end-to-end, encryption MAY be performed after encapsulation so there is no conflict between the two operations.
この仕様で定義されたペイロード形式を使用するRTPパケットは、RTP仕様[1]で説明されているセキュリティ上の考慮事項の対象となります。これは、メディアストリームの機密性が暗号化によって達成されることを意味します。ペイロード形式はエンドツーエンドで配置されているため、暗号化はカプセル化の後に実行される場合があり、2つの操作間で競合は発生しません。
As this format transports background noise, there are no significant security, confidentiality, or authentication concerns.
この形式はバックグラウンドノイズを転送するため、セキュリティ、機密性、認証に関する重大な問題はありません。
[1] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[1] Schulzrinne、H.、Casner、S.、Frederick、R。およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、RFC 1889、1996年1月。
[2] ITU Recommendation G.711 (11/88) - Pulse code modulation (PCM) of voice frequencies.
[2] ITU勧告G.711（11/88）-音声周波数のパルスコード変調（PCM）。
[3] ITU Recommendation G.726 (12/90) - 40, 32, 24, 16 kbit/s Adaptive Differential Pulse Code Modulation (ADPCM).
[3] ITU勧告G.726（12/90）-40、32、24、16 kbit / s適応型差分パルス符号変調（ADPCM）。
[4] ITU Recommendation G.727 (12/90) - 5-, 4-, 3- and 2-bits sample embedded adaptive differential pulse code modulation (ADPCM).
[4] ITU勧告G.727（12/90）-5、4、3、および2ビットサンプルの埋め込み型適応差動パルスコード変調（ADPCM）。
[5] ITU Recommendation G.728 (09/92) - Coding of speech at 16 kbits/s using low-delay code excited linear prediction.
[5] ITU勧告G.728（09/92）-低遅延コード励起線形予測を使用した16 kbits / sでの音声のコーディング。
[6] ITU Recommendation G.722 (11/88) - 7 kHz audio-coding within 64 kbit/s.
[6] ITU勧告G.722（11/88）-64 kbit / s以内の7 kHzオーディオコーディング。
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[7] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月。
[8] Appendix II to Recommendation G.711 (02/2000) - A comfort noise payload definition for ITU-T G.711 use in packet-based multimedia communication systems.
[8] 勧告G.711の付録II（2000年2月）-パケットベースのマルチメディア通信システムで使用されるITU-T G.711のコンフォートノイズペイロード定義。
[9] Annex B (08/97) to Recommendation G.729 - C source code and test vectors for implementation verification of the algorithm of the G.729 silence compression scheme.
[9] 勧告G.729の付録B（97年8月）-G.729無音圧縮スキームのアルゴリズムの実装検証のためのCソースコードとテストベクトル。
[10] Schulzrinne, H., "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 1890, January 1996.
[10] Schulzrinne、H。、「Minimal Controlを使用したオーディオおよびビデオ会議のRTPプロファイル」、RFC 1890、1996年1月。
[11] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[11] Handley、M。およびV. Jacobson、「SDP：Session Description Protocol」、RFC 2327、1998年4月。
[12] Luthi, P., "RTP Payload Format for ITU-T Recommendation G.722.1", RFC 3047, January 2001.
[12] Luthi、P。、「ITU-T勧告G.722.1のRTPペイロード形式」、RFC 3047、2001年1月。
Robert Zopf Lucent Technologies INS Access VoIP Networks 2G-234A 101 Crawfords Corner Rd Holmdel, NJ 07733-3030 US
Robert Zopf Lucent Technologies INS Access VoIP Networks 2G-234A 101 Crawfords Corner Rd Holmdel、NJ 07733-3030 US
Phone: 1-732-949-1667 Fax: 1-732-949-7016 EMail: zopf@lucent.com
電話：1-732-949-1667ファックス：1-732-949-7016メール：zopf@lucent.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（C）The Internet Society（2002）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する派生物を、全体または一部を問わず、準備、コピー、公開、配布することができます。ただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能への資金提供は、現在Internet Societyから提供されています。