Network Working Group M. Crispin
Request for Comments: 4315 December 2005
Obsoletes: 2359
Category: Standards Track
Network Working Group M. Crispin
Request for Comments: 4315 December 2005
Obsoletes: 2359
Category: Standards Track
Internet Message Access Protocol (IMAP) - UIDPLUS extension
Internet消息访问协议（IMAP）-UIDPLUS扩展
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 (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
The UIDPLUS extension of the Internet Message Access Protocol (IMAP) provides a set of features intended to reduce the amount of time and resources used by some client operations. The features in UIDPLUS are primarily intended for disconnected-use clients.
Internet消息访问协议（IMAP）的UIDPLUS扩展提供了一组功能，旨在减少某些客户端操作使用的时间和资源量。UIDPLUS中的功能主要用于断开连接的客户端。
The UIDPLUS extension is present in any IMAP server implementation that returns "UIDPLUS" as one of the supported capabilities to the CAPABILITY command.
UIDPLUS扩展存在于将“UIDPLUS”作为支持的功能之一返回给CAPABILITY命令的任何IMAP服务器实现中。
The UIDPLUS extension defines an additional command. In addition, this document recommends new status response codes in IMAP that SHOULD be returned by all server implementations, regardless of whether or not the UIDPLUS extension is implemented.
UIDPLUS扩展定义了一个附加命令。此外，本文档还建议在IMAP中使用新的状态响应代码，无论是否实现UIDPLUS扩展，所有服务器实现都应返回这些代码。
The added facilities of the features in UIDPLUS are optimizations; clients can provide equivalent functionality, albeit less efficiently, by using facilities in the base protocol.
UIDPLUS中新增的功能是优化；通过使用基本协议中的设施，客户端可以提供等效的功能，尽管效率较低。
In examples, "C:" and "S:" indicate lines sent by the client and server, respectively.
在示例中，“C:”和“S:”分别表示客户端和服务器发送的行。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不得”、“应”、“不应”、“可”和“可选”应按照[关键词]中的说明进行解释。
A "UID set" is similar to the [IMAP] sequence set; however, the "*" value for a sequence number is not permitted.
“UID集合”类似于[IMAP]序列集合；但是，不允许序列号的“*”值。
The following command definition is an extension to [IMAP] section 6.4.
以下命令定义是[IMAP]第6.4节的扩展。
Arguments: sequence set
参数：序列集
Data: untagged responses: EXPUNGE
数据：未标记的响应：删除
Result: OK - expunge completed NO - expunge failure (e.g., permission denied) BAD - command unknown or arguments invalid
结果：确定-删除完成否-删除失败（例如，权限被拒绝）错误-命令未知或参数无效
The UID EXPUNGE command permanently removes all messages that both have the \Deleted flag set and have a UID that is included in the specified sequence set from the currently selected mailbox. If a message either does not have the \Deleted flag set or has a UID that is not included in the specified sequence set, it is not affected.
UID EXPUNGE命令将从当前选定邮箱中永久删除所有设置了\Deleted标志且UID包含在指定序列集中的邮件。如果消息未设置\Deleted标志，或其UID未包含在指定的序列集中，则不会受到影响。
This command is particularly useful for disconnected use clients. By using UID EXPUNGE instead of EXPUNGE when resynchronizing with the server, the client can ensure that it does not inadvertantly remove any messages that have been marked as \Deleted by other clients between the time that the client was last connected and the time the client resynchronizes.
此命令对于断开连接的使用客户端特别有用。通过在与服务器重新同步时使用UID EXPUNGE而不是EXPUNGE，客户端可以确保在客户端上次连接到客户端和客户端重新同步之间，不会无意中删除任何被其他客户端标记为\已删除的消息。
If the server does not support the UIDPLUS capability, the client should fall back to using the STORE command to temporarily remove the \Deleted flag from messages it does not want to remove, then issuing the EXPUNGE command. Finally, the client should use the STORE command to restore the \Deleted flag on the messages in which it was temporarily removed.
如果服务器不支持UIDPLUS功能，则客户端应返回使用STORE命令从其不想删除的消息中临时删除\Deleted标志，然后发出EXPUNGE命令。最后，客户机应该使用STORE命令在临时删除\Deleted标志的消息上恢复该标志。
Alternatively, the client may fall back to using just the EXPUNGE command, risking the unintended removal of some messages.
或者，客户端可能会退回到仅使用EXPUNGE命令，从而冒着意外删除某些消息的风险。
Example: C: A003 UID EXPUNGE 3000:3002
S: * 3 EXPUNGE
S: * 3 EXPUNGE
S: * 3 EXPUNGE
S: A003 OK UID EXPUNGE completed
Example: C: A003 UID EXPUNGE 3000:3002
S: * 3 EXPUNGE
S: * 3 EXPUNGE
S: * 3 EXPUNGE
S: A003 OK UID EXPUNGE completed
The following response codes are extensions to the response codes defined in [IMAP] section 7.1. With limited exceptions, discussed below, server implementations that advertise the UIDPLUS extension SHOULD return these response codes.
以下响应代码是[IMAP]第7.1节中定义的响应代码的扩展。除了下面讨论的有限例外情况外，发布UIDPLUS扩展的服务器实现应该返回这些响应代码。
In the case of a mailbox that has permissions set so that the client can COPY or APPEND to the mailbox, but not SELECT or EXAMINE it, the server SHOULD NOT send an APPENDUID or COPYUID response code as it would disclose information about the mailbox.
如果邮箱的权限设置为客户端可以复制或附加到邮箱，但不能选择或检查邮箱，则服务器不应发送APPENDUID或COPYUID响应代码，因为这会泄露有关邮箱的信息。
In the case of a mailbox that has UIDNOTSTICKY status (as defined below), the server MAY omit the APPENDUID or COPYUID response code as it is not meaningful.
对于具有UIDNOTSTICKY状态（定义如下）的邮箱，服务器可能会忽略APPENDUID或COPYUID响应代码，因为它没有意义。
If the server does not return the APPENDUID or COPYUID response codes, the client can discover this information by selecting the destination mailbox. The location of messages placed in the destination mailbox by COPY or APPEND can be determined by using FETCH and/or SEARCH commands (e.g., for Message-ID or some unique marker placed in the message in an APPEND).
如果服务器未返回APPENDUID或COPYUID响应代码，则客户端可以通过选择目标邮箱来发现此信息。通过使用FETCH和/或SEARCH命令（例如，对于附加中放置在邮件中的邮件ID或某些唯一标记），可以确定通过复制或附加放置在目标邮箱中的邮件的位置。
APPENDUID
附录
Followed by the UIDVALIDITY of the destination mailbox and the UID assigned to the appended message in the destination mailbox, indicates that the message has been appended to the destination mailbox with that UID.
后跟目标邮箱的UID有效性和分配给目标邮箱中附加邮件的UID，表示邮件已使用该UID附加到目标邮箱。
If the server also supports the [MULTIAPPEND] extension, and if multiple messages were appended in the APPEND command, then the second value is a UID set containing the UIDs assigned to the appended messages, in the order they were transmitted in the APPEND command. This UID set may not contain extraneous UIDs or the symbol "*".
如果服务器还支持[MULTIAPPEND]扩展，并且如果在APPEND命令中追加了多条消息，则第二个值是一个UID集，其中包含分配给追加消息的UID，它们在APPEND命令中的传输顺序。此UID集不能包含无关的UID或符号“*”。
Note: the UID set form of the APPENDUID response code MUST NOT be used if only a single message was appended. In particular, a server MUST NOT send a range such as 123:123. This is because a client that does not support [MULTIAPPEND] expects only a single UID and not a UID set.
注意：如果只追加了一条消息，则不能使用APPENDUID响应代码的UID集合形式。特别是，服务器不能发送123:123这样的范围。这是因为不支持[MULTIAPPEND]的客户端只需要一个UID，而不需要UID集。
UIDs are assigned in strictly ascending order in the mailbox (refer to [IMAP], section 2.3.1.1) and UID ranges are as in [IMAP]; in particular, note that a range of 12:10 is exactly equivalent to 10:12 and refers to the sequence 10,11,12.
UID在邮箱中严格按升序分配（参考[IMAP]，第2.3.1.1节），UID范围如[IMAP]所示；特别要注意的是，12:10的范围完全等同于10:12，并表示序列10,11,12。
This response code is returned in a tagged OK response to the APPEND command.
此响应代码在对APPEND命令的带标记的OK响应中返回。
COPYUID
COPYUID
Followed by the UIDVALIDITY of the destination mailbox, a UID set containing the UIDs of the message(s) in the source mailbox that were copied to the destination mailbox and containing the UIDs assigned to the copied message(s) in the destination mailbox, indicates that the message(s) have been copied to the destination mailbox with the stated UID(s).
后跟目标邮箱的UID有效性，UID集包含复制到目标邮箱的源邮箱中邮件的UID，并包含分配给目标邮箱中复制邮件的UID，表示邮件已使用声明的UID复制到目标邮箱（s） 。
The source UID set is in the order the message(s) were copied; the destination UID set corresponds to the source UID set and is in the same order. Neither of the UID sets may contain extraneous UIDs or the symbol "*".
源UID集与消息的复制顺序一致；目标UID集与源UID集对应，顺序相同。两个UID集都不能包含无关的UID或符号“*”。
UIDs are assigned in strictly ascending order in the mailbox (refer to [IMAP], section 2.3.1.1) and UID ranges are as in [IMAP]; in particular, note that a range of 12:10 is exactly equivalent to 10:12 and refers to the sequence 10,11,12.
UID在邮箱中严格按升序分配（参考[IMAP]，第2.3.1.1节），UID范围如[IMAP]所示；特别要注意的是，12:10的范围完全等同于10:12，并表示序列10,11,12。
This response code is returned in a tagged OK response to the COPY command.
此响应代码在对COPY命令的带标记的OK响应中返回。
UIDNOTSTICKY
UIDNOTSTICKY
The selected mailbox is supported by a mail store that does not support persistent UIDs; that is, UIDVALIDITY will be different each time the mailbox is selected. Consequently, APPEND or COPY to this mailbox will not return an APPENDUID or COPYUID response code.
不支持持久UID的邮件存储支持所选邮箱；也就是说，每次选择邮箱时，UIDVality都会不同。因此，追加或复制到此邮箱不会返回APPENDUID或COPYUID响应代码。
This response code is returned in an untagged NO response to the SELECT command.
此响应代码在对SELECT命令的未标记无响应中返回。
Note: servers SHOULD NOT have any UIDNOTSTICKY mail stores. This facility exists to support legacy mail stores in which it is technically infeasible to support persistent UIDs. This should be avoided when designing new mail stores.
注意：服务器不应具有任何UIDNOTSTICKY邮件存储。此功能的存在是为了支持旧式邮件存储，在旧式邮件存储中，技术上不可能支持持久UID。在设计新的邮件存储时应避免这种情况。
Example: C: A003 APPEND saved-messages (\Seen) {297}
C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
C: From: Fred Foobar <foobar@example.com>
C: Subject: afternoon meeting
C: To: mooch@example.com
C: Message-Id: <B27397-0100000@example.com>
C: MIME-Version: 1.0
C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
C:
C: Hello Joe, do you think we can meet at 3:30 tomorrow?
C:
S: A003 OK [APPENDUID 38505 3955] APPEND completed
C: A004 COPY 2:4 meeting
S: A004 OK [COPYUID 38505 304,319:320 3956:3958] Done
C: A005 UID COPY 305:310 meeting
S: A005 OK No matching messages, so nothing copied
C: A006 COPY 2 funny
S: A006 OK Done
C: A007 SELECT funny
S: * 1 EXISTS
S: * 1 RECENT
S: * OK [UNSEEN 1] Message 1 is first unseen
S: * OK [UIDVALIDITY 3857529045] Validity session-only
S: * OK [UIDNEXT 2] Predicted next UID
S: * NO [UIDNOTSTICKY] Non-persistent UIDs
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [PERMANENTFLAGS (\Deleted \Seen)] Limited
S: A007 OK [READ-WRITE] SELECT completed
Example: C: A003 APPEND saved-messages (\Seen) {297}
C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
C: From: Fred Foobar <foobar@example.com>
C: Subject: afternoon meeting
C: To: mooch@example.com
C: Message-Id: <B27397-0100000@example.com>
C: MIME-Version: 1.0
C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
C:
C: Hello Joe, do you think we can meet at 3:30 tomorrow?
C:
S: A003 OK [APPENDUID 38505 3955] APPEND completed
C: A004 COPY 2:4 meeting
S: A004 OK [COPYUID 38505 304,319:320 3956:3958] Done
C: A005 UID COPY 305:310 meeting
S: A005 OK No matching messages, so nothing copied
C: A006 COPY 2 funny
S: A006 OK Done
C: A007 SELECT funny
S: * 1 EXISTS
S: * 1 RECENT
S: * OK [UNSEEN 1] Message 1 is first unseen
S: * OK [UIDVALIDITY 3857529045] Validity session-only
S: * OK [UIDNEXT 2] Predicted next UID
S: * NO [UIDNOTSTICKY] Non-persistent UIDs
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [PERMANENTFLAGS (\Deleted \Seen)] Limited
S: A007 OK [READ-WRITE] SELECT completed
In this example, A003 and A004 demonstrate successful appending and copying to a mailbox that returns the UIDs assigned to the messages. A005 is an example in which no messages were copied; this is because in A003, we see that message 2 had UID 304, and message 3 had UID 319; therefore, UIDs 305 through 310 do not exist (refer to section 2.3.1.1 of [IMAP] for further explanation). A006 is an example of a message being copied that did not return a COPYUID; and, as expected, A007 shows that the mail store containing that mailbox does not support persistent UIDs.
在本例中，A003和A004演示了成功附加和复制到邮箱，该邮箱返回分配给邮件的UID。A005是未复制任何消息的示例；这是因为在A003中，我们看到消息2有UID 304，消息3有UID 319；因此，UID 305至310不存在（有关进一步解释，请参阅[IMAP]第2.3.1.1节）。A006是一个被复制但未返回COPYUID的消息示例；而且，正如预期的那样，A007显示包含该邮箱的邮件存储不支持持久UID。
Formal syntax is defined using ABNF [ABNF], which extends the ABNF rules defined in [IMAP]. The IMAP4 ABNF should be imported before attempting to validate these rules.
形式语法是使用ABNF[ABNF]定义的，它扩展了[IMAP]中定义的ABNF规则。在尝试验证这些规则之前，应导入IMAP4 ABNF。
append-uid = uniqueid
append-uid = uniqueid
capability =/ "UIDPLUS"
能力=/“UIDPLUS”
command-select =/ uid-expunge
命令select=/uid expunge
resp-code-apnd = "APPENDUID" SP nz-number SP append-uid
响应代码apnd=“APPENDUID”SP nz编号SP APPENDUID
resp-code-copy = "COPYUID" SP nz-number SP uid-set SP uid-set
resp code copy=“COPYUID”SP nz编号SP uid set SP uid set
resp-text-code =/ resp-code-apnd / resp-code-copy / "UIDNOTSTICKY"
; incorporated before the expansion rule of
; atom [SP 1*<any TEXT-CHAR except "]">]
; that appears in [IMAP]
resp-text-code =/ resp-code-apnd / resp-code-copy / "UIDNOTSTICKY"
; incorporated before the expansion rule of
; atom [SP 1*<any TEXT-CHAR except "]">]
; that appears in [IMAP]
uid-expunge = "UID" SP "EXPUNGE" SP sequence-set
uid expunge=“uid”SP“expunge”SP序列集
uid-set = (uniqueid / uid-range) *("," uid-set)
uid-set = (uniqueid / uid-range) *("," uid-set)
uid-range = (uniqueid ":" uniqueid)
; two uniqueid values and all values
; between these two regards of order.
; Example: 2:4 and 4:2 are equivalent.
uid-range = (uniqueid ":" uniqueid)
; two uniqueid values and all values
; between these two regards of order.
; Example: 2:4 and 4:2 are equivalent.
Servers that support [MULTIAPPEND] will have the following extension to the above rules:
支持[MULTIAPPEND]的服务器将对上述规则进行以下扩展：
append-uid =/ uid-set ; only permitted if client uses [MULTIAPPEND] ; to append multiple messages.
追加uid=/uid集；仅当客户端使用[MULTIAPPEND]时才允许；附加多条消息。
The COPYUID and APPENDUID response codes return information about the mailbox, which may be considered sensitive if the mailbox has permissions set that permit the client to COPY or APPEND to the mailbox, but not SELECT or EXAMINE it.
COPYUID和APPENDUID响应代码返回有关邮箱的信息，如果邮箱的权限设置允许客户端复制或附加到邮箱，但不允许选择或检查邮箱，则可能会认为这些信息是敏感的。
Consequently, these response codes SHOULD NOT be issued if the client does not have access to SELECT or EXAMINE the mailbox.
因此，如果客户端无权选择或检查邮箱，则不应发出这些响应代码。
This document constitutes registration of the UIDPLUS capability in the imap4-capabilities registry, replacing [RFC2359].
本文档构成了UIDPLUS功能在imap4功能注册表中的注册，取代了[RFC2359]。
[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月。
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[IMAP]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 35012003年3月。
[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月。
[MULTIAPPEND] Crispin, M., "Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension", RFC 3502, March 2003.
[MULTIAPPEND]Crispin，M.，“互联网消息访问协议（IMAP）-多附加扩展”，RFC 35022003年3月。
[RFC2359] Myers, J., "IMAP4 UIDPLUS extension", RFC 2359, June 1998.
[RFC2359]迈尔斯，J.，“IMAP4 UIDPLUS扩展”，RFC2359，1998年6月。
This document obsoletes [RFC2359]. However, it is based upon that document, and takes substantial text from it (albeit with numerous clarifications in wording).
本文件废除了[RFC2359]。然而，它以该文件为基础，并从中提取了大量文本（尽管在措辞上作了许多澄清）。
[RFC2359] implied that a server must always return COPYUID/APPENDUID data; thus suggesting that in such cases the server should return arbitrary data if the destination mailbox did not support persistent UIDs. This document adds the UIDNOTSTICKY response code to indicate that a mailbox does not support persistent UIDs, and stipulates that a UIDPLUS server does not return COPYUID/APPENDUID data when the COPY (or APPEND) destination mailbox has UIDNOTSTICKY status.
[RFC2359]意味着服务器必须始终返回COPYUID/APPENDUID数据；因此，建议在这种情况下，如果目标邮箱不支持持久UID，服务器应返回任意数据。本文档添加UIDNOTSTICKY响应代码以指示邮箱不支持持久UID，并规定当复制（或附加）目标邮箱处于UIDNOTSTICKY状态时，UIDPLUS服务器不返回COPYUID/APPENDUID数据。
Author's Address
作者地址
Mark R. Crispin Networks and Distributed Computing University of Washington 4545 15th Avenue NE Seattle, WA 98105-4527
Mark R. Crispin网络与分布式计算华盛顿大学西雅图第十五大街4545号WA98105-427
Phone: (206) 543-5762 EMail: MRC@CAC.Washington.EDU
电话：（206）543-5762电子邮件：MRC@CAC.Washington.EDU
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
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 currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。