[要約] RFC 3656は、分散型メールボックスデータベースプロトコルであるMUPDATEについての要約です。このプロトコルの目的は、複数のメールボックスサーバー間でメールボックスデータを同期し、一貫性を保つことです。
Network Working Group R. Siemborski
Request for Comments: 3656 Carnegie Mellon University
Category: Experimental December 2003
The Mailbox Update (MUPDATE) Distributed Mailbox Database Protocol
メールボックスアップデート（MUPDATE）分散メールボックスデータベースプロトコル
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.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（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.
Mailbox Update（MUPDATE）プロトコルにより、インターネットメッセージアクセスプロトコル（IMAP）または郵便局プロトコルのグループ - バージョン3（POP3）サーバーが統合されたメールボックス名空間で機能できます。このドキュメントは、そのプロトコルの参照ガイドとして機能することを目的としています。
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]サーバーがあるアーキテクチャをサポートするには、Atomic Mailbox操作を提供し、データベースの一貫性について十分な保証を提供する必要があります。
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].
このドキュメントの「必須」、「必須」、「必須」、「必要」、「推奨」、「推奨」、「必要」、「必要はない」、「必須」、「必要はない」、「必要はありません」は、BCP 14、RFC 2119 [キーワード]で定義されていると解釈されます。。
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.
文字通りの外では、クライアントとサーバーの両方が、少なくとも1024オクテット（後続のCRおよびLF文字を含む）のライン長さをサポートする必要があります。長さの長さの行を送信する必要がある場合、実装はリテラルを使用してそうする必要があります。
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}として、CRLF（10のオクテットカウントを持つリテラル）として表されます。
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応答の後、必須の実装定義文字列があります。この応答は、更新コマンドに応じて与えられた場合のストリーミング更新モードの開始も示しています。
Example:
例：
C: N01 NOOP
S: N01 OK "NOOP Complete"
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応答は、操作がサーバーによって明示的に拒否されたか、その他の失敗が失敗したことを示します。拒否の理由を説明する必要がある応答がない後、必須の実装定義文字列があります。
Example:
例：
C: A01 AUTHENTICATE "PLAIN"
S: A01 NO "PLAIN is not a supported SASL mechanism"
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 "*".
タグ付きの悪い応答は、クライアントからのコマンドを解析または理解できなかったことを示しています。エラーに関する追加情報を提供するために、悪い応答の後に必須の実装定義文字列があります。特定のコマンドのタグが何であるかが不明な場合は、攻撃されていない悪い応答が許可されていることに注意してください（たとえば、MUPDATEサーバーによって空白行が受信された場合、攻撃されていない悪い応答が生成される可能性があります）。未編成の応答の場合、タグは「*」に置き換える必要があります。
Example:
例：
C: C01 SELECT "INBOX"
S: C01 BAD "This is not an IMAP server"
C:
S: * BAD "Need Command"
3.4. Response: BYE
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"
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.
タグ付きリザーブ応答は、発見、リスト、または更新コマンドに応じてのみ指定できます。2つのパラメーターが含まれています。予約されているメールボックスの名前（[IMAP]で指定されているMUTF-7エンコード）と、データベースを使用しているクライアントによって内容が定義されている場所の文字列ですが、この文字列の形式は、メールボックスを保存しているサーバーのホスト名です。
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リザーブ "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.
タグ付きメールボックスの応答は、発見、リスト、または更新コマンドに応じてのみ指定できます。3つのパラメーターが含まれます。メールボックスの名前、ロケーション文字列（予備）、およびメールボックスのIMAP ACL [IMAP-ACL]を指定するクライアント定義の文字列です。このメッセージは、指定されたメールボックスにクライアントがアクセスできることを示しています。
Example:
例：
S: U01 MAILBOX "internet.bugtraq" "mail2.example.org" "anyone rls"3.7. Response: DELETE
S：U01 Mailbox "Internet.Bugtraq" "Mail2.example.org" "neveyny rls" 3.7。応答：削除します
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).
タグ付き削除応答は、更新コマンドに応じてのみ指定でき、更新コマンドへのOK応答が指定される前に指定されないでください。これには、スレーブのデータベースから削除する必要があるメールボックスの単一のパラメーターが含まれています。この応答は、指定されたメールボックスがデータベースの名前空間に存在しなくなったことを示しており、アクティブ、予約、または存在しないメールボックス名に与えられる可能性があります。（実装は、存在しないメールボックスの削除応答を発行するべきではありません）。
Example:
例：
S: U01 DELETE "user.rjs3.sent-mail-jan-2002"
S：u01「user.rjs3.sent-mail-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メカニズムのスペース分離リストを含める行が含まれている必要があります。メカニズム名は原子として送信されます。サーバーは、利用可能なメカニズムを宣伝しない場合があります（認証が発生する前にstartTLを完了する必要があることを示すため）。StartTLSがサーバーによってサポートされていない場合、行に少なくとも1つのメカニズムを含める必要があります。
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)"
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.
以下は、クライアントがMUPDATEサーバーに送信できる有効なコマンドです。認証、アクティブ化、非アクティブ化、削除、検索、リスト、ログアウト、リザーブ、startTLS、および更新です。
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コマンドが成功する前に、サーバーは認証、StartTLS、およびログアウトを除くコマンドを受け入れてはなりません（他のすべてのコマンドに対して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.
Activateコマンドには、メールボックス名、その場所、およびACLの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または位置情報を更新するためにも使用できます。アクティブ化コマンドが成功するには、メールボックスが予約される（またはデータベースに存在する）要件ではないことに注意してください。実装は、データベースの現在の状態とデータベースの同期を促進するため、この動作を許可する必要があります。
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]メカニズムを示す文字列です。2番目は、オプションのbase64エンコード（[MIME]のセクション6.8で定義されている）を含む文字列が最初に送信されます。
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ブロブはすべて、ワイヤー間で送信する必要があります。Base64エンコード形式で、その後にCRとLFの組み合わせが必要です。彼らは文字列としてエンコードしてはなりません。
Clients may cancel authentication by sending a * followed by a CR and LF.
クライアントは、Aを送信して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応答の最後にCRとLFの組み合わせに続いて使用する必要があります（つまり、クライアントの次のコマンドから始まる）セッションごとに1つの成功した認証コマンドのみが発行される場合があります。
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.
非アクティブ化コマンドは、メールボックス名とロケーションデータの2つのパラメーターを採用します。メールボックスは既に存在し、MUPDateサーバーでアクティブ化する必要があります。サーバーがOKで応答した場合、メールボックス名は予備の状態に移動されました。サーバーがNOに応答した場合、メールボックス名は移動されていません（たとえば、メールボックスはまだアクティブではありませんでした）。メールボックスについて知られているACL情報は、非アクティブ化が成功したときに失われる可能性があります。このコマンドを奴隷に発行してはなりません。
Example:
例：
C: A01 DEACTIVATE "user.rjs3.new" "mail3.example.org!u4"
S: A01 OK "Mailbox Reserved."
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コマンドには、データベースの名前空間から削除されるメールボックス名が1つのパラメーターのみが表示されます。メールボックスが存在しない場合、サーバーは応答なしで提供する必要があります。このコマンドは、スレーブサーバーに発行されてはなりません。
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"
Example (mailbox is reserved):
例（メールボックスは予約されています）：
C: F01 FIND "user.rjs3"
S: F01 RESERVE "user.rjs3" "mail4.example.org"
S: F01 OK "Search Complete"
4.6. Command: LIST
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コマンドには、レコードの位置フィールドと一致させるためのプレフィックスである単一のオプションパラメーターが表示されます。パラメーターがなければ、リストはデータベース内のすべてのレコードを返します。
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.
一致する各メールボックスについて、メールボックスまたは予備の応答（該当する場合）のいずれかがクライアントに送信されます。すべての応答が完了すると、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"
The LOGOUT command tells the server to close the connection. Its only valid response is the BYE response. The LOGOUT command takes no parameters.
ログアウトコマンドは、接続を閉じるようにサーバーに指示します。その唯一の有効な応答は、さようなら応答です。ログアウトコマンドにはパラメーターがありません。
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コマンドにはパラメーターがありません。クライアントが認証されている場合、その唯一の許容可能な応答は大丈夫です。サーバーが接続上に持っている可能性のあるアイドルタイムアウトは、このコマンドの受領時にリセットする必要があります。
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.
更新コマンドが発行された後にこのコマンドが発行された場合、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.
リザーブコマンドは、予備のデータとロケーションデータのメールボックス名、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."
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の前に機能リストを変更する中間攻撃から保護するために必要です。また、レイヤーで利用可能な新しいSASLメカニズム（またはその他の機能）を宣伝するために必要です。クライアントは、キャッシュされた機能情報を破棄し、新しい情報に置き換える必要があります。
After the a successful STARTTLS command, the server SHOULD return a NO response to additional STARTTLS commands.
StartTLSコマンドが成功した後、サーバーは追加のstartTLSコマンドへのNO応答を返す必要があります。
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コマンドに対する悪い応答を返す必要があります。
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)"
4.11. Command: UPDATE
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.
更新コマンドは、スレーブがマスターからの更新ストリームを初期化する方法です（ただし、このコマンドをスレーブに発行することも有効です）。コマンドに応じて、サーバーはデータベース内のすべてのメールボックスのリスト（パラメーターレスリストコマンドと同じ結果）に続いてOK応答を返します。この時点から、マスターデータベースに更新が発生する場合はいつでも、30秒以内に更新をスレーブにストリーミングする必要があります。つまり、該当する場合にリザーブ、メールボックス、または削除を送信します。
After a client has issued an UPDATE command, it may only issue NOOP and LOGOUT commands for the remainder of the session.
クライアントが更新コマンドを発行した後、セッションの残りの部分についてNOOPおよびログアウトコマンドのみを発行することができます。
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"
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]で指定されているように、拡張されたBackus-Naurフォーム（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 = "activate" sp string sp string sp string
cmd-authenticate = "AUTHENTICATE" SP sasl-mech [ SP string ] cmd-delete = "DELETE" SP string
cmd-authenticate = "Authenticate" sp sasl-mech [sp string] cmd-delete = "delete" sp string
cmd-find = "FIND" SP string
cmd-find = "sp string" sp string
cmd-list = "LIST" [ SP string ]
cmd-list = "list" [sp string]
cmd-logout = "LOGOUT"
cmd-noop = "NOOP"
cmd-reserve = "RESERVE" SP string SP string
cmd-reserve = "リザーブ" sp string sp string
cmd-starttls = "STARTTLS"
cmd-update = "UPDATE"
command = tag SP command-type CRLF
command-type = cmd-activate / cmd-authenticate / cmd-delete /
cmd-find / cmd-list / cmd-logout / cmd-noop /
cmd-reserve / cmd-starttls / cmd-update
response = tag SP response-type CRLF
response-type = rsp-ok / rsp-no / rsp-bad / rsp-bye / rsp-mailbox /
rsp-reserve / rsp-delete
rsp-bad = "BAD" SP string
rsp-bad = "bad" sp文字列
rsp-bye = "BYE" SP string
rsp-bye = "bye" sp string
rsp-mailbox = "MAILBOX" SP string SP string SP string
rsp-mailbox = "mailbox" sp string sp string sp string
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 string sp string
rsp-delete = "DELETE" SP string
rsp-delete = "delete" sp文字列
sasl-mech = 1*ATOM-CHAR
; ATOM-CHAR is defined in [ACAP]
string = quoted / literal ; quoted and literal are defined in [ACAP]
string = quoted / literal;引用され、文字通りは[acap]で定義されています
tag = 1*ATOM-CHAR
; ATOM-CHAR is defined in [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リソースを参照する目的でA 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つの可能な形式のいずれかの1つだけが必要です。
mupdate://<iserver>/
mupdate://<iserver>/<mailbox>
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.
最初のフォームはMUPDateサーバー全体を指し、2番目のフォームはサーバーとメールボックスの両方を示し、サーバーに認証された一度に対して検索を実行します。<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のBNFからの端子[IMAP-URL]も使用されます。
mupdateurl = "mupdate://" iserver "/" [ enc_mailbox ] ; iserver and enc_mailbox are as defined in [IMAP-URL]
mupdateurl = "mupdate：//" iserver "/" [enc_mailbox];iServerとenc_mailboxは[imap-url]で定義されています
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.
プロトコルは、すべての認証されたユーザーが原子運用を維持するために協力していると想定しています。したがって、プロトコルがこれを必要としないという事実にもかかわらず、すべての新しいメールボックスはアクティブ化される前に予約する必要があります。したがって、提供されたロックに従わない参加者のセットが一貫性のないデータベースを作成する可能性があります。この動作により、メールボックスの実際の位置と同期が簡素化されるため、アクティブ化を実行するために最初にメールボックスを予約する必要はありません。
The IANA has assigned TCP port number 3905 to "mupdate".
IANAは、TCPポート番号3905を「Mupdate」に割り当てました。
The IANA has registered a URL scheme for the MUPDATE protocol, as defined in section 6.1 of this document.
IANAは、このドキュメントのセクション6.1で定義されているように、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
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.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[IMAP] Crispin, M., "Internet Message Access Protocol - Version 4", RFC 3501, March 2003.
[IMAP] Crispin、M。、「インターネットメッセージアクセスプロトコル -バージョン4」、RFC 3501、2003年3月。
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[ABNF] Crocker、D.、ed。および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] Freed、N。and N. Bornstein、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[IMAP-ACL] Myers, J., "IMAP4 ACL extension", RFC 2086, January 1997.
[IMAP-ACL] Myers、J。、「IMAP4 ACL Extension」、RFC 2086、1997年1月。
[SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[SASL] Myers、J。、「Simple Authentication and Security Layer（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] Newman、C。and J. Myers、「ACAP-アプリケーション構成アクセスプロトコル」、RFC 2244、1997年11月。
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[TLS] Dierks、T。およびC. Allen、「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] Myers、J。and M. Rose、「郵便局プロトコル - バージョン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. King、「URLスキーム名の登録手順」、BCP 35、RFC 2717、1999年11月。
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
ロバート・シエンボルスキー・カーネギー・メロン、アンドリュー・システムズ・グループサイエート・ホール207 5000フォーブス・アベニュー・ピッツバーグ、ペンシルバニア州15213
Phone: (412) 268-7456
EMail: rjs3+@andrew.cmu.edu
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。