Network Working Group T. Showalter
Request for Comments: 2971 Mirapoint, Inc.
Category: Standards Track October 2000
IMAP4 ID extension
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 (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
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.
インターネットメッセージアクセスプロトコルへのIDの拡張 - バージョン4rev1（IMAP4rev1の）プロトコルは、バグレポートや使用状況の統計をより完全にするために、その実装に交換識別情報にサーバとクライアントを可能にします。
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プロトコルは、リモートメールストアにアクセスするための方法を提供しますが、それは、クライアントまたはサーバがサービスを提供するために使用するものをプログラム広告を掲載するには、no施設を提供していません。クライアントまたはサーバが使用中であるかを知るためにしばしば困難であるとして、実装者は、ユーザーからの完全なバグレポートを取得するためにこのことを困難にしています。
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コマンドは、連絡先情報（バグがこれまでに発生した）と一緒に使用されているどのようなプログラムに関する情報を宣伝するための機能を提供します。
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"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[キーワード]に記載されているように解釈されます。
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：」はそれぞれクライアントとサーバから送信されたラインを示します。改行は読みやすくするために挿入されています。
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.
この情報は統計上の目的のために情報を提供したい任意のクライアントからサーバーに送信され、サーバはCAPABILITYコマンドによって返された機能のリストに含まアトム「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応答に基づいてサーバーにその動作を操作したり、制限することを拒否してはなりません。
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の能力のメカニズムに取って代わるないことが肝要です。
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.
実装は、彼らが利用できる持っていないか、まったく何の情報よりも少ない情報を送信することができます。このような行動は、ユーザーのプライバシーを維持するために有用である可能性があります。セキュリティの考慮、セクション7を参照してください。
Arguments: client parameter list or NIL
引数：クライアントのパラメータリストやNIL
Responses: OPTIONAL untagged response: ID
回答：オプションのタグなし応答：ID
Result: OK identification information accepted BAD command unknown or arguments invalid
結果：無効不明または引数BADコマンドを受け入れOK識別情報
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：A023 ID（ "名前" "SODR" "バージョン"、 "19.34"、 "ベンダー" "ピンク・フロイドの音楽リミテッド"）S：* ID NIL S：A023 OK 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コマンドに応答して、サーバは、その実装についての情報を含むタグ付きの応答を返信します。フォーマットは、クライアントリストと同じです。
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：A042 ID NIL S：* ID（ "名前" "サイラス" "バージョン" "1.5" "OS" "SunOSの" "OSバージョン" "5.5" "サポート-URL"「のmailto：サイラス・バグ+ @ andrew.cmu.edu」）S：A042 OK IDコマンドが完成します
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を送ることができます。
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
連絡先/ベンダーの日付プログラムのサポートアドレス郵便アドレスに連絡して、クライアント/サーバーのサポート - URL URLのオペレーティング・システムのベンダーベンダーのオペレーティングシステムOSバージョンバージョンのプログラムOS名のプログラムのバージョンのバージョン番号の名前を命名IMAP4rev1のコマンドコマンドで日時はすなわち、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応答を介して送信された情報は、ユーザーのプライバシーを侵害することがあります。セキュリティの考慮、セクション7を参照してください。
Implementations MUST NOT send the same field name more than once.
実装は複数回同じフィールド名を送ってはいけません。
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]で使用される拡張バッカスナウア記法（BNF）の表記を使用します。
command_any ::= "CAPABILITY" / "LOGOUT" / "NOOP" / x_command / id
;; adds id command to command_any in [IMAP4rev1]
id ::= "ID" SPACE id_params_list
id_response ::= "ID" SPACE id_params_list
id_params_list ::= "(" #(string SPACE nstring) ")" / nil
;; list of field value pairs
response_data ::= "*" SPACE (resp_cond_state / resp_cond_bye /
mailbox_data / message_data / capability_data / id_response)
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コマンドに応答して、特定の情報フィールドの伝達を遮断するように作用することができます。しかし、ファイアウォールは、完全に、かつ無条件にクライアントやサーバーリストのどちらかを削除しないでください現在の拡張を無効にすべきではありません。
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.
最後に、能力応答を処理するときにファイアウォールが、拡張の名前は、ファイアウォールがの知識がないことをクライアントに返すことを許可してはならないことに留意すべきです。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[キーワード]ブラドナーの、S.、「要件レベルを示すためにRFCsにおける使用のためのキーワード」、RFC 2119、1997年3月。
[IMAP4rev1] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 2060, October 1996.
[IMAP4rev1の]クリスピン、M.、 "インターネットメッセージアクセスプロトコル - バージョン4rev1"、RFC 2060、1996年10月。
[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[RFC-822]クロッカー、D.、 "ARPAインターネットテキストメッセージの形式の規格"、STD 11、RFC 822、1982年8月。
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のコマンドまたは応答の引数としてNILを送信することによって、IDのサポートを無効にする方法を提供することが非常に望ましいです。
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プロトコルストリームを変更、ファイアウォールの影響を受けています。詳細については、ファイアウォールやその他の仲介業者とIDの拡張のセクション5、使用を参照してください。
Tim Showalter Mirapoint, Inc. 909 Hermosa Ct. Sunnyvale, CA 94095
ティム・ショーウォルター監督ミラポイント社909エルモサのCt。サニーベール、CA 94095
EMail: tjs@mirapoint.com
メールアドレス：tjs@mirapoint.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
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機能のための基金は現在、インターネット協会によって提供されます。