Network Working Group A. Melnikov
Request for Comments: 4551 Isode Ltd.
Updates: 3501 S. Hole
Category: Standards Track ACI WorldWide/MessagingDirect
June 2006
Network Working Group A. Melnikov
Request for Comments: 4551 Isode Ltd.
Updates: 3501 S. Hole
Category: Standards Track ACI WorldWide/MessagingDirect
June 2006
IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization
用于条件存储操作或快速标志更改重新同步的IMAP扩展
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.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（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（RFC 3501）客户端需要协调对公共IMAP邮箱的更改。示例包括代表同一用户工作的不同客户端，以及访问共享邮箱的多个用户。这些客户端需要一种机制来同步邮箱中邮件的状态更改。它们必须能够保证在任何时候只有一个客户端可以更改消息状态（例如，消息标志）。此类应用程序的一个示例是使用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.
条件存储设施为消息状态信息提供了受保护的更新机制，可以检测和解决多个写邮件客户端之间的冲突。
The Conditional Store facility also allows a client to quickly resynchronize mailbox flag changes.
条件存储设施还允许客户端快速重新同步邮箱标志更改。
This document defines an extension to IMAP (RFC 3501).
本文档定义了IMAP（RFC 3501）的扩展。
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. 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
The Conditional STORE extension is present in any IMAP4 implementation that returns "CONDSTORE" as one of the supported capabilities in the CAPABILITY command response.
条件存储扩展存在于任何IMAP4实现中，该实现在CAPABILITY命令响应中将“CONDSTORE”作为支持的功能之一返回。
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服务器必须将一个称为修改序列（mod序列）的无符号64位正值与每个IMAP消息相关联。这是一个不透明值，每当修改元数据项时，服务器都会更新该值。服务器必须保证在同一邮箱上执行的每个存储命令（包括从不同连接同时存储到不同元数据项）将获得不同的mod sequence值。此外，对于在同一邮箱上的同一会话中执行的任何两个成功存储操作，第二个已完成操作的mod序列必须大于第一个已完成操作的mod序列。请注意，后一条规则不允许将系统时钟用作mod序列，因为如果系统时间发生变化（例如，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.
Mod sequences允许支持CONDSTORE扩展的客户机确定消息元数据是否在某个已知时刻发生了更改。每当标志状态发生变化时（即，在以前未设置标志的位置添加标志，或在设置标志之前删除标志），必须更新消息修改序列的值。当标志已经存在时添加标志或当标志不存在时删除标志不应改变mod序列。
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命令、复制到邮箱或使用外部机制），服务器将生成一个新的修改序列，该修改序列高于邮箱中所有邮件的最高修改序列，并将其分配给追加的邮件。
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.
服务器可以为不同的元数据项存储单独的（每条消息）修改序列值。如果服务器执行此操作，则每消息mod sequence是指定消息的所有元数据项的最高mod sequence。
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.
支持此扩展的服务器不需要能够为每个可用邮箱存储mod序列。第3.1.2节描述了如果特定邮箱不支持mod序列的持久存储，服务器将如何操作。
This extension makes the following changes to the IMAP4 protocol:
此扩展对IMAP4协议进行以下更改：
a) adds UNCHANGEDSINCE STORE modifier.
a) 添加未更改的自存储修改器。
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) 向STORE命令添加修改后的响应代码，该代码应与OK响应一起使用。（也可用于无响应。）
c) adds a new MODSEQ message data item for use with the FETCH command.
c) 添加一个新的MODSEQ消息数据项，以便与FETCH命令一起使用。
d) adds CHANGEDSINCE FETCH modifier.
d) 添加CHANGEDSINCE提取修改器。
e) adds a new MODSEQ search criterion.
e) 添加新的MODSEQ搜索条件。
f) extends the syntax of untagged SEARCH responses to include mod-sequence.
f) 扩展未标记搜索响应的语法，以包括mod sequence。
g) adds new OK untagged responses for the SELECT and EXAMINE commands.
g) 为“选择”和“检查”命令添加新的“确定”未标记响应。
h) defines an additional parameter to SELECT/EXAMINE commands.
h) 定义用于选择/检查命令的附加参数。
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扩展的客户机通过发出以下命令表示其愿意在所有未标记的获取响应中接收mod sequence更新：
- 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命令、-状态（HIGHESTMODSEQ）命令、-包含MODSEQ消息数据项的FETCH或SEARCH命令、-带有CHANGEDSINCE修饰符的FETCH命令，或-带有UNCHANGEDSINCE修饰符的STORE命令。
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.
服务器必须在所有后续未标记的获取响应（直到连接关闭）中包含mod sequence数据，无论这些响应是由常规存储、具有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感知客户机”来指宣布愿意接收上述mod序列更新的客户机。术语“CONDSTORE enabling command”指上述任何命令。本文档的后续扩展可能会扩展CONDSTORE启用命令的列表。会话中执行的第一个CONDSTORE启用命令必须导致
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.
服务器返回HIGHESTMODSEQ（第3.1.1节），除非在选择当前选定邮箱时服务器已发送NOMODSEQ（第3.1.2节）响应代码。
The rest of this document describes the protocol changes more rigorously.
本文档的其余部分更严格地描述了协议更改。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[关键词]中所述进行解释。
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邮箱是专用的，只能由所属用户访问。其他邮箱不是，因为所有者设置了允许其他用户访问的访问控制列表[ACL]，或者因为它是共享邮箱。如果元数据项的任何更改是持久的，并且对访问邮箱的所有其他用户可见，那么我们将该邮箱的元数据项称为“共享”。否则，元数据项称为“private”。请注意，私有元数据项对于以同一用户身份访问邮箱的所有会话仍然可见。还请注意，不同的邮箱可能共享不同的元数据项。
See Section 1 for the definition of a "CONDSTORE-aware client" and a "CONDSTORE enabling command".
请参阅第1节，了解“CONDSTORE感知客户端”和“CONDSTORE启用命令”的定义。
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.
本文档添加了两个新的响应代码，HIGHESTMODSEQ和NOMODSEQ。如果选择/检查命令成功，则必须在OK Untaged响应中返回其中一个响应代码。
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.
打开邮箱时，服务器必须检查邮箱是否支持mod序列的持久存储。如果邮箱支持mod序列的持久存储，并且邮箱打开操作成功，则服务器必须发送OK Untaged响应，包括HIGHESTMODSEQ响应代码。如果不支持邮箱的持久存储，则服务器必须发送OK Untaged响应，包括NOMODSEQ响应代码。
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 untagged响应中返回。支持邮箱mod序列持久存储的服务器必须在每个成功的SELECT或EXAMINE命令中发送OK untagged响应，包括HIGHESTMODSEQ响应代码：
OK [HIGHESTMODSEQ <mod-sequence-value>]
正常[最高ModSeq<mod sequence value>]
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.
其中<mod sequence value>是邮箱中所有邮件的最高mod sequence值。当服务器更改邮箱的UIDVality时，它不必为邮箱保持相同的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的值来检查是否必须从服务器重新提取元数据。如果选定邮箱的UIDVality值已更改，则客户端必须删除高速缓存的HIGHESTMODSEQ值。如果邮箱的UIDVality相同，并且客户端缓存中存储的HIGHESTMODSEQ值小于服务器返回的值，则服务器上的某些元数据项自上次同步以来已更改，客户端需要更新其缓存。客户可以使用SEARCH MODSEQ（第3.4节）准确地找出哪些元数据项已更改。或者，客户机可以使用CHANGEDSINCE修饰符（第3.3.1节）发出FETCH命令，以获取元数据项在某些已知修改序列之后发生更改的所有消息的数据。
Example 1:
例1：
C: A142 SELECT INBOX
S: * 172 EXISTS
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 [HIGHESTMODSEQ 715194045007]
S: A142 OK [READ-WRITE] SELECT completed
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
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:
不支持邮箱mod序列的持久存储的服务器必须在每个成功的SELECT或EXAMINE命令中发送OK untaged响应，包括NOMODSEQ响应代码。为邮箱返回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或SEARCH命令，-带有UNCHANGEDSINCE修饰符的STORE命令
MUST reject any such command with the tagged BAD response.
必须拒绝带有标记错误响应的任何此类命令。
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 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
This document defines the following STORE modifier (see Section 2.5 of [IMAPABNF]):
本文件定义了以下存储修饰符（见[IMAPABNF]第2.5节）：
UNCHANGEDSINCE <mod-sequence>
不变自<mod sequence>
For each message specified in the message set, the server performs the following. If the mod-sequence of any metadata item of the
对于消息集中指定的每条消息，服务器执行以下操作。如果
message is equal or less than the specified UNCHANGEDSINCE value, then the requested operation (as described by the message data item) is performed. If the operation is successful, the server MUST update the mod-sequence attribute of the message. An untagged FETCH response MUST be sent, even if the .SILENT suffix is specified, and the response MUST include the MODSEQ message data item. This is required to update the client's cache with the correct mod-sequence values. See Section 3.3.2 for more details.
消息等于或小于指定的UNCHANGEDSINCE值，则执行请求的操作（如消息数据项所述）。如果操作成功，服务器必须更新消息的mod sequence属性。即使指定了.SILENT后缀，也必须发送未标记的获取响应，并且响应必须包括MODSEQ消息数据项。这是使用正确的mod sequence值更新客户端缓存所必需的。详见第3.3.2节。
However, if the mod-sequence of any metadata item of the message is greater than the specified UNCHANGEDSINCE value, then the requested operation MUST NOT be performed. In this case, the mod-sequence attribute of the message is not updated, and the message number (or unique identifier in the case of the UID STORE command) is added to the list of messages that failed the UNCHANGESINCE test.
但是，如果消息的任何元数据项的mod sequence大于指定的UNCHANGEDSINCE值，则不得执行请求的操作。在这种情况下，消息的mod sequence属性不会更新，消息编号（或UID STORE命令中的唯一标识符）将添加到未通过UNCHANGEFISH测试的消息列表中。
When the server finished performing the operation on all the messages in the message set, it checks for a non-empty list of messages that failed the UNCHANGESINCE test. If this list is non-empty, the server MUST return in the tagged response a MODIFIED response code. The MODIFIED response code includes the message set (for STORE) or set of UIDs (for UID STORE) of all messages that failed the UNCHANGESINCE test.
当服务器完成对消息集中的所有消息执行操作时，它会检查未通过UNCHANGESINCE测试的消息的非空列表。如果此列表非空，服务器必须在标记的响应中返回修改的响应代码。修改后的响应代码包括未通过UNCHANGESINCE测试的所有消息的消息集（用于存储）或UID集（用于UID存储）。
Example 3:
例3：
All messages pass the UNCHANGESINCE test.
所有消息都通过了unchangefaster测试。
C: a103 UID STORE 6,4,8 (UNCHANGEDSINCE 12121230045)
+FLAGS.SILENT (\Deleted)
S: * 1 FETCH (UID 4 MODSEQ (12121231000))
S: * 2 FETCH (UID 6 MODSEQ (12121230852))
S: * 4 FETCH (UID 8 MODSEQ (12121130956))
S: a103 OK Conditional Store completed
C: a103 UID STORE 6,4,8 (UNCHANGEDSINCE 12121230045)
+FLAGS.SILENT (\Deleted)
S: * 1 FETCH (UID 4 MODSEQ (12121231000))
S: * 2 FETCH (UID 6 MODSEQ (12121230852))
S: * 4 FETCH (UID 8 MODSEQ (12121130956))
S: a103 OK Conditional Store completed
Example 4:
例4：
C: a104 STORE * (UNCHANGEDSINCE 12121230045) +FLAGS.SILENT
(\Deleted $Processed)
S: * 50 FETCH (MODSEQ (12111230047))
S: a104 OK Store (conditional) completed
C: a104 STORE * (UNCHANGEDSINCE 12121230045) +FLAGS.SILENT
(\Deleted $Processed)
S: * 50 FETCH (MODSEQ (12111230047))
S: a104 OK Store (conditional) completed
Example 5:
例5：
C: c101 STORE 1 (UNCHANGEDSINCE 12121230045) -FLAGS.SILENT
(\Deleted)
S: * OK [HIGHESTMODSEQ 12111230047]
C: c101 STORE 1 (UNCHANGEDSINCE 12121230045) -FLAGS.SILENT
(\Deleted)
S: * OK [HIGHESTMODSEQ 12111230047]
S: * 50 FETCH (MODSEQ (12111230048))
S: c101 OK Store (conditional) completed
S: * 50 FETCH (MODSEQ (12111230048))
S: c101 OK Store (conditional) completed
HIGHESTMODSEQ response code was sent by the server presumably because this was the first CONDSTORE enabling command.
HIGHESTMODSEQ响应代码由服务器发送，可能是因为这是第一个CONDSTORE启用命令。
Example 6:
例6：
In spite of the failure of the conditional STORE operation for message 7, the server continues to process the conditional STORE in order to find all messages that fail the test.
尽管消息7的条件存储操作失败，服务器仍继续处理条件存储，以查找所有未通过测试的消息。
C: d105 STORE 7,5,9 (UNCHANGEDSINCE 320162338)
+FLAGS.SILENT (\Deleted)
S: * 5 FETCH (MODSEQ (320162350))
S: d105 OK [MODIFIED 7,9] Conditional STORE failed
C: d105 STORE 7,5,9 (UNCHANGEDSINCE 320162338)
+FLAGS.SILENT (\Deleted)
S: * 5 FETCH (MODSEQ (320162350))
S: d105 OK [MODIFIED 7,9] Conditional STORE failed
Example 7:
例7：
Same as above, but the server follows the SHOULD recommendation in Section 6.4.6 of [IMAP4].
同上，但服务器应遵循[IMAP4]第6.4.6节中的建议。
C: d105 STORE 7,5,9 (UNCHANGEDSINCE 320162338)
+FLAGS.SILENT (\Deleted)
S: * 7 FETCH (MODSEQ (320162342) FLAGS (\Seen \Deleted))
S: * 5 FETCH (MODSEQ (320162350))
S: * 9 FETCH (MODSEQ (320162349) FLAGS (\Answered))
S: d105 OK [MODIFIED 7,9] Conditional STORE failed
C: d105 STORE 7,5,9 (UNCHANGEDSINCE 320162338)
+FLAGS.SILENT (\Deleted)
S: * 7 FETCH (MODSEQ (320162342) FLAGS (\Seen \Deleted))
S: * 5 FETCH (MODSEQ (320162350))
S: * 9 FETCH (MODSEQ (320162349) FLAGS (\Answered))
S: d105 OK [MODIFIED 7,9] Conditional STORE failed
Use of UNCHANGEDSINCE with a modification sequence of 0 always fails if the metadata item exists. A system flag MUST always be considered existent, whether it was set or not.
如果元数据项存在，则使用修改序列为0的UNCHANGEDSINCE始终失败。无论是否设置了系统标志，都必须始终将其视为存在。
Example 8:
例8：
C: a102 STORE 12 (UNCHANGEDSINCE 0)
+FLAGS.SILENT ($MDNSent)
S: a102 OK [MODIFIED 12] Conditional STORE failed
C: a102 STORE 12 (UNCHANGEDSINCE 0)
+FLAGS.SILENT ($MDNSent)
S: a102 OK [MODIFIED 12] Conditional STORE failed
The client has tested the presence of the $MDNSent user-defined keyword.
客户端已测试$MDNSent用户定义关键字的存在性。
Note: A client trying to make an atomic change to the state of a particular metadata item (or a set of metadata items) should be prepared to deal with the case when the server returns the MODIFIED response code if the state of the metadata item being watched hasn't changed (but the state of some other metadata item has). This is necessary, because some servers don't store separate mod-sequences
注意：试图对特定元数据项（或一组元数据项）的状态进行原子更改的客户机应准备好处理这样的情况：如果正在监视的元数据项的状态没有更改（但某些其他元数据项的状态已更改），服务器将返回修改后的响应代码。这是必要的，因为有些服务器不存储单独的mod序列
for different metadata items. However, a server implementation SHOULD avoid generating spurious MODIFIED responses for +FLAGS/-FLAGS STORE operations, even when the server stores a single mod-sequence per message. Section 5 describes how this can be achieved.
用于不同的元数据项。但是，服务器实现应该避免为+FLAGS/-FLAGS存储操作生成虚假的修改响应，即使在服务器为每条消息存储单个mod序列时也是如此。第5节描述了如何实现这一点。
Unless the server has included an unsolicited FETCH to update client's knowledge about messages that have failed the UNCHANGEDSINCE test, upon receipt of the MODIFIED response code, the client SHOULD try to figure out if the required metadata items have indeed changed by issuing FETCH or NOOP command. It is RECOMMENDED that the server avoids the need for the client to do that by sending an unsolicited FETCH response (Examples 9 and 10).
除非服务器包含一个未经请求的FETCH来更新客户端对未通过UNCHANGEDSINCE测试的消息的了解，否则在收到修改后的响应代码后，客户端应该通过发出FETCH或NOOP命令来尝试确定所需的元数据项是否确实发生了更改。建议服务器通过发送未经请求的获取响应（示例9和10），避免客户机执行此操作。
If the required metadata items haven't changed, the client SHOULD retry the command with the new mod-sequence. The client SHOULD allow for a configurable but reasonable number of retries (at least 2).
如果所需的元数据项没有更改，客户端应使用新的mod序列重试该命令。客户端应允许可配置但合理的重试次数（至少2次）。
Example 9:
例9：
In the example below, the server returns the MODIFIED response code without sending information describing why the STORE UNCHANGEDSINCE operation has failed.
在下面的示例中，服务器返回修改后的响应代码，而不发送描述STORE UNCHANGEDSINCE操作失败原因的信息。
C: a106 STORE 100:150 (UNCHANGEDSINCE 212030000000)
+FLAGS.SILENT ($Processed)
S: * 100 FETCH (MODSEQ (303181230852))
S: * 102 FETCH (MODSEQ (303181230852))
...
S: * 150 FETCH (MODSEQ (303181230852))
S: a106 OK [MODIFIED 101] Conditional STORE failed
C: a106 STORE 100:150 (UNCHANGEDSINCE 212030000000)
+FLAGS.SILENT ($Processed)
S: * 100 FETCH (MODSEQ (303181230852))
S: * 102 FETCH (MODSEQ (303181230852))
...
S: * 150 FETCH (MODSEQ (303181230852))
S: a106 OK [MODIFIED 101] Conditional STORE failed
The flag $Processed was set on the message 101...
已在消息101上设置标志$Processed。。。
C: a107 NOOP
S: * 101 FETCH (MODSEQ (303011130956) FLAGS ($Processed))
S: a107 OK
C: a107 NOOP
S: * 101 FETCH (MODSEQ (303011130956) FLAGS ($Processed))
S: a107 OK
Or the flag hasn't changed, but another has (note that this server behaviour is discouraged. Server implementers should also see Section 5)...
或者该标志没有更改，但另一个标志已更改（请注意，不鼓励这种服务器行为。服务器实现者还应参阅第5节）。。。
C: b107 NOOP
S: * 101 FETCH (MODSEQ (303011130956) FLAGS (\Deleted \Answered))
S: b107 OK
C: b107 NOOP
S: * 101 FETCH (MODSEQ (303011130956) FLAGS (\Deleted \Answered))
S: b107 OK
...and the client retries the operation for the message 101 with the updated UNCHANGEDSINCE value
…并且客户端使用更新后的UNCHANGEDSINCE值重试消息101的操作
C: b108 STORE 101 (UNCHANGEDSINCE 303011130956)
+FLAGS.SILENT ($Processed)
S: * 101 FETCH (MODSEQ (303181230852))
S: b108 OK Conditional Store completed
C: b108 STORE 101 (UNCHANGEDSINCE 303011130956)
+FLAGS.SILENT ($Processed)
S: * 101 FETCH (MODSEQ (303181230852))
S: b108 OK Conditional Store completed
Example 10:
例10：
Same as above, but the server avoids the need for the client to poll for changes.
同上，但服务器避免了客户端轮询更改的需要。
The flag $Processed was set on the message 101 by another client...
另一个客户端在消息101上设置了标志$Processed。。。
C: a106 STORE 100:150 (UNCHANGEDSINCE 212030000000)
+FLAGS.SILENT ($Processed)
S: * 100 FETCH (MODSEQ (303181230852))
S: * 101 FETCH (MODSEQ (303011130956) FLAGS ($Processed))
S: * 102 FETCH (MODSEQ (303181230852))
...
S: * 150 FETCH (MODSEQ (303181230852))
S: a106 OK [MODIFIED 101] Conditional STORE failed
C: a106 STORE 100:150 (UNCHANGEDSINCE 212030000000)
+FLAGS.SILENT ($Processed)
S: * 100 FETCH (MODSEQ (303181230852))
S: * 101 FETCH (MODSEQ (303011130956) FLAGS ($Processed))
S: * 102 FETCH (MODSEQ (303181230852))
...
S: * 150 FETCH (MODSEQ (303181230852))
S: a106 OK [MODIFIED 101] Conditional STORE failed
Or the flag hasn't changed, but another has (note that this server behaviour is discouraged. Server implementers should also see Section 5)...
或者该标志没有更改，但另一个标志已更改（请注意，不鼓励这种服务器行为。服务器实现者还应参阅第5节）。。。
C: a106 STORE 100:150 (UNCHANGEDSINCE 212030000000)
+FLAGS.SILENT ($Processed)
S: * 100 FETCH (MODSEQ (303181230852))
S: * 101 FETCH (MODSEQ (303011130956) FLAGS (\Deleted \Answered))
S: * 102 FETCH (MODSEQ (303181230852))
...
S: * 150 FETCH (MODSEQ (303181230852))
S: a106 OK [MODIFIED 101] Conditional STORE failed
C: a106 STORE 100:150 (UNCHANGEDSINCE 212030000000)
+FLAGS.SILENT ($Processed)
S: * 100 FETCH (MODSEQ (303181230852))
S: * 101 FETCH (MODSEQ (303011130956) FLAGS (\Deleted \Answered))
S: * 102 FETCH (MODSEQ (303181230852))
...
S: * 150 FETCH (MODSEQ (303181230852))
S: a106 OK [MODIFIED 101] Conditional STORE failed
...and the client retries the operation for the message 101 with the updated UNCHANGEDSINCE value
…并且客户端使用更新后的UNCHANGEDSINCE值重试消息101的操作
C: b108 STORE 101 (UNCHANGEDSINCE 303011130956)
+FLAGS.SILENT ($Processed)
S: * 101 FETCH (MODSEQ (303181230852))
S: b108 OK Conditional Store completed
C: b108 STORE 101 (UNCHANGEDSINCE 303011130956)
+FLAGS.SILENT ($Processed)
S: * 101 FETCH (MODSEQ (303181230852))
S: b108 OK Conditional Store completed
Or the flag hasn't changed, but another has (nice server behaviour. Server implementers should also see Section 5)...
或者该标志没有改变，但另一个标志改变了（良好的服务器行为。服务器实现者还应参见第5节）。。。
C: a106 STORE 100:150 (UNCHANGEDSINCE 212030000000) +FLAGS.SILENT ($Processed)
C:a106存储100:150（自212030000000起保持不变）+FLAGS.SILENT（$Processed）
S: * 100 FETCH (MODSEQ (303181230852))
S: * 101 FETCH (MODSEQ (303011130956) FLAGS ($Processed \Deleted
\Answered))
S: * 102 FETCH (MODSEQ (303181230852))
...
S: * 150 FETCH (MODSEQ (303181230852))
S: a106 OK Conditional STORE completed
S: * 100 FETCH (MODSEQ (303181230852))
S: * 101 FETCH (MODSEQ (303011130956) FLAGS ($Processed \Deleted
\Answered))
S: * 102 FETCH (MODSEQ (303181230852))
...
S: * 150 FETCH (MODSEQ (303181230852))
S: a106 OK Conditional STORE completed
Example 11:
例11：
The following example is based on the example from the Section 4.2.3 of [RFC-2180] and demonstrates that the MODIFIED response code may be also returned in the tagged NO response.
以下示例基于[RFC-2180]第4.2.3节中的示例，并证明修改后的响应代码也可以在标记的无响应中返回。
Client tries to conditionally STORE flags on a mixture of expunged and non-expunged messages; one message fails the UNCHANGEDSINCE test.
客户端尝试在已删除和未删除的消息的混合上有条件地存储标志；一条消息未通过未更改的自测试。
C: B001 STORE 1:7 (UNCHANGEDSINCE 320172338) +FLAGS (\SEEN)
S: * 1 FETCH (MODSEQ (320172342) FLAGS (\SEEN))
S: * 3 FETCH (MODSEQ (320172342) FLAGS (\SEEN))
S: B001 NO [MODIFIED 2] Some of the messages no longer exist.
C: B001 STORE 1:7 (UNCHANGEDSINCE 320172338) +FLAGS (\SEEN)
S: * 1 FETCH (MODSEQ (320172342) FLAGS (\SEEN))
S: * 3 FETCH (MODSEQ (320172342) FLAGS (\SEEN))
S: B001 NO [MODIFIED 2] Some of the messages no longer exist.
C: B002 NOOP
S: * 4 EXPUNGE
S: * 4 EXPUNGE
S: * 4 EXPUNGE
S: * 4 EXPUNGE
S: * 2 FETCH (MODSEQ (320172340) FLAGS (\Deleted \Answered))
S: B002 OK NOOP Completed.
C: B002 NOOP
S: * 4 EXPUNGE
S: * 4 EXPUNGE
S: * 4 EXPUNGE
S: * 4 EXPUNGE
S: * 2 FETCH (MODSEQ (320172340) FLAGS (\Deleted \Answered))
S: B002 OK NOOP Completed.
By receiving FETCH responses for messages 1 and 3, and EXPUNGE responses that indicate that messages 4 through 7 have been expunged, the client retries the operation only for the message 2. The updated UNCHANGEDSINCE value is used.
通过接收消息1和3的FETCH响应，以及指示消息4到7已被删除的EXPUNGE响应，客户端仅对消息2重试该操作。使用更新后的未更改的初始值。
C: b003 STORE 2 (UNCHANGEDSINCE 320172340) +FLAGS (\Seen)
S: * 2 FETCH (MODSEQ (320180050))
S: b003 OK Conditional Store completed
C: b003 STORE 2 (UNCHANGEDSINCE 320172340) +FLAGS (\Seen)
S: * 2 FETCH (MODSEQ (320180050))
S: b003 OK Conditional Store completed
Note: If a message is specified multiple times in the message set, and the server doesn't internally eliminate duplicates from the message set, it MUST NOT fail the conditional STORE operation for the second (or subsequent) occurrence of the message if the operation completed successfully for the first occurrence. For example, if the client specifies:
注意：如果在消息集中多次指定消息，并且服务器没有在内部消除消息集中的重复项，则如果第一次操作成功完成，则对于第二次（或后续）出现的消息，服务器不得使条件存储操作失败。例如，如果客户端指定：
e105 STORE 7,3:9 (UNCHANGEDSINCE 12121230045) +FLAGS.SILENT (\Deleted)
e105存储7,3:9（自12121230045起未更改）+FLAGS.SILENT（\已删除）
the server must not fail the operation for message 7 as part of processing "3:9" if it succeeded when message 7 was processed the first time.
如果在第一次处理消息7时成功，则作为处理“3:9”的一部分，服务器不得使消息7的操作失败。
Once the client specified the UNCHANGEDSINCE modifier in a STORE command, the server MUST include the MODSEQ fetch response data items in all subsequent unsolicited FETCH responses.
一旦客户端在STORE命令中指定了UNCHANGEDSINCE修饰符，服务器就必须在所有后续未经请求的获取响应中包含MODSEQ获取响应数据项。
This document also changes the behaviour of the server when it has performed a STORE or UID STORE command and the UNCHANGEDSINCE modifier is not specified. If the operation is successful for a message, the server MUST update the mod-sequence attribute of the message. The server is REQUIRED to include the mod-sequence value whenever it decides to send the unsolicited FETCH response to all CONDSTORE-aware clients that have opened the mailbox containing the message.
当服务器执行STORE或UID STORE命令且未指定UNCHANGEDSINCE修饰符时，本文档还会更改服务器的行为。如果消息的操作成功，服务器必须更新消息的mod sequence属性。每当服务器决定将未经请求的获取响应发送给所有打开包含消息的邮箱的感知CONDSTORE的客户端时，服务器都需要包含mod sequence值。
Server implementers should also see Section 3.8 for additional quality of implementation issues related to the STORE command.
服务器实现者还应参阅第3.8节，了解与STORE命令相关的其他实现质量问题。
This document defines the following FETCH modifier (see Section 2.4 of [IMAPABNF]):
本文件定义了以下提取修饰符（见[IMAPABNF]第2.4节）：
CHANGEDSINCE <mod-sequence>
更改自<修改顺序>
CHANGEDSINCE FETCH modifier allows to create a further subset of the list of messages described by sequence set. The information described by message data items is only returned for messages that have mod-sequence bigger than <mod-sequence>.
CHANGEDSINCE FETCH修饰符允许创建序列集描述的消息列表的另一个子集。只有mod sequence大于<mod sequence>的消息才会返回消息数据项描述的信息。
When CHANGEDSINCE FETCH modifier is specified, it implicitly adds MODSEQ FETCH message data item (Section 3.3.2).
当指定CHANGEDSINCE FETCH修饰符时，它隐式添加MODSEQ FETCH消息数据项（第3.3.2节）。
Example 12:
例12：
C: s100 UID FETCH 1:* (FLAGS) (CHANGEDSINCE 12345)
S: * 1 FETCH (UID 4 MODSEQ (65402) FLAGS (\Seen))
S: * 2 FETCH (UID 6 MODSEQ (75403) FLAGS (\Deleted))
S: * 4 FETCH (UID 8 MODSEQ (29738) FLAGS ($NoJunk $AutoJunk
$MDNSent))
S: s100 OK FETCH completed
C: s100 UID FETCH 1:* (FLAGS) (CHANGEDSINCE 12345)
S: * 1 FETCH (UID 4 MODSEQ (65402) FLAGS (\Seen))
S: * 2 FETCH (UID 6 MODSEQ (75403) FLAGS (\Deleted))
S: * 4 FETCH (UID 8 MODSEQ (29738) FLAGS ($NoJunk $AutoJunk
$MDNSent))
S: s100 OK FETCH completed
This extension adds a MODSEQ message data item to the FETCH command. The MODSEQ message data item allows clients to retrieve mod-sequence values for a range of messages in the currently selected mailbox.
此扩展将MODSEQ消息数据项添加到FETCH命令中。MODSEQ消息数据项允许客户端检索当前选定邮箱中一系列消息的mod sequence值。
Once the client specified the MODSEQ message data item in a FETCH request, the server MUST include the MODSEQ fetch response data items in all subsequent unsolicited FETCH responses.
一旦客户端在获取请求中指定了MODSEQ消息数据项，服务器必须在所有后续未经请求的获取响应中包含MODSEQ获取响应数据项。
Syntax: MODSEQ
语法：MODSEQ
The MODSEQ message data item causes the server to return MODSEQ fetch response data items.
MODSEQ消息数据项导致服务器返回MODSEQ fetch响应数据项。
Syntax: MODSEQ ( <permsg-modsequence> )
Syntax: MODSEQ ( <permsg-modsequence> )
MODSEQ response data items contain per-message mod-sequences.
MODSEQ响应数据项包含每条消息的mod序列。
The MODSEQ response data item is returned if the client issued FETCH with MODSEQ message data item. It also allows the server to notify the client about mod-sequence changes caused by conditional STOREs (Section 3.2) and/or changes caused by external sources.
如果客户端使用MODSEQ消息数据项发出FETCH，则返回MODSEQ响应数据项。它还允许服务器将条件存储（第3.2节）引起的mod序列更改和/或外部源引起的更改通知客户机。
Example 13:
例13：
C: a FETCH 1:3 (MODSEQ)
S: * 1 FETCH (MODSEQ (624140003))
S: * 2 FETCH (MODSEQ (624140007))
S: * 3 FETCH (MODSEQ (624140005))
S: a OK Fetch complete
C: a FETCH 1:3 (MODSEQ)
S: * 1 FETCH (MODSEQ (624140003))
S: * 2 FETCH (MODSEQ (624140007))
S: * 3 FETCH (MODSEQ (624140005))
S: a OK Fetch complete
In this example, the client requests per-message mod-sequences for a set of messages.
在本例中，客户机请求一组消息的每条消息mod序列。
When a flag for a message is modified in a different session, the server sends an unsolicited FETCH response containing the mod-sequence for the message.
当在不同会话中修改消息的标志时，服务器将发送一个非请求的获取响应，其中包含消息的mod序列。
Example 14:
例14：
(Session 1, authenticated as a user "alex"). The user adds a shared flag \Deleted:
（会话1，身份验证为用户“alex”）。用户添加共享标志\已删除：
C: A142 SELECT INBOX
...
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [PERMANENTFLAGS (\Answered \Deleted \Seen \*)] Limited
C: A142 SELECT INBOX
...
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [PERMANENTFLAGS (\Answered \Deleted \Seen \*)] Limited
...
...
C: A160 STORE 7 +FLAGS.SILENT (\Deleted)
S: * 7 FETCH (MODSEQ (2121231000))
S: A160 OK Store completed
C: A160 STORE 7 +FLAGS.SILENT (\Deleted)
S: * 7 FETCH (MODSEQ (2121231000))
S: A160 OK Store completed
(Session 2, also authenticated as the user "alex"). Any changes to flags are always reported to all sessions authenticated as the same user as in the session 1.
（会话2，也被认证为用户“alex”）。对标志的任何更改始终报告给作为会话1中的同一用户进行身份验证的所有会话。
C: C180 NOOP
S: * 7 FETCH (FLAGS (\Deleted \Answered) MODSEQ (12121231000))
S: C180 OK Noop completed
C: C180 NOOP
S: * 7 FETCH (FLAGS (\Deleted \Answered) MODSEQ (12121231000))
S: C180 OK Noop completed
(Session 3, authenticated as a user "andrew"). As \Deleted is a shared flag, changes in session 1 are also reported in session 3:
（会话3，身份验证为用户“andrew”）。由于\Deleted是一个共享标志，会话1中的更改也会在会话3中报告：
C: D210 NOOP
S: * 7 FETCH (FLAGS (\Deleted \Answered) MODSEQ (12121231000))
S: D210 OK Noop completed
C: D210 NOOP
S: * 7 FETCH (FLAGS (\Deleted \Answered) MODSEQ (12121231000))
S: D210 OK Noop completed
The user modifies a private flag \Seen in session 1...
用户修改会话1中的私有标志\n。。。
C: A240 STORE 7 +FLAGS.SILENT (\Seen)
S: * 7 FETCH (MODSEQ (12121231777))
S: A240 OK Store completed
C: A240 STORE 7 +FLAGS.SILENT (\Seen)
S: * 7 FETCH (MODSEQ (12121231777))
S: A240 OK Store completed
...which is only reported in session 2...
…仅在第2课时报告。。。
C: C270 NOOP
S: * 7 FETCH (FLAGS (\Deleted \Answered \Seen) MODSEQ
(12121231777))
S: C270 OK Noop completed
C: C270 NOOP
S: * 7 FETCH (FLAGS (\Deleted \Answered \Seen) MODSEQ
(12121231777))
S: C270 OK Noop completed
...but not in session 3.
…但不是在第3课时。
C: D300 NOOP
S: D300 OK Noop completed
C: D300 NOOP
S: D300 OK Noop completed
And finally, the user removes flags \Answered (shared) and \Seen (private) in session 1.
最后，用户在会话1中删除\respond（共享）和\Seen（私有）标志。
C: A330 STORE 7 -FLAGS.SILENT (\Answered \Seen)
S: * 7 FETCH (MODSEQ (12121245160))
S: A330 OK Store completed
C: A330 STORE 7 -FLAGS.SILENT (\Answered \Seen)
S: * 7 FETCH (MODSEQ (12121245160))
S: A330 OK Store completed
Both changes are reported in the session 2...
这两项更改都将在第2课时中报告。。。
C: C360 NOOP
S: * 7 FETCH (FLAGS (\Deleted) MODSEQ (12121245160))
S: C360 OK Noop completed
C: C360 NOOP
S: * 7 FETCH (FLAGS (\Deleted) MODSEQ (12121245160))
S: C360 OK Noop completed
...and only changes to shared flags are reported in session 3.
…并且在会话3中仅报告对共享标志的更改。
C: D390 NOOP
S: * 7 FETCH (FLAGS (\Deleted) MODSEQ (12121245160))
S: D390 OK Noop completed
C: D390 NOOP
S: * 7 FETCH (FLAGS (\Deleted) MODSEQ (12121245160))
S: D390 OK Noop completed
Server implementers should also see Section 3.8 for additional quality of implementation issues related to the FETCH command.
服务器实现者还应参阅第3.8节，了解与FETCH命令相关的其他实现质量问题。
The MODSEQ criterion for the SEARCH command allows a client to search for the metadata items that were modified since a specified moment.
SEARCH命令的MODSEQ标准允许客户端搜索自指定时刻以来修改的元数据项。
Syntax: MODSEQ [<entry-name> <entry-type-req>] <mod-sequence-valzer>
Syntax: MODSEQ [<entry-name> <entry-type-req>] <mod-sequence-valzer>
Messages that have modification values that are equal to or greater than <mod-sequence-valzer>. This allows a client, for example, to find out which messages contain metadata items that have changed since the last time it updated its disconnected cache. The client may also specify <entry-name> (name of metadata item) and <entry-type-req> (type of metadata item) before <mod-sequence-valzer>. <entry-type-req> can be one of "shared", "priv" (private), or "all". The latter means that the server should use the biggest value among "priv" and "shared" mod-sequences for the metadata item. If the server doesn't store internally separate mod-sequences for different metadata items, it MUST ignore <entry-name> and <entry-type-req>. Otherwise, the server should use them to narrow down the search.
修改值等于或大于<mod sequence valzer>的消息。例如，这允许客户端找出哪些消息包含自上次更新其断开连接的缓存以来已更改的元数据项。客户端还可以在<mod sequence valzer>之前指定<entry name>（元数据项的名称）和<entry type req>（元数据项的类型）<条目类型req>可以是“共享”、“私有”（私有）或“全部”中的一种。后者意味着服务器应该为元数据项使用“priv”和“shared”mod序列中的最大值。如果服务器没有在内部为不同的元数据项存储单独的mod序列，则必须忽略<entry name>和<entry type req>。否则，服务器应该使用它们来缩小搜索范围。
For a flag <flagname>, the corresponding <entry-name> has a form "/flags/<flagname>" as defined in [IMAPABNF]. Note that the leading "\" character that denotes a system flag has to be escaped as per Section 4.3 of [IMAP4], as the <entry-name> uses syntax for quoted strings.
对于标志<flagname>，对应的<entry name>具有[IMAPABNF]中定义的格式“/flags/<flagname>”。请注意，表示系统标志的前导“\”字符必须根据[IMAP4]第4.3节进行转义，因为<entry name>对带引号的字符串使用语法。
If client specifies a MODSEQ criterion in a SEARCH command and the server returns a non-empty SEARCH result, the server MUST also append (to the end of the untagged SEARCH response) the highest mod-sequence for all messages being returned. See also Section 3.5.
如果客户端在搜索命令中指定MODSEQ条件，并且服务器返回非空的搜索结果，则服务器还必须为所有返回的消息追加（到未标记的搜索响应的末尾）最高的mod序列。另见第3.5节。
Example 15:
例15：
C: a SEARCH MODSEQ "/flags/\\draft" all 620162338
S: * SEARCH 2 5 6 7 11 12 18 19 20 23 (MODSEQ 917162500)
S: a OK Search complete
C: a SEARCH MODSEQ "/flags/\\draft" all 620162338
S: * SEARCH 2 5 6 7 11 12 18 19 20 23 (MODSEQ 917162500)
S: a OK Search complete
In the above example, the message numbers of any messages containing the string "IMAP4" in the "value" attribute of the "/comment" entry and having a mod-sequence equal to or greater than 620162338 for the "\Draft" flag are returned in the search results.
在上面的示例中，搜索结果中返回在“/comment”条目的“value”属性中包含字符串“IMAP4”且“\Draft”标志的mod序列等于或大于620162338的任何消息的消息编号。
Example 16:
例16：
C: t SEARCH OR NOT MODSEQ 720162338 LARGER 50000
S: * SEARCH
S: t OK Search complete, nothing found
C: t SEARCH OR NOT MODSEQ 720162338 LARGER 50000
S: * SEARCH
S: t OK Search complete, nothing found
Data: zero or more numbers mod-sequence value (omitted if no match)
数据：零个或多个数字mod序列值（如果不匹配则省略）
This document extends syntax of the untagged SEARCH response to include the highest mod-sequence for all messages being returned.
本文档扩展了未标记搜索响应的语法，以包含返回的所有消息的最高mod序列。
If a client specifies a MODSEQ criterion in a SEARCH (or UID SEARCH) command and the server returns a non-empty SEARCH result, the server MUST also append (to the end of the untagged SEARCH response) the highest mod-sequence for all messages being returned. See Section 3.4 for examples.
如果客户端在搜索（或UID搜索）命令中指定MODSEQ条件，并且服务器返回非空搜索结果，则服务器还必须为返回的所有消息追加（到未标记搜索响应的末尾）最高mod序列。示例见第3.4节。
This document defines a new status data item:
本文档定义了一个新的状态数据项：
HIGHESTMODSEQ
最高ModSeq
The highest mod-sequence value of all messages in the mailbox. This is the same value that is returned by the server in the HIGHESTMODSEQ response code in an OK untagged response (see Section 3.1.1). If the server doesn't support the persistent storage of mod-sequences for the mailbox (see Section 3.1.2), the server MUST return 0 as the value of HIGHESTMODSEQ status data item.
邮箱中所有邮件的最高mod sequence值。这与服务器在OK Untaged响应（见第3.1.1节）的HIGHESTMODSEQ响应代码中返回的值相同。如果服务器不支持邮箱mod序列的持久存储（请参阅第3.1.2节），则服务器必须返回0作为HIGHESTMODSEQ状态数据项的值。
Example 17:
例17：
C: A042 STATUS blurdybloop (UIDNEXT MESSAGES HIGHESTMODSEQ)
S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292
HIGHESTMODSEQ 7011231777)
S: A042 OK STATUS completed
C: A042 STATUS blurdybloop (UIDNEXT MESSAGES HIGHESTMODSEQ)
S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292
HIGHESTMODSEQ 7011231777)
S: A042 OK STATUS completed
The CONDSTORE extension defines a single optional select parameter, "CONDSTORE", which tells the server that it MUST include the MODSEQ fetch response data items in all subsequent unsolicited FETCH responses.
CONDSTORE扩展定义了一个可选的选择参数“CONDSTORE”，它告诉服务器，它必须在所有后续未经请求的获取响应中包含MODSEQ获取响应数据项。
The CONDSTORE parameter to SELECT/EXAMINE helps avoid a race condition that might arise when one or more metadata items are modified in another session after the server has sent the HIGHESTMODSEQ response code and before the client was able to issue a CONDSTORE enabling command.
要选择/检查的CONDSTORE参数有助于避免在服务器发送HIGHESTMODSEQ响应代码之后、客户端能够发出CONDSTORE启用命令之前，在另一个会话中修改一个或多个元数据项时可能出现的争用情况。
Example 18:
例18：
C: A142 SELECT INBOX (CONDSTORE)
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 [HIGHESTMODSEQ 715194045007]
S: A142 OK [READ-WRITE] SELECT completed, CONDSTORE is now enabled
C: A142 SELECT INBOX (CONDSTORE)
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 [HIGHESTMODSEQ 715194045007]
S: A142 OK [READ-WRITE] SELECT completed, CONDSTORE is now enabled
Server implementations should follow the following rule, which applies to any successfully completed STORE/UID STORE (with and without UNCHANGEDSINCE modifier), as well as to a FETCH command that implicitly sets \Seen flag:
服务器实现应遵循以下规则，该规则适用于任何成功完成的存储/UID存储（带或不带UNCHANGEDSINCE修饰符），以及隐式设置\Seen标志的FETCH命令：
Adding the flag when it is already present or removing when it is not present SHOULD NOT change the mod-sequence.
当标志已经存在时添加标志或当标志不存在时删除标志不应改变mod序列。
This will prevent spurious client synchronization requests.
这将防止虚假的客户端同步请求。
However, note that client implementers MUST NOT rely on this server behavior. A client can't distinguish between the case when a server has violated the SHOULD mentioned above, and that when one or more clients set and unset (or unset and set) the flag in another session.
但是，请注意，客户机实现者不能依赖此服务器行为。客户机无法区分服务器违反上述应该的情况，以及一个或多个客户机在另一个会话中设置并取消设置（或取消设置并设置）标志的情况。
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) [ABNF] notation. Elements not defined here can be found in the formal syntax of the ABNF [ABNF], IMAP [IMAP4], and IMAP ABNF extensions [IMAPABNF] specifications.
以下语法规范使用增广的Backus-Naur形式（ABNF）[ABNF]表示法。这里未定义的元素可以在ABNF[ABNF]、IMAP[IMAP4]和IMAP ABNF扩展[IMAPABNF]规范的形式语法中找到。
Except as noted otherwise, all alphabetic characters are case-insensitive. The use of upper- or lowercase characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion.
除非另有说明，否则所有字母字符都不区分大小写。使用大写或小写字符定义标记字符串仅用于编辑清晰性。实现必须以不区分大小写的方式接受这些字符串。
capability =/ "CONDSTORE"
能力=/“CONDSTORE”
status-att =/ "HIGHESTMODSEQ" ;; extends non-terminal defined in RFC 3501.
状态att=/“最高级ModSeq”；；扩展RFC 3501中定义的非终端。
status-att-val =/ "HIGHESTMODSEQ" SP mod-sequence-valzer
;; extends non-terminal defined in [IMAPABNF].
;; Value 0 denotes that the mailbox doesn't
;; support persistent mod-sequences
;; as described in Section 3.1.2
status-att-val =/ "HIGHESTMODSEQ" SP mod-sequence-valzer
;; extends non-terminal defined in [IMAPABNF].
;; Value 0 denotes that the mailbox doesn't
;; support persistent mod-sequences
;; as described in Section 3.1.2
store-modifier =/ "UNCHANGEDSINCE" SP mod-sequence-valzer
;; Only a single "UNCHANGEDSINCE" may be
;; specified in a STORE operation
store-modifier =/ "UNCHANGEDSINCE" SP mod-sequence-valzer
;; Only a single "UNCHANGEDSINCE" may be
;; specified in a STORE operation
fetch-modifier =/ chgsince-fetch-mod ;; conforms to the generic "fetch-modifier" ;; syntax defined in [IMAPABNF].
fetch修饰符=/chgsince fetch mod；；符合通用的“提取修饰符”；；[IMAPABNF]中定义的语法。
chgsince-fetch-mod = "CHANGEDSINCE" SP mod-sequence-value
;; CHANGEDSINCE FETCH modifier conforms to
;; the fetch-modifier syntax
chgsince-fetch-mod = "CHANGEDSINCE" SP mod-sequence-value
;; CHANGEDSINCE FETCH modifier conforms to
;; the fetch-modifier syntax
fetch-att =/ fetch-mod-sequence
;; modifies original IMAP4 fetch-att
fetch-att =/ fetch-mod-sequence
;; modifies original IMAP4 fetch-att
fetch-mod-sequence = "MODSEQ"
fetch-mod-sequence = "MODSEQ"
fetch-mod-resp = "MODSEQ" SP "(" permsg-modsequence ")"
fetch mod resp=“MODSEQ”SP”（“permsg modsequence”）
msg-att-dynamic =/ fetch-mod-resp
msg att dynamic=/fetch mod resp
search-key =/ search-modsequence
;; modifies original IMAP4 search-key
;;
;; This change applies to all commands
;; referencing this non-terminal, in
;; particular SEARCH.
search-key =/ search-modsequence
;; modifies original IMAP4 search-key
;;
;; This change applies to all commands
;; referencing this non-terminal, in
;; particular SEARCH.
search-modsequence = "MODSEQ" [search-modseq-ext] SP mod-sequence-valzer
search modsequence=“MODSEQ”[search MODSEQ ext]SP mod sequence valzer
search-modseq-ext = SP entry-name SP entry-type-req
search-modseq-ext = SP entry-name SP entry-type-req
resp-text-code =/ "HIGHESTMODSEQ" SP mod-sequence-value / "NOMODSEQ" / "MODIFIED" SP set
响应文本代码=/“HIGHESTMODSEQ”SP模块序列值/“NOMODSEQ”/“MODIFIED”SP集合
entry-name = entry-flag-name
entry-name = entry-flag-name
entry-flag-name = DQUOTE "/flags/" attr-flag DQUOTE
;; each system or user defined flag <flag>
;; is mapped to "/flags/<flag>".
;;
;; <entry-flag-name> follows the escape rules
;; used by "quoted" string as described in
;; Section 4.3 of [IMAP4], e.g., for the flag
;; \Seen the corresponding <entry-name> is
;; "/flags/\\seen", and for the flag
;; $MDNSent, the corresponding <entry-name>
;; is "/flags/$mdnsent".
entry-flag-name = DQUOTE "/flags/" attr-flag DQUOTE
;; each system or user defined flag <flag>
;; is mapped to "/flags/<flag>".
;;
;; <entry-flag-name> follows the escape rules
;; used by "quoted" string as described in
;; Section 4.3 of [IMAP4], e.g., for the flag
;; \Seen the corresponding <entry-name> is
;; "/flags/\\seen", and for the flag
;; $MDNSent, the corresponding <entry-name>
;; is "/flags/$mdnsent".
entry-type-resp = "priv" / "shared"
;; metadata item type
entry-type-resp = "priv" / "shared"
;; metadata item type
entry-type-req = entry-type-resp / "all"
;; perform SEARCH operation on private
;; metadata item, shared metadata item or both
entry-type-req = entry-type-resp / "all"
;; perform SEARCH operation on private
;; metadata item, shared metadata item or both
permsg-modsequence = mod-sequence-value ;; per message mod-sequence
permsg modsequence=mod sequence值；；每消息模式序列
mod-sequence-value = 1*DIGIT
;; Positive unsigned 64-bit integer
;; (mod-sequence)
;; (1 <= n < 18,446,744,073,709,551,615)
mod-sequence-value = 1*DIGIT
;; Positive unsigned 64-bit integer
;; (mod-sequence)
;; (1 <= n < 18,446,744,073,709,551,615)
mod-sequence-valzer = "0" / mod-sequence-value
mod sequence valzer=“0”/mod sequence值
search-sort-mod-seq = "(" "MODSEQ" SP mod-sequence-value ")"
搜索排序mod seq=“（“MODSEQ”SP mod sequence value”）”
select-param =/ condstore-param ;; conforms to the generic "select-param" ;; non-terminal syntax defined in [IMAPABNF].
选择param=/condstore param；；符合通用的“选择参数”；；[IMAPABNF]中定义的非终端语法。
condstore-param = "CONDSTORE"
condstore-param = "CONDSTORE"
mailbox-data =/ "SEARCH" [1*(SP nz-number) SP search-sort-mod-seq]
邮箱数据=/“搜索”[1*（SP nz编号）SP搜索排序模式顺序]
attr-flag = "\\Answered" / "\\Flagged" / "\\Deleted" /
"\\Seen" / "\\Draft" / attr-flag-keyword /
attr-flag-extension
;; Does not include "\\Recent"
attr-flag = "\\Answered" / "\\Flagged" / "\\Deleted" /
"\\Seen" / "\\Draft" / attr-flag-keyword /
attr-flag-extension
;; Does not include "\\Recent"
attr-flag-extension = "\\" atom
;; Future expansion. Client implementations
;; MUST accept flag-extension flags. Server
;; implementations MUST NOT generate
;; flag-extension flags except as defined by
;; future standard or standards-track
;; revisions of [IMAP4].
attr-flag-extension = "\\" atom
;; Future expansion. Client implementations
;; MUST accept flag-extension flags. Server
;; implementations MUST NOT generate
;; flag-extension flags except as defined by
;; future standard or standards-track
;; revisions of [IMAP4].
attr-flag-keyword = atom
attr-flag-keyword = atom
This section describes how a server implementation that doesn't store separate per-metadata mod-sequences for different metadata items can avoid sending the MODIFIED response to any of the following conditional STORE operations:
本节介绍不为不同元数据项存储单独的每元数据mod序列的服务器实现如何避免将修改后的响应发送到以下任何条件存储操作：
+FLAGS -FLAGS +FLAGS.SILENT -FLAGS.SILENT
+FLAGS-FLAGS+FLAGS.SILENT-FLAGS.SILENT
Note that the optimization described in this section can't be performed in case of a conditional STORE FLAGS operation.
请注意，在条件存储标志操作的情况下，无法执行本节中描述的优化。
Let's use the following example. The client has issued
让我们使用下面的例子。客户已发出
C: a106 STORE 100:150 (UNCHANGEDSINCE 212030000000) +FLAGS.SILENT ($Processed)
C:a106存储100:150（自212030000000起保持不变）+FLAGS.SILENT（$Processed）
When the server receives the command and parses it successfully, it iterates through the message set and tries to execute the conditional STORE command for each message.
当服务器接收到命令并成功解析它时，它将迭代消息集，并尝试为每条消息执行条件存储命令。
Each server internally works as a client, i.e., it has to cache the current state of all IMAP flags as it is known to the client. In order to report flag changes to the client, the server compares the cached values with the values in its database for IMAP flags.
每个服务器在内部都作为客户端工作，即，它必须缓存客户端已知的所有IMAP标志的当前状态。为了向客户机报告标志更改，服务器将缓存的值与其数据库中的值进行比较，以查找IMAP标志。
Imagine that another client has changed the state of a flag \Deleted on the message 101 and that the change updated the mod-sequence for the message. The server knows that the mod-sequence for the mailbox has changed; however, it also knows that:
假设另一个客户端更改了消息101上的标记\已删除的状态，并且该更改更新了消息的mod序列。服务器知道邮箱的mod序列已更改；然而，它也知道：
a) the client is not interested in \Deleted flag, as it hasn't included it in +FLAGS.SILENT operation; and
a) 客户端对\Deleted标志不感兴趣，因为它没有将其包含在+FLAGS.SILENT操作中；和
b) the state of the flag $Processed hasn't changed (the server can determine this by comparing cached flag state with the state of the flag in the database).
b) 标记$Processed的状态未更改（服务器可以通过将缓存的标记状态与数据库中的标记状态进行比较来确定）。
Therefore, the server doesn't have to report MODIFIED to the client. Instead, the server may set $Processed flag, update the mod-sequence for the message 101 once again and send an untagged FETCH response with new mod-sequence and flags:
因此，服务器不必向客户端报告修改。相反，服务器可以设置$Processed标志，再次更新消息101的mod序列，并使用新mod序列和标志发送未标记的FETCH响应：
S: * 101 FETCH (MODSEQ (303011130956) FLAGS ($Processed \Deleted \Answered))
S:*101获取（MODSEQ（303011130956）标志（$Processed\Deleted\responsed））
See also Section 3.8 for additional quality-of-implementation issues.
有关实施质量的其他问题，请参见第3.8节。
It is believed that the Conditional STORE extension doesn't raise any new security concerns that are not already discussed in [IMAP4]. However, the availability of this extension may make it possible for IMAP4 to be used in critical applications it could not be used for previously, making correct IMAP server implementation and operation even more important.
据信，条件存储扩展不会引起[IMAP4]中未讨论的任何新的安全问题。但是，此扩展的可用性可能使IMAP4能够用于以前无法用于的关键应用程序，从而使正确的IMAP服务器实现和操作更加重要。
IMAP4 capabilities are registered by publishing a standards track or IESG approved experimental RFC. The registry is currently located at:
由RFG或IESC认证的轨道发布标准。注册处目前位于：
http://www.iana.org/assignments/imap4-capabilities
http://www.iana.org/assignments/imap4-capabilities
This document defines the CONDSTORE IMAP capability. IANA has added it to the registry accordingly.
本文档定义了CONDSTORE IMAP功能。IANA已相应地将其添加到注册表中。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[ABNF]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 4234，2005年10月。
[IMAP4] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[IMAP4]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 35012003年3月。
[IMAPABNF] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF", RFC 4466, April 2006.
[IMAPABNF]Melnikov，A.和C.Daboo，“IMAP4 ABNF的收集扩展”，RFC 4466，2006年4月。
[ACAP] Newman, C. and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997.
[ACAP]Newman，C.和J.Myers，“ACAP——应用程序配置访问协议”，RFC22441997年11月。
[ACL] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", RFC 4314, December 2005.
[ACL]Melnikov，A.，“IMAP4访问控制列表（ACL）扩展”，RFC 4314，2005年12月。
[ANN] Daboo, C. and R. Gellens, "IMAP ANNOTATE Extension", Work in Progress, March 2006.
[ANN]Daboo，C.和R.Gellens，“IMAP注释扩展”，正在进行的工作，2006年3月。
[NTP] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992.
[NTP]Mills，D.，“网络时间协议（第3版）规范、实施和分析”，RFC13051992年3月。
[RFC-2180] Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice", RFC 2180, July 1997.
[RFC-2180]Gahrns，M.，“IMAP4多址邮箱实践”，RFC 2180，1997年7月。
Some text was borrowed from "IMAP ANNOTATE Extension" [ANN] by Randall Gellens and Cyrus Daboo and from "ACAP -- Application Configuration Access Protocol" [ACAP] by Chris Newman and John Myers.
一些文本是从Randall Gellens和Cyrus Daboo的“IMAP注释扩展”[ANN]和Chris Newman和John Myers的“ACAP——应用程序配置访问协议”[ACAP]中借用的。
Many thanks to Randall Gellens for his thorough review of the document.
非常感谢Randall Gellens对该文件的全面审查。
The authors also acknowledge the feedback provided by Cyrus Daboo, Larry Greenfield, Chris Newman, Harrie Hazewinkel, Arnt Gulbrandsen, Timo Sirainen, Mark Crispin, Ned Freed, Ken Murchison, and Dave Cridland.
作者还感谢Cyrus Daboo、Larry Greenfield、Chris Newman、Harrie Hazewinkel、Arnt Gulbrandsen、Timo Sirainen、Mark Crispin、Ned Freed、Ken Murchison和Dave Cridland提供的反馈。
Authors' Addresses
作者地址
Alexey Melnikov Isode Limited 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX, United Kingdom
英国米德尔塞克斯郡汉普顿车站路36号城堡商业村5号Alexey Melnikov Isode Limited TW12 2BX
EMail: Alexey.Melnikov@isode.com
EMail: Alexey.Melnikov@isode.com
Steve Hole ACI WorldWide/MessagingDirect #1807, 10088 102 Ave Edmonton, AB T5J 2Z1 Canada
Steve Hole ACI WorldWide/MessagingDirect#1807，10088 102 Ave Edmonton，AB T5J 2Z1加拿大
EMail: Steve.Hole@messagingdirect.com
EMail: Steve.Hole@messagingdirect.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。