RFC3656 日本語訳
3656 The Mailbox Update (MUPDATE) Distributed Mailbox DatabaseProtocol. R. Siemborski. December 2003. (Format: TXT=35509 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Siemborski Request for Comments: 3656 Carnegie Mellon University Category: Experimental December 2003
Siemborskiがコメントのために要求するワーキンググループR.をネットワークでつないでください: 3656年のカーネギーメロン大学カテゴリ: 実験的な2003年12月
The Mailbox Update (MUPDATE)
Distributed Mailbox Database Protocol
メールボックスアップデート(MUPDATE)はメールボックスデータベースプロトコルを分配しました。
Status of this Memo
この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.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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)プロトコルはインターネットMessage Accessプロトコル(IMAP)かポストオフィスプロトコルのグループを許容します--統一されたメールボックス名前空間で機能するバージョン3(POP3)サーバ。 このドキュメントが参照ガイドとしてそのプロトコルに勤めることを意図します。
Siemborski Experimental [Page 1] RFC 3656 MUPDATE Distributed Mailbox Database Protocol December 2003
メールボックスデータベースプロトコル2003年12月に分配されたSiemborskiの実験的な[1ページ]RFC3656MUPDATE
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . 3 2。 概要. . . . . . . . . . . . . . . . . . . . . . 3 2.1について議定書の中で述べてください。 原子. . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2。 ストリング. . . . . . . . . . . . . . . . . . . . . . . . 4 3。 サーバ応答. . . . . . . . . . . . . . . . . . . . . . 4 3.1。 応答: .53.2を承認してください。 応答: .53.3がありません。 応答: 悪い.53.4。 応答: さようなら. . . . . . . . . . . . . . . . . . . . . 6 3.5。 応答: .63.6を予約してください。 応答: メールボックス. . . . . . . . . . . . . . . . . . . 6 3.7。 応答: .73.8を削除してください。 サーバ能力応答。 . . . . . . . . . . . . . . 7 4. クライアントコマンド. . . . . . . . . . . . . . . . . . . . . . . 8 4.1。 コマンド: .84.2を活性化してください。 コマンド: .84.3を認証してください。 コマンド: .94.4を非活性化してください。 コマンド: .94.5を削除してください。 コマンド: .94.6を見つけてください。 コマンド: .104.7を記載してください。 コマンド: .104.8にログアウトしてください。 コマンド: NOOP. . . . . . . . . . . . . . . . . . . . . 10 4.9。 コマンド: 蓄え。 . . . . . . . . . . . . . . . . . . . 10 4.10. コマンド: STARTTLS. . . . . . . . . . . . . . . . . . . 11 4.11。 コマンド: .125をアップデートしてください。 MUPDATEの正式な構文. . . . . . . . . . . . . . . . . . . . 12 6。 MUPDATE URL体系。 . . . . . . . . . . . . . . . . . . . . . 14 6.1. MUPDATE URL体系登録用紙。 . . . . . . . . . 14 7. セキュリティ問題. . . . . . . . . . . . . . . . . . . 15 8。 IANA問題. . . . . . . . . . . . . . . . . . . . . 16 9。 知的所有権はまっすぐになります。 . . . . . . . . . . . . . . . . 16 10. 参照。 . . . . . . . . . . . . . . . . . . . . . . . . . 17 10.1. 引用規格。 . . . . . . . . . . . . . . . . . 17 10.2. 有益な参照。 . . . . . . . . . . . . . . . . 17 11. 承認. . . . . . . . . . . . . . . . . . . . . . . 18 12。 作者のアドレス。 . . . . . . . . . . . . . . . . . . . . . . 18 13. 完全な著作権宣言文。 . . . . . . . . . . . . . . . . . . 19
Siemborski Experimental [Page 2] RFC 3656 MUPDATE Distributed Mailbox Database Protocol December 2003
メールボックスデータベースプロトコル2003年12月に分配されたSiemborskiの実験的な[2ページ]RFC3656MUPDATE
1. Introduction
1. 序論
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].
キーワード、「必須、「必須NOT」が「必要です」、“SHOULD"、「」、「推薦された」、および「」 これが記録するコネはBCP14、RFC2119[キーワード]で定義されるように解釈されることであるかもしれないべきです」。
In examples, "C:" and "S:" indicate lines sent by the client and server respectively.
例で「C:」 そして、「S:」 クライアントとサーバによってそれぞれ送られた系列を示してください。
2. Protocol Overview
2. プロトコル概要
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.
接続の後に、すべてのクライアントからサーバまでのコマンドが英数字のストリングである関連ユニークなタグを持たなければなりません。 コマンドはクライアントからサーバまでpipelinedされるかもしれません(次のコマンドを送る前に、すなわち、クライアントは応答を待つ必要はありません)。 サーバはコマンドを実行しなければなりません。しかしながら、オーダーでは、それらを受け取りました。
If the server supports an inactivity login timeout, it MUST be at least 15 minutes.
サーバが、不活発ログインがタイムアウトであるとサポートするなら、少なくとも15分でなければなりません。
Siemborski Experimental [Page 3] RFC 3656 MUPDATE Distributed Mailbox Database Protocol December 2003
メールボックスデータベースプロトコル2003年12月に分配されたSiemborskiの実験的な[3ページ]RFC3656MUPDATE
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キャラクタを含んでいて)。 より長い長さの台詞を伝えなければならないなら、実装は、そうするのにリテラルを利用しなければなりません。
2.1. Atoms
2.1. 原子
An atom consists of one or more alphanumeric characters. Atoms MUST be less than 15 octets in length.
原子は1つ以上の英数字から成ります。 原子は長さが15未満の八重奏であるに違いありません。
2.2. Strings
2.2. ストリング
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順序に従うのを示す任意のプラスサイン)の数、」 この応答のための「プラスサインが省略されるなら(連動しているリテラル)、受信側はa」+碁を前もって送らなければならなく」応答、および送付側がそうしなければならない待ち。 サーバはatleast4096八重奏のリテラルをサポートしなければなりません。
Strings that are sent from server to client SHOULD NOT be in the synchronized literal format.
サーバからクライアントSHOULD NOTに送られるストリングは連動している文字通りの形式においてそうです。
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.
引用文字列はゼロか7ビット以上のキャラクタの系列です、CR、LF、および二重引用文を除いて(<、「>)、各端の二重引用文字、」
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(0の八重奏カウントがあるリテラル)が続かれている、」
3. Server Responses
3. サーバ応答
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つ以上のタグ付けをされた応答を受けるかもしれません。サーバから応答を引き出したコマンドと同じタグは各応答に先行します。
Siemborski Experimental [Page 4] RFC 3656 MUPDATE Distributed Mailbox Database Protocol December 2003
メールボックスデータベースプロトコル2003年12月に分配されたSiemborskiの実験的な[4ページ]RFC3656MUPDATE
3.1. Response: OK
3.1. 応答: OK
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: 「NOOPは完成する」N01OK
3.2. Response: NO
3.2. 応答: いいえ
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.
タグ付けをされたいいえ応答は、操作が明らかにサーバによって否定されたか、または別の方法で失敗されたのを示します。 いいえ応答の後に、義務的な実装で定義されたストリングがあります。SHOULDは否定の理由について説明します。
Example:
例:
C: A01 AUTHENTICATE "PLAIN" S: A01 NO "PLAIN is not a supported SASL mechanism"
C: A01は「平野」Sを認証します: A01 NOは「PLAINはサポートしているSASLメカニズムではありません」です。
3.3. Response: BAD
3.3. 応答: 悪い
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サーバで空白行を受け取るなら、それはuntagged BAD応答を生成することができます)untagged BAD応答が許容されていることに注意してください。 非タグ付けをされた応答の場合では、タグを「*」に取り替えるべきです。
Example:
例:
C: C01 SELECT "INBOX" S: C01 BAD "This is not an IMAP server" C: S: * BAD "Need Command"
C: C01は「受信トレイ」Sを選択します: C01 BAD「これはIMAPサーバではありません」C: S: * 悪い「必要性コマンド」
Siemborski Experimental [Page 5] RFC 3656 MUPDATE Distributed Mailbox Database Protocol December 2003
メールボックスデータベースプロトコル2003年12月に分配されたSiemborskiの実験的な[5ページ]RFC3656MUPDATE
3.4. Response: BYE
3.4. 応答: さようなら
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応答は、サーバが、接続を終えると決めたのを示します。 SHOULDが理由について説明するBYE応答の後の接続を終える義務的な実装で定義されたストリングがあります。 BYE応答を伝える直後サーバは接続を終えなければなりません。
Example:
例:
C: L01 LOGOUT S: L01 BYE "User Logged Out"
C: L01がログアウトする、S: 「ユーザはログアウトした」L01不戦勝
3.5. Response: RESERVE
3.5. 応答: 蓄え
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.
FIND、LIST、またはUPDATEコマンドに対応してタグ付けをされたRESERVE応答を与えるだけであるかもしれません。 それは2つのパラメタを含んでいます: 予約されている([IMAP]で指定されるようにコード化するmUTF-7で)メールボックスの名前とコンテンツがこのストリングの形式がメールボックスを保存しているサーバに関するホスト名であることがRECOMMENDEDですが、データベースを使用しているクライアントによって定義される位置のストリング。
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"
3.6. Response: MAILBOX
3.6. 応答: メールボックス
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、LIST、またはUPDATEコマンドに対応してタグ付けをされたMAILBOX応答を与えるだけであるかもしれません。 それは3つのパラメタを含んでいます: メールボックスの名前、位置のストリング(RESERVEのように)、およびクライアントはメールボックスのIMAP ACL[IMAP-ACL]を指定するストリングを定義しました。 このメッセージは、与えられたメールボックスにクライアントによってアクセスされる準備ができているのを示します。
Example:
例:
S: U01 MAILBOX "internet.bugtraq" "mail2.example.org" "anyone rls"
S: 「だれでもrlsする」U01 MAILBOX"internet.bugtraq""mail2.example.org"
Siemborski Experimental [Page 6] RFC 3656 MUPDATE Distributed Mailbox Database Protocol December 2003
メールボックスデータベースプロトコル2003年12月に分配されたSiemborskiの実験的な[6ページ]RFC3656MUPDATE
3.7. Response: DELETE
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).
タグ付けをされたDELETE応答はUPDATEコマンドに対応して与えるだけであるかもしれなく、UPDATEコマンドへのOK応答を与える前に与えてはいけません。 それはただ一つのパラメタ、奴隷のデータベースから削除されるべきであるメールボックスのものを含んでいます。 この応答は、与えられたメールボックスがもうデータベースの名前空間で存在しないのを示して、どんなメールボックス名のためにも与えられる、アクティブであるか、予約される、または実在しないかもしれません。 (実装SHOULD NOTは実在しないメールボックスのための応答をDELETEに発行しますが。)
Example:
例:
S: U01 DELETE "user.rjs3.sent-mail-jan-2002"
S: U01は「user.rjs3.sentメールjan-2002」を削除します。
3.8. Server Capability Response
3.8. サーバ能力応答
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がサーバによってサポートされないなら、系列は少なくとも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.
」 *はMUPDATEを承認します。「どんな認識されていない応答以前、もクライアントは」 応答を無視しなければなりません。
Siemborski Experimental [Page 7] RFC 3656 MUPDATE Distributed Mailbox Database Protocol December 2003
メールボックスデータベースプロトコル2003年12月に分配されたSiemborskiの実験的な[7ページ]RFC3656MUPDATE
Example:
例:
S: * AUTH KERBEROS_V4 GSSAPI S: * STARTTLS S: * OK MUPDATE "mupdate.example.org" "Cyrus" "v2.1.2" "(master)"
S: * AUTHケルベロス_V4 GSSAPI S: * STARTTLS S: * OK MUPDATE"mupdate.example.org"「サイラス」「v2.10.2インチ「(マスター)」」
4. Client Commands
4. クライアントコマンド
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サーバに送るかもしれない有効なコマンドです: 認証、動かす、非活性化してください、削除、掘り出し物、リストがログアウトする、NOOP、蓄え、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コマンドが起こる前に、サーバはAUTHENTICATE、STARTTLS、およびLOGOUT以外の少しのコマンドも受け入れてはいけません(SHOULDは他のすべてのコマンドのためのいいえ応答で返答します)。
4.1. Command: ACTIVATE
4.1. コマンド: 動かします。
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コマンドには、3つのパラメタがあります: メールボックス名、位置、およびそのACL。 奴隷サーバにこのコマンドを発行しなければなりません。
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コマンドのために予約されるという(データベースに存在さえしてください)要件でないというメモ、メールボックスの現状でデータベースの同期を容易にするとき、実装はこの振舞いを許容しなければなりません。
4.2. Command: AUTHENTICATE
4.2. コマンド: 認証します。
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で定義されるように)コード化されたクライアント第1が送るストリング含有です。
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.
クライアントは、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]メカニズムを実装するREQUIREDである、それらですが、SHOULDはできるだけ多くのメカニズムを実装します。
Siemborski Experimental [Page 8] RFC 3656 MUPDATE Distributed Mailbox Database Protocol December 2003
メールボックスデータベースプロトコル2003年12月に分配されたSiemborskiの実験的な[8ページ]RFC3656MUPDATE
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.
セキュリティ層が交渉されるなら、セッション単位で1つのうまくいっているAUTHENTICATEコマンドだけを発行してもよいサーバのOK応答(すなわち、クライアントの次のコマンドで、始まる)の終わりに直接CRとLF組み合わせに続いて、それは使用されるべきです。
4.3. Command: DEACTIVATE
4.3. コマンド: 非活性化してください。
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状態に動かされました。 サーバがいいえを反応させるなら、メールボックス名は動かされていません(例えば、メールボックスは既にアクティブではありませんでした)。 DEACTIVATEが成功するとき、メールボックスに関して知られているどんなACL情報も失われるかもしれません。 このコマンドを奴隷に発行してはいけません。
Example:
例:
C: A01 DEACTIVATE "user.rjs3.new" "mail3.example.org!u4" S: A01 OK "Mailbox Reserved."
C: A01が"user.rjs3.new"を非活性化する、「mail3.example.org!u4"S:」 A01は「予約されたメールボックス」を承認します。
4.4. Command: DELETE
4.4. コマンド: 削除します。
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コマンドは、データベースの名前空間から取り除くためにただ一つのパラメタだけ、メールボックス名を取ります。 メールボックスが存在していないなら、サーバSHOULDはいいえ応答を与えます。 奴隷サーバにこのコマンドを発行してはいけません。
4.5. Command: FIND
4.5. コマンド: 掘り出し物
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は、"user.rjs3.xyzzy"がSであることがわかります: F01OKは「完全な状態で、探されます」。
Example (mailbox is reserved):
例(メールボックスは予約されています):
C: F01 FIND "user.rjs3" S: F01 RESERVE "user.rjs3" "mail4.example.org" S: F01 OK "Search Complete"
C: F01が見つける、「user.rjs3"S:」 「F01蓄えの"user.rjs3""mail4.example.org」S: F01OKは「完全な状態で、探されます」。
Siemborski Experimental [Page 9] RFC 3656 MUPDATE Distributed Mailbox Database Protocol December 2003
メールボックスデータベースプロトコル2003年12月に分配されたSiemborskiの実験的な[9ページ]RFC3656MUPDATE
4.6. Command: LIST
4.6. コマンド: リスト
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.
合っている各メールボックスに関しては、MAILBOXか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はSを記載します: L01は"user.rjs3""mail4.example.org!u2"Sを予約します: L01 MAILBOX、「user.leg、」 「mail2.example.org!u1"はSを「lrswipcdaに、急いで歩きます」。 L01は「リスト完全な」Cを承認します: L02は「mail4.example.org!」を記載します。 S: L02は"user.rjs3""mail4.example.org!u2"Sを予約します: L02OKは「完全な状態で、記載します」。
4.7. Command: LOGOUT
4.7. コマンド: ログアウトしてください。
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コマンドはパラメタを全く取りません。
4.8. Command: NOOP
4.8. コマンド: NOOP
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です。 接続SHOULDのときにこれを受け取り次第サーバでリセットするどんなアイドルタイムアウトも命令します。
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を待つことによって最新であることを保証できます。 OKはすべてのNOOP時点で未定であったアップデートを送るまで戻ってはいけません。
4.9. Command: RESERVE
4.9. コマンド: 蓄え
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
RESERVEコマンドは2つのパラメタ(まさしくRESERVE応答のような)、メールボックス名を蓄えと位置のデータに取ります。 サーバがOKを反応させるなら、メールボックス名は予約されました。 サーバがいいえを反応させるならメールボックス名が予約されていない、(
Siemborski Experimental [Page 10] RFC 3656 MUPDATE Distributed Mailbox Database Protocol December 2003
メールボックスデータベースプロトコル2003年12月に分配されたSiemborskiの実験的な[10ページ]RFC3656MUPDATE
example, another server has reserved it already). This command MUST NOT be issued to a slave.
例、別のサーバが既にそれを予約した、) このコマンドを奴隷に発行してはいけません。
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が"user.rjs3.new"を予約する、「mail3.example.org!u4"S:」 R01は「予約されたメールボックス」を承認します。 クライアントが地方のメールボックスをする<は操作>Cを作成します: 「A01 ACTIVATE"user.rjs3.new"「mail3.example.org!u4"」rjs3 lrswipcda」S: A01は「動くメールボックス」を承認します。
4.10. Command: STARTTLS
4.10. コマンド: STARTTLS
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]交渉の始めを要求します。 交渉はCRLF直後OK応答で始まります。 クライアントが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]交渉の間、クライアント資格証明書を供給しても、サーバは非認証された州に残っています。 いったん首尾よく[TLS]クライアント資格証明書を交換すると、[SASL]EXTERNALメカニズムは認証するのにおいて使用されているかもしれません。 サーバはEXTERNALメカニズムをサポートするのに必要でないことに注意してください。
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.
aうまくいっているSTARTTLSが命令した後に、サーバSHOULDは追加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の広告を出してはいけません、そして、SHOULDは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: TLS層の>Sの下にS01 OK「現在のTLS交渉を始めてください」<TLS交渉、より遠いコマンドがあります: * AUTHケルベロス_V4 GSSAPI平野S: * OK MUPDATE"mupdate.example.org"「サイラス」「v2.10.2インチ「(マスター)」」
Siemborski Experimental [Page 11] RFC 3656 MUPDATE Distributed Mailbox Database Protocol December 2003
メールボックスデータベースプロトコル2003年12月に分配されたSiemborskiの実験的な[11ページ]RFC3656MUPDATE
4.11. Command: UPDATE
4.11. コマンド: アップデート
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応答があとに続いたデータベース(parameterless LISTコマンドと同じ結果)ですべてのメールボックスのリストを返します。 このポイントフォワードから、アップデートがマスターデータベースの心に浮かぶときはいつも、それは30秒以内にアップデートを奴隷に流さなければなりません。 それらが適切であるので、すなわち、それはRESERVE、MAILBOX、またはDELETEに応答を送るでしょう。
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はSをアップデートします: U01 MAILBOX、「user.leg、」 「mail2.example.org!u1"はSを「lrswipcdaに、急いで歩きます」。 U01 MAILBOX"user.rjs3""mail3.example.org!u4""rjs3 lrswipcda"S: U01 RESERVE"internet.bugtraq"、「mail1.example.org!u5"「lrsである人はだれも」S:」 「ストリーミングは始まる」というU01 OK<がいつか過ぎます、そして、別のクライアントは新しいメールボックス>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: U01は"user.leg.new"Sを削除します: 「NOOPは完成する」N01OK
5. MUPDATE Formal Syntax
5. MUPDATEの正式な構文
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]の指定されるとしてのAugmented BN記法(ABNF)記法を使用します。 これは[ABNF]のAppendix 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
SPストリングSPストリングSPが結ぶ=「動かすこと」をcmd動かしてください。
cmd-authenticate = "AUTHENTICATE" SP sasl-mech [ SP string ]
「認証=」SP sasl-mechをcmd認証してください。[SPストリング]
Siemborski Experimental [Page 12] RFC 3656 MUPDATE Distributed Mailbox Database Protocol December 2003
メールボックスデータベースプロトコル2003年12月に分配されたSiemborskiの実験的な[12ページ]RFC3656MUPDATE
cmd-delete = "DELETE" SP string
SPが結ぶ=「削除」をcmd削除してください。
cmd-find = "FIND" SP string
cmd-掘り出し物=「掘り出し物」SPストリング
cmd-list = "LIST" [ SP string ]
cmd-リストは「リスト」と等しいです。[SPストリング]
cmd-logout = "LOGOUT"
cmdログアウトしている=は「ログアウトします」。
cmd-noop = "NOOP"
cmd-noopは"NOOP"と等しいです。
cmd-reserve = "RESERVE" SP string SP string
cmd-蓄え=「蓄え」SPストリングSPストリング
cmd-starttls = "STARTTLS"
cmd-starttlsは「STARTTLS」と等しいです。
cmd-update = "UPDATE"
cmd-アップデート=「アップデート」
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-starttls/アップデートをcmd動かすか、cmd認証する、またはcmd削除します。
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削除するrsp rsp rsp rsp rsp-OK/ノー/悪い/rsp-不戦勝/メールボックス/蓄えと等しいです。
rsp-bad = "BAD" SP string
「悪い」SPが結ぶrsp悪い=
rsp-bye = "BYE" SP string
rsp-さようなら、=「さようなら」SPストリング
rsp-mailbox = "MAILBOX" SP string SP string SP string
rsp-メールボックス=「メールボックス」SPストリングSPストリングSPストリング
rsp-no = "NO" SP string
rsp-いいえ、=「いいえ」SPストリング
rsp-ok = "OK" SP string
rsp-OK=「OK」SPストリング
rsp-reserve = "RESERVE" SP string SP string
rsp-蓄え=「蓄え」SPストリングSPストリング
rsp-delete = "DELETE" SP string
SPが結ぶ=「削除」をrsp削除してください。
sasl-mech = 1*ATOM-CHAR
; ATOM-CHAR is defined in [ACAP]
sasl-mechは1*ATOM-CHARと等しいです。 ATOM-CHARは中で定義されます。[ACAP]
string = quoted / literal
; quoted and literal are defined in [ACAP]
ストリング=は/リテラルを引用しました。 引用、リテラルは中で定義されます。[ACAP]
Siemborski Experimental [Page 13] RFC 3656 MUPDATE Distributed Mailbox Database Protocol December 2003
メールボックスデータベースプロトコル2003年12月に分配されたSiemborskiの実験的な[13ページ]RFC3656MUPDATE
tag = 1*ATOM-CHAR
; ATOM-CHAR is defined in [ACAP]
=1*ATOM-CHARにタグ付けをしてください。 ATOM-CHARは中で定義されます。[ACAP]
6. MUPDATE URL Scheme
6. MUPDATE URL体系
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>
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.
最初のフォームは全体でMUPDATEサーバを示して、2番目のフォームは一度に対するFINDがサーバに認証したサーバと動かすメールボックスの両方を示します。<iserver>の一部がホスト名とポートと共にユーザ名と認証情報を含むかもしれないことに注意してください。
6.1. MUPDATE URL Scheme Registration Form
6.1. MUPDATE URL体系登録用紙
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 Schemeを定義します。 また、IMAP URL[IMAP-URL]のBNFからの端末は使用されます。
mupdateurl = "mupdate://" iserver "/" [ enc_mailbox ]
; iserver and enc_mailbox are as defined in [IMAP-URL]
「mupdateurlは「」 mupdate://iserver」/と等しい」[enc_メールボックス]。 _メールボックスが定義されるとしてあるiserverとenc[IMAP-URL]
Character encoding considerations:
文字符号化問題:
Identical to those described in [IMAP-URL] for the appropriate
terminals.
[IMAP-URL]で適切な端末に説明されたものと同じです。
Siemborski Experimental [Page 14] RFC 3656 MUPDATE Distributed Mailbox Database Protocol December 2003
メールボックスデータベースプロトコル2003年12月に分配されたSiemborskiの実験的な[14ページ]RFC3656MUPDATE
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 Schemeのユーザは[IMAP-URL]で議論するセキュリティ問題を見直すべきです。 特に、URLの認証機構情報を含む結果は調査されるべきです。
Relevant Publications:
関連刊行物:
This document and [IMAP-URL].
このドキュメントと[IMAP-URL。]
Author, Change Controller, and Contact for Further Information:
詳細に関する作者、変化コントローラ、および接触:
Author of this document.
このドキュメントの作者。
7. Security Considerations
7. セキュリティ問題
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.
より安全な展開で、すべての書き込み禁止アクセスがアクセス使用にマスターを書かなければならないアカウントを持つだけでありに奴隷を通って行くかもしれません。 これには、アップデートがクライアントに届くわずかに長い時間の不都合があります。
Siemborski Experimental [Page 15] RFC 3656 MUPDATE Distributed Mailbox Database Protocol December 2003
メールボックスデータベースプロトコル2003年12月に分配されたSiemborskiの実験的な[15ページ]RFC3656MUPDATE
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.
プロトコルは、原子操作を維持するためにすべての認証されたユーザが協力していると仮定します。 したがって、すべての新しいメールボックスSHOULD、ACTIVATEdになる前のRESERVEdになってください、プロトコルがこれを必要としないで、1セットの関係者にとって、したがって、どれがそうしないかが矛盾したデータベースを作成するために提供されたロックに従うのが、可能であるという事実にもかかわらず。 メールボックスが最初に実行している必要はないRESERVEing、この振舞いがメールボックスの実際の場所との同期を簡素化するので、動かします。
8. IANA Considerations
8. IANA問題
The IANA has assigned TCP port number 3905 to "mupdate".
IANAは"mupdate"へのポートNo.3905をTCPに割り当てました。
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
9. Intellectual Property Rights
9. 知的所有権
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はどんな知的所有権の正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。どんなそのような権利も特定するためにいずれも取り組みにしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、または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専務に情報を扱ってください。
Siemborski Experimental [Page 16] RFC 3656 MUPDATE Distributed Mailbox Database Protocol December 2003
メールボックスデータベースプロトコル2003年12月に分配されたSiemborskiの実験的な[16ページ]RFC3656MUPDATE
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[KEYWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[IMAP] Crispin, M., "Internet Message Access Protocol - Version
4", RFC 3501, March 2003.
[IMAP] クリスピン、M.、「バージョン4インチ、RFC3501、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"、1997年11月のRFC2234。
[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)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。
[IMAP-ACL] Myers, J., "IMAP4 ACL extension", RFC 2086, January 1997.
[IMAP-ACL] マイアーズ、J.、「IMAP4 ACL拡張子」、RFC2086、1997年1月。
[SASL] Myers, J., "Simple Authentication and Security Layer
(SASL)", RFC 2222, October 1997.
[SASL] マイアーズ、J.、「簡易認証とセキュリティは(SASL)を層にする」RFC2222、1997年10月。
[IMAP-URL] Newman, C., "IMAP URL Scheme", RFC 2192, September 1997.
[IMAP-URL] ニューマン、C.、「IMAP URL体系」、RFC2192、1997年9月。
[ACAP] Newman, C. and J. Myers, "ACAP -- Application
Configuration Access Protocol", RFC 2244, November 1997.
[ACAP] ニューマン、C.、およびJ.マイアーズ、「ACAP--アプリケーション構成アクセスは議定書を作る」、RFC2244、11月1997日
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[TLS] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。
10.2. Informative References
10.2. 有益な参照
[POP3] Myers, J. and M. Rose, "Post Office Protocol - Version
3", STD 53, RFC 1939, May 1996.
[POP3] マイアーズ、J.、およびM.ローズ、「郵便局は議定書を作ります--バージョン3インチ、STD53、RFC1939、1996年5月。」
[RFC2717] Petke, R. and I. King, "Registration Procedures for URL
Scheme Names", BCP 35, RFC 2717, November 1999.
[RFC2717]Petke、R.とI.キング、「URL体系名のための登録手順」BCP35、1999年11月のRFC2717。
Siemborski Experimental [Page 17] RFC 3656 MUPDATE Distributed Mailbox Database Protocol December 2003
メールボックスデータベースプロトコル2003年12月に分配されたSiemborskiの実験的な[17ページ]RFC3656MUPDATE
11. Acknowledgments
11. 承認
Lawrence Greenfield and Ken Murchison, for a great deal of input on both the protocol and the text of the documents.
プロトコルとドキュメントの原本の両方に関する大きな入力のためのローレンス・グリーンフィールドとケン・マーチソン。
12. Author's Address
12. 作者のアドレス
Robert Siemborski Carnegie Mellon, Andrew Systems Group Cyert Hall 207 5000 Forbes Avenue Pittsburgh, PA 15213
ロバート・Siemborskiカーネギー・メロン、フォーブズ・Avenueピッツバーグ、アンドリューSystemsグループCyertホール207 5000PA 15213
Phone: (412) 268-7456 EMail: rjs3+@andrew.cmu.edu
以下に電話をしてください。 (412) 268-7456 メールしてください: rjs3+@andrew.cmu.edu
Siemborski Experimental [Page 18] RFC 3656 MUPDATE Distributed Mailbox Database Protocol December 2003
メールボックスデータベースプロトコル2003年12月に分配されたSiemborskiの実験的な[18ページ]RFC3656MUPDATE
13. Full Copyright Statement
13. 完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or 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機能のための基金は現在、インターネット協会によって提供されます。
Siemborski Experimental [Page 19]
Siemborski実験的です。[19ページ]
一覧
スポンサーリンク
