RFC3081 日本語訳

Network Working Group                                            M. Rose
Request for Comments: 3081                        Invisible Worlds, Inc.
Category: Standards Track                                     March 2001

コメントを求めるワーキンググループM.バラ要求をネットワークでつないでください: 3081年の目に見えない世界Inc.カテゴリ: 2001年の標準化過程行進

                     Mapping the BEEP Core onto TCP

TCPへのビープ音コアを写像します。

Status of this Memo

この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.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

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

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

Abstract

要約

   This memo describes how a BEEP (Blocks Extensible Exchange Protocol)
   session is mapped onto a single TCP (Transmission Control Protocol)
   connection.

このメモはBEEP(Extensible Exchangeプロトコルを妨げる)セッションがどう写像されるかを独身のTCP(通信制御プロトコル)接続に説明します。

Table of Contents

目次

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . . 1
   2.    Session Management . . . . . . . . . . . . . . . . . . . . . 2
   3.    Message Exchange . . . . . . . . . . . . . . . . . . . . . . 2
   3.1   Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.1.1 Channel Creation . . . . . . . . . . . . . . . . . . . . . . 3
   3.1.2 Sending Messages . . . . . . . . . . . . . . . . . . . . . . 3
   3.1.3 Processing SEQ Frames  . . . . . . . . . . . . . . . . . . . 4
   3.1.4 Use of Flow Control  . . . . . . . . . . . . . . . . . . . . 4
   4.    Security Considerations  . . . . . . . . . . . . . . . . . . 6
         References . . . . . . . . . . . . . . . . . . . . . . . . . 6
         Author's Address . . . . . . . . . . . . . . . . . . . . . . 6
   A.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
         Full Copyright Statement . . . . . . . . . . . . . . . . . . 8

1. 序論. . . . . . . . . . . . . . . . . . . . . . . . 1 2。 セッション管理. . . . . . . . . . . . . . . . . . . . . 2 3。 交換処理. . . . . . . . . . . . . . . . . . . . . . 2 3.1フロー制御. . . . . . . . . . . . . . . . . . . . . . . . 3 3.1.1は.4が使用するフロー制御. . . . . . . . . . . . . . . . . . . . 4 4の創造. . . . . . . . . . . . . . . . . . . . . . 3 3.1.2の送付メッセージ. . . . . . . . . . . . . . . . . . . . . . 3 3.1.3個の処理SEQフレーム. . . . . . . . . . . . . . . . . . . 4 3.1にチャネルを開設します。 セキュリティ問題. . . . . . . . . . . . . . . . . . 6参照. . . . . . . . . . . . . . . . . . . . . . . . . 6作者の.6のアドレスA.承認. . . . . . . . . . . . . . . . . . . . . . 7の完全な著作権宣言文. . . . . . . . . . . . . . . . . . 8

1. Introduction

1. 序論

   This memo describes how a BEEP [1] session is mapped onto a single
   TCP [2] connection.  Refer to Section 2.5 of [1] for an explanation
   of the mapping requirements.

このメモはBEEP[1]セッションがどう写像されるかを単独のTCP[2]接続に説明します。 マッピング要件に関する説明のための[1]のセクション2.5を参照してください。

Rose                        Standards Track                     [Page 1]

RFC 3081             Mapping the BEEP Core onto TCP           March 2001

2001年3月にTCPへのビープ音コアを写像するバラ標準化過程[1ページ]RFC3081

2. Session Management

2. セッション管理

   The mapping of BEEP session management onto the TCP service is
   straight-forward.

TCPサービスへのBEEPセッション管理のマッピングは簡単です。

   A BEEP session is established when a TCP connection is established
   between two BEEP peers:

TCP接続が2人のBEEP同輩の間で確立されるとき、BEEPセッションは確立しています:

   o  the BEEP peer that issues a passive TCP OPEN call is termed the
      listener; and,

o 受け身のTCP OPEN呼び出しを発行するBEEP同輩はリスナーと呼ばれます。 そして

   o  the BEEP peer that issues an active TCP OPEN call is termed the
      initiator.

o 活発なTCP OPEN呼び出しを発行するBEEP同輩は創始者と呼ばれます。

   A simultaneous TCP OPEN would result in both BEEP peers believing
   they are the initiator and neither peer will be able to start any
   channels.  Because of this, services based on BEEP must be designed
   so that simultaneous TCP OPENs cannot occur.

同時のTCP OPENは彼らが創始者であり、どちらの同輩もどんなチャンネルも始動できないと信じている両方のBEEP同輩をもたらすでしょう。 これのために、同時のTCP OPENsが起こることができないように、BEEPに基づくサービスを設計しなければなりません。

   If both peers agree to release a BEEP session (c.f., [1]'s Section
   2.4), the peer sending the "ok" reply, immediately issues the TCP
   CLOSE call.  Upon receiving the reply, the other peer immediately
   issues the TCP CLOSE call.

両方の同輩がBEEPセッション(c.f.、[1]によるセクション2.4です)(「間違いありません、な」回答を送る同輩)がすぐに発行するリリースに同意するなら、TCP CLOSEは呼びます。 回答を受け取ると、もう片方の同輩はすぐに、TCP CLOSE呼び出しを発行します。

   A BEEP session is terminated when either peer issues the TCP ABORT
   call, and the TCP connection is subsequently aborted.

どちらの同輩もTCP ABORT呼び出しを発行するとき、BEEPセッションは終えられます、そして、TCP接続は次に、中止されます。

3. Message Exchange

3. 交換処理

   The mapping of BEEP exchanges onto the TCP service is less straight-
   forward.

TCPサービスへのBEEP交換のマッピングは前方でそれほどまっすぐではありません。

   Messages are reliably sent and received using TCP's SEND and RECEIVE
   calls.  (This also provides ordered delivery of messages on the same
   channel.)

TCPのSENDを使用することでメッセージを確かに送って、受け取ります、そして、RECEIVEは呼びます。 (また、これは同じチャンネルにおけるメッセージの命令された配送を提供します。)

   Although TCP imposes flow control on a per-connection basis, if
   multiple channels are simultaneously in use on a BEEP session, BEEP
   must provide a mechanism to avoid starvation and deadlock.  To
   achieve this, BEEP re-introduces a mechanism used by the TCP:
   window-based flow control -- each channel has a sliding window that
   indicates the number of payload octets that a peer may transmit
   before receiving further permission.

TCPは1接続あたり1つの基礎にフロー制御を課しますが、複数のチャンネルがBEEPセッションのときに同時に使用中であるなら、BEEPは、飢餓を避けて、行き詰まるためにメカニズムを提供しなければなりません。 これを達成するために、BEEPはTCPによって使用されたメカニズムを再紹介します: 窓のベースのフロー制御--各チャンネルはさらなる許可を受ける前に同輩が伝えるかもしれないペイロード八重奏の数を示す引窓を持っています。

Rose                        Standards Track                     [Page 2]

RFC 3081             Mapping the BEEP Core onto TCP           March 2001

2001年3月にTCPへのビープ音コアを写像するバラ標準化過程[2ページ]RFC3081

3.1 Flow Control

3.1フロー制御

   Recall from Section 2.2.1.2 of [1] that every payload octet sent in
   each direction on a channel has an associated sequence number.
   Numbering of payload octets within a data frame is such that the
   first payload octet is the lowest numbered, and the following payload
   octets are numbered consecutively.

セクション2.2.1から、あらゆるペイロード八重奏が、チャンネルに関する各指示が関連一連番号に持っているのを送った[1]について.2を思い出してください。 最初のペイロード八重奏はデータフレームの中のペイロード八重奏の付番がそのようなものであるので、番号付で最も低いです、そして、以下のペイロード八重奏は連続して付番されます。

   The actual sequence number space is finite, though very large,
   ranging from 0..4294967295 (2**32 - 1).  Since the space is finite,
   all arithmetic dealing with sequence numbers is performed modulo
   2**32.  This unsigned arithmetic preserves the relationship of
   sequence numbers as they cycle from 2**32 - 1 to 0 again.  Consult
   Sections 2 through 5 of [3] for a discussion of the arithmetic
   properties of sequence numbers.

0から変化して、実際の一連番号スペースは、有限であって、もっとも、非常に大きいです。4294967295 (2**32 - 1). スペースが有限であるので、一連番号に対処するすべての演算が実行された法2**32です。 再び2**1〜32--0から循環するとき、この無記名の演算は一連番号の関係を保存します。 一連番号の算数の特性の議論のための[3]のセクション2〜5に相談してください。

3.1.1 Channel Creation

3.1.1 チャンネル創造

   When a channel is created, the sequence number associated with the
   first payload octet of the first data frame is 0, and the initial
   window size for that channel is 4096 octets.  After channel creation,
   a BEEP peer may update the window size by sending a SEQ frame
   (Section 3.1.3).

チャンネルが創造されるとき、最初のデータフレームの最初のペイロード八重奏に関連している一連番号は0です、そして、そのチャンネルのための初期のウィンドウサイズは4096の八重奏です。 チャンネル創造の後に、BEEP同輩は、SEQフレーム(セクション3.1.3)を送ることによって、ウィンドウサイズをアップデートするかもしれません。

   If a BEEP peer is asked to create a channel and it is unable to
   allocate at least 4096 octets for that channel, it must decline
   creation of the channel, as specified in Section 2.3.1.2 of [1].
   Similarly, during establishment of the BEEP session, if the BEEP peer
   acting in the listening role is unable to allocate at least 4096
   octets for channel 0, then it must return a negative reply, as
   specified in Section 2.4 of [1], instead of a greeting.

BEEP同輩がチャンネルを創造するように頼まれて、そのチャンネルのために少なくとも4096の八重奏を割り当てることができないなら、チャンネルの創造を断たなければなりません、[1]についてセクション2.3.1で.2を指定するので。 同様に、聴取の役割で行動しているBEEP同輩がチャンネル0のために少なくとも4096の八重奏を割り当てることができないなら、BEEPセッションの設立の間、否定的な返事を返さなければなりません、[1]のセクション2.4で指定されるように、挨拶の代わりに。

3.1.2 Sending Messages

3.1.2 送付メッセージ

   Before a message is sent, the sending BEEP peer must ensure that the
   size of the payload is within the window advertised by the receiving
   BEEP peer.  If not, it has three choices:

メッセージを送る前に、送付BEEP同輩は、受信BEEP同輩によって広告に掲載された窓の中にペイロードのサイズがあるのを保証しなければなりません。 そうでなければ、それには、3つの選択があります:

   o  if the window would allow for at least one payload octet to be
      sent, the BEEP peer may segment the message and start by sending a
      smaller data frame (up to the size of the remaining window);

o 窓が、少なくとも1つのペイロード八重奏が送られるのを許容するなら、BEEP同輩は、より小さいデータを送るのによるメッセージと始めが縁どる(残っている窓のサイズまで)セグメントを許容します。

   o  the BEEP peer may delay sending the message until the window
      becomes larger; or,

o BEEP同輩は、窓が、より大きくなるまでメッセージを送るのを遅らせるかもしれません。 または

Rose                        Standards Track                     [Page 3]

RFC 3081             Mapping the BEEP Core onto TCP           March 2001

2001年3月にTCPへのビープ音コアを写像するバラ標準化過程[3ページ]RFC3081

   o  the BEEP peer may signal to its application that it is unable to
      send the message, allowing the application to try again at a later
      time (or perhaps signaling its application when a larger window is
      available).

o BEEP同輩は、メッセージを送ることができないとアプリケーションに合図するかもしれません、アプリケーションが後で再試行するのを許容して(より大きい窓が利用可能であるときに、恐らくアプリケーションに合図して)。

   The choice is implementation-dependent, although it is recommended
   that the application using BEEP be given a mechanism for influencing
   the decision.

選択は実現依存しています、決定に影響を及ぼすためにBEEPを使用するアプリケーションにメカニズムを与えるのがお勧めですが。

3.1.3 Processing SEQ Frames

3.1.3 処理SEQフレーム

   As an application accepts responsibility for incoming data frames,
   its BEEP peer should send SEQ frames to advertise a new window.

アプリケーションが受信データフレームへの責任を引き受けるとき、BEEP同輩は、新しい窓の広告を出すためにフレームをSEQに送るべきです。

   The ABNF [4] for a SEQ frame is:

SEQフレームへのABNF[4]は以下の通りです。

      seq        = "SEQ" SP channel SP ackno SP window CR LF

seqは"SEQ"SPチャンネルSP ackno SPウィンドウCR LFと等しいです。

      ackno      = seqno

acknoはseqnoと等しいです。

      window     = size

窓=サイズ

      ; channel, seqno, and size are defined in Section 2.2.1 of [1].

; チャンネル、seqno、およびサイズは[1]についてセクション2.2.1で定義されます。

   The SEQ frame has three parameters:

SEQフレームには、3つのパラメタがあります:

   o  a channel number;

o 論理機番。

   o  an acknowledgement number, that indicates the value of the next
      sequence number that the sender is expecting to receive on this
      channel; and,

o 承認番号であり、それは送付者がこのチャンネルで受けると予想している次の一連番号の値を示します。 そして

   o  a window size, that indicates the number of payload octets
      beginning with the one indicated by the acknowledgement number
      that the sender is expecting to receive on this channel.

o ウィンドウサイズであり、それは、承認番号に従ってもので始まるペイロード八重奏の数が、送付者が、このチャンネルの上に受信すると予想しているのを示したのを示します。

   A single space character (decimal code 32, " ") separates each
   component.  The SEQ frame is terminated with a CRLF pair.

シングルスペースキャラクタ、(10進コード32、「「)、各コンポーネントを切り離す、」 SEQフレームはCRLF組と共に終えられます。

   When a SEQ frame is received, if any of the channel number,
   acknowledgement number, or window size cannot be determined or is
   invalid, then the BEEP session is terminated without generating a
   response, and it is recommended that a diagnostic entry be logged.

SEQフレームが論理機番のどれか、承認番号であるなら受け取られているか、またはウィンドウサイズが決定できませんし、無効であると、応答を発生させないで、BEEPセッションは終えられます、そして、診断エントリーが登録されるのは、お勧めです。

3.1.4 Use of Flow Control

3.1.4 フロー制御の使用

   The key to successful use of flow control within BEEP is to balance
   performance and fairness:

BEEPの中のフロー制御のうまくいっている使用のキーは性能と公正のバランスをとることになっています:

Rose                        Standards Track                     [Page 4]

RFC 3081             Mapping the BEEP Core onto TCP           March 2001

2001年3月にTCPへのビープ音コアを写像するバラ標準化過程[4ページ]RFC3081

   o  large messages should be segmented into frames no larger than
      two-thirds of TCP's negotiated maximum segment size;

o 大きいメッセージはTCPの2/3が最大のセグメントサイズを交渉したほど大きくないフレームに区分されるべきです。

   o  frames for different channels with traffic ready to send should be
      sent in a round-robin fashion;

o 連続ファッションで交通が準備ができている異なったチャンネルが送るフレームを送るべきです。

   o  each time a frame is received, a SEQ frame should be sent whenever
      the window size that will be sent is at least one half of the
      buffer space available to this channel; and,

o フレームが受け取られている各回、送られるウィンドウサイズが少なくともこのチャンネルに、利用可能なバッファ領域の半分であるときはいつも、SEQフレームを送るべきです。 そして

   o  if the transport service presents multiple frames to a BEEP peer
      simultaneously, then a single consolidating SEQ frame may be sent.

o 輸送サービスが同時に複数のフレームをBEEP同輩に贈るなら、単一の固まっているSEQフレームを送るかもしれません。

   In order to avoid pathological interactions with the transport
   service, it is important that a BEEP peer advertise windows based on
   available buffer space, to allow data to be read from the transport
   service as soon as available.  Further, SEQ frames for a channel must
   have higher priority than messages for that channel.

輸送サービスとの病理学的な相互作用を避けるために、BEEP同輩が利用可能になる次第データが輸送サービスから読まれるのを許容するために利用可能なバッファ領域に基づく窓の広告を出すのは、重要です。 さらに、チャンネルのためのSEQフレームには、そのチャンネルへのメッセージより高い優先度がなければなりません。

   Implementations may wish to provide queue management facilities to
   the application using BEEP, e.g., channel priorities, (relative)
   buffer allocations, and so on.  In particular, implementations should
   not allow a given channel to monopolize the underlying transport
   window (e.g., slow readers should get small windows).

実現は、BEEP、例えば、チャンネルプライオリティ、(相対的)のバッファ配分などを使用することで待ち行列管理施設をアプリケーションに提供したがっているかもしれません。 特に、与えられたチャンネルは実現で基本的な輸送ウィンドウを独占できないべきです(例えば、読むのが遅い人は小さい窓を手に入れるべきです)。

   In addition, where possible, implementations should support transport
   layer APIs that convey congestion information.  These APIs allow an
   implementation to determine its share of the available bandwidth, and
   also be notified of changes in the estimated path bandwidth.  Note
   that when a BEEP session has multiple channels that are
   simultaneously exchanging large messages, implementations without
   access to this information may have uncertain fairness and progress
   properties during times of network congestion.

さらに、可能であるところでは、実現が混雑情報を伝えるトランスポート層APIを支持するべきです。 これらのAPIは、実現が利用可能な帯域幅のシェアを決定して、また、およそ経路帯域幅の変化について通知されるのを許容します。 BEEPセッションに同時に大きいメッセージを交換する複数のチャンネルがあるときネットワークの混雑の倍の間この情報へのアクセスのない実現には不確実な公正と進歩の特性があるかもしれないことに注意してください。

   Finally, implementors should follow the guidelines given in the
   relevant portions of RFC1122 [5] that deal with flow control (and
   bear in mind that issues such as retransmission, while they interact
   with flow control in TCP, are not applicable to this memo).  For
   example, Section 4.2.2.16 of RFC1122 [5] indicates that a "receiver
   SHOULD NOT shrink the window, i.e., move the right window edge to the
   left" and then discusses the impact of this rule on unacknowledged
   data.  In the context of mapping BEEP onto a single TCP connection,
   only the portions concerning flow control should be implemented.

最終的に、作成者はフロー制御に対処するRFC1122[5]の関連部分で与えられたガイドラインに従うべきです(TCPのフロー制御と対話しますが、「再-トランスミッション」などの問題がこのメモに適切でないことを覚えておいてください)。 受信機SHOULD NOTは窓を縮小します、すなわち、正しい窓の縁を左に動かしてください。例えば.16RFC1122[5]が示すセクション4.2.2、そのa、「」 次に、不承認のデータでこの規則の影響について議論します。 単独のTCP接続にBEEPを写像することの文脈では、フロー制御に関する部分だけが実行されるべきです。

Rose                        Standards Track                     [Page 5]

RFC 3081             Mapping the BEEP Core onto TCP           March 2001

2001年3月にTCPへのビープ音コアを写像するバラ標準化過程[5ページ]RFC3081

4. Security Considerations

4. セキュリティ問題

   Consult Section [1]'s Section 9 for a discussion of security issues.

相談してください。安全保障問題の議論のためのセクション[1]によるセクション9です。

References

参照

   [1]  Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC
        3080, March 2001.

[1] ローズ、M.、「ブロックの広げることができる交換プロトコルコア」、RFC3080、2001年3月。

   [2]  Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
        September 1981.

[2] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。

   [3]  Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
        August 1996.

[3]ElzとR.とR.ブッシュ、「通し番号演算」、RFC1982、1996年8月。

   [4]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
        Specifications: ABNF", RFC 2234, November 1997.

[4] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。

   [5]  Braden, R., "Requirements for Internet Hosts -- Communication
        Layers", STD 3, RFC 1122, October 1989.

[5] ブレーデン、R.、「インターネットのためのホスト--コミュニケーションが層にされるという要件」、STD3、RFC1122、10月1989日

Author's Address

作者のアドレス

   Marshall T. Rose
   Invisible Worlds, Inc.
   1179 North McDowell Boulevard
   Petaluma, CA  94954-6559
   US

マーシャルT.のバラの目に見えない世界のInc.1179の北のマクドウェル・Boulevardカリフォルニア94954-6559ペタルマ(米国)

   Phone: +1 707 789 3700
   EMail: mrose@invisible.net
   URI:   http://invisible.net/

以下に電話をしてください。 +1 3700年の707 789メール: mrose@invisible.net ユリ: http://invisible.net/

Rose                        Standards Track                     [Page 6]

RFC 3081             Mapping the BEEP Core onto TCP           March 2001

2001年3月にTCPへのビープ音コアを写像するバラ標準化過程[6ページ]RFC3081

Appendix A. Acknowledgements

付録A.承認

   The author gratefully acknowledges the contributions of: Dave
   Crocker, Steve Harris, Eliot Lear, Keith McCloghrie, Craig Partridge,
   Vernon Schryver, and, Joe Touch.  In particular, Dave Crocker
   provided helpful suggestions on the nature of flow control in the
   mapping.

作者は感謝して以下の貢献を承諾します。 そして、デーヴ・クロッカー、スティーブ・ハリス、エリオットリア、キースMcCloghrie、クレイグPartridge、ヴァーノンSchryver、ジョーTouch。 特に、デーヴ・クロッカーはフロー制御の本質で役立つ提案をマッピングに提供しました。

Rose                        Standards Track                     [Page 7]

RFC 3081             Mapping the BEEP Core onto TCP           March 2001

2001年3月にTCPへのビープ音コアを写像するバラ標準化過程[7ページ]RFC3081

Full Copyright Statement

完全な著作権宣言文

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

Copyright(C)インターネット協会(2001)。 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.

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

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Rose                        Standards Track                     [Page 8]

バラ標準化過程[8ページ]