[要約] RFC 2971はIMAP4 ID拡張の仕様であり、クライアントとサーバー間の相互認識を可能にする。目的は、クライアントとサーバーが互いの機能やバージョンを認識し、適切な動作を行うこと。
Network Working Group T. Showalter
Request for Comments: 2971 Mirapoint, Inc.
Category: Standards Track October 2000
IMAP4 ID extension
IMAP4 ID拡張機能
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.
Copyright（c）The Internet Society（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プロトコルは、リモートメールストアにアクセスする方法を提供しますが、クライアントまたはサーバーがサービスを提供するために使用するプログラムを宣伝する機能を提供しません。これにより、実装者はユーザーから完全なバグレポートを取得することが困難になります。これは、クライアントまたはサーバーが使用しているものを知ることが困難な場合があるためです。
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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.
この情報は、統計的な目的のために情報を提供することを希望するクライアントによってサーバーに送信されます。これは、サーバーが、機能コマンドによって返される機能のリストに含まれるAtom "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
結果：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
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
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
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.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、RFC 2119、1997年3月。
[IMAP4rev1] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 2060, October 1996.
[IMAP4REV1] CRISPIN、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] Crocker、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プロトコルストリームを変更するファイアウォールの影響を受けます。詳細については、セクション5、ファイアウォールおよびその他の仲介者によるID拡張機能の使用を参照してください。
Tim Showalter Mirapoint, Inc. 909 Hermosa Ct. Sunnyvale, CA 94095
Tim Showalter Mirapoint、Inc。909 Hermosa Ct。サニーベール、CA 94095
EMail: tjs@mirapoint.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。