[要約] RFC 2343は、複数のMPEGビデオストリームを1つのRTPペイロードにバンドルするためのフォーマットを定義しています。このRFCの目的は、効率的なビデオストリーミングとネットワークリソースの最適化を実現することです。
Network Working Group M. Civanlar
Request for Comments: 2343 G. Cash
Category: Experimental B. Haskell
AT&T Labs-Research
May 1998
RTP Payload Format for Bundled MPEG
バンドルされたMPEGのRTPペイロード形式
Status of this Memo
本文書の状態
This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティの実験プロトコルを定義します。このメモは、いかなる種類のインターネット標準も指定していません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
Abstract
概要
This document describes a payload type for bundled, MPEG-2 encoded video and audio data that may be used with RTP, version 2. Bundling has some advantages for this payload type particularly when it is used for video-on-demand applications. This payload type may be used when its advantages are important enough to sacrifice the modularity of having separate audio and video streams.
このドキュメントでは、RTPバージョン2で使用できる、バンドルされたMPEG-2エンコードビデオおよびオーディオデータのペイロードタイプについて説明します。バンドルは、特にビデオオンデマンドアプリケーションに使用される場合、このペイロードタイプにいくつかの利点があります。このペイロードタイプは、その利点が、個別のオーディオストリームとビデオストリームを持つというモジュール性を犠牲にするほど重要である場合に使用できます。
This document describes a bundled packetization scheme for MPEG-2 encoded audio and video streams using the Real-time Transport Protocol (RTP), version 2 [1].
このドキュメントでは、Real-time Transport Protocol（RTP）、バージョン2 [1]を使用したMPEG-2エンコードのオーディオおよびビデオストリームのバンドルされたパケット化スキームについて説明します。
The MPEG-2 International standard consists of three layers: audio, video and systems [2]. The audio and the video layers define the syntax and semantics of the corresponding "elementary streams." The systems layer supports synchronization and interleaving of multiple compressed streams, buffer initialization and management, and time identification. RFC 2250 [3] describes packetization techniques to transport individual audio and video elementary streams as well as the transport stream, which is defined at the system layer, using the RTP.
MPEG-2 International規格は、オーディオ、ビデオ、システムの3つのレイヤーで構成されています[2]。オーディオレイヤーとビデオレイヤーは、対応する「エレメンタリーストリーム」の構文とセマンティクスを定義します。システム層は、複数の圧縮ストリームの同期とインターリーブ、バッファの初期化と管理、および時間の識別をサポートしています。 RFC 2250 [3]は、RTPを使用して、個々のオーディオおよびビデオのエレメンタリーストリームと、システムレイヤーで定義されているトランスポートストリームをトランスポートするためのパケット化技術について説明しています。
The bundled packetization scheme is needed because it has several advantages over other schemes for some important applications including video-on-demand (VOD) where, audio and video are always used together. Its advantages over independent packetization of audio and video are:
バンドルされたパケット化スキームは、オーディオとビデオが常に一緒に使用されるビデオオンデマンド（VOD）を含むいくつかの重要なアプリケーションの他のスキームに比べていくつかの利点があるため必要です。オーディオとビデオの独立したパケット化に対するその利点は次のとおりです。
1. Uses a single port per "program" (i.e. bundled A/V). This may increase the number of streams that can be served e.g., from a VOD server. Also, it eliminates the performance hit when two ports are used for the separate audio and video streams on the client side.
1. 「プログラム」ごとに1つのポートを使用します（つまり、バンドルされたA / V）。これにより、たとえばVODサーバーから提供できるストリームの数が増える可能性があります。また、2つのポートがクライアント側の個別のオーディオストリームとビデオストリームに使用されている場合のパフォーマンスへの影響を排除します。
2. Provides implicit synchronization of audio and video. This is particularly convenient when the A/V data is stored in an interleaved format at the server.
2. オーディオとビデオの暗黙的な同期を提供します。これは、A / Vデータがサーバーでインターリーブ形式で保存されている場合に特に便利です。
3. Reduces the header overhead. Since using large packets increases the effects of losses and delay, audio only packets need to be smaller increasing the overhead. An A/V bundled format can provide about 1% overall overhead reduction. Considering the high bitrates used for MPEG-2 encoded material, e.g. 4 Mbps, the number of bits saved, e.g. 40 Kbps, may provide noticeable audio or video quality improvement.
3. ヘッダーのオーバーヘッドを減らします。大きなパケットを使用すると、損失と遅延の影響が大きくなるため、オーディオのみのパケットを小さくしてオーバーヘッドを増やす必要があります。 A / Vバンドル形式では、全体のオーバーヘッドを約1％削減できます。 MPEG-2でエンコードされた素材に使用される高ビットレートを考慮します。 4 Mbps、保存されたビット数。 40 Kbpsは、オーディオまたはビデオの品質を著しく向上させる可能性があります。
4. May reduce overall receiver buffer size. Audio and video streams may experience different delays when transmitted separately. The receiver buffers need to be designed for the longest of these delays. For example, let's assume that using two buffers, each with a size B, is sufficient with probability P when each stream is transmitted individually. The probability that the same buffer size will be sufficient when both streams need to be received is P times the conditional probability of B being sufficient for the second stream given that it was sufficient for the first one. This conditional probability is, generally, less than one requiring use of a larger buffer size to achieve the same probability level.
4. 全体的なレシーバーバッファーサイズを減らす可能性があります。オーディオストリームとビデオストリームでは、別々に送信すると異なる遅延が発生する可能性があります。レシーバーバッファーは、これらの遅延の中で最も長くなるように設計する必要があります。たとえば、各ストリームが個別に送信される場合、サイズBの2つのバッファを使用すれば、確率Pで十分であると仮定します。両方のストリームを受信する必要がある場合に同じバッファーサイズで十分である確率は、Bの条件付き確率のP倍です。この条件付き確率は、通常、同じ確率レベルを達成するために大きなバッファーサイズを使用する必要がある確率よりも低くなります。
5. May help with the control of the overall bandwidth used by an A/V program.
5. A / Vプログラムで使用される全体的な帯域幅の制御に役立ちます。
And, the advantages over packetization of the transport layer streams are:
また、トランスポート層ストリームのパケット化に対する利点は次のとおりです。
1. Reduced overhead. It does not contain systems layer information which is redundant for the RTP (essentially they address similar issues).
1. オーバーヘッドの削減。 RTPにとって冗長なシステムレイヤー情報は含まれていません（基本的には、同様の問題に対処しています）。
2. Easier error recovery. Because of the structured packetization consistent with the application layer framing (ALF) principle, loss concealment and error recovery can be made simpler and more effective.
2. より簡単なエラー回復。アプリケーションレイヤーフレーミング（ALF）の原則に準拠した構造化パケット化により、損失の隠蔽とエラー回復をより簡単に、より効果的に行うことができます。
Video encapsulation follows rules similar to the ones described in [3] for encapsulation of MPEG elementary streams. Specifically,
ビデオのカプセル化は、MPEGエレメンタリーストリームのカプセル化に関して、[3]で説明されているものと同様のルールに従います。具体的には
1. The MPEG Video_Sequence_Header, when present, will always be at the beginning of an RTP payload.
1. MPEG Video_Sequence_Headerは、存在する場合、常にRTPペイロードの先頭にあります。
2. An MPEG GOP_header, when present, will always be at the beginning of the RTP payload, or will follow a Video_Sequence_Header.
2. MPEG GOP_headerが存在する場合、常にRTPペイロードの先頭にあるか、Video_Sequence_Headerの後に続きます。
3. An MPEG Picture_Header, when present, will always be at the beginning of a RTP payload, or will follow a GOP_header.
3. MPEG Picture_Headerは、存在する場合、常にRTPペイロードの先頭にあるか、GOP_headerの後に続きます。
In addition to these, it is required that:
これらに加えて、以下が必要です。
4. Each packet must contain an integral number of video slices.
4. 各パケットには、整数のビデオスライスが含まれている必要があります。
It is the application's responsibility to adjust the slice sizes and the number of slices put in each RTP packet so that lower level fragmentation does not occur. This approach simplifies the receivers while somewhat increasing the complexity of the transmitter's packetizer. Considering that a slice can be as small as a single macroblock, it is possible to prevent fragmentation for most of the cases. If a packet size exceeds the path maximum transmission unit (path-MTU) [4], this payload type depends on the lower protocol layers for fragmentation although, this may cause problems with packet classification for integrated services (e.g. with RSVP).
低レベルの断片化が発生しないように、各RTPパケットに入れられるスライスサイズとスライス数を調整するのはアプリケーションの責任です。このアプローチは、トランスミッタのパケタイザの複雑さを幾分増加させながらレシーバを簡素化します。スライスが単一のマクロブロックと同じくらい小さい場合があることを考えると、ほとんどの場合で断片化を防ぐことができます。パケットサイズがパス最大伝送ユニット（パスMTU）[4]を超える場合、このペイロードタイプはフラグメンテーションの下位プロトコルレイヤーに依存しますが、統合サービス（RSVPなど）のパケット分類で問題が発生する可能性があります。
The video data is followed by a sufficient number of integral audio frames to cover the duration of the video segment included in a packet. For example, if the first packet contains three 1/900 seconds long slices of video, and Layer I audio coding is used at a 44.1kHz sampling rate, only one audio frame covering 384/44100 seconds of audio need be included in this packet. Since the length of this audio frame (8.71 msec.) is longer than that of the video segment contained in this packet (3.33 msec), the next few packets may not contain any audio frames until the packet in which the covered video time extends outside the length of the previously transmitted audio frames. Alternatively, it is possible, in this proposal, to repeat the latest audio frame in "no-audio" packets for packet loss resilience. Again, it is the application's responsibility to adjust the bundled packet size according to the minimum MTU size to prevent fragmentation.
ビデオデータの後には、パケットに含まれるビデオセグメントの期間をカバーするのに十分な数の統合オーディオフレームが続きます。たとえば、最初のパケットに1/900秒の長さのビデオスライスが3つ含まれ、レイヤーIオーディオコーディングが44.1kHzのサンプリングレートで使用されている場合、384/44100秒のオーディオをカバーする1つのオーディオフレームのみをこのパケットに含める必要があります。このオーディオフレームの長さ（8.71ミリ秒）は、このパケットに含まれているビデオセグメントの長さ（3.33ミリ秒）よりも長いため、次の数個のパケットには、カバーされるビデオ時間が外に出るパケットまでオーディオフレームが含まれない場合があります。以前に送信された音声フレームの長さ。あるいは、この提案では、パケット損失の回復力を得るために、「オーディオなし」パケットで最新のオーディオフレームを繰り返すことが可能です。繰り返しになりますが、断片化を防ぐために、最小MTUサイズに従ってバンドルされたパケットサイズを調整するのはアプリケーションの責任です。
The following RTP header fields are used:
次のRTPヘッダーフィールドが使用されます。
Payload Type: A distinct payload type number, which may be dynamic, should be assigned to BMPEG.
ペイロードタイプ：動的である可能性がある個別のペイロードタイプ番号をBMPEGに割り当てる必要があります。
M Bit: Set for packets containing end of a picture.
Mビット：画像の終わりを含むパケットに設定します。
timestamp: 32-bit 90 kHz timestamp representing sampling time of the MPEG picture. May not be monotonically increasing if B pictures are present. Same for all packets belonging to the same picture. For packets that contain only a sequence, extension and/or GOP header, the timestamp is that of the subsequent picture.
timestamp：MPEG画像のサンプリング時間を表す32ビットの90 kHzタイムスタンプ。 Bピクチャが存在する場合、単調増加しない場合があります。同じ画像に属するすべてのパケットで同じです。シーケンス、拡張、GOPヘッダーのみを含むパケットの場合、タイムスタンプは後続の画像のタイムスタンプです。
2.2. BMPEG Specific Header:
2.2. BMPEG固有のヘッダー：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P |N|MBZ| Audio Length | | Audio Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MBZ
P: Picture type (2 bits). I (0), P (1), B (2).
P：画像タイプ（2ビット）。 I（0）、P（1）、B（2）。
N: Header data changed (1 bit). Set if any part of the video sequence, extension, GOP and picture header data is different than that of the previously sent headers. It gets reset when all the header data gets repeated (see Appendix 1).
N：ヘッダーデータが変更されました（1ビット）。ビデオシーケンス、拡張子、GOPおよび画像ヘッダーデータのいずれかの部分が以前に送信されたヘッダーのデータと異なる場合に設定します。すべてのヘッダーデータが繰り返されるとリセットされます（付録1を参照）。
MBZ: Must be zero. Reserved for future use.
MBZ：ゼロでなければなりません。将来の使用のために予約されています。
Audio Length: (10 bits) Length of the audio data in this packet in bytes. Start of the audio data is found by subtracting "Audio Length" from the total length of the received packet.
オーディオの長さ：（10ビット）このパケットのオーディオデータの長さ（バイト単位）。音声データの先頭は、受信したパケットの全長から「音声長」を引くことでわかります。
Audio Offset: (16 bits) The offset between the start of the audio frame and the RTP timestamp for this packet in number of audio samples (for multi-channel sources, a set of samples covering all channels is counted as one sample for this purpose.) Audio offset is a signed integer in two's complement form. It allows a ~ +/- 750 msec offset at 44.1 KHz audio sampling rate. For a very low video frame rate (e.g., a frame per second), this offset may not be sufficient and this payload format may not be usable.
オーディオオフセット：（16ビット）オーディオフレームの開始とこのパケットのRTPタイムスタンプの間のオフセット（オーディオサンプル数）（マルチチャネルソースの場合、すべてのチャネルをカバーするサンプルのセットは、この目的のために1つのサンプルとしてカウントされます） 。）オーディオオフセットは、2の補数形式の符号付き整数です。 44.1 KHzオーディオサンプリングレートで〜+/- 750ミリ秒のオフセットが可能です。非常に低いビデオフレームレート（フレーム/秒など）の場合、このオフセットは十分ではなく、このペイロード形式は使用できない場合があります。
If B frames are present, audio frames are not re-ordered along with video. Instead, they are packetized along with video frames in their transmission order (e.g., an audio segment packetized with a video segment corresponding to a P picture may belong to a B picture, which will be transmitted later and should be rendered at the same time with this audio segment.) Even though the video segments are reordered, the audio offset for a particular audio segment is still relative to the RTP timestamp in the packet containing that audio segment.
Bフレームが存在する場合、オーディオフレームはビデオと共に並べ替えられません。代わりに、それらは送信順にビデオフレームと一緒にパケット化されます（たとえば、Pピクチャに対応するビデオセグメントでパケット化されたオーディオセグメントは、後で送信され、同時にレンダリングされるBピクチャに属している場合があります。このオーディオセグメント。）ビデオセグメントが並べ替えられても、特定のオーディオセグメントのオーディオオフセットは、そのオーディオセグメントを含むパケットのRTPタイムスタンプに相対的です。
Since a special picture counter, such as the "temporal reference (TR)" field of [3], is not included in this payload format, lost GOP headers may not be detected. The only effect of this may be incorrect decoding of the B pictures immediately following the lost GOP header for some edited video material.
[3]の "temporal reference（TR）"フィールドなどの特別な画像カウンターはこのペイロード形式に含まれていないため、失われたGOPヘッダーは検出されない可能性があります。これの唯一の影響は、一部の編集されたビデオ素材の失われたGOPヘッダーの直後のBピクチャの正しくないデコードである可能性があります。
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 data compression used with this payload format is applied end-to-end, encryption may be performed after compression so there is no conflict between the two operations.
この仕様で定義されたペイロード形式を使用するRTPパケットは、RTP仕様[1]で説明されているセキュリティ上の考慮事項の対象となります。これは、メディアストリームの機密性が暗号化によって達成されることを意味します。このペイロード形式で使用されるデータ圧縮はエンドツーエンドで適用されるため、圧縮後に暗号化を実行して、2つの操作が競合しないようにすることができます。
This payload type does not exhibit any significant non-uniformity in the receiver side computational complexity for packet processing to cause a potential denial-of-service threat.
このペイロードタイプは、パケット処理がサービス拒否の脅威を引き起こす可能性があるため、受信側の計算の複雑さに大きな不均一性はありません。
A security review of this payload format found no additional considerations beyond those in the RTP specification.
このペイロード形式のセキュリティレビューでは、RTP仕様以外の考慮事項は見つかりませんでした。
Appendix 1. Error Recovery
付録1.エラー回復
Packet losses can be detected from a combination of the sequence number and the timestamp fields of the RTP fixed header. The extent of the loss can be determined from the timestamp, the slice number and the horizontal location of the first slice in the packet. The slice number and the horizontal location can be determined from the slice header and the first macroblock address increment, which are located at fixed bit positions.
パケット損失は、RTP固定ヘッダーのシーケンス番号とタイムスタンプフィールドの組み合わせから検出できます。損失の範囲は、タイムスタンプ、スライス番号、およびパケット内の最初のスライスの水平位置から判断できます。スライス番号と水平位置は、固定ビット位置にあるスライスヘッダーと最初のマクロブロックアドレス増分から決定できます。
If lost data consists of slices all from the same picture, new data following the loss may simply be given to the video decoder which will normally repeat missing pixels from a previous picture. The next audio frame must be played at the appropriate time determined by the timestamp and the audio offset contained in the received packet. Appropriate audio frames (e.g., representing background noise) may need to be fed to the audio decoder in place of the lost audio frames to keep the lip-synch and/or to conceal the effects of the losses.
失われたデータがすべて同じ画像からのスライスで構成されている場合、失われた後の新しいデータは、通常、前の画像から欠落しているピクセルを繰り返すビデオデコーダーに単に与えられます。次のオーディオフレームは、タイムスタンプと受信パケットに含まれるオーディオオフセットによって決定される適切な時間に再生される必要があります。リップシンクを維持するため、および/または損失の影響を隠すために、失われたオーディオフレームの代わりに適切なオーディオフレーム（たとえば、バックグラウンドノイズを表す）をオーディオデコーダに供給する必要がある場合があります。
If the received new data after a loss is from the next picture (i.e. no complete picture loss) and the N bit is not set, previously received headers for the particular picture type (determined from the P bits) can be given to the video decoder followed by the new data. If N is set, data deletion until a new picture start code is advisable unless headers are made available to the receiver through some other channel.
損失後に受信した新しいデータが次の画像からのものであり（つまり、完全な画像損失がない場合）、Nビットが設定されていない場合、以前に受信した特定の画像タイプのヘッダー（Pビットから決定）をビデオデコーダーに与えることができます。その後に新しいデータが続きます。 Nが設定されている場合、ヘッダーが他のチャネルを介して受信者に提供されない限り、新しい画像開始コードまでのデータ削除が推奨されます。
If data for more than one picture is lost and headers are not available, unless N is zero and at least one packet has been received for every intervening picture of the same type and that the N bit was 0 for each of those pictures, resynchronization to a new video sequence header is advisable.
複数の画像のデータが失われ、ヘッダーが利用できない場合は、Nがゼロで、同じタイプの介在するすべての画像に対して少なくとも1つのパケットが受信され、これらの画像のそれぞれについてNビットが0であった場合、再同期して新しいビデオシーケンスヘッダーをお勧めします。
In all cases of heavy packet losses, if the correct headers for the missing Pictures are available, they can be given to the video decoder and the received data can be used irrespective of the N bit value or the number of lost pictures.
大量のパケット損失のすべてのケースで、欠落している画像の正しいヘッダーが利用可能な場合、それらをビデオデコーダーに与え、Nビット値または失われた画像の数に関係なく受信データを使用できます。
Appendix 2. Resynchronization
付録2.再同期
As described in [3], use of frequent video sequence headers makes it possible to join in a program at arbitrary times. Also, it reduces the resynchronization time after severe losses.
[3]で説明されているように、ビデオシーケンスヘッダーを頻繁に使用すると、任意の時間にプログラムに参加することができます。また、重大な損失後の再同期時間も短縮されます。
References
参考文献
[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] ISO/IEC International Standard 13818; "Generic coding of moving pictures and associated audio information," November 1994.
[2] ISO / IEC国際規格13818; 「動画および関連する音声情報の一般的なコーディング」、1994年11月。
[3] Hoffman, D., Fernando, G., Goyal, V., and M. Civanlar, "RTP Payload Format for MPEG1/MPEG2 Video", RFC 2250, January 1998.
[3] Hoffman、D.、Fernando、G.、Goyal、V。、およびM. Civanlar、「RTP Payload Format for MPEG1 / MPEG2 Video」、RFC 2250、1998年1月。
[4] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.
[4] Mogul、J。、およびS. Deering、「Path MTU Discovery」、RFC 1191、1990年11月。
Authors' Addresses
著者のアドレス
M. Reha Civanlar AT&T Labs-Research 100 Schultz Drive Red Bank, NJ 07701 USA
M. Reha Civanlar AT＆T Labs-Research 100 Schultz Drive Red Bank、NJ 07701 USA
EMail: civanlar@research.att.com
Glenn L. Cash AT&T Labs-Research 100 Schultz Drive Red Bank, NJ 07701 USA
Glenn L. Cash AT＆T Labs-Research 100 Schultz Drive Red Bank、NJ 07701 USA
EMail: glenn@research.att.com
Barry G. Haskell AT&T Labs-Research 100 Schultz Drive Red Bank, NJ 07701 USA
Barry G. Haskell AT＆T Labs-Research 100 Schultz Drive Red Bank、NJ 07701 USA
EMail: bgh@research.att.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。