RFC4551 日本語訳

Network Working Group                                        A. Melnikov
Request for Comments: 4551                                    Isode Ltd.
Updates: 3501                                                    S. Hole
Category: Standards Track                  ACI WorldWide/MessagingDirect
                                                               June 2006

コメントを求めるワーキンググループA.メリニコフの要求をネットワークでつないでください: 4551のIsode株式会社アップデート: 3501秒間カテゴリを掘ってください: 規格はMessagingDirect2006年6月にACIの世界的な/を追跡します。

             IMAP Extension for Conditional STORE Operation
                or Quick Flag Changes Resynchronization

条件付きの店舗運営か迅速な旗のためのIMAP拡張子はResynchronizationを変えます。

Status of This Memo

このメモの状態

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

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

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2006).

Copyright(C)インターネット協会(2006)。

Abstract

要約

   Often, multiple IMAP (RFC 3501) clients need to coordinate changes to
   a common IMAP mailbox.  Examples include different clients working on
   behalf of the same user, and multiple users accessing shared
   mailboxes.  These clients need a mechanism to synchronize state
   changes for messages within the mailbox.  They must be able to
   guarantee that only one client can change message state (e.g.,
   message flags) at any time.  An example of such an application is use
   of an IMAP mailbox as a message queue with multiple dequeueing
   clients.

しばしば、複数のIMAP(RFC3501)クライアントは、一般的なIMAPメールボックスへの変化を調整する必要があります。 例は同じユーザを代表して働いている異なったクライアント、および共有されたメールボックスにアクセスする複数のユーザを含んでいます。 これらのクライアントは、メカニズムがメールボックスの中のメッセージのための州の変化を連動させる必要があります。 彼らは、1人のクライアントだけがいつでもメッセージ状態(例えば、メッセージ旗)を変えることができるのを保証できなければなりません。 そのようなアプリケーションに関する例は複数のdequeueingクライアントがいるメッセージキューとしてのIMAPメールボックスの使用です。

   The Conditional Store facility provides a protected update mechanism
   for message state information that can detect and resolve conflicts
   between multiple writing mail clients.

Conditionalストア施設は複数の書くことのメールクライアントの間の闘争を検出して、解決できるメッセージ州の情報に保護されたアップデートメカニズムを提供します。

   The Conditional Store facility also allows a client to quickly
   resynchronize mailbox flag changes.

また、Conditionalストア施設で、クライアントはメールボックス旗の変化をすぐに再連動させることができます。

   This document defines an extension to IMAP (RFC 3501).

このドキュメントはIMAP(RFC3501)と拡大を定義します。

Melnikov & Hole             Standards Track                     [Page 1]

RFC 4551          IMAP Extension for Conditional STORE         June 2006

メリニコフと穴の規格は条件付きの店2006年6月にRFC4551IMAP拡張子を追跡します[1ページ]。

Table of Contents

目次

   1.  Introduction and Overview ................................. 3
   2.  Conventions Used in This Document ......................... 5
   3.  IMAP Protocol Changes ..................................... 6
   3.1. New OK untagged responses for SELECT and EXAMINE ......... 6
   3.1.1. HIGHESTMODSEQ response code ............................ 6
   3.1.2. NOMODSEQ response code ................................. 7
   3.2. STORE and UID STORE Commands ............................. 7
   3.3 FETCH and UID FETCH Commands ..............................13
   3.3.1. CHANGEDSINCE FETCH modifier ............................13
   3.3.2. MODSEQ message data item in FETCH Command ..............14
   3.4. MODSEQ search criterion in SEARCH ........................16
   3.5. Modified SEARCH untagged response ........................17
   3.6. HIGHESTMODSEQ status data items ..........................17
   3.7. CONDSTORE parameter to SELECT and EXAMINE ................18
   3.8. Additional quality of implementation issues ..............18
   4.  Formal Syntax .............................................19
   5.  Server implementation considerations ......................21
   6.  Security Considerations ...................................22
   7.  IANA Considerations .......................................22
   8.  References ................................................23
   8.1. Normative References .....................................23
   8.2. Informative References ...................................23
   9.  Acknowledgements ..........................................23

1. 序論と概要… 3 2. このドキュメントで中古のコンベンション… 5 3. IMAPは変化について議定書の中で述べます… 6 3.1. 新しいOKはSELECTとEXAMINEのために応答に非タグ付けをしました… 6 3.1.1. HIGHESTMODSEQ応答コード… 6 3.1.2. NOMODSEQ応答コード… 7 3.2. 店とUIDはコマンドを保存します… 7 3.3のフェッチとUIDはコマンドをとって来ます…13 3.3.1. CHANGEDSINCE FETCH修飾語…13 3.3.2. FETCH CommandのMODSEQメッセージデータ項目…14 3.4. MODSEQは検索における評価基準を捜します…16 3.5. 変更された検索は応答に非タグ付けをしました…17 3.6. HIGHESTMODSEQ状態データ項目…17 3.7. SELECTとEXAMINEへのCONDSTOREパラメタ…18 3.8. 導入問題の追加品質…18 4. 正式な構文…19 5. サーバ実装問題…21 6. セキュリティ問題…22 7. IANA問題…22 8. 参照…23 8.1. 標準の参照…23 8.2. 有益な参照…23 9. 承認…23

Melnikov & Hole             Standards Track                     [Page 2]

RFC 4551          IMAP Extension for Conditional STORE         June 2006

メリニコフと穴の規格は条件付きの店2006年6月にRFC4551IMAP拡張子を追跡します[2ページ]。

1. Introduction and Overview

1. 序論と概要

   The Conditional STORE extension is present in any IMAP4
   implementation that returns "CONDSTORE" as one of the supported
   capabilities in the CAPABILITY command response.

Conditionalストア拡張子はサポートしている能力の1つとして能力コマンド応答で"CONDSTORE"を返すどんなIMAP4実装でも存在しています。

   An IMAP server that supports this extension MUST associate a positive
   unsigned 64-bit value called a modification sequence (mod-sequence)
   with every IMAP message.  This is an opaque value updated by the
   server whenever a metadata item is modified.  The server MUST
   guarantee that each STORE command performed on the same mailbox
   (including simultaneous stores to different metadata items from
   different connections) will get a different mod-sequence value.
   Also, for any two successful STORE operations performed in the same
   session on the same mailbox, the mod-sequence of the second completed
   operation MUST be greater than the mod-sequence of the first
   completed.  Note that the latter rule disallows the use of the system
   clock as a mod-sequence, because if system time changes (e.g., an NTP
   [NTP] client adjusting the time), the next generated value might be
   less than the previous one.

この拡大をサポートするIMAPサーバは変更系列(モッズ系列)と呼ばれる上向きの未署名の64ビットの値をあらゆるIMAPメッセージに関連づけなければなりません。 これはメタデータ項目が変更されているときはいつも、サーバによってアップデートされた不透明な値です。 サーバは、同じメールボックス(異なった接続からの異なったメタデータ項目に同時の店を含める)に実行されたそれぞれのストアコマンドが異なったモッズ系列値を得るのを保証しなければなりません。 また、同じメールボックスの同じセッションのときに実行されたどんな2つのうまくいっているストア操作にも2番目の完成した操作のモッズ系列も1つの番目もののモッズ系列が完成したよりすばらしいに違いありません。 後者の規則がモッズ系列としてシステムクロックの使用を禁じることに注意してください、システム時間が(例えば、時間を調整するNTP[NTP]クライアント)を変えるなら、次の発生している値が前のもの以下であるかもしれないので。

   Mod-sequences allow a client that supports the CONDSTORE extension to
   determine if a message metadata has changed since some known moment.
   Whenever the state of a flag changes (i.e., the flag is added where
   previously it wasn't set, or the flag is removed and before it was
   set) the value of the modification sequence for the message MUST be
   updated.  Adding the flag when it is already present or removing when
   it is not present SHOULD NOT change the mod-sequence.

モッズ系列で、CONDSTORE拡張子をサポートするクライアントは、いつかの知られている瞬間以来メッセージメタデータが変化しているかどうかと決心できます。 旗の状態が変化する(旗は取り外されました、そして、すなわち、旗が以前にそれが設定されなかったところで加えられたか、または以前、それは設定されました)ときはいつも、メッセージのための変更系列の値をアップデートしなければなりません。 それが存在していないとき、それが既に存在しているとき、旗を加えるか、または取り外して、SHOULD NOTはモッズ系列を変えます。

   When a message is appended to a mailbox (via the IMAP APPEND command,
   COPY to the mailbox, or using an external mechanism) the server
   generates a new modification sequence that is higher than the highest
   modification sequence of all messages in the mailbox and assigns it
   to the appended message.

メールボックス(メールボックス、または使用へのIMAP APPENDコマンド、COPYを通した外部のメカニズム)にメッセージを追加するとき、サーバは、新しい変更がすべてのメッセージのメールボックスで最も高い変更系列より高い系列であると生成して、追加されたメッセージにそれを割り当てます。

   The server MAY store separate (per-message) modification sequence
   values for different metadata items.  If the server does so, per-
   message mod-sequence is the highest mod-sequence of all metadata
   items for the specified message.

サーバがそうをするならサーバは異なったメタデータ項目のための店の別々(1メッセージあたりの)の変更系列値がそうするかもしれない、-、メッセージモッズ系列が指定されたメッセージのためのすべてのメタデータ項目の最も高いモッズ系列です。

   The server that supports this extension is not required to be able to
   store mod-sequences for every available mailbox.  Section 3.1.2
   describes how the server may act if a particular mailbox doesn't
   support the persistent storage of mod-sequences.

この拡大をサポートするサーバは、あらゆる利用可能なメールボックスのためにモッズ系列を保存できるように必要ではありません。 セクション3.1 .2 特定のメールボックスがモッズ系列の永続的なストレージをサポートしないならサーバがどう行動するかもしれないかを説明します。

Melnikov & Hole             Standards Track                     [Page 3]

RFC 4551          IMAP Extension for Conditional STORE         June 2006

メリニコフと穴の規格は条件付きの店2006年6月にRFC4551IMAP拡張子を追跡します[3ページ]。

   This extension makes the following changes to the IMAP4 protocol:

この拡大はIMAP4プロトコルへの以下の変更を行います:

      a) adds UNCHANGEDSINCE STORE modifier.

a) UNCHANGEDSINCE STORE修飾語を加えます。

      b) adds the MODIFIED response code which should be used with an OK
         response to the STORE command.  (It can also be used in a NO
         response.)

b)はストアコマンドへのOK応答と共に使用されるべきであるMODIFIED応答コードを加えます。 (また、いいえ応答にそれを使用できます。)

      c) adds a new MODSEQ message data item for use with the FETCH
         command.

c)は使用のためにFETCHコマンドで新しいMODSEQメッセージデータ項目を加えます。

      d) adds CHANGEDSINCE FETCH modifier.

d)はCHANGEDSINCE FETCH修飾語を加えます。

      e) adds a new MODSEQ search criterion.

e)は新しいMODSEQ検索評価基準を加えます。

      f) extends the syntax of untagged SEARCH responses to include
         mod-sequence.

f)は、モッズ系列を含むように非タグ付けをされた検索応答の構文を広げています。

      g) adds new OK untagged responses for the SELECT and EXAMINE
         commands.

g)は、新しいOKがSELECTとEXAMINEコマンドのための応答に非タグ付けをしたと言い足します。

      h) defines an additional parameter to SELECT/EXAMINE commands.

h)は追加パラメタをSELECT/EXAMINEコマンドと定義します。

      i) adds the HIGHESTMODSEQ status data item to the STATUS command.

i)はHIGHESTMODSEQ状態データ項目をSTATUSコマンドに追加します。

   A client supporting CONDSTORE extension indicates its willingness to
   receive mod-sequence updates in all untagged FETCH responses by
   issuing:

CONDSTOREが拡大であるとサポートするクライアントは、モッズ系列を受け取る意欲がすべてのuntagged FETCHで以下を発行することによって応答をアップデートするのを示します。

      -  a SELECT or EXAMINE command with the CONDSTORE parameter,
      -  a STATUS (HIGHESTMODSEQ) command,
      -  a FETCH or SEARCH command that includes the MODSEQ message data
         item,
      -  a FETCH command with the CHANGEDSINCE modifier, or
      -  a STORE command with the UNCHANGEDSINCE modifier.

- または、CONDSTOREパラメタがあるSELECTかEXAMINEコマンド--STATUS(HIGHESTMODSEQ)コマンド--MODSEQメッセージデータ項目を含んでいるFETCHか検索命令--CHANGEDSINCE修飾語によるFETCHコマンド、--UNCHANGEDSINCE修飾語によるストアコマンド。

   The server MUST include mod-sequence data in all subsequent untagged
   FETCH responses (until the connection is closed), whether they were
   caused by a regular STORE, a STORE with UNCHANGEDSINCE modifier, or
   an external agent.

サーバはすべてのその後のuntagged FETCH応答にモッズ系列データを含まなければなりません(接続が閉じられるまで)、それらが通常のストア、UNCHANGEDSINCE修飾語があるストア、または外部のエージェントによって引き起こされたか否かに関係なく。

   This document uses the term "CONDSTORE-aware client" to refer to a
   client that announces its willingness to receive mod-sequence updates
   as described above.  The term "CONDSTORE enabling command" will refer
   any of the commands listed above.  A future extension to this
   document may extend the list of CONDSTORE enabling commands.  A first
   CONDSTORE enabling command executed in the session MUST cause the

このドキュメントは、上で説明されるようにモッズ系列アップデートを受ける意欲を発表するクライアントについて言及するのに「CONDSTORE意識しているクライアント」という用語を使用します。 用語「コマンドを可能にするCONDSTORE」は上に記載されたコマンドのいずれも参照するでしょう。 このドキュメントへの今後の拡大はコマンドを可能にするCONDSTOREのリストを広げるかもしれません。 コマンドを可能にする最初のCONDSTOREはセッションが引き起こさなければならないコネを実行しました。

Melnikov & Hole             Standards Track                     [Page 4]

RFC 4551          IMAP Extension for Conditional STORE         June 2006

メリニコフと穴の規格は条件付きの店2006年6月にRFC4551IMAP拡張子を追跡します[4ページ]。

   server to return HIGHESTMODSEQ (Section 3.1.1) unless the server has
   sent NOMODSEQ (Section 3.1.2) response code when the currently
   selected mailbox was selected.

現在選択されたメールボックスであるときに、サーバがNOMODSEQ(セクション3.1.2)に応答コードを送らない場合、HIGHESTMODSEQ(セクション3.1.1)を返すサーバは選択されました。

   The rest of this document describes the protocol changes more
   rigorously.

このドキュメントの残りはプロトコル変化について、よりきびしく説明します。

2.  Conventions Used in This Document

2. 本書では使用されるコンベンション

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [KEYWORDS].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[キーワード]で説明されるように本書では解釈されることであるべきですか?

   In examples, lines beginning with "S:" are sent by the IMAP server,
   and lines beginning with "C:" are sent by the client.  Line breaks
   may appear in example commands solely for editorial clarity; when
   present in the actual message, they are represented by "CRLF".

例、系列始め、「S:」 IMAPサーバによって送られて、始めを裏打ちする、「C:」 クライアントによって送られます。 ラインブレイクは唯一編集の明快のための例のコマンドに現れるかもしれません。 実際のメッセージに存在しているとき、それらは"CRLF"によって表されます。

   Formal syntax is defined using ABNF [ABNF].

正式な構文は、ABNF[ABNF]を使用することで定義されます。

   The term "metadata" or "metadata item" is used throughout this
   document.  It refers to any system or user-defined keyword.  Future
   documents may extend "metadata" to include other dynamic message
   data.

「メタデータ」か「メタデータ項目」という用語はこのドキュメント中で使用されます。 それはどんなシステムやユーザによって定義されたキーワードも示します。 将来のドキュメントは、他のダイナミックなメッセージデータを含むように「メタデータ」を広げるかもしれません。

   Some IMAP mailboxes are private, accessible only to the owning user.
   Other mailboxes are not, either because the owner has set an Access
   Control List [ACL] that permits access by other users, or because it
   is a shared mailbox.  Let's call a metadata item "shared" for the
   mailbox if any changes to the metadata items are persistent and
   visible to all other users accessing the mailbox.  Otherwise, the
   metadata item is called "private".  Note that private metadata items
   are still visible to all sessions accessing the mailbox as the same
   user.  Also note that different mailboxes may have different metadata
   items as shared.

所有しているユーザだけに、いくつかのIMAPメールボックスが、個人的であって、アクセスしやすいです。 他のメールボックスはそうではありません、所有者が他のユーザでアクセスを許可するAccess Control List[ACL]を設定したか、それが共有されたメールボックスであるので。 メールボックスにアクセスする他のすべてのユーザにとって、メタデータ項目へのどれか変化が永続的であって、目に見えるなら、メールボックスのためにメタデータ項目が「共有されている」と言いましょう。 さもなければ、メタデータ項目は「個人的である」と呼ばれます。 個人的なメタデータ項目がまだ同じユーザとしてメールボックスにアクセスするすべてのセッションに目に見えていることに注意してください。 また、異なったメールボックスには共有されるとして異なったメタデータ項目があるかもしれないことに注意してください。

   See Section 1 for the definition of a "CONDSTORE-aware client" and a
   "CONDSTORE enabling command".

「CONDSTORE意識しているクライアント」と「CONDSTOREの可能なコマンド」の定義に関してセクション1を見てください。

Melnikov & Hole             Standards Track                     [Page 5]

RFC 4551          IMAP Extension for Conditional STORE         June 2006

メリニコフと穴の規格は条件付きの店2006年6月にRFC4551IMAP拡張子を追跡します[5ページ]。

3.  IMAP Protocol Changes

3. IMAPプロトコル変化

3.1.  New OK Untagged Responses for SELECT and EXAMINE

3.1. 新しさ、Untagged応答を承認する、選択して、審査

   This document adds two new response codes, HIGHESTMODSEQ and
   NOMODSEQ.  One of those response codes MUST be returned in the OK
   untagged response for a successful SELECT/EXAMINE command.

このドキュメントは2の新しい応答のコード、HIGHESTMODSEQ、およびNOMODSEQを加えます。 うまくいっているSELECT/EXAMINEコマンドのためのOKの非タグ付けをされた応答でそれらの応答コードの1つを返さなければなりません。

   When opening a mailbox, the server must check if the mailbox supports
   the persistent storage of mod-sequences.  If the mailbox supports the
   persistent storage of mod-sequences and the mailbox open operation
   succeeds, the server MUST send the OK untagged response including
   HIGHESTMODSEQ response code.  If the persistent storage for the
   mailbox is not supported, the server MUST send the OK untagged
   response including NOMODSEQ response code instead.

メールボックスを開けるとき、サーバは、メールボックスがモッズ系列の永続的なストレージをサポートするかどうかチェックしなければなりません。 メールボックスがモッズ系列の永続的なストレージをサポートして、メールボックス開放的手術が成功するなら、サーバはHIGHESTMODSEQ応答コードを含むOKの非タグ付けをされた応答を送らなければなりません。 メールボックスのための永続的なストレージがサポートされないなら、サーバは代わりにNOMODSEQ応答コードを含むOKの非タグ付けをされた応答を送らなければなりません。

3.1.1.  HIGHESTMODSEQ Response Code

3.1.1. HIGHESTMODSEQ応答コード

   This document adds a new response code that is returned in the OK
   untagged response for the SELECT and EXAMINE commands.  A server
   supporting the persistent storage of mod-sequences for the mailbox
   MUST send the OK untagged response including HIGHESTMODSEQ response
   code with every successful SELECT or EXAMINE command:

このドキュメントはSELECTとEXAMINEコマンドのためのOKの非タグ付けをされた応答で返される新しい応答コードを加えます。 メールボックスがOKを送らなければならないので、モッズ系列の永続的なストレージをサポートするサーバはあらゆるうまくいっているSELECTかEXAMINEコマンドのときにHIGHESTMODSEQ応答コードを含む応答に非タグ付けをしました:

      OK [HIGHESTMODSEQ <mod-sequence-value>]

OK[HIGHESTMODSEQ<モッズ系列価値の>]

      where <mod-sequence-value> is the highest mod-sequence value of
      all messages in the mailbox.  When the server changes UIDVALIDITY
      for a mailbox, it doesn't have to keep the same HIGHESTMODSEQ for
      the mailbox.

<モッズ系列価値の>がすべてのメッセージのメールボックスで最も高いモッズ系列値であるところ。 サーバがメールボックスのためにUIDVALIDITYを変えるとき、それはメールボックスのために同じHIGHESTMODSEQを保つ必要はありません。

   A disconnected client can use the value of HIGHESTMODSEQ to check if
   it has to refetch metadata from the server.  If the UIDVALIDITY value
   has changed for the selected mailbox, the client MUST delete the
   cached value of HIGHESTMODSEQ.  If UIDVALIDITY for the mailbox is the
   same, and if the HIGHESTMODSEQ value stored in the client's cache is
   less than the value returned by the server, then some metadata items
   on the server have changed since the last synchronization, and the
   client needs to update its cache.  The client MAY use SEARCH MODSEQ
   (Section 3.4) to find out exactly which metadata items have changed.
   Alternatively, the client MAY issue FETCH with the CHANGEDSINCE
   modifier (Section 3.3.1) in order to fetch data for all messages that
   have metadata items changed since some known modification sequence.

切断しているクライアントは、それがそうしたかどうかサーバからの「再-フェッチ」メタデータにチェックするのにHIGHESTMODSEQの値を使用できます。UIDVALIDITY値が選択されたメールボックスのために変化したなら、クライアントはHIGHESTMODSEQのキャッシュされた値を削除しなければなりません。 メールボックスのためのUIDVALIDITYが同じであり、クライアントのキャッシュで保存されたHIGHESTMODSEQ値がサーバによって返された値以下であるなら、最後の同期以来サーバのいくつかのメタデータ項目が変化しています、そして、クライアントはキャッシュをアップデートする必要があります。 クライアントは、まさにどのメタデータ項目が変化したかを見つけるのに、SEARCH MODSEQ(セクション3.4)を使用するかもしれません。 あるいはまた、クライアントは、何らかの知られている変更系列以来メタデータ項目を変えるすべてのメッセージのためのデータをとって来るためにCHANGEDSINCE修飾語(セクション3.3.1)でFETCHを発行するかもしれません。

   Example 1:

例1:

      C: A142 SELECT INBOX
      S: * 172 EXISTS

C: A142は受信トレイSを選択します: * 172は存在しています。

Melnikov & Hole             Standards Track                     [Page 6]

RFC 4551          IMAP Extension for Conditional STORE         June 2006

メリニコフと穴の規格は条件付きの店2006年6月にRFC4551IMAP拡張子を追跡します[6ページ]。

      S: * 1 RECENT
      S: * OK [UNSEEN 12] Message 12 is first unseen
      S: * OK [UIDVALIDITY 3857529045] UIDs valid
      S: * OK [UIDNEXT 4392] Predicted next UID
      S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
      S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
      S: * OK [HIGHESTMODSEQ 715194045007]
      S: A142 OK [READ-WRITE] SELECT completed

S: * 1、最近のS: * OK[UNSEEN12]メッセージ12は最初に、見えないSです: * OK[UIDVALIDITY3857529045]のUIDs有効なS: * OK[UIDNEXT4392]は次のUID Sを予測しました: * 旗(\に答えた\は\削除された\見られた\草稿に旗を揚げさせた)のS: * OK[PERMANENTFLAGS(\は\見られた\*を削除した)]はSを制限しました: * OK[HIGHESTMODSEQ715194045007]S: 完成したA142 OK[READ-WRITE]SELECT

3.1.2.  NOMODSEQ Response Code

3.1.2. NOMODSEQ応答コード

   A server that doesn't support the persistent storage of mod-sequences
   for the mailbox MUST send the OK untagged response including NOMODSEQ
   response code with every successful SELECT or EXAMINE command.  A
   server that returned NOMODSEQ response code for a mailbox, which
   subsequently receives one of the following commands while the mailbox
   is selected:

メールボックスがOKを送らなければならないので、モッズ系列の永続的なストレージをサポートしないサーバはあらゆるうまくいっているSELECTかEXAMINEコマンドのときにNOMODSEQ応答コードを含む応答に非タグ付けをしました。 メールボックスが選択されますが、以下のコマンドの1つが次に受信されるメールボックスのために応答コードをNOMODSEQに返したサーバ:

      -  a FETCH command with the CHANGEDSINCE modifier,
      -  a FETCH or SEARCH command that includes the MODSEQ message data
         item, or
      -  a STORE command with the UNCHANGEDSINCE modifier

- または、CHANGEDSINCE修飾語によるFETCHコマンド--MODSEQメッセージデータ項目を含んでいるFETCHか検索命令、--、UNCHANGEDSINCE修飾語によるストアコマンド

   MUST reject any such command with the tagged BAD response.

タグ付けをされたBAD応答でどんなそのようなコマンドも拒絶しなければなりません。

   Example 2:

例2:

      C: A142 SELECT INBOX
      S: * 172 EXISTS
      S: * 1 RECENT
      S: * OK [UNSEEN 12] Message 12 is first unseen
      S: * OK [UIDVALIDITY 3857529045] UIDs valid
      S: * OK [UIDNEXT 4392] Predicted next UID
      S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
      S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
      S: * OK [NOMODSEQ] Sorry, this mailbox format doesn't support
           modsequences
      S: A142 OK [READ-WRITE] SELECT completed

C: A142は受信トレイSを選択します: * 172が存在している、S: * 1、最近のS: * OK[UNSEEN12]メッセージ12は最初に、見えないSです: * OK[UIDVALIDITY3857529045]のUIDs有効なS: * OK[UIDNEXT4392]は次のUID Sを予測しました: * 旗(\に答えた\は\削除された\見られた\草稿に旗を揚げさせた)のS: * OK[PERMANENTFLAGS(\は\見られた\*を削除した)]はSを制限しました: * 残念な状態で[NOMODSEQ]を承認してください、そして、このメールボックス形式はmodsequences Sをサポートしません: 完成したA142 OK[READ-WRITE]SELECT

3.2.  STORE and UID STORE Commands

3.2. 店とUIDはコマンドを保存します。

   This document defines the following STORE modifier (see Section 2.5
   of [IMAPABNF]):

このドキュメントは以下のストア修飾語を定義します([IMAPABNF]のセクション2.5を見てください):

   UNCHANGEDSINCE <mod-sequence>

UNCHANGEDSINCE<モッズ系列>。