RFC3503 日本語訳

Network Working Group                                        A. Melnikov
Request for Comments: 3503                 ACI Worldwide/MessagingDirect
Category: Standards Track                                     March 2003

コメントを求めるワーキンググループA.メリニコフの要求をネットワークでつないでください: 3503年のACI世界的な/MessagingDirectカテゴリ: 2003年の標準化過程行進

          Message Disposition Notification (MDN) profile for
                Internet Message Access Protocol (IMAP)

メッセージDisposition Notification(MDN)はインターネットMessage Accessのためにプロトコルの輪郭を描きます。(IMAP)

Status of this Memo

このMemoの状態

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Copyright(C)インターネット協会(2003)。 All rights reserved。

Abstract

要約

   The Message Disposition Notification (MDN) facility defined in RFC
   2298 provides a means by which a message can request that message
   processing by the recipient be acknowledged as well as a format to be
   used for such acknowledgements.  However, it doesn't describe how
   multiple Mail User Agents (MUAs) should handle the generation of MDNs
   in an Internet Message Access Protocol (IMAP4) environment.

RFC2298で定義されたMessage Disposition Notification(MDN)施設はメッセージが、受取人によるメッセージ処理が形式と同様にそのような承認に使用されると承諾されるよう要求できる手段を提供します。 しかしながら、それは複数のメール・ユーザー・エージェント(MUAs)がどうインターネットMessage Accessプロトコル(IMAP4)環境における、MDNsの世代を扱うべきであるかを説明しません。

   This document describes how to handle MDNs in such an environment and
   provides guidelines for implementers of IMAP4 that want to add MDN
   support to their products.

このドキュメントは、そのような環境でMDNsを扱う方法を説明して、それらの製品にMDNサポートを加えたがっているIMAP4のimplementersにガイドラインを供給します。

Melnikov                    Standards Track                     [Page 1]

RFC 3503                  MDN profile for IMAP                March 2003

メリニコフStandards Track[1ページ]RFC3503MDNはIMAPのために2003年3月の輪郭を描きます。

Table of Contents

目次

   1.  Conventions Used in this Document.............................  2
   2.  Introduction and Overview.....................................  2
   3.  Client behavior...............................................  3
       3.1. Client behavior when receiving a message.................  5
       3.2. Client behavior when copying a message...................  5
       3.3. Client behavior when sending a message...................  5
       3.4. Client behavior when saving a temporary message..........  5
   4.  Server behavior...............................................  5
       4.1. Server that supports arbitrary keywords..................  5
       4.2. Server that supports only $MDNSent keyword...............  5
       4.3. Interaction with IMAP ACL extension......................  6
   5.  Examples......................................................  6
   6.  Security Considerations.......................................  7
   7.  Formal Syntax.................................................  7
   8.  Acknowledgments...............................................  7
   9.  Normative References..........................................  8
   10. Author's Address..............................................  8
   11. Full Copyright Statement......................................  9

1. このDocumentのコンベンションUsed… 2 2. 序論と概要… 2 3. クライアントの振舞い… 3 3.1. メッセージを受け取るときのクライアントの振舞い… 5 3.2. メッセージをコピーするときのクライアントの振舞い… 5 3.3. メッセージを送るときのクライアントの振舞い… 5 3.4. 一時的なメッセージを保存するときのクライアントの振舞い… 5 4. サーバの振舞い… 5 4.1. 任意のキーワードをサポートするサーバ… 5 4.2. 唯一の$がMDNSentキーワードであるとサポートするサーバ… 5 4.3. IMAP ACL拡張子との相互作用… 6 5. 例… 6 6. セキュリティ問題… 7 7. 正式な構文… 7 8. 承認… 7 9. 標準の参照… 8 10. 作者のアドレス… 8 11. 完全な著作権宣言文… 9

1.  Conventions Used in this Document

1. このDocumentのコンベンションUsed

   "C:" and "S:" in examples show lines sent by the client and server
   respectively.

「C:」 そして、「S:」 例では、クライアントとサーバによってそれぞれ送られた系列を示してください。

   The keywords "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in
   this document when typed in uppercase are to be interpreted as
   defined in "Key words for use in RFCs to Indicate Requirement Levels"
   [KEYWORDS].

キーワード“MUST"、「必須NOT」“SHOULD"、「」 本書では中でタイプされると「5月」大文字は「RFCsにおける使用が要件レベルを示すキーワード」[キーワード]で定義されるように解釈されないべきであることですか?

2.  Introduction and Overview

2. 序論と概要

   This memo defines an additional [IMAP4] mailbox keyword that allows
   multiple Mail User Agents (MUAs) to know if a requested receipt
   notification was sent.

このメモは複数のメール・ユーザー・エージェント(MUAs)が、要求された領収書通知が送られたかどうかを知ることができる追加[IMAP4]メールボックスキーワードを定義します。

   Message Disposition Notification [MDN] does not require any special
   support of IMAP in the case where a user has access to the mailstore
   from only one computer and is using a single MUA.  In this case, the
   MUA behaves as described in [MDN], i.e., the MUA performs automatic
   processing and generates corresponding MDNs, it performs requested
   action and, with the user's permission, sends appropriate MDNs.  The
   MUA will not send MDN twice because the MUA keeps track of sent
   notifications in a local configuration.  However, that does not work
   when IMAP is used to access the same mailstore from different
   locations or is using different MUAs.

メッセージDisposition Notification[MDN]はユーザが1台のコンピュータだけからmailstoreに近づく手段を持って、独身のMUAを使用している場合における、IMAPの少しの特別なサポートも必要としません。 この場合、MUAが[MDN]で説明されるように振る舞って、すなわち、MUAが自動処理を実行して、対応するMDNsを生成して、それは、要求された動作を実行して、ユーザの許可と共に適切なMDNsを送ります。 MUAが地方の構成で送られた通知の動向をおさえるので、MUAは二度MDNを送らないでしょう。 しかしながら、IMAPが別の場所から同じmailstoreにアクセスするのに使用されるか、または異なったMUAsを使用しているとき、それは働いていません。

Melnikov                    Standards Track                     [Page 2]

RFC 3503                  MDN profile for IMAP                March 2003

メリニコフStandards Track[2ページ]RFC3503MDNはIMAPのために2003年3月の輪郭を描きます。

   This document defines a new special purpose mailbox keyword $MDNSent
   that must be used by MUAs.  It does not define any new command or
   response for IMAP, but describes a technique that MUAs should use to
   achieve interoperability.

このドキュメントはMUAsが使用しなければならない新しい専用メールボックスキーワード$MDNSentを定義します。 それは、IMAPのために少しの新しいコマンドや応答も定義しませんが、MUAsが相互運用性を達成するのに使用するはずであるテクニックについて説明します。

   When a client opens a mailbox for the first time, it verifies that
   the server is capable of storing the $MDNSent keyword by examining
   the PERMANENTFLAGS response code.  In order to support MDN in IMAP, a
   server MUST support either the $MDNSent keyword, or arbitrary message
   keywords.

クライアントが初めてメールボックスを開けると、それは、サーバがPERMANENTFLAGS応答コードを調べることによって$MDNSentキーワードを保存できることを確かめます。 IMAPでMDNをサポートするために、サーバは、$がMDNSentキーワード、または任意のメッセージキーワードであるとサポートしなければなりません。

3.  Client behavior

3. クライアントの振舞い

   The use of IMAP requires few additional steps in mail processing on
   the client side.  The following timeline modifies the timeline found
   in Section 4 of [MDN].

IMAPの使用はクライアント側でメール処理における追加数ステップしか必要としません。 以下のスケジュールは[MDN]のセクション4で見つけられたスケジュールを変更します。

   -- User composes message.

-- ユーザはメッセージを構成します。

   -- User tells MUA to send message.

-- ユーザは、メッセージを送るようにMUAに言います。

   -- MUA passes message to MSA (original recipient information passed
      along).  MUA [optionally] saves message to a folder for sent mail
      with $MDNSent flag set.

-- MUAはMSA(伝えられたオリジナルの受取人情報)にメッセージを通過します。 MUAは送られたメールのためにMDNSent旗が設定した$で[任意に]フォルダーにメッセージを保存します。

   -- MSA sends message to MTA.

-- MSAはメッセージをMTAに送ります。

   -- Final MTA receives message.

-- 最終的なMTAはメッセージを受け取ります。

   -- Final MTA delivers message to MUA (possibly generating DSN).

-- 最終的なMTAはメッセージをMUAに提供します(ことによるとDSNを生成して)。

   -- MUA logs into IMAP server, opens mailbox, verifies if mailbox can
      store $MDNSent keyword by examining PERMANENTFLAGS response.

-- MUAは、IMAPサーバにログインして、メールボックスを開けて、メールボックスがPERMANENTFLAGS応答を調べることによって$MDNSentキーワードを保存できるかどうか確かめます。

   -- MUA performs automatic processing and generates corresponding MDNs
      ("dispatched", "processed", "deleted", "denied" or "failed"
      disposition type with "automatic-action" and "MDN-sent-
      automatically" disposition modes) for messages that do not have
      $MDNSent keyword, or \Draft flag set. (*)

-- MUAが$MDNSentキーワードを持っていないメッセージのために、自動処理を実行して、対応するMDNsを生成するか(「急い」で、「自動動作」で「否定された」か「失敗した」気質タイプを「削除され」て、「処理し」て、気質モードを「-自動的にMDN送る」)、またはDraftが旗を揚げさせる\はセットしました。 (*)

   -- MUA sets the $MDNSent keyword for every message that required an
      automatic MDN to be sent, whether or not the MDN was sent.

-- MUAは自動MDNが送られるのを必要としたあらゆるメッセージのための$MDNSentキーワードを設定します、MDNを送ったか否かに関係なく。

   -- MUA displays a list of messages to user.

-- MUAはメッセージのリストをユーザに表示します。

   -- User selects a message and requests that some action be performed
      on it.

-- ユーザはメッセージと何らかの動作がそれに実行されるという要求を選択します。

Melnikov                    Standards Track                     [Page 3]

RFC 3503                  MDN profile for IMAP                March 2003

メリニコフStandards Track[3ページ]RFC3503MDNはIMAPのために2003年3月の輪郭を描きます。

   -- MUA performs requested action and, with user's permission, sends
      appropriate MDN ("displayed", "dispatched", "processed",
      "deleted", "denied" or "failed" disposition type with "manual-
      action" and "MDN-sent-manually" or "MDN-sent-automatically"
      disposition mode).  If the generated MDN is saved to a mailbox
      with the APPEND command, the client MUST specify the $MDNSent
      keyword in the APPEND.

-- MUAは要求された動作を実行して、ユーザの許可と共に適切なMDN(「マニュアル動作」と「手動で送られたMDN」か「自動的に送られたMDN」気質モードがある「表示された」か、「派遣された」か、「処理された」か、「削除された」か、「否定された」か「失敗した」気質タイプ)を送ります。 発生しているMDNがAPPENDコマンドでメールボックスへ取っておかれるなら、クライアントはAPPENDの$MDNSentキーワードを指定しなければなりません。

   -- MUA sets the $MDNSent keyword for all messages for which the user
      confirmed the dispatching of disposition (or was explicitly
      prohibited to do so).

-- MUAはユーザが気質(または、そうするために明らかに禁止された)の急ぎを確認したすべてのメッセージのための$MDNSentキーワードを設定します。

   -- User possibly performs other actions on message, but no further
      MDNs are generated.

-- ユーザはことによるとメッセージへの他の動作を実行しますが、一層のどんなMDNsも発生していません。

   (*) Note: MUA MUST NOT use \Recent flag as an indicator that it
       should send MDN, because according to [IMAP4], "If multiple
       connections have the same mailbox selected simultaneously, it is
       undefined which of these connections will see newly-arrived
       messages with \Recent set and which will see it without \Recent
       set".  Thus, using \Recent as an indicator will cause
       unpredictable client behavior with different IMAP4 servers.
       However, the client MAY use \Seen flag as one of the indicators
       that MDN must not be sent.  The client MUST NOT use any other
       standard flags, like \Draft or \Answered, to indicate that MDN
       was previously sent, because they have different well known
       meaning.  In any case, in the presence of the $MDNSent keyword,
       the client MUST ignore all other flags or keywords for the
       purpose of generating an MDN and MUST NOT send the MDN.

(*) 以下に注意してください。 MUA MUST NOTはRecentがMDNを送るべきであるというインディケータとして旗を揚げさせる\を使用します、[IMAP4]に従って「複数の接続が同時に同じメールボックスを選択させるなら、これらの接続のどれがRecentが設定する\があるRecentが設定する\なしでそれを見る新来のメッセージを見るかは、未定義である」ので。 したがって、インディケータとして\Recentを使用すると、異なったIMAP4サーバによる予測できないクライアントの振舞いは引き起こされるでしょう。 しかしながら、クライアントはSeenがMDNを送ってはいけないというインディケータの1つとして旗を揚げさせる\を使用するかもしれません。 クライアントはMDNが以前に送られたのを示すのに\Draftや\Answeredのようにいかなる他の標準の旗も使用してはいけません、それらには異なったよく知られている意味があるので。 どのような場合でも、MDNを生成する目的のための他のすべての旗かキーワードを無視しなければならなくて、$MDNSentキーワードがあるとき、クライアントは、MDNを送ってはいけません。

   When the client opens a mailbox for the first time, it must verify
   that the server supports the $MDNSent keyword, or arbitrary message
   keywords by examining PERMANENTFLAGS response code.

クライアントが初めてメールボックスを開けると、それは、サーバが、$がMDNSentキーワード、または任意のメッセージキーワードであるとPERMANENTFLAGS応答コードを調べることによってサポートすることを確かめなければなりません。

   The client MUST NOT try to set the $MDNSent keyword if the server is
   incapable of storing it permanently.

サーバが永久にそれを保存できないなら、クライアントは$MDNSentキーワードを設定しようとしてはいけません。

   The client MUST be prepared to receive NO from the server as the
   result of STORE $MDNSent when the server advertises the support of
   storing arbitrary keywords, because the server may limit the number
   of message keywords it can store in a particular mailbox.  A client
   SHOULD NOT send MDN if it fails to store the $MDNSent keyword.

クライアントはサーバが任意のキーワードを保存するサポートの広告を出したらストア$MDNSentの結果としてサーバを受け取らない用意ができていなければなりません、サーバがそれが特定のメールボックスの中に保存できるメッセージキーワードの数を制限するかもしれないので。 SHOULD NOTがそれであるならMDNを送るクライアントは$MDNSentキーワードを保存しません。

   Once the $MDNSent keyword is set, it MUST NOT be unset by a client.
   The client MAY set the $MDNSent keyword when a user denies sending
   the notification.  This prohibits all other MUAs from sending MDN for
   this message.

$MDNSentキーワードがいったん設定されると、それはクライアントによるunsetであるはずがありません。 ユーザが、通知を送ることを否定するとき、クライアントは$MDNSentキーワードを設定するかもしれません。 これはこのメッセージのために送付MDNから他のすべてのMUAsを禁じます。

Melnikov                    Standards Track                     [Page 4]

RFC 3503                  MDN profile for IMAP                March 2003

メリニコフStandards Track[4ページ]RFC3503MDNはIMAPのために2003年3月の輪郭を描きます。

3.1.  Client behavior when receiving a message

3.1. メッセージを受け取るときのクライアントの振舞い

   The client MUST NOT send MDN if a message has the $MDNSent keyword
   set.  It also MUST NOT send MDN if a message has \Draft flag, because
   some clients use this flag to mark a message as incomplete.

メッセージにMDNSentキーワードが設定した$があるなら、クライアントはMDNを送ってはいけません。 また、メッセージにDraftが旗を揚げさせる\があるなら、それはMDNを送ってはいけません、何人かのクライアントが不完全であるとしてメッセージをマークするのにこの旗を使用するので。

   See the timeline in section 3 for details on client behavior when
   receiving a message.

メッセージを受け取るときにはクライアントの振舞いに関する詳細に関してセクション3のスケジュールを見てください。

3.2.  Client behavior when copying a message

3.2. メッセージをコピーするときのクライアントの振舞い

   The client SHOULD verify that $MDNSent is preserved on a COPY
   operation.  Furthermore, when a message is copied between servers
   with the APPEND command, the client MUST set the $MDNSent keyword
   correctly.

クライアントSHOULDは、$MDNSentがCOPY操作のときに保存されることを確かめます。 メッセージがサーバの間にAPPENDコマンドでコピーされるとき、その上、クライアントは正しく$MDNSentキーワードを設定しなければなりません。

3.3.  Client behavior when sending a message

3.3. メッセージを送るときのクライアントの振舞い

   When saving a sent message to any folder, the client MUST set the
   $MDNSent keyword to prevent another client from sending MDN for the
   message.

どんなフォルダーにも送信されたメッセージを保存するとき、クライアントは、$MDNSentキーワードに別のクライアントがメッセージのためにMDNを送るのを防ぐように設定しなければなりません。

3.4.  Client behavior when saving a temporary message

3.4. 一時的なメッセージを保存するときのクライアントの振舞い

   When saving an unfinished message to any folder client MUST set
   $MDNSent keyword to prevent another client from sending MDN for the
   message.

節約するとき、どんなフォルダークライアントへの未完成のメッセージも、$MDNSentキーワードに別のクライアントがメッセージのためにMDNを送るのを防ぐように設定しなければなりません。

4.  Server behavior

4. サーバの振舞い

   Server implementors that want to follow this specification must
   insure that their server complies with either section 4.1 or section
   4.2.  If the server also supports the IMAP [ACL] extension, it MUST
   also comply with the section 4.3.

この仕様に従いたがっているサーバ作成者は、彼らのサーバがセクション4.1かセクション4.2のどちらかに従うのを保障しなければなりません。 また、また、サーバが、IMAP[ACL]が拡大であるとサポートするなら、それはセクション4.3に従わなければなりません。

4.1.  Server that supports arbitrary keywords

4.1. 任意のキーワードをサポートするサーバ

   No changes are required from the server to make it compatible with
   the extension described in this document if it supports arbitrary
   keywords.

変化で、全く本書では任意のキーワードをサポートするなら、それはサーバから説明される拡大と互換性があるようになる必要はありません。

4.2.  Server that supports only $MDNSent keyword

4.2. 唯一の$がMDNSentキーワードであるとサポートするサーバ

   Servers that support only the $MDNSent keyword MUST preserve it on
   the COPY operation.  It is also expected that a server that supports
   SEARCH <flag> will also support the SEARCH KEYWORD $MDNSent.

唯一の$がMDNSentキーワードであるとサポートするサーバはCOPY操作のときにそれを保存しなければなりません。 また、また、検索が<旗の>であるとサポートするサーバが、SEARCH KEYWORD$がMDNSentであるとサポートすると予想されます。

Melnikov                    Standards Track                     [Page 5]

RFC 3503                  MDN profile for IMAP                March 2003

メリニコフStandards Track[5ページ]RFC3503MDNはIMAPのために2003年3月の輪郭を描きます。

4.3.  Interaction with IMAP ACL extension

4.3. IMAP ACL拡張子との相互作用

   Any server that conforms to either 4.1 or 4.2 and also supports the
   IMAP [ACL] extension, SHOULD preserve the $MDNSent keyword on COPY
   even if the client does not have 'w' right.  This will prevent the
   generation of a duplicated MDN for the same message.  Note that the
   server MUST still check if the client has rights to perform the COPY
   operation on a message according to [ACL].

4.1か4.2に従って、またIMAP[ACL]が拡大であるとサポートするどんなサーバ、クライアントが'w'を右に持たないでも、SHOULDはCOPYに関する$MDNSentキーワードを保存します。 これは同じメッセージのためにコピーされたMDNの世代を防ぐでしょう。 サーバが、クライアントに[ACL]に従ってメッセージにCOPY操作を実行する権利があるかどうかまだチェックしなければならないことに注意してください。

5.  Examples

5. 例

   1) MUA opens mailbox for the first time.

1) MUAは初めて、メールボックスを開けます。

   a) The server supports storing of arbitrary keywords

a) サーバは任意のキーワードの保存をサポートします。

   C: a100 select INBOX
   S: * FLAGS (\Flagged \Draft \Deleted \Seen)
   S: * OK [PERMANENTFLAGS (\Flagged \Draft \Deleted \Seen \*)]
   S: * 5 EXISTS
   S: * 3 RECENT
   S: * OK [UIDVALIDITY 894294713]
   S: a100 OK [READ-WRITE] Completed

C: a100の選んだ受信トレイS: * 旗(\旗を揚げさせられた\草稿\は見られた\を削除した)のS: * OK[PERMANENTFLAGS(\旗を揚げさせられた\草稿\は\見られた\*を削除した)]S: * 5が存在している、S: * 3、最近のS: * OK[UIDVALIDITY894294713]S: OK[READ-WRITE]が完成したa100

   b) The server supports storing of the $MDNSent keyword

b) サーバは$MDNSentキーワードの保存をサポートします。

   C: a100 select INBOX
   S: * FLAGS (\Flagged \Draft \Deleted \Seen $MDNSent)
   S: * OK [PERMANENTFLAGS (\Flagged \Draft \Deleted \Seen $MDNSent)]
   S: * 5 EXISTS
   S: * 3 RECENT
   S: * OK [UIDVALIDITY 894294713]
   S: a100 OK [READ-WRITE] Completed

C: a100の選んだ受信トレイS: * 旗(\は\草稿\削除された\目にふれている$MDNSentに旗を揚げさせた)のS: * OK[PERMANENTFLAGS(\は\草稿\削除された\目にふれている$MDNSentに旗を揚げさせた)]S: * 5が存在している、S: * 3、最近のS: * OK[UIDVALIDITY894294713]S: OK[READ-WRITE]が完成したa100

   2) The MUA successfully sets the $MDNSent keyword

2) MUAは首尾よく$MDNSentキーワードを設定します。

   C: a200 STORE 4 +FLAGS ($MDNSent)
   S: * 4 FETCH (FLAGS (\Flagged \Seen $MDNSent))
   S: * FLAGS ($MDNSent \Flagged \Deleted \Draft \Seen)
   S: * OK [PERMANENTFLAGS ($MDNSent \Flagged \Deleted \Draft \Seen \*)]
   S: a200 OK STORE completed

C: a200ストア4+FLAGS($MDNSent)S: * 4は(旗(\は\目にふれている$MDNSentに旗を揚げさせた))にSをとって来ます: * 旗($MDNSent\は見られた\削除された\草稿\に旗を揚げさせた)のS: * OK[PERMANENTFLAGS($MDNSent\は\削除された\草稿\見られた\*に旗を揚げさせた)]S: OKストアが完成したa200

   3) The server refuses to store the $MDNSent keyword

3) サーバは、$MDNSentキーワードを保存するのを拒否します。

   C: a200 STORE 4 +FLAGS ($MDNSent)
   S: a200 NO STORE failed : no space left to store $MDNSent keyword

C: a200ストア4+FLAGS($MDNSent)S: a200いいえストアは失敗しました: どんなスペースも$MDNSentキーワードを保存するのを残らせていません。

Melnikov                    Standards Track                     [Page 6]

RFC 3503                  MDN profile for IMAP                March 2003

メリニコフStandards Track[6ページ]RFC3503MDNはIMAPのために2003年3月の輪郭を描きます。

   4) All clients and servers MUST treat the $MDNSent keyword as case
   insensitive in all operations, as stated in [IMAP].

4) すべてのクライアントとサーバは[IMAP]に述べられているようにすべての操作で大文字と小文字を区別しないとしての$MDNSentキーワードを扱わなければなりません。

   C: a300 FETCH 1:* FLAGS
   S: * 1 FETCH (FLAGS (\Seen))
   S: * 2 FETCH (FLAGS (\Answered \Seen $MdnSENt))
   S: * 3 FETCH (FLAGS ())
   S: * 4 FETCH (FLAGS (\Flagged \Seen $MdnSENT))
   S: * 5 FETCH (FLAGS ($MDNSent))
   S: * 6 FETCH (FLAGS (\Recent))
   S: a300 OK FETCH completed
   C: a400 SEARCH KEYWORDS $mdnsent
   S: * SEARCH 2 4 5
   S: a400 OK SEARCH completed

C: a300 FETCH1: *FLAGS S: * 1 フェッチ(旗(見られた\))S: * 2は(旗(\目にふれている$MdnSENtに答えた\))にSをとって来ます: * 3がとって来る、(旗の())S: * 4は(旗(\は\目にふれている$MdnSENTに旗を揚げさせた))にSをとって来ます: * 5 (旗($MDNSent))Sをとって来てください: * 6は(旗(\最近の))にSをとって来ます: a300OK FETCHはCを完成しました: a400SEARCH KEYWORDS$mdnsent S: * 5秒間の検索2 4: OK検索が完成したa400

6.  Security Considerations

6. セキュリティ問題

   There are no known security issues with this extension, not found in
   [MDN] and/or [IMAP4].

この拡大の安全保障問題は[MDN]、そして/または、[IMAP4]で見つけられるのではなく、知られていません。

   Section 4.3 changes ACL checking requirements on an IMAP server that
   implements IMAP [ACL] extension.

セクション4.3はIMAP[ACL]が拡大であると実装するIMAPサーバに関する要件をチェックするACLを変えます。

7.  Formal Syntax

7. 正式な構文

   The following syntax specification uses the augmented Backus-Naur
   Form (BNF) notation as specified in [RFC-822], as modified by
   [IMAP4].  Non-terminals referenced, but not defined below, are as
   defined by [IMAP4].

[IMAP4]によって変更されるように以下の構文仕様は[RFC-822]の指定されるとしての増大しているBN記法(BNF)記法を使用します。 [IMAP4]によって定義されるように参照をつけられましたが、以下で定義されなかった非端末があります。

   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.

別の方法で注意されるのを除いて、すべての英字がケース神経が鈍いです。 トークンストリングを定義する上側の、または、下側のケースキャラクタの使用は編集の明快だけのためのものです。 実装は大文字と小文字を区別しないファッションでこれらのストリングを受け入れなければなりません。

   flag_keyword    ::= "$MDNSent" / other_keywords

_キーワードに旗を揚げさせてください:、:= 「$MDNSent」/他の_キーワード

   other_keywords  ::= atom

他の_キーワード:、:= 原子

8.  Acknowledgments

8. 承認

   This document is the product of discussions that took place on the
   IMAP mailing list.  Special gratitude to Cyrus Daboo and Randall
   Gellens for reviewing the document.

このドキュメントはIMAPメーリングリストで行われた議論の成果です。 ドキュメントを再検討するためのサイラスDabooとランドルGellensにおける特別な謝意。

   Thank you to my father who as he has helped to make me what I am.  I
   miss you terribly.

彼が、私を現在の姿にするのを助けたとき、だれを私の父をありがとうございます。 あなたがものすごくいなくて寂しいです。

Melnikov                    Standards Track                     [Page 7]

RFC 3503                  MDN profile for IMAP                March 2003

メリニコフStandards Track[7ページ]RFC3503MDNはIMAPのために2003年3月の輪郭を描きます。

9.  Normative References

9. 引用規格

   [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月。

   [MDN]      Fajman, R., "An Extensible Message Format for Message
              Disposition Notifications", RFC 2298, March 1998.

[MDN] Fajman、R.、「メッセージ気質通知のための広げることができるメッセージ・フォーマット」、RFC2298、1998年3月。

   [IMAP4]    Crispin, M., "Internet Message Access Protocol - Version
              4rev1", RFC 3501, March 2003.

[IMAP4] クリスピン、M.、「バージョン4rev1"、RFC3501、2003年インターネットメッセージアクセス・プロトコル--3月。」

   [ACL]      Myers, J., "IMAP4 ACL extension", RFC 2086, January 1997.

[ACL] マイアーズ、J.、「IMAP4 ACL拡張子」、RFC2086、1997年1月。

10.  Author's Address

10. 作者のアドレス

   Alexey Melnikov
   ACI Worldwide/MessagingDirect
   59 Clarendon Road
   Watford, Hertfordshire
   United Kingdom, WD17 1FQ

AlexeyメリニコフACIの世界的な/MessagingDirect59クラレンドンRoadワットフォード、ハートフォードシアイギリスWD17 1FQ

   Phone: +44 1923 81 2877
   EMail: mel@messagingdirect.com

以下に電話をしてください。 +44 1923 81 2877はメールされます: mel@messagingdirect.com

Melnikov                    Standards Track                     [Page 8]

RFC 3503                  MDN profile for IMAP                March 2003

メリニコフStandards Track[8ページ]RFC3503MDNはIMAPのために2003年3月の輪郭を描きます。

11.  Full Copyright Statement

11. 完全な著作権宣言文

   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 assigns.

上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Melnikov                    Standards Track                     [Page 9]

メリニコフ標準化過程[9ページ]