Network Working Group R. Siemborski
Request for Comments: 3656 Carnegie Mellon University
Category: Experimental December 2003
The Mailbox Update (MUPDATE)
Distributed Mailbox Database Protocol
Status of this Memo
このメモの位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
Abstract
抽象
As the demand for high-performance mail delivery agents increases, it becomes apparent that single-machine solutions are inadequate to the task, both because of capacity limits and that the failure of the single machine means a loss of mail delivery for all users. It is preferable to allow many machines to share the responsibility of mail delivery.
高性能メール配信エージェント増加に対する需要として、それが単一マシンソリューションが原因で容量制限の単一機械の故障がすべてのユーザーのメール配信の損失を意味両方、タスクに不十分であることが明らかとなります。多くのマシンがメール配信の責任を共有できるようにすることが望ましいです。
The Mailbox Update (MUPDATE) protocol allows a group of Internet Message Access Protocol (IMAP) or Post Office Protocol - Version 3 (POP3) servers to function with a unified mailbox namespace. This document is intended to serve as a reference guide to that protocol.
バージョン3（POP3）サーバーの統一されたメールボックスの名前空間で機能する - メールボックスの更新（MUPDATE）プロトコルは、インターネットメッセージアクセスプロトコル（IMAP）またはポストオフィスプロトコルのグループができます。この文書は、そのプロトコルへの参照ガイドとして役立つように意図されています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Atoms . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Strings . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Server Responses . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Response: OK . . . . . . . . . . . . . . . . . . . . . 5
3.2. Response: NO . . . . . . . . . . . . . . . . . . . . . 5
3.3. Response: BAD . . . . . . . . . . . . . . . . . . . . . 5
3.4. Response: BYE . . . . . . . . . . . . . . . . . . . . . 6
3.5. Response: RESERVE . . . . . . . . . . . . . . . . . . . 6
3.6. Response: MAILBOX . . . . . . . . . . . . . . . . . . . 6
3.7. Response: DELETE . . . . . . . . . . . . . . . . . . . 7
3.8. Server Capability Response. . . . . . . . . . . . . . . 7
4. Client Commands . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Command: ACTIVATE . . . . . . . . . . . . . . . . . . . 8
4.2. Command: AUTHENTICATE . . . . . . . . . . . . . . . . . 8
4.3. Command: DEACTIVATE . . . . . . . . . . . . . . . . . . 9
4.4. Command: DELETE . . . . . . . . . . . . . . . . . . . . 9
4.5. Command: FIND . . . . . . . . . . . . . . . . . . . . . 9
4.6. Command: LIST . . . . . . . . . . . . . . . . . . . . . 10
4.7. Command: LOGOUT . . . . . . . . . . . . . . . . . . . . 10
4.8. Command: NOOP . . . . . . . . . . . . . . . . . . . . . 10
4.9. Command: RESERVE. . . . . . . . . . . . . . . . . . . . 10
4.10. Command: STARTTLS . . . . . . . . . . . . . . . . . . . 11
4.11. Command: UPDATE . . . . . . . . . . . . . . . . . . . . 12
5. MUPDATE Formal Syntax . . . . . . . . . . . . . . . . . . . . 12
6. MUPDATE URL Scheme. . . . . . . . . . . . . . . . . . . . . . 14
6.1. MUPDATE URL Scheme Registration Form. . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9. Intellectual Property Rights. . . . . . . . . . . . . . . . . 16
10. References. . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References. . . . . . . . . . . . . . . . . . 17
10.2. Informative References. . . . . . . . . . . . . . . . . 17
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
12. Author's Address. . . . . . . . . . . . . . . . . . . . . . . 18
13. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 19
In order to support an architecture where there are multiple [IMAP, POP3] servers sharing a common mailbox database, it is necessary to be able to provide atomic mailbox operations, as well as offer sufficient guarantees about database consistency.
一般的なメールボックスデータベースを共有する複数[IMAP、POP3]サーバが存在するアーキテクチャをサポートするためには、データベースの一貫性についてアトミックメールボックスの操作、ならびに提供十分な保証を提供できることが必要です。
The primary goal of the MUPDATE protocol is to be simple to implement yet allow for database consistency between participants.
MUPDATEプロトコルの主な目的は、実装はまだ参加者間のデータベースの整合性を可能にするために簡単なことです。
The key words "MUST, "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are to be interpreted as defined in BCP 14, RFC 2119 [KEYWORDS].
キーワード「MUST、 "NOT MUST"、 "必須"、 "SHOULD"、 ""、 "RECOMMENDEDべきではない"、および "the" は本書ではBCP 14で定義されるように解釈されるべきでいてもよく、RFC 2119 [KEYWORDS] 。
In examples, "C:" and "S:" indicate lines sent by the client and server respectively.
実施例では、「C：」および「S：」はそれぞれクライアントとサーバから送信されたラインを示します。
The MUPDATE protocol assumes a reliable data stream such as a TCP network connection. IANA has registered port 3905 with a short name of "mupdate" for this purpose.
MUPDATEプロトコルは、TCPネットワーク接続として信頼性の高いデータストリームを想定しています。 IANAは、この目的のために「mupdate」の短い名前でポート3905を登録しています。
In the current implementation of the MUPDATE protocol there are three types of participants: a single master server, slave (or replica) servers, and clients. The master server maintains an authoritative copy of the mailbox database. Slave servers connect to the MUPDATE master server as clients, and function as replicas from the point of view of end clients. End clients may connect to either the master or any slave and perform searches against the database, however operations that change the database can only be performed against the master. For the purposes of protocol discussion we will consider a slave's connection to the master identical to that of any other client.
シングルマスタサーバ、スレーブ（またはレプリカ）サーバ、およびクライアント：MUPDATEプロトコルの現在の実装では、参加者の3つのタイプがあります。マスターサーバーは、メールボックスデータベースの正式なコピーを保持します。スレーブサーバは、エンドクライアントの観点から、レプリカとしてMUPDATEマスタークライアントとしてサーバー、および機能に接続します。エンドクライアントは、しかし、唯一のマスターに対して実行することができ、データベースを変更する操作をマスターまたはスレーブのいずれかに接続し、データベースに対して検索を行うことができます。プロトコルの議論の目的のために我々は他のクライアントと同一のマスタースレーブの接続を検討します。
After connection, all commands from a client to server must have an associated unique tag which is an alphanumeric string. Commands MAY be pipelined from the client to the server (that is, the client need not wait for the response before sending the next command). The server MUST execute the commands in the order they were received, however.
接続後は、クライアントからサーバへのすべてのコマンドは、英数字の文字列で関連付けられた固有のタグを持っている必要があります。コマンドは（つまり、クライアントは、次のコマンドを送信する前に応答を待つ必要はありません）クライアントからサーバへのパイプライン化してもよいです。サーバーは、しかし、それらが受信された順序でコマンドを実行する必要があります。
If the server supports an inactivity login timeout, it MUST be at least 15 minutes.
サーバが非アクティブのログインタイムアウトをサポートしている場合、それは少なくとも15分でなければなりません。
MUPDATE uses data formats similar to those used in [ACAP]. That is, atoms and strings. All commands and tags in the protocol are transmitted as atoms. All other data is considered to a string, and must be quoted or transmitted as a literal.
MUPDATEは[ACAP]で使用されるものと同様のデータフォーマットを使用します。これは、原子や文字列です。プロトコルのすべてのコマンドとタグが原子として送信されます。他のすべてのデータは、文字列とみなされ、引用されたか、リテラルとして送信する必要があります。
Outside of a literal, both clients and servers MUST support line lengths of at least 1024 octets (including the trailing CR and LF characters). If a line of a longer length must be transmitted, implementations MUST make use of literals to do so.
リテラルの外に、クライアントとサーバの両方が（トレーリングCRとLF文字を含む）は、少なくとも1024オクテットの線路長をサポートしなければなりません。長い長さの行を送信しなければならない場合、実装はそうするためにリテラルを使用する必要があります。
An atom consists of one or more alphanumeric characters. Atoms MUST be less than 15 octets in length.
アトムは1文字以上の英数字で構成されています。原子は、長さが15個の未満のオクテットでなければなりません。
As in [ACAP], a string may be either literal or a quoted string. A literal is a sequence of zero or more octets (including CR and LF), prefix-quoted with an octet count in the form of an open brace ("{"), the number of octets, an optional plus sign to indicate that the data follows immediately (a non-synchronized literal), a close brace ("}"), and a CRLF sequence. If the plus sign is omitted (a synchronized literal), then the receiving side MUST send a "+ go ahead" response, and the sending side MUST wait for this response. Servers MUST support literals of atleast 4096 octets.
[ACAP]のように、文字列リテラルまたは引用符で囲まれた文字列のいずれであってもよいです。リテラルは、（CRやLFを含む）は、ゼロ以上のオクテットのシーケンスであるオープンブレース（「{」）の形のオクテットカウント、オクテットの数、任意でプレフィクス引用プラスことを示すために署名しますデータは、（非同期リテラル）、閉じる括弧（「}」）とは、CRLFシーケンス直後に続きます。プラス記号が（リテラル同期）省略された場合、受信側は、「+先に行く」応答を送らなければなりませんし、送信側は、この応答を待たなければなりません。サーバーは少なくとも4096オクテットのリテラルをサポートしなければなりません。
Strings that are sent from server to client SHOULD NOT be in the synchronized literal format.
サーバからクライアントに送信された文字列は、同期リテラル形式でするべきではありません。
A quoted string is a sequence of zero or more 7-bit characters, excluding CR, LF, and the double quote (<">), with double quote characters at each end.
引用符で囲まれた文字列は、各末端に二重引用符で、（< ">）CR、LF、および二重引用符を除いて、ゼロまたはそれ以上の7ビット文字のシーケンスです。
The empty string is represented as either "" (a quoted string with zero characters between double quotes) or as {0} followed by CRLF (a literal with an octet count of 0).
空の文字列は、いずれかの「」（二重引用符の間にゼロ文字を引用文字列）として、または、{0}（0のオクテットカウントがリテラル）CRLFが続くように表されます。
Every client command in the MUPDATE protocol may receive one or more tagged responses from the server. Each response is preceded by the same tag as the command that elicited the response from the server.
MUPDATEプロトコルのすべてのクライアントコマンドは、サーバから1つのまたは複数のタグ付きの応答を受け取ることができます。各応答は、サーバからの応答を誘発したコマンドと同じタグが先行します。
A tagged OK response indicates that the operation completed successfully. There is a mandatory implementation-defined string after the OK response. This response also indicates the beginning of the streaming update mode when given in response to an UPDATE command.
タグ付きOK応答は、操作が正常に完了したことを示しています。 OK応答の後に必須実装で定義された文字列があります。 UPDATEコマンドに応答して与えられたときに、この応答には、ストリーミング更新モードの始まりを示します。
Example:
例：
C: N01 NOOP S: N01 OK "NOOP Complete"
C：N01 NOOP S：N01 OK "コンプリートNOOP"
A tagged NO response indicates that the operation was explicitly denied by the server or otherwise failed. There is a mandatory implementation-defined string after the NO response that SHOULD explain the reason for denial.
タグ付きNO応答は、操作が明示的にサーバーによって拒否されたか、そうでない場合は失敗したことを示していません。拒否の理由を説明しなければならないNO応答後の必須実装で定義された文字列があります。
Example:
例：
C: A01 AUTHENTICATE "PLAIN" S: A01 NO "PLAIN is not a supported SASL mechanism"
C：A01 AUTHENTICATE "PLAIN" S：A01 NO "PLAINは、サポートされているSASLメカニズムではありません"
A tagged BAD response indicates that the command from the client could not be parsed or understood. There is a mandatory implementation-defined string after the BAD response to provide additional information about the error. Note that untagged BAD responses are allowed if it is unclear what the tag for a given command is (for example, if a blank line is received by the mupdate server, it can generate an untagged BAD response). In the case of an untagged response, the tag should be replaced with a "*".
タグ付けされたBAD応答は、クライアントからのコマンドを解析または理解できなかったことを示しています。エラーに関する追加情報を提供するために、BAD応答後の必須実装で定義された文字列があります。与えられたコマンドのタグは、（空行がmupdateサーバによって受信された場合、例えば、それがタグなしBAD応答を生成することができる）であるものは不明である場合タグなしBAD応答が許可されていることに留意されたいです。タグなし応答の場合、タグは「*」に置き換えてください。
Example:
例：
C: C01 SELECT "INBOX" S: C01 BAD "This is not an IMAP server" C: S: * BAD "Need Command"
C：C01 SELECT "INBOX" S：C01 BADはC "これはIMAPサーバではありません"：S：* BAD "が必要コマンド"
A tagged BYE response indicates that the server has decided to close the connection. There is a mandatory implementation-defined string after the BYE response that SHOULD explain the reason for closing the connection. The server MUST close the connection immediately after transmitting the BYE response.
タグ付けされたBYE応答は、サーバが接続をクローズすることを決定したことを示します。接続を閉じるための理由を説明しなければならないBYE応答後の必須実装で定義された文字列があります。サーバは、BYE応答を送信した後、すぐに接続を閉じる必要があります。
Example:
例：
C: L01 LOGOUT S: L01 BYE "User Logged Out"
C：L01 LOGOUT S：L01 BYE "ユーザーがログアウト"
A tagged RESERVE response may only be given in response to a FIND, LIST, or UPDATE command. It includes two parameters: the name of the mailbox that is being reserved (in mUTF-7 encoding, as specified in [IMAP]) and a location string whose contents is defined by the clients that are using the database, though it is RECOMMENDED that the format of this string be the hostname of the server which is storing the mailbox.
タグ付けされたRESERVE応答は、FIND、リスト、またはUPDATEコマンドに応答して与えられてもよいです。それが推奨されてもいること、（[IMAP]で指定されるように、mUTF-7エンコーディングに）予約されているメールボックスの名前とコンテンツデータベースを使用しているクライアントによって定義されたロケーション文字列：これは2つのパラメータを含みますこの文字列の形式は、メールボックスを格納しているサーバーのホスト名であること。
This response indicates that the given name is no longer available in the namespace, though it does not indicate that the given mailbox is available to clients at the current time.
この応答は、それが与えられたメールボックスが、現在の時点でクライアントに利用可能であることを示すものではありませんが、与えられた名前は、名前空間で利用できなくなったことを示していません。
Example:
例：
S: U01 RESERVE "internet.bugtraq" "mail2.example.org"
S：U01 RESERVE "internet.bugtraq" "mail2.example.org"
A tagged MAILBOX response may only be given in response to a FIND, LIST, or UPDATE command. It includes three parameters: the name of the mailbox, a location string (as with RESERVE), and a client-defined string that specifies the IMAP ACL [IMAP-ACL] of the mailbox. This message indicates that the given mailbox is ready to be accessed by clients.
タグ付けされたメールボックスの応答は、FIND、リスト、またはUPDATEコマンドに応答して与えられてもよいです。メールボックスの名前、（RESERVEと同様に）位置文字列、およびメールボックスのIMAP ACL [IMAP-ACL]を指定するクライアントが定義した文字列という3つのパラメータを含みます。このメッセージは、指定したメールボックスは、クライアントからアクセスする準備ができていることを示しています。
Example:
例：
S: U01 MAILBOX "internet.bugtraq" "mail2.example.org" "anyone rls"
S：U01 MAILBOX "internet.bugtraq" "mail2.example.org" "誰もがRLS"
A tagged DELETE response may only be given in response to an UPDATE command, and MUST NOT be given before the OK response to the UPDATE command is given. It contains a single parameter, that of the mailbox that should be deleted from the slave's database. This response indicates that the given mailbox no longer exists in the namespace of the database, and may be given for any mailbox name, active, reserved, or nonexistent. (Though implementations SHOULD NOT issue DELETE responses for nonexistent mailboxes).
タグ付けされたDELETE応答はUPDATEコマンドに応答して与えられることができる、とUPDATEコマンドへのOK応答が指定されている前に与えてはなりません。これは、スレーブのデータベースから削除する必要があるメールボックスのそれを単一のパラメータが含まれています。この応答は、所与のメールボックスがもはやデータベースの名前空間に存在し、予約済み、アクティブ、任意のメールボックス名に指定された、または存在しない可能性があることを示していません。 （実装が存在しないメールボックスのDELETE応答を発行するべきではありませんけど）。
Example:
例：
S: U01 DELETE "user.rjs3.sent-mail-jan-2002"
S：U01 "はuser.rjs3.sentメール-JAN-2002" を削除
Upon connection of the client to the server, and directly following a successful STARTTLS command, the server MUST issue a capabilities banner, of the following format:
クライアントからサーバーへの接続時には、直接の成功STARTTLSコマンドを次のように、サーバは、次の形式で、機能のバナーを発行しなければなりません。
The banner MUST contain a line that begins with "* AUTH" and contain a space-separated list of SASL mechanisms that the server will accept for authentication. The mechanism names are transmitted as atoms. Servers MAY advertise no available mechanisms (to indicate that STARTTLS must be completed before authentication may occur). If STARTTLS is not supported by the server, then the line MUST contain at least one mechanism.
バナーは「* AUTH」で始まる行が含まれており、サーバが認証のために受け入れるSASLメカニズムのスペース区切りのリストを含まなければなりません。メカニズム名は原子として送信されます。サーバは、（認証が発生する可能性があります前に、STARTTLSを完了しなければならないことを示すために）使用可能なメカニズムを広告するかもしれません。 STARTTLSがサーバによってサポートされていない場合、その行は、少なくとも一つのメカニズムを含まなければなりません。
If the banner is being issued without a TLS layer, and the server supports the STARTTLS command, the banner MUST contain the line "* STARTTLS". If the banner is being issued under a TLS layer (or the server does not support STARTTLS), the banner MUST NOT contain this line.
バナーはTLS層なしで発行され、サーバがSTARTTLSコマンドをサポートしている場合、バナーは「* STARTTLSを」行を含まなければなりません。バナーはTLS層の下に発行されている（またはサーバーがSTARTTLSをサポートしていない）場合は、バナーは、この行を含めることはできません。
The last line of the banner MUST start with "* OK MUPDATE" and be followed by four strings: the server's hostname, an implementation-defined string giving the name of the implementation, an implementation-defined string giving the version of the implementation, and a string that indicates if the server is a master or a slave. The master/slave indication MUST be either "(master)" or an MUPDATE URL that defines where the master can be contacted.
バナーの最後の行は「* OK MUPDATE」で始まる必要があり、4つの文字列が続き：サーバーのホスト名、実装、実装のバージョンを与える実装定義された文字列の名前を与え、実装定義の文字列、およびサーバがマスタまたはスレーブであるかどうかを示す文字列。マスタ/スレーブ表示はいずれかでなければなりません「（マスター）」またはマスターを接触させることができる場所を定義MUPDATEのURL。
Any unrecognized responses before the "* OK MUPDATE" response MUST be ignored by the client.
「* OK MUPDATE」応答の前に認識されない応答はクライアントによって無視されなければなりません。
Example:
例：
S: * AUTH KERBEROS_V4 GSSAPI S: * STARTTLS S: * OK MUPDATE "mupdate.example.org" "Cyrus" "v2.1.2" "(master)"
S：* AUTH KERBEROS_V4 GSSAPI S：* STARTTLS S：* OK MUPDATE "mupdate.example.org" "サイラス" "v2.1.2" "（マスター）"
The following are valid commands that a client may send to the MUPDATE server: AUTHENTICATE, ACTIVATE, DEACTIVATE, DELETE, FIND, LIST, LOGOUT, NOOP, RESERVE, STARTTLS, and UPDATE.
AUTHENTICATE、アクティブ化、非アクティブ化、DELETE、FIND、LIST、LOGOUT、NOOP、RESERVE、STARTTLS、およびUPDATE：以下は、クライアントがMUPDATEサーバーに送信ことが有効なコマンドです。
Before a successful AUTHENTICATE command has occurred, the server MUST NOT accept any commands except for AUTHENTICATE, STARTTLS, and LOGOUT (and SHOULD reply with a NO response for all other commands).
成功したAUTHENTICATEコマンドが発生した前に、サーバはAUTHENTICATE、STARTTLS、およびLOGOUTを除く任意のコマンドを受け入れてはいけません（および他のすべてのコマンドのためのNO応答を返信する必要があります）。
The ACTIVATE command has 3 parameters: the mailbox name, its location, and its ACL. This command MUST NOT not be issued to a slave server.
メールボックス名、その場所、およびそのACL：ACTIVATEコマンドは、3つのパラメータがあります。このコマンドは、スレーブサーバに発行されていないてはなりません。
This command can also be used to update the ACL or location information of a mailbox. Note that it is not a requirement for a mailbox to be reserved (or even exist in the database) for an ACTIVATE command to succeed, implementations MUST allow this behavior as it facilitates synchronization of the database with the current state of the mailboxes.
このコマンドは、メールボックスのACLまたは位置情報を更新するために使用することができます。それはメールボックスの現在の状態とデータベースの同期化を容易にするように予約するメールボックスの要件ではないことに注意してください（またはデータベースに存在する）成功するACTIVATEコマンドで、実装はこの動作を許容しなければなりません。
The AUTHENTICATE command initiates a [SASL] negotiation session between the client and the server. It has two parameters. The first parameter is mandatory, and is a string indicating the desired [SASL] mechanism. The second is a string containing an optional BASE64 encoded (as defined in section 6.8 of [MIME]) client first send.
AUTHENTICATEコマンドは、クライアントとサーバの間の[SASL]交渉セッションを開始します。これは、2つのパラメータがあります。最初のパラメータは必須であり、所望の[SASL]メカニズムを示す文字列です。第二は、最初の送信のクライアント（[MIME]のセクション6.8で定義されるように）符号化された任意BASE64を含む文字列です。
All of the remaining SASL blobs that are sent MUST be sent across the wire must be in BASE64 encoded format, and followed by a CR and LF combination. They MUST NOT be encoded as strings.
送信される残りSASLブロブの全ては、CRとLF組み合わせによってBASE64符号化された形式である必要があり、ワイヤを介して送信し、従わなければなりません。彼らは、文字列としてエンコードされてはなりません。
Clients may cancel authentication by sending a * followed by a CR and LF.
クライアントは、CRとLFが続く*を送信して認証を取り消すことができます。
The [SASL] service name for the MUPDATE protocol is "mupdate". Implementations are REQUIRED to implement the GSSAPI [SASL] mechanism, though they SHOULD implement as many mechanisms as possible.
MUPDATEプロトコルの[SASL]サービス名は「mupdate」です。彼らはできるだけ多くの機構を実装する必要も実装は、GSSAPI [SASL]メカニズムを実装するために必要とされます。
If a security layer is negotiated, it should be used directly following the CR and LF combination at the end of the server's OK response (i.e., beginning with the client's next command) Only one successful AUTHENTICATE command may be issued per session.
セキュリティ層がネゴシエートされている場合は、セッションごとに発行することができる直接サーバーのOK応答（すなわち、クライアントの次のコマンドで始まる）一つだけの成功AUTHENTICATEコマンドの末尾にCRとLFの組み合わせを以下に使用する必要があります。
The DEACTIVATE command takes two parameters, the mailbox name and location data. The mailbox MUST already exist and be activated on the MUPDATE server. If the server responds OK, then the mailbox name has been moved to the RESERVE state. If the server responds NO, then the mailbox name has not been moved (for example, the mailbox was not already active). Any ACL information that is known about the mailbox MAY be lost when a DEACTIVATE succeeds. This command MUST NOT be issued to a slave.
DEACTIVATEコマンドは、2つのパラメータ、メールボックスの名前と場所のデータを取ります。メールボックスがすでに存在している必要があり、MUPDATEサーバ上で起動します。サーバはOK応答した場合、そのメールボックス名がRESERVE状態に移動されました。サーバはNOを応答した場合、そのメールボックス名は、（たとえば、メールボックスがすでにアクティブではありませんでした）に移動されていません。 DEACTIVATEが成功したときのメールボックスについて知られている任意のACL情報が失われることがあります。このコマンドはスレーブに発行されてはなりません。
Example:
例：
C: A01 DEACTIVATE "user.rjs3.new" "mail3.example.org!u4" S: A01 OK "Mailbox Reserved."
C：A01 DEACTIVATE "user.rjs3.new" "mail3.example.org U4" S：A01 OK "！メールボックスの予約済み"。
The DELETE command takes only a single parameter, the mailbox name to be removed from the database's namespace. The server SHOULD give a NO response if the mailbox does not exist. This command MUST NOT be issued to a slave server.
DELETEコマンドは、メールボックス名は、データベースの名前空間から削除されるように、単一のパラメータだけを取ります。メールボックスが存在しない場合、サーバーはNO応答を与える必要があります。このコマンドは、スレーブサーバに発行されてはなりません。
The FIND command takes a single parameter, a mailbox name. The server then responds with the current record for the given mailbox, if any, and an OK response.
FINDコマンドは、単一のパラメータ、メールボックス名を取ります。その後、サーバは、特定のメールボックスの現在のレコードがあれば、そしてOK応答で応答します。
Example (mailbox does not exist):
例（メールボックスが存在しません。）：
C: F01 FIND "user.rjs3.xyzzy" S: F01 OK "Search Complete"
C：F01のFIND "user.rjs3.xyzzy" S：F01のOKは "完全な検索します"
Example (mailbox is reserved):
例（メールボックスが予約されています）：
C: F01 FIND "user.rjs3" S: F01 RESERVE "user.rjs3" "mail4.example.org" S: F01 OK "Search Complete"
C：F01 FIND "user.rjs3" S：F01 RESERVE "user.rjs3" "mail4.example.org" S：F01のOK "完全な検索"
The LIST command is similar to running FIND across the entire database. The LIST command takes a single optional parameter, which is a prefix to try to match against the location field of the records. Without the parameter, LIST returns every record in the database.
LISTコマンドは、データベース全体FINDを実行するのに似ています。 LISTコマンドは、レコードの場所フィールド照合しようとする接頭辞である単一のオプションのパラメータを取ります。パラメータがない場合、LISTは、データベース内のすべてのレコードを返します。
For each mailbox that matches, either a MAILBOX or a RESERVE response (as applicable) is sent to the client. When all responses are complete, an OK response is issued.
一致した各メールボックスについて、メールボックスまたはRESERVE応答（該当する場合）のいずれかをクライアントに送信されます。すべての応答が完了したら、OK応答が発行されます。
Example:
例：
C: L01 LIST S: L01 RESERVE "user.rjs3" "mail4.example.org!u2" S: L01 MAILBOX "user.leg" "mail2.example.org!u1" "leg lrswipcda" S: L01 OK "List Complete" C: L02 LIST "mail4.example.org!" S: L02 RESERVE "user.rjs3" "mail4.example.org!u2" S: L02 OK "List Complete"
C：L01 LIST S：L01 RESERVE "user.rjs3" "mail4.example.org U2" S：L01 MAILBOX "！user.leg" "mail2.example.org U1！" "脚lrswipcda" S：L01 OK「リストコンプリート」C：L02 LIST "mail4.example.org"！ S：L02 RESERVE "user.rjs3" "mail4.example.org U2" S：L02 OK "！リストコンプリート"
The LOGOUT command tells the server to close the connection. Its only valid response is the BYE response. The LOGOUT command takes no parameters.
LOGOUTコマンドは、接続を閉じるために、サーバーに指示します。その唯一の有効な応答は、BYE応答です。 LOGOUTコマンドはパラメータを取りません。
The NOOP command takes no parameters. Provided the client is authenticated, its only acceptable response is an OK. Any idle timeouts that the server may have on the connection SHOULD be reset upon receipt of this command.
NOOPコマンドはパラメータを取りません。提供されるクライアントが認証され、その唯一の許容応答がOKです。サーバが接続にした可能性のあるすべてのアイドルタイムアウトは、このコマンドの受信時にリセットされる必要があります。
If this command is issued after an UPDATE command has been issued, then the OK response also indicates that all pending database updates have been sent to the client. That is, the slave can guarantee that its local database is up to date as of a certain time by issuing a NOOP and waiting for the OK. The OK MUST NOT return until all updates that were pending at the time of the NOOP have been sent.
UPDATEコマンドが発行された後に、このコマンドが発行されている場合は、[OK]を応答もすべての保留中のデータベースの更新がクライアントに送信されていることを示しています。つまり、スレーブはそのローカルデータベースはNOOPを発行し、OKを待っていることによって、特定の時点での最新であることを保証することができています。 NOOPの時点で保留されたすべての更新が送信されるまで、OKを返してはなりません。
The RESERVE command takes two parameters (just like the RESERVE response), the mailbox name to reserve and location data. If the server responds OK, then the mailbox name has been reserved. If the server responds NO, then the mailbox name has not been reserved (for example, another server has reserved it already). This command MUST NOT be issued to a slave.
RESERVEコマンドは、予約した位置データに、（単にRESERVE応答のような）メールボックス名を2つのパラメータを取ります。サーバはOK応答した場合、そのメールボックスの名前は予約されています。サーバはNOを応答した場合、そのメールボックス名は、（例えば、別のサーバーがすでにそれを予約している）に予約されていません。このコマンドはスレーブに発行されてはなりません。
The typical sequence for mailbox creation is:
メールボックスの作成のための典型的なシーケンスは以下のとおりです。
C: R01 RESERVE "user.rjs3.new" "mail3.example.org!u4" S: R01 OK "Mailbox Reserved." <client does local mailbox create operations> C: A01 ACTIVATE "user.rjs3.new" "mail3.example.org!u4" "rjs3 lrswipcda" S: A01 OK "Mailbox Activated."
C：R01 RESERVE "user.rjs3.new" "mail3.example.org U4" S：R01 OK "！メールボックスの予約済み"。 A01 ACTIVATE "user.rjs3.new" "mail3.example.org U4" "rjs3 lrswipcda" S：！：A01 OK "活性化メールボックス。" C <クライアントは、ローカルのメールボックスには、オペレーションを作成しません>
The STARTTLS command requests the commencement of a [TLS] negotiation. The negotiation begins immediately after the CRLF in the OK response. After a client issues a STARTTLS command, it MUST NOT issue further commands until a server response is seen and the [TLS] negotiation is complete.
STARTTLSコマンドは、[TLS]交渉の開始を要求します。交渉はOK応答でCRLFの直後に開始されます。クライアントがSTARTTLSコマンドを発行した後、サーバーの応答が見られるまでには、さらにコマンドを発行してはならないと[TLS]交渉は完了です。
The STARTTLS command is only valid in non-authenticated state. The server remains in non-authenticated state, even if client credentials are supplied during the [TLS] negotiation. The [SASL] EXTERNAL mechanism MAY be used to authenticate once [TLS] client credentials are successfully exchanged. Note that servers are not required to support the EXTERNAL mechanism.
STARTTLSコマンドは非認証状態でのみ有効です。サーバーは、クライアントの資格情報は、[TLS]交渉中に供給されていても、非認証状態のまま。 [SASL]外部機構は、一度[TLS]クライアントの資格情報を認証するために使用されるかもしれ成功裏に交換されます。サーバが外部メカニズムをサポートするために必要とされていないことに注意してください。
After the [TLS] layer is established, the server MUST re-issue the initial response banner (see Section 3.8). This is necessary to protect against man-in-the-middle attacks which alter the capabilities list prior to STARTTLS, as well as to advertise any new SASL mechanisms (or other capabilities) that may be available under the layer. The client MUST discard cached capability information and replace it with the new information.
[TLS]層が確立された後、サーバは（3.8節を参照）初期応答のバナーを再発行しなければなりません。これは、従来STARTTLSの機能のリストを変更man-in-the-middle攻撃から保護する必要があるだけでなく、層の下に入手可能である任意の新しいSASLメカニズム（またはその他の能力）をアドバタイズします。クライアントは、キャッシュされた能力情報を破棄し、新しい情報とそれを交換する必要があります。
After the a successful STARTTLS command, the server SHOULD return a NO response to additional STARTTLS commands.
成功STARTTLSコマンドの後、サーバーは、追加のSTARTTLSコマンドに対する応答を返すべきではありません。
Servers MAY choose to not implement STARTTLS. In this case, they MUST NOT advertise STARTTLS in their capabilities banner, and SHOULD return a BAD response to the STARTTLS command, if it is issued.
サーバーはSTARTTLSを実装しないことを選ぶかもしれません。この場合、彼らは彼らの能力のバナーにSTARTTLSを広告してはならない、それが発行されている場合、STARTTLSコマンドへのBAD応答を返すべきです。
Example:
例：
C: S01 STARTTLS S: S01 OK "Begin TLS negotiation now" <TLS negotiation, further commands are under TLS layer> S: * AUTH KERBEROS_V4 GSSAPI PLAIN S: * OK MUPDATE "mupdate.example.org" "Cyrus" "v2.1.2" "(master)"
C：S01 STARTTLS S：S01 OK "は今TLSネゴシエーションを開始します" <TLS折衝、さらにコマンドはTLS層の下にある> S：* AUTH KERBEROS_V4 GSSAPI PLAIN S：* OK MUPDATE "mupdate.example.org" "サイラス"「V2。 1.2" "（マスター）"
The UPDATE command is how a slave initializes an update stream from the master (though it is also valid to issue this command to a slave). In response to the command, the server returns a list of all mailboxes in its database (the same results as a parameterless LIST command) followed by an OK response. From this point forward, whenever an update occurs to the master database, it MUST stream the update to the slave within 30 seconds. That is, it will send RESERVE, MAILBOX, or DELETE responses as they are applicable.
UPDATEコマンドは、（スレーブにこのコマンドを発行することも有効であるが）スレーブがマスターから更新ストリームを初期化する方法です。コマンドに応答して、サーバは、OKレスポンスに続いて、そのデータベース内のすべてのメールボックス（パラメータのないLISTコマンドと同じ結果）のリストを返します。更新は、マスターデータベースに発生するたびに、この点から前方に、それは30秒以内スレーブに更新をストリーミングしなければなりません。つまり、RESERVE、MAILBOXを送ったり、彼らが適用されるような応答を削除します、です。
After a client has issued an UPDATE command, it may only issue NOOP and LOGOUT commands for the remainder of the session.
クライアントがUPDATEコマンドを発行した後は、それだけでNOOPとLOGOUTがセッションの残りのコマンドを発行することができます。
Example:
例：
C: U01 UPDATE S: U01 MAILBOX "user.leg" "mail2.example.org!u1" "leg lrswipcda" S: U01 MAILBOX "user.rjs3" "mail3.example.org!u4" "rjs3 lrswipcda" S: U01 RESERVE "internet.bugtraq" "mail1.example.org!u5" "anyone lrs" S: U01 OK "Streaming Begins" <some time goes by, and another client creates a new mailbox> S: U01 RESERVE "user.leg.new" "mail2.example.org!u1" <some more time passes, and the create succeeds> S: U01 MAILBOX "user.leg.new" "mail2.example.org!u1" "leg lrswipcda" <much more time passes, and the slave decides to send a NOOP to reset its inactivity timer> C: N01 NOOP S: U01 DELETE "user.leg.new" S: N01 OK "NOOP Complete"
C：U01 UPDATE S：！U01 MAILBOX "user.leg" "mail2.example.org U1" "脚lrswipcda" S！：U01 MAILBOX "user.rjs3" "mail3.example.org U4" "rjs3 lrswipcda" S： U01 RESERVE "internet.bugtraq" "mail1.example.org U5" "誰LRS" S：！OK U01は、<いくつかの時間が経つと、別のクライアントには、新しいメールボックスを作成します> "ストリーミング開始" S：U01 RESERVE「user.legを.new」 "！mail2.example.org U1" S <いくつかのより多くの時間が経過すると、作成は成功>：U01のMAILBOX "user.leg.new" "mail2.example.org U1" "脚lrswipcda" <はるかに！時間が経過し、スレーブはその非アクティブタイマー> CリセットするNOOP送信することを決定：N01 NOOP Sを：N01 OK "コンプリートNOOP"：U01は "user.leg.new" SをDELETE
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [ABNF]. This uses the ABNF core rules as specified in Appendix A of [ABNF].
以下の構文仕様は、[ABNF]で指定された拡張バッカス・ナウアフォーム（ABNF）の表記を使用します。 [ABNF]の付録Aで指定されるように、これはABNFコアルールを使用します。
Except as noted otherwise, all alphabetic characters are case-insensitive. The use of upper or lower case characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion.
特記しないものを除いて、すべての英字は大文字と小文字を区別しません。トークン文字列を定義するための、大・小文字の使用は、編集上明確にするためです。実装は大文字と小文字を区別しないやり方で、これらの文字列を受け入れなければなりません。
Note that this specification also uses some terminals from section 8 of [ACAP].
本明細書はまた、[ACAP]のセクション8から一部の端末を使用することに注意してください。
cmd-activate = "ACTIVATE" SP string SP string SP string
CMD-アクティブ= "ACTIVATE" SP文字列SP文字列SP文字列
cmd-authenticate = "AUTHENTICATE" SP sasl-mech [ SP string ] cmd-delete = "DELETE" SP string
CMD-認証= "AUTHENTICATE" SPのSASL-メカ[SP文字列] CMD-削除= "DELETE" SP文字列
cmd-find = "FIND" SP string
CMD-見つけ=はSP文字列を "FIND"
cmd-list = "LIST" [ SP string ]
CMD-リスト= "LIST" [SP文字列]
cmd-logout = "LOGOUT"
CMD-ログアウト= "LOGOUT"
cmd-noop = "NOOP"
NOOP-CMD = "NOOP"
cmd-reserve = "RESERVE" SP string SP string
CMDリザーブ= "RESERVE" SP文字列SP文字列
cmd-starttls = "STARTTLS"
CMD-STARTTLS = "STARTTLS"
cmd-update = "UPDATE"
CMD-更新= "UPDATE"
command = tag SP command-type CRLF
コマンド=タグSPコマンド型CRLF
command-type = cmd-activate / cmd-authenticate / cmd-delete / cmd-find / cmd-list / cmd-logout / cmd-noop / cmd-reserve / cmd-starttls / cmd-update
コマンド型= CMD-アクティブ/ CMD-認証/ CMD-削除/ CMD-見つける/ CMD-リスト/ CMD-ログアウト/コマンドNOOP / CMDリザーブ/ CMD-STARTTLS /コマンドの更新
response = tag SP response-type CRLF
応答=タグSP応答型CRLF
response-type = rsp-ok / rsp-no / rsp-bad / rsp-bye / rsp-mailbox / rsp-reserve / rsp-delete
応答型= RSP-OK / RSP-なし/ RSP-悪い/ RSP-BYE / RSP-メールボックス/ RSP-準備/ RSP-削除
rsp-bad = "BAD" SP string
RSP-悪い= "BAD" SP文字列
rsp-bye = "BYE" SP string
RSP-BYE = "BYE" SP文字列
rsp-mailbox = "MAILBOX" SP string SP string SP string
RSP-メールボックス= "MAILBOX" SP文字列SP文字列SP文字列
rsp-no = "NO" SP string
RSP-NO = "NO" SP文字列
rsp-ok = "OK" SP string
RSP-OK = "OK" SP文字列
rsp-reserve = "RESERVE" SP string SP string
RSP-予備= "RESERVE" SP文字列SP文字列
rsp-delete = "DELETE" SP string
RSP-削除= SP文字列を "DELETE"
sasl-mech = 1*ATOM-CHAR ; ATOM-CHAR is defined in [ACAP]
SASL-メカ= 1 * ATOM-CHAR。 ATOM-CHARは[ACAP]で定義されています
string = quoted / literal ; quoted and literal are defined in [ACAP]
文字列=リテラル/引用されました。引用されたとリテラルは、[ACAP]で定義されています
tag = 1*ATOM-CHAR ; ATOM-CHAR is defined in [ACAP]
タグ= 1 * ATOM-CHAR。 ATOM-CHARは[ACAP]で定義されています
This document defines the a URL scheme for the purposes of referencing MUPDATE resources, according to the requirements in [RFC2717]. This includes both MUPDATE servers as a whole, along with individual mailbox entries on a given MUPDATE server.
この文書では、[RFC2717]で要件に応じて、MUPDATEリソースを参照する目的のためのURLスキームを定義します。これは、与えられたMUPDATEサーバー上の個々のメールボックスのエントリとともに、全体としての両方MUPDATEサーバが含まれています。
There is no MIME type associated with these resources. It is intended that a URL consumer would either retrieve the MUPDATE record in question, or simply connect to the MUPDATE server running on the specified host. Note that the consumer will need to have authentication credentials for the specified host.
これらのリソースに関連付けられたMIMEタイプはありません。 URLの消費者が質問にMUPDATEレコードを取得、または単に指定されたホスト上で実行されているMUPDATEサーバーに接続しますいずれかが意図されています。消費者は、指定されたホストの認証資格情報を持っている必要がありますので注意してください。
The MUPDATE URL scheme is similar to the IMAP URL scheme [IMAP-URL]. However, it only takes one of two possible forms:
MUPDATE URLスキームは、IMAP URLスキーム[IMAP-URL]に類似しています。しかし、それだけで2つの形式のいずれかを取ります。
mupdate://<iserver>/ mupdate://<iserver>/<mailbox>
mupdate：// <iserver> / mupdate：// <iserver> / <メールボックス>
The first form refers to a MUPDATE server as a whole, the second form indicates both the server and a mailbox to run a FIND against once authenticated to the server. Note that part of <iserver> may include username and authentication information along with a hostname and port.
第一の形態は、第2の形態は、サーバと一度サーバに認証に対してFINDを実行するために、メールボックスの両方を示し、全体としてMUPDATEサーバを指します。 <iserver>の一部は、ホスト名とポートに加えて、ユーザー名と認証情報を含む場合があります。
URL scheme name: "mupdate"
URLスキーム名： "mupdate"
URL scheme syntax:
URLスキームの構文：
This defines the MUPDATE URL Scheme in [ABNF]. Terminals from the BNF of IMAP URLs [IMAP-URL] are also used.
これは、[ABNF]でMUPDATE URLスキームを定義します。 IMAPのURL [IMAP-URL]のBNFからの端子も使用されています。
mupdateurl = "mupdate://" iserver "/" [ enc_mailbox ] ; iserver and enc_mailbox are as defined in [IMAP-URL]
mupdateurl = "mupdate：//" iserver "/" [enc_mailbox]。 [IMAP-URL]で定義されているようiserverとenc_mailboxがあります
Character encoding considerations:
文字エンコーディングの考慮事項：
Identical to those described in [IMAP-URL] for the appropriate terminals.
適切な端末の[IMAP-URL]に記載のものと同じ。
Intended Usage:
使用目的：
The form of the URL without an associated mailbox is intended to designate a MUPDATE server only. If a mailbox name is included in the URL, then the consumer is expected to execute a FIND command for that mailbox on the specified server.
関連するメールボックスのないURLの形式はのみMUPDATEサーバを指定することを意図しています。メールボックス名がURLに含まれている場合、消費者は、指定されたサーバー上のメールボックスのFINDコマンドを実行することが期待されます。
Applications and/or protocols which use this URL scheme name:
このURLのスキーム名を使用するアプリケーションおよび/またはプロトコル：
The protocol described in this document.
この文書に記載されているプロトコル。
Interoperability Considerations:
相互運用性に関する注意事項：
None.
無し。
Security Considerations:
セキュリティの考慮事項：
Users of the MUPDATE URL Scheme should review the security considerations that are discussed in [IMAP-URL]. In particular, the consequences of including authentication mechanism information in a URL should be reviewed.
MUPDATE URLスキームのユーザは、[IMAP-URL]で議論されているセキュリティ上の考慮事項を確認する必要があります。具体的には、URLで認証機構の情報を含めての結果は見直されるべきです。
Relevant Publications:
関連出版物：
This document and [IMAP-URL].
このドキュメントと[IMAP-URL]。
Author, Change Controller, and Contact for Further Information:
著者、変更コントローラ、および詳細情報のための連絡先：
Author of this document.
本書の著者。
While no unauthenticated users may make modifications or even perform searches on the database, it is important to note that this specification assumes no protections of any type for authenticated users.
非認証ユーザーが変更をしない、あるいはデータベースで検索を実行することができるが、この仕様は、認証されたユーザーのために、あらゆるタイプのない保護を前提としていないことに注意することが重要です。
All authenticated users have complete access to the database. For this reason it is important to ensure that accounts that are making use of the database are well secured.
すべての認証済みユーザーは、データベースへの完全なアクセス権を持っています。この理由は、データベースを利用しているアカウントが十分に確保されていることを確認することが重要です。
A more secure deployment might have all read only access go through a slave, and only have accounts which need write access use the master. This has the disadvantage of a marginally longer time for updates to reach the clients.
より安全な展開は、すべてのスレーブを通過し、アクセスのみのマスターを使用するを書く必要があるアカウントを持っているだけで読み取りアクセス権を持っているかもしれません。これにより、クライアントに到達するための更新のためのわずかに長い時間という欠点があります。
The protocol assumes that all authenticated users are cooperating to maintain atomic operations. Therefore, all new mailboxes SHOULD be RESERVEd before they are ACTIVATEd, despite the fact that the protocol does not require this, and it is therefore possible for a set of participants which do not obey the provided locking to create an inconsistent database. RESERVEing the mailbox first is not required to perform an activate because this behavior simplifies synchronization with the actual location of the mailboxes.
このプロトコルは、すべての認証済みユーザーがアトミック操作を維持するために協力していることを前提としています。彼らは活性化される前に、したがって、すべての新しいメールボックスは、プロトコルがこれを必要としないという事実にもかかわらず、予約する必要があり、それが一貫性のないデータベースを作成するために設けられたロックに従わない参加者の集合のためのことが可能です。この現象は、メールボックスの実際の位置との同期を簡素化するため、メールボックスをRESERVEingする最初のアクティブ化を実行するために必要とされません。
The IANA has assigned TCP port number 3905 to "mupdate".
IANAは「mupdate」にTCPポート番号3905が割り当てられています。
The IANA has registered a URL scheme for the MUPDATE protocol, as defined in section 6.1 of this document.
このドキュメントのセクション6.1で定義されているIANAは、MUPDATEプロトコルのURLスキームを登録しています。
IANA has registered a GSSAPI service name of "mupdate" for the MUPDATE protocol in the registry maintained at:
IANAがで維持、レジストリ内MUPDATEプロトコルの「mupdate」のGSSAPIサービス名を登録しています：
http://www.iana.org/assignments/gssapi-service-names
ｈっｔｐ：／／ｗっｗ。いあな。おｒｇ／あっしｇんめんｔｓ／ｇっさぴーせｒゔぃせーなめｓ
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETFは、そのような権限下で、ライセンスがたりないかもしれない可能性があるためにどの本書または程度に記載されている技術の実装や使用に関係すると主張される可能性があります任意の知的財産やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能。また、そうした権利を特定するために取り組んできたことを表していないん。スタンダードトラックおよび標準関連文書における権利に関するIETFの手続きの情報は、BCP-11に記載されています。権利の主張のコピーは、出版のために利用可能とライセンスの保証が利用できるようにする、または本仕様の実装者または利用者が、そのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますIETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、その注意にこの標準を実践するために必要な場合があり技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 IETF専務に情報を扱ってください。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[IMAP] Crispin, M., "Internet Message Access Protocol - Version 4", RFC 3501, March 2003.
[IMAP]クリスピン、M.、 "インターネットメッセージアクセスプロトコル - バージョン4"、RFC 3501、2003年3月。
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[ABNF]クロッカー、D.、エド。そして、P. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 2234、1997年11月。
[MIME] Freed, N. and N. Bornstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[MIME]解放され、N.とN. Bornstein、 "多目的インターネットメール拡張（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[IMAP-ACL] Myers, J., "IMAP4 ACL extension", RFC 2086, January 1997.
[IMAP-ACL]マイヤーズ、J.、 "IMAP4 ACL拡張"、RFC 2086、1997年1月。
[SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[SASL]マイヤーズ、J.、 "簡易認証セキュリティー層（SASL）"、RFC 2222、1997年10月。
[IMAP-URL] Newman, C., "IMAP URL Scheme", RFC 2192, September 1997.
[IMAP-URL]ニューマン、C.、 "IMAP URLスキーム"、RFC 2192、1997年9月。
[ACAP] Newman, C. and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997.
[ACAP]ニューマン、C.及びJ.マイヤーズ、 "ACAP - アプリケーション構成アクセスプロトコル"、RFC 2244、1997年11月。
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[TLS]ダークス、T.とC.アレン、 "TLSプロトコルバージョン1.0"、RFC 2246、1999年1月。
[POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[POP3]マイヤーズ、J.とM.ローズ、 "ポストオフィスプロトコル - バージョン3"、STD 53、RFC 1939、1996年5月。
[RFC2717] Petke, R. and I. King, "Registration Procedures for URL Scheme Names", BCP 35, RFC 2717, November 1999.
[RFC2717] Petke、R.とI.キング、BCP 35、RFC 2717、1999年11月 "URLスキーム名の登録手順"。
Lawrence Greenfield and Ken Murchison, for a great deal of input on both the protocol and the text of the documents.
プロトコルおよびドキュメントのテキストの両方の入力が大量のためのローレンス・グリーンフィールドとケンマーチソン、。
Robert Siemborski Carnegie Mellon, Andrew Systems Group Cyert Hall 207 5000 Forbes Avenue Pittsburgh, PA 15213
ロバートSiemborskiカーネギーメロン、アンドリュー・システムズ・グループCyertホール207 5000フォーブス・アベニューピッツバーグ、PA 15213
Phone: (412) 268-7456 EMail: rjs3+@andrew.cmu.edu
電話：（412）268-7456 Eメール：rjs3+@andrew.cmu.edu
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
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 assignees.
上記の制限は永続的なものであり、インターネットソサエティもしくはその継承者や譲渡者によって取り消されることはありません。
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機能のための基金は現在、インターネット協会によって提供されます。