RFC2448 日本語訳

2448 AT&T's Error Resilient Video Transmission Technique. M. Civanlar,G. Cash, B. Haskell. November 1998. (Format: TXT=14655 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                        M. Civanlar
Request for Comments: 2448                                       G. Cash
Category: Informational                                       B. Haskell
                                                      AT&T Labs-Research
                                                           November 1998

Civanlarがコメントのために要求するワーキンググループM.をネットワークでつないでください: 2448年のG.現金カテゴリ: 情報のB.ハスケルAT&T研究室研究1998年11月

          AT&T's Error Resilient Video Transmission Technique

AT&Tの誤りの弾力があるビデオ透過法

Status of this Memo

このMemoの状態

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Copyright(C)インターネット協会(1998)。 All rights reserved。

Abstract

要約

   This document describes a set of techniques for packet loss resilient
   transmission of compressed video bitstreams based on reliable
   delivery of their vital information-carrying segments. The described
   techniques can be used over packet networks without packet
   prioritization. These techniques are related to AT&T/Lucent patents
   [1, 2].

このドキュメントはそれらの重大な情報を運ぶセグメントの信頼できる配信に基づく圧縮されたビデオbitstreamsのパケット損失の立ち直りの早いトランスミッションのための1セットのテクニックについて説明します。 パケット網の上でパケット優先順位づけなしで説明されたテクニックを使用できます。 これらのテクニックはAT&T/透明な特許[1、2]に関連します。

1. Introduction

1. 序論

   It is well known that every bit in a compressed video bitstream is
   not equal. Some bits belong to segments defining vital information
   such as picture types, quantization values, parameter ranges, average
   intensity values for image blocks, etc. When transporting compressed
   video bitstreams over packet networks, packet losses from such
   segments cause a much longer lasting and severe degradation on the
   output of a decoder than that caused by packet losses from other
   segments. We will call the vital information-carrying segments "High
   Priority (HP)" segments. The rest of the bitstream consists of "Low
   Priority (LP)" segments. Clearly, the video outputs resulting from
   transport techniques that protect the HP segments against packet
   losses are more resilient to packet losses in general.

ちょうど圧縮されたビデオでは、bitstreamが等しくないのは、よく知られています。 数ビットは絵がタイプする極めて重要な情報を定義するセグメント、量子化値、パラメタ範囲、何画像ブロックも平均した強度値などに属します。 デコーダの出力のときにパケット網の上で圧縮されたビデオbitstreamsを輸送するとき、そのようなセグメントからのパケット損失は他のセグメントからのパケット損失で引き起こされたそれよりはるかに長い持続と厳しい退行を引き起こします。 私たちは、重大な情報を運ぶセグメント「高い優先度(hp)」をセグメントと呼ぶつもりです。 bitstreamの残りは「低い優先度(LP)」セグメントから成ります。 明確に、パケット損失に対してHPセグメントを保護する輸送のテクニックから生じるビデオ出力は一般に、パケット損失に立ち直りが早いです。

   Protection of the HP segments can be accomplished in many ways. These
   include:

様々な意味でHPセグメントの保護を実行できます。 これらは:

      - redundant transmission of the HP segments as described
        in [3] for MPEG RTP payloads

- MPEG RTPペイロードのための[3]の説明されるとしてのHPセグメントの余分な送信

Civanlar, et. al.            Informational                      [Page 1]

RFC 2448                AT&T's Error Resilient             November 1998

et Civanlar、アル。 RFC大西洋標準時2448とTの1998年11月に立ち直りの早い情報[1ページ]の誤り

      - using forward error correction (FEC) techniques
      - transmitting HP segments over reserved channels or using
        differentiated services.

- 前進型誤信号訂正(FEC)のテクニックを使用します--控え目なチャンネルの上のHPセグメントを伝えるか、使用がサービスを微分しました。

   Both redundant transmission and FEC techniques increase the bandwidth
   needed to transmit the compressed video bitstream. FEC techniques
   increase the effectiveness of this additional bandwidth for packet
   loss protection at the expense of increased processing at the
   receiver and the transmitter ends and increased overall delay. Using
   channel reservations or differentiated services based approaches may
   be the best solutions for protecting the HP segments but, they
   require network infrastructure changes.

余分なトランスミッションとFECのテクニックの両方が圧縮されたビデオbitstreamを伝えるのに必要である帯域幅を増加させます。 FECのテクニックはパケット損失保護のために受信機での増加する処理、送信機エンド、および増加する総合的な遅れを犠牲にしてこの追加帯域幅の有効性を増加させます。 チャンネルの予約か微分されたサービスを利用して、ベースのアプローチはHPセグメントを保護する最も良い解決策であるかもしれませんが、彼らはネットワークインフラ変化を必要とします。

   This document outlines another set of HP segment protection
   techniques based on AT&T/Lucent patents [1, 2] that can be used for
   reliable video transmission over packet networks without a built-in
   prioritization mechanism. These techniques use reliable transport
   protocols and "out-of-band" delivery approaches. In this context, the
   term "out-of-band" is used to imply information transmission means
   other than those used for transmitting the main video stream.  The
   details of these techniques are discussed in the following sections.
   An implementation of these, as applied to MPEG-2 video transmission
   over IP networks, is described in [4].

このドキュメントはパケット網の上の信頼できる映像の送波に内蔵の優先順位づけメカニズムなしで使用できるAT&T/透明な特許[1、2]に基づくもう1セットのHPセグメント保護のテクニックについて概説します。 これらのテクニックは信頼できるトランスポート・プロトコルを使用します、そして、配送は「バンドの外に」アプローチします。 このような関係においては、「バンドの外」という用語は、主なビデオストリームを伝えるのに使用されるものを除いて、トランスミッションが意味する情報を含意するのに使用されます。 以下のセクションでこれらのテクニックの詳細について議論します。 IPネットワークの上のMPEG-2映像の送波に適用されるこれらの実現は[4]で説明されます。

   The IESG/IETF take no position regarding the validity or scope of any
   intellectual property right or other rights that might be claimed to
   pertain to the implementation or use of the technology, or the extent
   to which any license under such rights might or might not be
   available.  See the IETF IPR web page at http://www.ietf.org/ipr.html
   for any additional information that has been forwarded to the IETF.

IESG/IETFは正当性、実現に関係すると主張されるどんな知的所有権や他の権利の範囲か技術の使用、またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 http://www.ietf.org/ipr.html でIETFに転送されたあらゆる追加情報に関してIETF IPRウェブページを見てください。

2. Identification of the HP segments

2. HPセグメントの識別

   The classification of a part of a video bitstream as an HP segment
   depends on two factors.  The first one is the encoding algorithm used
   in compressing the video data. It is impossible to segment a
   compressed video bitstream without knowing the syntax and the
   semantics of the encoding algorithm. The second factor is the
   determination of a compromise between the HP segment size and the
   corresponding loss resilience. As the segment size increases, so does
   the loss resilience.  On the other hand, it may not be feasible to
   deliver large HP segments reliably.

HPセグメントとしてのビデオbitstreamの一部の分類は2つの要素に依存します。 最初の1つはビデオ・データを圧縮する際に使用されるコード化アルゴリズムです。 bitstreamにコード化アルゴリズムの構文と意味論を知らないで圧縮されたビデオを区分するのは不可能です。 2番目の要素はHPセグメントサイズと対応する損失弾力の間の妥協の決断です。 セグメントサイズが増加するのに従って、損失弾力もそうします。 他方では、大きいHPセグメントを確かに伝達するのは可能でないかもしれません。

   As an example, the "data partitioning" method of the MPEG-2 standard
   [5] defines the syntax and semantics for one particular way of
   partitioning an MPEG-2 encoded video bitstream into HP and LP
   segments.  In data partitioning, the smallest useful HP segment can
   be selected to contain only the header information, which is usually

例と、MPEG-2規格[5]の「データ仕切り」の方法は構文を定義します、そして、MPEG-2を仕切る1つの特定の方法のための意味論はHPとLPセグメントにビデオbitstreamをコード化しました。 データ仕切りでは、最も小さい役に立つHPセグメントがヘッダー情報だけを含むのを選択できます。(通常、ヘッダー情報はそうです)。

Civanlar, et. al.            Informational                      [Page 2]

RFC 2448                AT&T's Error Resilient             November 1998

et Civanlar、アル。 RFC大西洋標準時2448とTの1998年11月に立ち直りの早い情報[2ページ]の誤り

   less than two percent of the video data. HP segments defined this way
   contain vital information including picture type, quantization
   factor, motion vector ranges, etc. without which the rest of the
   bitstream is not decodable.  As an alternative, the DC coefficients
   (the average values) for each picture macroblock may be included in
   the HP segment increasing its size to about 40% of the bitstream.
   This way HP segments can be made to carry somewhat usable video
   information also; however, their reliable transmission may become a
   demanding task.

ビデオ・データの2パーセント未満。 この道と定義されたHPセグメントは絵のタイプ、量子化要素、運動ベクトル範囲などをbitstreamの残りが解読可能でない含む極めて重要な情報を含んでいます。 代替手段として、それぞれの絵のmacroblockのためのDC係数(平均値)はサイズをbitstreamのおよそ40%まで増加させるHPセグメントで含まれるかもしれません。 HPセグメントにいくらか使用可能なビデオ情報も運ばせることができるこの方法。 しかしながら、彼らの信頼できるトランスミッションは過酷なタスクになるかもしれません。

   Since it is not possible to formulate a general technique that can be
   used for identifying the HP segments in any encoded video bitstream,
   we will assume that such segments are identified some way prior to
   the transmission. For example, some encoders can generate HP and LP
   segments separately, a stored bitstream can be in the partitioned
   format, etc. Also, consistent with most of the popular coding
   techniques, we assume that the HP segments (HP1, HP2, ...) are
   dispersed on the entire bitstream over time as shown in Fig. 1.

どんなコード化されたビデオbitstreamでもHPセグメントを特定するのに使用できる一般的なテクニックを定式化するのが可能でないので、私たちは、そのようなセグメントがトランスミッションの何らかの道前に特定されると思うつもりです。 例えば、いくつかのエンコーダが別々にHPとLPセグメントを発生させることができて、仕切られた形式などには格納されたbitstreamがあることができます。 また、ポピュラーなコーディング技法の大部分と一致していて、私たちはそれを仮定します。HPセグメント(HP1、HP2)は時間がたつにつれて、図1に示されるように全体のbitstreamで分散されます。

   +---+----------------+---+----------------------+---+-----
   |HP1|     LP1        |HP2|        LP2           |HP3| ...
   +---+----------------+---+----------------------+---+-----
                                Figure 1
       HP segments dispersed on an encoded video bitstream over time

+---+----------------+---+----------------------+---+----- |HP1| LP1|HP2| LP2|HP3| ... +---+----------------+---+----------------------+---+----- 図1 時間がたつにつれてコード化されたビデオbitstreamで分散されたHPセグメント

3. Transmission of HP data using a reliable transport protocol [1]

3. 信頼できるトランスポート・プロトコルを使用するHPデータの伝達[1]

   In this approach, one or more of the HP segments are transmitted
   using a reliable transport protocol prior to starting the
   transmission of the LP segments. For point-to-point applications,
   TCP, for multipoint applications, an appropriate reliable multicast
   protocol [6] may be used for transporting the HP segments. The number
   of HP segments to be sent before starting the transmission of the LP
   segments depends on the application's tolerance to the start-up
   delay.  Depending on the HP segment size and the path-MTU [7], one or
   more HP segments can be put in each packet carrying the HP data.

このアプローチでは、HPセグメントの1つか以上が、LPセグメントの送信を始める前に信頼できるトランスポート・プロトコルを使用することで伝えられます。 二地点間アプリケーション、TCPに関しては、多点アプリケーションにおいて、適切な信頼できるマルチキャストプロトコル[6]は、HPセグメントを輸送するのに使用されるかもしれません。 LPセグメントの送信を始める前に送られるHPセグメントの数は始動遅れへのアプリケーションの寛容に依存します。 HPセグメントサイズと経路-MTU[7]によって、HPデータを運ぶ各パケットに1HP以上のセグメントを入れることができます。

   HP segments can be packetized using RTP with the following
   definitions for the header fields:

ヘッダーフィールドに以下の定義があるRTPを使用することでHPセグメントをpacketizedされることができます:

      Payload Type: A distinct payload type number, which may be
      dynamic, should be assigned to HP segments of each video payload.

有効搭載量タイプ: 異なったペイロード形式数(ダイナミックであるかもしれない)はそれぞれのビデオペイロードのHPセグメントに割り当てられるべきです。

      M Bit: Set for packets containing HP data for key pictures.

Mは噛み付きました: 主要な絵のためのHPデータを含むパケットには、セットしてください。

      timestamp: Uses the same format as that of the video payload.
      Shows the sampling time for the video data following the first HP
      segment in the packet.

タイムスタンプ: ビデオペイロードのものと同じ形式を使用します。 パケットで最初のHPセグメントに続くビデオ・データのための標本抽出時間を示しています。

Civanlar, et. al.            Informational                      [Page 3]

RFC 2448                AT&T's Error Resilient             November 1998

et Civanlar、アル。 RFC大西洋標準時2448とTの1998年11月に立ち直りの早い情報[3ページ]の誤り

   The SSRC field may be defined following the rules developed for the
   transmission of layered media streams in [8]. That is:

[8]の層にされたメディアの流れのトランスミッションのために開発された規則に従って、SSRC分野は定義されるかもしれません。 それは以下の通りです。

      - A single SSRC space is used for the HP segment packets and the
      main video stream. Only the latter is used for SSRC allocation and
      conflict resolution. When a source discovers that it has collided,
      it transmits an RTCP BYE message on only the main video stream.

- ただ一つのSSRCスペースはHPセグメントパケットと主なビデオストリームに使用されます。 後者だけがSSRC配分と紛争解決に使用されます。 情報筋が、それが衝突したと発見するとき、それは主なビデオストリームだけに関するRTCP BYEメッセージを送ります。

      - A participant sends sender identification (SDES) on only the
      main video stream.

- 関係者は主なビデオストリームだけのときに識別(SDES)を送付者に送ります。

   Most HP segments are self-identifying and can be packed without any
   additional headers. For others, techniques used for packetizing
   generic payload types may be used or special payload types may be
   defined.

ほとんどのHPセグメントは、自己特定であり、少しも追加ヘッダーなしで梱包できます。 他のもののために、一般的なペイロードタイプをpacketizingするのに使用されるテクニックが使用されるかもしれませんか、または特別なペイロードタイプは定義されるかもしれません。

   It is possible to send the HP data along with the LP data (i.e., the
   original, unpartitioned bitstream) in addition to sending the HP
   segments separately. This way, the separately transmitted HP segments
   are needed only when packet losses occur.

別々にHPセグメントを送ることに加えてLPデータ(すなわち、オリジナル、unpartitioned bitstream)に伴うHPデータを送るのは可能です。 パケット損失が起こるときだけ、このように、別々に伝えられたHPセグメントが必要です。

4. Out-of-band transmission of the HP information [2]

4. HP情報のバンドで出ている伝達[2]

   In cases where a certain sequence of HP segments is used periodically
   for the entire duration of the video bitstream, this sequence may be
   transmitted once before the start of video transmission using a
   reliable transport protocol. The receiver can save this information
   and use it to recover lost HP segments during the main video
   transmission.

HPセグメントのある系列がビデオbitstreamの全体の持続時間に定期的に使用される場合では、この系列は、映像の送波の始まりの前に信頼できるトランスポート・プロトコルを使用することで一度伝えられるかもしれません。 受信機は、主な映像の送波の間、無くなっているHPセグメントを回復するのにこの情報を保存して、それを使用できます。

   In this approach, the timestamps are not meaningful for the HP data
   and they may not be included in the transmitted HP segment sequence.
   In most cases, the synchronization between the stored HP segments and
   the LP data stream can be accomplished using the key-frames because
   the HP data sequence usually cover the video segment between two
   key-frames (e.g. a group-of-pictures (GOP) in MPEG). If the sequence
   of HP segments covers a video sequence with more than one key-frame,
   some indicator, e.g. if available the M-bit may be used to indicate a
   packet which carries the beginning of LP data that follows the first
   stored HP segment.

このアプローチでは、HPデータには、タイムスタンプは重要ではありません、そして、それらは伝えられたHPセグメント系列に含まれないかもしれません。 多くの場合、HPデータ系列が通常2個の主要なフレーム(例えば、MPEGにおける、絵のグループ(共和党))の間のビデオセグメントをカバーしているので主要なフレームを使用することで格納されたHPセグメントとLPデータ・ストリームの間の同期を実行できます。 HPセグメントの系列が1個の主要なフレーム、何らかのインディケータ以上でビデオ系列をカバーしているなら、例えば、利用可能であるなら、M-ビットは、最初の格納されたHPセグメントに続くLPデータの始まりを運ぶパケットを示すのに使用されるかもしれません。

5. Security Considerations

5. セキュリティ問題

   RTP packets transmitted according to the techniques outlined in this
   document are subject to the security considerations discussed in the
   RTP specification [9]. This implies that confidentiality of the media
   streams is achieved by encryption. Because the data compression used
   is applied end-to-end, encryption may be performed after compression

本書では概説されたテクニックに従って伝えられたRTPパケットはRTP仕様[9]で議論したセキュリティ問題を受けることがあります。 これは、メディアの流れの秘密性が暗号化で達成されるのを含意します。 使用されるデータ圧縮が適用された終わりから終わりであるので、暗号化は圧縮の後に実行されるかもしれません。

Civanlar, et. al.            Informational                      [Page 4]

RFC 2448                AT&T's Error Resilient             November 1998

et Civanlar、アル。 RFC大西洋標準時2448とTの1998年11月に立ち直りの早い情報[4ページ]の誤り

   so there is no conflict between the two operations. For certain
   coding techniques and applications, encrypting only the HP segments
   may provide sufficent confidentiality.

それで、2つの操作の間には、闘争が全くありません。 あるコーディング技法とアプリケーションのために、HPだけをコード化して、セグメントはsufficent秘密性を提供するかもしれません。

   The described techniques do not introduce any significant additional
   non-uniformity in the receiver side computational complexity for
   packet processing to cause a potential denial-of-service threat.

パケット処理が潜在的サービスの否定の脅威を引き起こすように、説明されたテクニックは受信機サイド計算量における少しの重要な追加非の一様性も導入しません。

References

参照

   [1] Glenn L. Cash, Mehmet R. Civanlar, "Method Of And Apparatus For
       The Transmission Of High And Low Priority Segments Of A Video
       Bitstream Over Packet Networks," United States Patent Number:
       5,481,312, Jan. 2, 1996.

[1] グレンL.現金、メーメトR.Civanlar、米国特許は「パケット網の上のビデオBitstreamの上下の優先権セグメントの送信のための方法と装置」に付番します: 548万1312 1996年1月2日。

   [2] Glenn L. Cash, Mehmet R. Civanlar, "Video Bitstream Regeneration
       Using Previously Agreed To High Priority Segments," United States
       Patent Number: 5,510,844, April 23, 1996.

[2] グレンL.現金、メーメトR.Civanlar、「ビデオBitstream再生使用は以前に高い優先権セグメントに同意しました」、合衆国特許番号: 551万844 1996年4月23日。

   [3] Hoffman, D., Fernando, G., Goyal, V. and M. Civanlar, "RTP
       Payload Format for MPEG1/MPEG2 Video", RFC 2250, April 1997.

[3] ホフマンとD.とフェルナンドとG.とGoyalとV.とM.Civanlar、「MPEG1/MPEG2ビデオのためのRTP有効搭載量形式」、RFC2250、1997年4月。

   [4] M. R. Civanlar, G. L. Cash, "A practical system for MPEG-2 based
       video-on-demand over ATM packet networks and the WWW," Signal
       Processing: Image Communication, no. 8, pp. 221-227, Elsevier,
       1996.

[4] M.R.Civanlar、G.L.Cash、「MPEG-2の実用的なシステムはATMパケット網の上のビデオ・オン・デマンドとWWWを基礎づけました」、Signal Processing: イメージCommunication、No.8、ページ 221-227、Elsevier、1996。

   [5] ISO/IEC International Standard 13818; "Generic coding of moving
       pictures and associated audio information," November 1994.

[5] ISO/IEC国際規格13818。 1994年11月の「映画と関連オーディオ情報の一般的なコード化」。

   [6] Overview of Reliable Multicast Protocols Web Page, URL
       http://gaia.cs.umass.edu/sigcomm_mcast/talk1.html.

[6] 信頼できるマルチキャストプロトコルウェブページ、URL http://gaia.cs.umass.edu/sigcomm_mcast/talk1.html の概観。

   [7] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191,
       November 1990.

[7] ムガール人とJ.とS.デアリング、「経路MTU発見」、RFC1191、1990年11月。

   [8] M. F. Speer, S. McCanne, "RTP Usage with Layered Multimedia
       Streams", Work in Progress.

[8] M.F.シュペーア、「層にされたマルチメディアの流れがあるRTP用法」というS.McCanneは進行中で働いています。

   [9] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP:
       A Transport Protocol for Real-Time Applications", RFC 1889,
       January 1996.

[9]Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、RFC1889、1996年1月。

Civanlar, et. al.            Informational                      [Page 5]

RFC 2448                AT&T's Error Resilient             November 1998

et Civanlar、アル。 RFC大西洋標準時2448とTの1998年11月に立ち直りの早い情報[5ページ]の誤り

Authors' Addresses

作者のアドレス

   M. Reha Civanlar
   AT&T Labs-Research
   100 Schultz Drive
   Red Bank, NJ 07701
   USA

M.の研究室研究の100のシュルツのドライブの赤いReha Civanlar AT&T銀行、ニュージャージー07701米国

   EMail: civanlar@research.att.com

メール: civanlar@research.att.com

   Glenn L. Cash
   AT&T Labs-Research
   100 Schultz Drive
   Red Bank, NJ 07701
   USA

グレンL.現金AT&T研究室研究100のシュルツのドライブの赤い銀行、ニュージャージー07701米国

   EMail: glenn@research.att.com

メール: glenn@research.att.com

   Barry G. Haskell
   AT&T Labs-Research
   100 Schultz Drive
   Red Bank, NJ 07701
   USA

バリーG.ハスケルAT&T研究室研究100のシュルツのドライブの赤い銀行、ニュージャージー07701米国

   EMail: bgh@research.att.com

メール: bgh@research.att.com

Civanlar, et. al.            Informational                      [Page 6]

RFC 2448                AT&T's Error Resilient             November 1998

et Civanlar、アル。 RFC大西洋標準時2448とTの1998年11月に立ち直りの早い情報[6ページ]の誤り

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Copyright(C)インターネット協会(1998)。 All rights reserved。

   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.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   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.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Civanlar, et. al.            Informational                      [Page 7]

et Civanlar、アル。 情報[7ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

isNaN

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る