RFC2971 日本語訳

Network Working Group                                        T. Showalter
Request for Comments: 2971                                Mirapoint, Inc.
Category: Standards Track                                    October 2000

コメントを求めるワーキンググループT.ショウォーター要求をネットワークでつないでください: 2971年のMirapoint Inc.カテゴリ: 標準化過程2000年10月

                           IMAP4 ID extension

IMAP4 ID拡張子

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 (2000).  All Rights Reserved.

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

Abstract

要約

   The ID extension to the Internet Message Access Protocol - Version
   4rev1 (IMAP4rev1) protocol allows the server and client to exchange
   identification information on their implementation in order to make
   bug reports and usage statistics more complete.

インターネットMessage AccessプロトコルへのID拡大--バージョン4rev1(IMAP4rev1)プロトコルで、サーバとクライアントは、バグレポートと用法統計をより完全にするように彼らの実装の識別情報を交換できます。

1. Introduction

1. 序論

   The IMAP4rev1 protocol described in [IMAP4rev1] provides a method for
   accessing remote mail stores, but it provides no facility to
   advertise what program a client or server uses to provide service.
   This makes it difficult for implementors to get complete bug reports
   from users, as it is frequently difficult to know what client or
   server is in use.

[IMAP4rev1]で説明されたIMAP4rev1プロトコルは遠く離れたメール店にアクセスするためのメソッドを提供しますが、それは、クライアントかサーバがサービスを提供するのに使用するすべてのプログラムの広告を出すために施設を全く提供しません。 これで、作成者がユーザから完全なバグレポートを得るのが難しくなります、どんなクライアントかサーバが使用中であるかを知るのが頻繁に難しいので。

   Additionally, some sites may wish to assemble usage statistics based
   on what clients are used, but in an an environment where users are
   permitted to obtain and maintain their own clients this is difficult
   to accomplish.

さらに、いくつかのサイトがしかし、クライアントが何に使用されるかに基づく用法統計を組み立てたがっているかもしれない、ユーザがそれら自身のクライアントがこれであると得て、主張することを許可されている環境は達成するのが難しいです。

   The ID command provides a facility to advertise information on what
   programs are being used along with contact information (should bugs
   ever occur).

IDコマンドは、どんなプログラムが問い合わせ先と共に使用されるかの情報の広告を出すために施設を提供します(バグが発生するはずであるなら)。

Showalter                   Standards Track                     [Page 1]

RFC 2971                   IMAP4 ID extension               October 2000

ショウォーターStandards Track[1ページ]RFC2971IMAP4 ID拡張子2000年10月

2. Conventions Used in this Document

2. このDocumentのコンベンションUsed

   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 [KEYWORDS].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[キーワード]で説明されるように本書では解釈されることであるべきですか?

   The conventions used in this document are the same as specified in
   [IMAP4rev1].  In examples, "C:" and "S:" indicate lines sent by the
   client and server respectively.  Line breaks have been inserted for
   readability.

本書では使用されるコンベンションは[IMAP4rev1]で指定されるのと同じです。 例で「C:」 そして、「S:」 クライアントとサーバによってそれぞれ送られた系列を示してください。 読み易さのためにラインブレイクを挿入してあります。

3. Specification

3. 仕様

   The sole purpose of the ID extension is to enable clients and servers
   to exchange information on their implementations for the purposes of
   statistical analysis and problem determination.

ID拡大の唯一の目的はクライアントとサーバが統計分析と問題決断の目的のためにそれらの実装で情報交換するのを可能にすることです。

   This information is be submitted to a server by any client wishing to
   provide information for statistical purposes, provided the server
   advertises its willingness to take the information with the atom "ID"
   included in the list of capabilities returned by the CAPABILITY
   command.

この情報はそうです。統計的な目的のための情報を提供したがっているあらゆるクライアントによってサーバに提出されてください、サーバが能力コマンドで返された能力のリストに「ID」を含んでいる原子で情報で取る意欲の広告を出すなら。

   Implementations MUST NOT make operational changes based on the data
   sent as part of the ID command or response.  The ID command is for
   human consumption only, and is not to be used in improving the
   performance of clients or servers.

実装はIDコマンドか応答の一部として送られたデータに基づく操作上の変更を行ってはいけません。 IDコマンドは、人間の消費だけであって、クライアントかサーバの性能を向上させる際に使用されないことです。

   This includes, but is not limited to, the following:

含んでいますが、これが制限されない、以下:

      Servers MUST NOT attempt to work around client bugs by using
      information from the ID command.  Clients MUST NOT attempt to work
      around server bugs based on the ID response.

サーバは、クライアントバグの周りでIDコマンドから情報を使用することによって働くのを試みてはいけません。 クライアントは、ID応答に基づくサーババグの周りで働くのを試みてはいけません。

      Servers MUST NOT provide features to a client or otherwise
      optimize for a particular client by using information from the ID
      command.  Clients MUST NOT provide features to a server or
      otherwise optimize for a particular server based on the ID
      response.

サーバは、特徴をクライアントに提供してはいけませんし、またそうでなければ、特定のクライアントのためにIDコマンドから情報を使用することによって、最適化されてはいけません。 クライアントは、特徴をサーバに提供してはいけませんし、またそうでなければ、ID応答に基づく特定のサーバのために最適化してはいけません。

      Servers MUST NOT deny access to or refuse service for a client
      based on information from the ID command.  Clients MUST NOT refuse
      to operate or limit their operation with a server based on the ID
      response.

サーバは、情報に基づくクライアントのために、IDコマンドからアクセスを拒絶してはいけませんし、またサービスを拒否してはいけません。 クライアントは、ID応答に基づくサーバによる彼らの操作を操作するか、または制限するのを拒否してはいけません。

Showalter                   Standards Track                     [Page 2]

RFC 2971                   IMAP4 ID extension               October 2000

ショウォーターStandards Track[2ページ]RFC2971IMAP4 ID拡張子2000年10月

   Rationale: It is imperative that this extension not supplant IMAP's
   CAPABILITY mechanism with a ad-hoc approach where implementations
   guess each other's features based on who they claim to be.

原理: この拡大が臨時のアプローチがある実装がそれらが、だれを主張するかに基づく互いの顔を推測するIMAPのCAPABILITYメカニズムに取って代わらないのは、必須です。

   Implementations MUST NOT send false information in an ID command.

実装はIDコマンドにおける偽情報を送ってはいけません。

   Implementations MAY send less information than they have available or
   no information at all.  Such behavior may be useful to preserve user
   privacy.  See Security Considerations, section 7.

実装はそれらには全く利用可能であるかいいえ、情報があるより少ない情報を送るかもしれません。 そのような振舞いは、ユーザプライバシーを保存するために役に立つかもしれません。 Security Considerations、セクション7を見てください。

3.1. ID Command

3.1. IDコマンド

   Arguments:  client parameter list or NIL

議論: クライアントパラメータ・リストかNIL

   Responses:  OPTIONAL untagged response: ID

応答: OPTIONAL untagged応答: ID

   Result:     OK    identification information accepted
               BAD   command unknown or arguments invalid

結果: OK識別情報は、BADコマンドが未知である、または議論が無効であると受け入れました。

   Implementation identification information is sent by the client with
   the ID command.

実装識別情報はIDコマンドと共にクライアントによって送られます。

   This command is valid in any state.

このコマンドはどんな状態でも有効です。

   The information sent is in the form of a list of field/value pairs.
   Fields are permitted to be any IMAP4 string, and values are permitted
   to be any IMAP4 string or NIL.  A value of NIL indicates that the
   client can not or will not specify this information.  The client may
   also send NIL instead of the list, indicating that it wants to send
   no information, but would still accept a server response.

送られた情報が分野/値の組のリストの形にあります。 分野はどんなIMAP4ストリングであることも許可されていて、値はどんなIMAP4ストリングやNILであることも許可されています。 NILの値は、クライアントが指定しないか、またはこの情報を指定できないのを示します。 また、クライアントはリストの代わりにNILを送るかもしれません、情報を全く送りたくはありませんが、まだサーバ応答を受け入れているのを示して。

   The available fields are defined in section 3.3.

利用可能な分野はセクション3.3で定義されます。

   Example:  C: a023 ID ("name" "sodr" "version" "19.34" "vendor"
                 "Pink Floyd Music Limited")
             S: * ID NIL
             S: a023 OK ID completed

例: C: a023ID、(「名前」"sodr"「バージョン」、「19.34インチ「ベンダー」「ピンクフロイド音楽株式会社」) S:、」 * ID無S: OK IDが完成したa023

3.2. ID Response

3.2. ID応答

   Contents:   server parameter list

コンテンツ: サーバパラメータ・リスト

   In response to an ID command issued by the client, the server replies
   with a tagged response containing information on its implementation.
   The format is the same as the client list.

クライアントによって発行されたIDコマンドに対応して、タグ付けをされた応答が実装の情報を含んでいて、サーバは返答します。 形式は顧客リストと同じです。

Showalter                   Standards Track                     [Page 3]

RFC 2971                   IMAP4 ID extension               October 2000

ショウォーターStandards Track[3ページ]RFC2971IMAP4 ID拡張子2000年10月

   Example:  C: a042 ID NIL
             S: * ID ("name" "Cyrus" "version" "1.5" "os" "sunos"
                  "os-version" "5.5" "support-url"
                  "mailto:cyrus-bugs+@andrew.cmu.edu")
             S: a042 OK ID command completed

例: C: a042ID NIL S: * ID ("name" "Cyrus" "version" "1.5" "os" "sunos" "os-version" "5.5" "support-url" "mailto:cyrus-bugs+@andrew.cmu.edu") S: OK IDコマンドが完成したa042

   A server MUST send a tagged ID response to an ID command.  However, a
   server MAY send NIL in place of the list.

サーバはタグ付けをされたID応答をIDコマンドに送らなければなりません。 しかしながら、サーバはリストに代わってNILを送るかもしれません。

3.3. Defined Field Values

3.3. 定義された分野値

   Any string may be sent as a field, but the following are defined to
   describe certain values that might be sent.  Implementations are free
   to send none, any, or all of these.  Strings are not case-sensitive.
   Field strings MUST NOT be longer than 30 octets.  Value strings MUST
   NOT be longer than 1024 octets.  Implementations MUST NOT send more
   than 30 field-value pairs.

分野としてどんなストリングも送るかもしれませんが、送られるかもしれないある値について説明するために以下を定義します。 実装は自由にこれらをなにも、いずれ、またはすべて、送ることができます。 ストリングは大文字と小文字を区別していません。 分野ストリングは30の八重奏より長いはずがありません。 値のストリングは1024の八重奏より長いはずがありません。 実装は30分野価値の組以上を送ってはいけません。

     name            Name of the program
     version         Version number of the program
     os              Name of the operating system
     os-version      Version of the operating system
     vendor          Vendor of the client/server
     support-url     URL to contact for support
     address         Postal address of contact/vendor
     date            Date program was released, specified as a date-time
                       in IMAP4rev1
     command         Command used to start the program
     arguments       Arguments supplied on the command line, if any
                       if any
     environment     Description of environment, i.e., UNIX environment
                       variables or Windows registry settings

IMAP4rev1コマンドCommandの日付-時間が以前はよくArgumentsがコマンドラインで供給したプログラム引数を始めていたとき、接触/ベンダー日付のDateプログラムのサポートアドレスPostalアドレスのために連絡するクライアント/サーバサポート-url URLのオペレーティングシステムベンダーVendorのオペレーティングシステムOSバージョンバージョンのプログラムOS Nameのプログラムバージョンバージョン番号の名前Nameはリリースされて、指定されていました; もしあれば、すなわち、環境のどんな環境記述、unix環境変数かWindows登録設定です。

   Implementations MUST NOT use contact information to submit automatic
   bug reports.  Implementations may include information from an ID
   response in a report automatically prepared, but are prohibited from
   sending the report without user authorization.

実装は、自動バグレポートを提出するのに問い合わせ先を使用してはいけません。 実装は、自動的に作成されたレポートにおけるID応答から情報を含むかもしれませんが、ユーザ承認なしでレポートを送るのが禁止されています。

   It is preferable to find the name and version of the underlying
   operating system at runtime in cases where this is possible.

これが可能である場合におけるランタイムのときに基本的なオペレーティングシステムの名前とバージョンを見つけるのは望ましいです。

   Information sent via an ID response may violate user privacy.  See
   Security Considerations, section 7.

ID応答で送られた情報はユーザプライバシーに違反するかもしれません。 Security Considerations、セクション7を見てください。

   Implementations MUST NOT send the same field name more than once.

実装は一度より同じフィールド名を送ってはいけません。

Showalter                   Standards Track                     [Page 4]

RFC 2971                   IMAP4 ID extension               October 2000

ショウォーターStandards Track[4ページ]RFC2971IMAP4 ID拡張子2000年10月

4. Formal Syntax

4. 正式な構文

   This  syntax is intended to augment the grammar specified in
   [IMAP4rev1] in order to provide for the ID command.  This
   specification uses the augmented Backus-Naur Form (BNF) notation as
   used in [IMAP4rev1].

この構文がIDコマンドに備えるために[IMAP4rev1]で指定された文法を増大させることを意図します。 この仕様は[IMAP4rev1]で使用されるように増大しているBN記法(BNF)記法を使用します。

     command_any ::= "CAPABILITY" / "LOGOUT" / "NOOP" / x_command / id
         ;; adds id command to command_any in [IMAP4rev1]

_いずれも命令してください:、:= "CAPABILITY"/「ログアウト」/"NOOP"/x_コマンド/イド。 命令するイドコマンドを_いくらか加えます。[IMAP4rev1]

     id ::= "ID" SPACE id_params_list

イド:、:= 「ID」SPACEイド_params_リスト

     id_response ::= "ID" SPACE id_params_list

イド_応答:、:= 「ID」SPACEイド_params_リスト

     id_params_list ::= "(" #(string SPACE nstring) ")" / nil
         ;; list of field value pairs

イド_params_は以下を記載します:= 「(「#ストリング(SPACE nstring)」)」 /無。 分野値の組のリスト

     response_data ::= "*" SPACE (resp_cond_state / resp_cond_bye /
         mailbox_data / message_data / capability_data / id_response)

応答_データ:、:= 「*」スペース(resp_cond_状態/resp_cond_さようなら、/メールボックス_データ/メッセージ_データ/能力_データ/イド_応答)

5. Use of the ID extension with Firewalls and Other Intermediaries

5. FirewallsとOther IntermediariesとのID拡張子の使用

   There exist proxies, firewalls, and other intermediary systems that
   can intercept an IMAP session and make changes to the data exchanged
   in the session.  Such intermediaries are not anticipated by the IMAP4
   protocol design and are not within the scope of the IMAP4 standard.
   However, in order for the ID command to be useful in the presence of
   such intermediaries, those intermediaries need to take special note
   of the ID command and response.  In particular, if an intermediary
   changes any part of the IMAP session it must also change the ID
   command to advertise its presence.

プロキシ、ファイアウォール、およびIMAPセッションを妨害して、セッションのときに交換されたデータへの変更を行うことができる他の仲介者システムが、います。 そのような仲介者は、IMAP4プロトコルデザインによって予期されないで、またIMAP4規格の範囲の中にいません。 しかしながら、そのような仲介者の面前で役に立つIDコマンドの注文では、それらの仲介者は、IDコマンドと応答の特別なノートを取る必要があります。 また、仲介者が何かIMAPセッションの部分を変えるなら、特に、それは存在の広告を出すIDコマンドを変えなければなりません。

   A firewall MAY act to block transmission of specific information
   fields in the ID command and response that it believes reveal
   information that could expose a security vulnerability.  However, a
   firewall SHOULD NOT disable the extension, when present, entirely,
   and SHOULD NOT unconditionally remove either the client or server
   list.

ファイアウォールは、IDコマンドとそれがセキュリティの脆弱性を暴露することができた情報を明らかにすると信じている応答における、特殊情報分野の送信を妨げるために作動するかもしれません。 しかしながら、ファイアウォールSHOULD NOTは存在しているときの拡大を完全に無効にします、そして、SHOULD NOTは無条件にクライアントかサーバリストを外します。

   Finally, it should be noted that a firewall, when handling a
   CAPABILITY response, MUST NOT allow the names of extensions to be
   returned to the client that the firewall has no knowledge of.

最終的に、CAPABILITY応答を扱うとき、拡大の名前がファイアウォールでファイアウォールが知識を全く持っていないクライアントに返ってはいけないことに注意されるべきです。

Showalter                   Standards Track                     [Page 5]

RFC 2971                   IMAP4 ID extension               October 2000

ショウォーターStandards Track[5ページ]RFC2971IMAP4 ID拡張子2000年10月

6. References

6. 参照

   [KEYWORDS]  Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", RFC 2119, March 1997.

[KEYWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、RFC2119、1997年3月。

   [IMAP4rev1] Crispin, M., "Internet Message Access Protocol - Version
               4rev1", RFC 2060, October 1996.

[IMAP4rev1] クリスピン、M.、「バージョン4rev1"、RFC2060、1996年インターネットメッセージアクセス・プロトコル--10月。」

   [RFC-822]   Crocker, D., "Standard for the Format of ARPA Internet
               Text Messages", STD 11, RFC 822, August 1982.

[RFC-822] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822、1982年8月。

7. Security Considerations

7. セキュリティ問題

   This extension has the danger of violating the privacy of users if
   misused.  Clients and servers should notify users that they implement
   and enable the ID command.

この拡大には、誤用されるならユーザのプライバシーに違反するという危険があります。 クライアントとサーバは、彼らがIDコマンドを実装して、可能にするようにユーザに通知するべきです。

   It is highly desirable that implementations provide a method of
   disabling ID support, perhaps by not sending ID at all, or by sending
   NIL as the argument to the ID command or response.

実装がIDがサポートであると恐らく全くIDを送らないか、または議論としてIDコマンドか応答にNILを送ることによって無効にするメソッドを提供するのは、非常に望ましいです。

   Implementors must exercise extreme care in adding fields sent as part
   of an ID command or response.  Some fields, including a processor ID
   number, Ethernet address, or other unique (or mostly unique)
   identifier allow tracking of users in ways that violate user privacy
   expectations.

野原がIDコマンドか応答の一部として発信したと言い足す際に作成者は極度に用心しなければなりません。 いくつかの分野、プロセッサID番号、イーサネット・アドレス、または他のユニークで(ほとんどユニーク)の識別子がユーザプライバシー期待に違反する方法でユーザに追跡するのを許容する包含。

   Having implementation information of a given client or server may
   make it easier for an attacker to gain unauthorized access due to
   security holes.

与えられたクライアントかサーバの実装情報を持っているのに、攻撃者がセキュリティーホールによる不正アクセスを獲得するのが、より簡単になるかもしれません。

   Since this command includes arbitrary data and does not require the
   user to authenticate, server implementations are cautioned to guard
   against an attacker sending arbitrary garbage data in order to fill
   up the ID log.  In particular, if a server naively logs each ID
   command to disk without inspecting it, an attacker can simply fire up
   thousands of connections and send a few kilobytes of random data.
   Servers have to guard against this.  Methods include truncating
   abnormally large responses; collating responses by storing only a
   single copy, then keeping a counter of the number of times that
   response has been seen; keeping only particularly interesting parts
   of responses; and only logging responses of users who actually log
   in.

このコマンドが任意のデータを含んで、認証するユーザを必要としないので、サーバ実装がIDログを満たすために任意のゴミデータを送る攻撃者に用心すると警告されます。 サーバがそれを点検しないでそれぞれのIDコマンドをディスクに純真に登録するなら、攻撃者は、特に、単に何千もの接続を起動して、数キロバイトの無作為のデータを送ることができます。 サーバはこれに用心しなければなりません。 メソッドは、異常に大きい応答に先端を切らせるのを含んでいます。 ただ一つのコピーだけを保存することによって応答を照合して、次に、回数のカウンタを保って、その応答を見てあります。 特にだけ応答のおもしろい部分を保ちます。 そして、実際にログインするユーザの伐採応答だけ。

   Security is affected by firewalls which modify the IMAP protocol
   stream; see section 5, Use of the ID Extension with Firewalls and
   Other Intermediaries, for more information.

セキュリティはIMAPプロトコルストリームを変更するファイアウォールで影響を受けます。 詳しい情報に関してセクション5、FirewallsとOther IntermediariesとID ExtensionのUseを見てください。

Showalter                   Standards Track                     [Page 6]

RFC 2971                   IMAP4 ID extension               October 2000

ショウォーターStandards Track[6ページ]RFC2971IMAP4 ID拡張子2000年10月

8. Author's Address

8. 作者のアドレス

   Tim Showalter
   Mirapoint, Inc.
   909 Hermosa Ct.
   Sunnyvale, CA 94095

ティムショウォーターMirapoint909Inc.Hermosa ct。 サニーベル、カリフォルニア 94095

   EMail: tjs@mirapoint.com

メール: tjs@mirapoint.com

Showalter                   Standards Track                     [Page 7]

RFC 2971                   IMAP4 ID extension               October 2000

ショウォーターStandards Track[7ページ]RFC2971IMAP4 ID拡張子2000年10月

9.  Full Copyright Statement

9. 完全な著作権宣言文

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

Copyright(C)インターネット協会(2000)。 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機能のための基金は現在、インターネット協会によって提供されます。

Showalter                   Standards Track                     [Page 8]

ショウォーター標準化過程[8ページ]