Network Working Group P. Resnick
Request for Comments: 4469 QUALCOMM Incorporated
Updates: 3501, 3502 April 2006
Category: Standards Track
Network Working Group P. Resnick
Request for Comments: 4469 QUALCOMM Incorporated
Updates: 3501, 3502 April 2006
Category: Standards Track
Internet Message Access Protocol (IMAP) CATENATE Extension
Internet消息访问协议（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
摘要
The CATENATE extension to the Internet Message Access Protocol (IMAP) extends the APPEND command to allow clients to create messages on the IMAP server that may contain a combination of new data along with parts of (or entire) messages already on the server. Using this extension, the client can catenate parts of an already existing message onto a new message without having to first download the data and then upload it back to the server.
Internet消息访问协议（IMAP）的CATENATE扩展扩展扩展了APPEND命令，允许客户端在IMAP服务器上创建消息，这些消息可能包含新数据的组合以及服务器上已有的部分（或全部）消息。使用此扩展，客户端可以将现有消息的一部分链接到新消息上，而无需先下载数据，然后再将其上载回服务器。
The CATENATE extension to the Internet Message Access Protocol (IMAP) [1] allows the client to create a message on the server that can include the text of messages (or parts of messages) that already exist on the server without having to FETCH them and APPEND them back to the server. The CATENATE extension extends the APPEND command so that, instead of a single message literal, the command can take as arguments any combination of message literals (as described in IMAP [1]) and message URLs (as described in the IMAP URL Scheme [2] specification). The server takes all the pieces and catenates them into the output message. The CATENATE extension can also coexist with the MULTIAPPEND extension [3] to APPEND multiple messages in a single command.
Internet Message Access Protocol（IMAP）[1]的CATENATE扩展允许客户端在服务器上创建一条消息，该消息可以包含服务器上已经存在的消息（或部分消息）的文本，而无需获取它们并将其追加回服务器。CATENATE扩展扩展扩展了APPEND命令，因此命令可以将消息文本（如IMAP[1]中所述）和消息URL（如IMAP URL方案[2]规范中所述）的任意组合作为参数，而不是单个消息文本。服务器获取所有片段并将它们链接到输出消息中。CATENATE扩展还可以与MULTIAPPEND扩展共存[3]，以便在一个命令中追加多条消息。
There are some obvious uses for the CATENATE extension. The motivating use case was to provide a way for a resource-constrained client to compose a message for subsequent submission that contains data that already exists in that client's IMAP store. Because the client does not have to download and re-upload potentially large message parts, bandwidth and processing limitations do not have as much impact. In addition, since the client can create a message in its own IMAP store, the command also addresses the desire of the client to archive a copy of a sent message without having to upload the message twice. (Mechanisms for sending the message are outside the scope of this document.)
链状延伸有一些明显的用途。激发动机的用例是为资源受限的客户机提供一种方式，以便为后续提交编写包含该客户机的IMAP存储中已经存在的数据的消息。由于客户端不必下载和重新上传可能较大的消息部分，因此带宽和处理限制不会产生太大影响。此外，由于客户机可以在其自己的IMAP存储中创建消息，因此该命令还满足了客户机存档已发送消息副本的需求，而无需将消息上载两次。（发送消息的机制不在本文档的范围内。）
The extended APPEND command can also be used to copy parts of a message to another mailbox for archival purposes while getting rid of undesired parts. In environments where server storage is limited, a client could get rid of large message parts by copying over only the necessary parts and then deleting the original message. The mechanism could also be used to add data to a message (such as prepending message header fields) or to include other data by making a copy of the original and catenating the new data.
extended APPEND命令还可用于将邮件的某些部分复制到另一个邮箱以进行存档，同时清除不需要的部分。在服务器存储有限的环境中，客户机可以通过只复制必要的部分，然后删除原始消息，从而消除大型消息部分。该机制还可用于向消息中添加数据（例如，预先添加消息头字段），或通过复制原始数据并链接新数据来包含其他数据。
A server that supports this extension returns "CATENATE" as one of the responses to the CAPABILITY command.
支持此扩展的服务器返回“CATENATE”作为对CAPABILITY命令的响应之一。
Arguments: mailbox name (The following can be repeated in the presence of the MULTIAPPEND extension [3]) OPTIONAL flag parenthesized list OPTIONAL date/time string a single message literal or one or more message parts to catenate, specified as: message literal or message (or message part) URL
参数：邮箱名称（在存在多附加扩展[3]的情况下可以重复以下内容）可选标志括号中的列表可选日期/时间字符串要链接的单个邮件文本或一个或多个邮件部分，指定为：邮件文本或邮件（或邮件部分）URL
Responses: OPTIONAL NO responses: BADURL, TOOBIG
响应：可选无响应：BADURL，太大
Result: OK - append completed NO - append error: can't append to that mailbox, error in flags or date/time or message text, or can't fetch that data BAD - command unknown or arguments invalid
结果：确定-追加已完成否-追加错误：无法追加到该邮箱，标志或日期/时间或消息文本错误，或无法获取该数据错误-命令未知或参数无效
The APPEND command concatenates all the message parts and appends them as a new message to the end of the specified mailbox. The parenthesized flag list and date/time string set the flags and the internal date, respectively, as described in IMAP [1]. The subsequent command parameters specify the message parts that are appended sequentially to the output message.
APPEND命令连接所有邮件部分，并将它们作为新邮件附加到指定邮箱的末尾。括号内的标志列表和日期/时间字符串分别设置标志和内部日期，如IMAP[1]中所述。后续命令参数指定按顺序附加到输出消息的消息部分。
If the original form of APPEND is used, a message literal follows the optional flag list and date/time string, which is appended as described in IMAP [1]. If the extended form is used, "CATENATE" and a parenthesized list of message literals and message URLs follows, each of which is appended to the new message. If a message literal is specified (indicated by "TEXT"), the octets following the count are appended. If a message URL is specified (indicated by "URL"), the octets of the body part pointed to by that URL are appended, as if the literal returned in a FETCH BODY response were put in place of the message part specifier. The APPEND command does not cause the \Seen flag to be set for any catenated body part. The APPEND command does not change the selected mailbox.
如果使用原始形式的APPEND，消息文本将跟随可选标志列表和日期/时间字符串，如IMAP[1]中所述进行追加。如果使用扩展形式，则会出现“CATENATE”和带括号的消息文本和消息URL列表，每个文本和URL都会附加到新消息中。如果指定了消息文本（由“TEXT”表示），则会追加计数后的八位字节。如果指定了消息URL（由“URL”指示），则会附加该URL所指向的正文部分的八位字节，就像在获取正文响应中返回的文本代替了消息部分说明符一样。APPEND命令不会导致为任何链接的身体部位设置\Seen标志。APPEND命令不会更改所选邮箱。
In the extended APPEND command, the string following "URL" is an IMAP URL [2] and is interpreted according to the rules of [2]. The present document only describes the behavior of the command using IMAP URLs that refer to specific messages or message parts on the current IMAP server from the current authenticated IMAP session. Because of that, only relative IMAP message or message part URLs (i.e., those having no scheme or <iserver>) are used. The base URL
在extended APPEND命令中，“URL”后面的字符串是IMAP URL[2]，并根据[2]的规则进行解释。本文档仅描述使用IMAP URL的命令行为，这些URL引用当前IMAP服务器上来自当前已验证IMAP会话的特定消息或消息部分。因此，只使用相对的IMAP消息或消息部分URL（即，没有scheme或<iserver>的URL）。基本URL
for evaluating the relative URL is considered "imap://user@server/", where "user" is the user name of the currently authenticated user and "server" is the domain name of the current server. When in the selected state, the base URL is considered "imap://user@server/mailbox", where "mailbox" is the encoded name of the currently selected mailbox. Additionally, since the APPEND command is valid in the authenticated state of an IMAP session, no further LOGIN or AUTHENTICATE command is performed for URLs specified in the extended APPEND command.
用于评估相对URL时，请考虑“imap://user@server/，其中“user”是当前经过身份验证的用户的用户名，“server”是当前服务器的域名。处于选定状态时，将考虑基本URL“imap://user@服务器/邮箱”，其中“邮箱”是当前选定邮箱的编码名称。此外，由于APPEND命令在IMAP会话的已验证状态下有效，因此不会对扩展APPEND命令中指定的URL执行进一步的登录或验证命令。
Note: Use of an absolute IMAP URL or any URL that refers to anything other than a message or message part from the current authenticated IMAP session is outside the scope of this document and would require an extension to this specification, and a server implementing only this specification would return NO to such a request.
注意：使用绝对IMAP URL或引用来自当前已验证IMAP会话的消息或消息部分以外的任何内容的任何URL不在本文档的范围内，需要对本规范进行扩展，并且仅实现本规范的服务器将对此类请求返回否。
The client is responsible for making sure that the catenated message is in the format of an Internet Message Format (RFC 2822) [4] or Multipurpose Internet Mail Extension (MIME) [5] message. In particular, when a URL is catenated, the server copies octets, unchanged, from the indicated message or message part to the catenated message. It does no data conversion (e.g., MIME transfer encodings) nor any verification that the data is appropriate for the MIME part of the message into which it is inserted. The client is also responsible for inserting appropriate MIME boundaries between body parts, and writing MIME Content-Type and Content-Transfer-Encoding lines as needed in the appropriate places.
客户机负责确保链接的消息采用Internet消息格式（RFC 2822）[4]或多用途Internet邮件扩展（MIME）[5]消息的格式。特别是，当链接URL时，服务器会将所指示的消息或消息部分的八位字节复制到链接的消息中，保持不变。它不进行数据转换（例如，MIME传输编码），也不验证数据是否适合插入其中的消息的MIME部分。客户机还负责在身体部位之间插入适当的MIME边界，并根据需要在适当的位置编写MIME内容类型和内容传输编码行。
Responses behave just as the original APPEND command described in IMAP [1]. If the server implements the IMAP UIDPLUS extension [6], it will also return an APPENDUID response code in the tagged OK response. Two response codes are provided in Section 4 that can be used in the tagged NO response if the APPEND command fails.
响应的行为与IMAP[1]中描述的原始APPEND命令相同。如果服务器实现IMAP UIDPLUS扩展[6]，它还将在标记的OK响应中返回APPENDUID响应代码。第4节中提供了两个响应代码，如果APPEND命令失败，可以在标记的NO响应中使用。
When a APPEND command fails, it may return a response code that describes a reason for the failure.
当APPEND命令失败时，它可能返回一个描述失败原因的响应代码。
The BADURL response code is returned if the APPEND fails to process one of the specified URLs. Possible reasons for this are bad URL syntax, unrecognized URL schema, invalid message UID, or invalid body part. The BADURL response code contains the first URL specified as a parameter to the APPEND command that has caused the operation to fail.
如果追加无法处理指定的URL之一，则返回BADURL响应代码。可能的原因是错误的URL语法、无法识别的URL架构、无效的消息UID或无效的正文部分。BADURL响应代码包含第一个URL，该URL被指定为导致操作失败的APPEND命令的参数。
The TOOBIG response code is returned if the resulting message will exceed the 4-GB IMAP message limit. This might happen, for example, if the client specifies 3 URLs for 2-GB messages. Note that even if the server doesn't return TOOBIG, it still has to be defensive against misbehaving or malicious clients that try to construct a message over the 4-GB limit. The server may also wish to return the TOOBIG response code if the resulting message exceeds a server-specific message size limit.
如果生成的消息将超过4-GB IMAP消息限制，则返回TOOBIG响应代码。例如，如果客户端为2-GB消息指定3个URL，则可能会发生这种情况。请注意，即使服务器没有返回太大，它仍然必须对试图构造超过4-GB限制的消息的行为不端或恶意客户端进行防御。如果生成的消息超过服务器特定的消息大小限制，服务器可能还希望返回TOOBIG响应代码。
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) [7] notation. Elements not defined here can be found in the formal syntax of the ABNF [7], IMAP [1], and IMAP ABNF extensions [8] specifications. Note that capability and resp-text-code are extended from the IMAP [1] specification and append-data is extended from the IMAP ABNF extensions [8] specification.
以下语法规范使用增广的Backus-Naur形式（ABNF）[7]表示法。这里未定义的元素可以在ABNF[7]、IMAP[1]和IMAP ABNF扩展[8]规范的形式语法中找到。请注意，capability和resp text code是从IMAP[1]规范扩展而来的，append data是从IMAP ABNF extensions[8]规范扩展而来的。
append-data =/ "CATENATE" SP "(" cat-part *(SP cat-part) ")"
append-data =/ "CATENATE" SP "(" cat-part *(SP cat-part) ")"
cat-part = text-literal / url
cat-part = text-literal / url
text-literal = "TEXT" SP literal
text literal=“text”SP literal
url = "URL" SP astring
url=“url”SP astring
resp-text-code =/ toobig-response-code / badurl-response-code
resp-text-code =/ toobig-response-code / badurl-response-code
toobig-response-code = "TOOBIG"
toobig-response-code = "TOOBIG"
badurl-response-code = "BADURL" SP url-resp-text
badurl响应代码=“badurl”SP url响应文本
url-resp-text = 1*(%x01-09 /
%x0B-0C /
%x0E-5B /
%x5D-FE) ; Any TEXT-CHAR except "]"
url-resp-text = 1*(%x01-09 /
%x0B-0C /
%x0E-5B /
%x5D-FE) ; Any TEXT-CHAR except "]"
capability =/ "CATENATE"
能力=/“连环”
The astring in the definition of url and the url-resp-text in the definition of badurl-response-code each contain an imapurl as defined by [2].
url定义中的astring和badurl响应代码定义中的url resp文本均包含[2]定义的imapurl。
Thanks to the members of the LEMONADE working group for their input. Special thanks to Alexey Melnikov for the examples.
感谢柠檬水工作组成员的投入。特别感谢Alexey Melnikov提供的示例。
The CATENATE extension does not raise any security considerations that are not present for the base protocol or in the use of IMAP URLs, and these issues are discussed in the IMAP [1] and IMAP URL [2] documents.
CATENATE扩展不会引起任何基本协议或IMAP URL使用中不存在的安全注意事项，这些问题在IMAP[1]和IMAP URL[2]文档中讨论。
IMAP4 capabilities are registered by publishing a standards track or IESG approved experimental RFC. The registry is currently located at <http://www.iana.org/assignments/imap4-capabilities>. This document defines the CATENATE IMAP capability. The IANA has added this capability to the registry.
由RFG或IESC认证的轨道发布标准。注册处目前位于<http://www.iana.org/assignments/imap4-capabilities>. 本文档定义了CATENATE IMAP功能。IANA已将此功能添加到注册表中。
Lines not starting with "C: " or "S: " are continuations of the previous lines.
不以“C:”或“S:”开头的行是前几行的延续。
The original message in examples 1 and 2 below (UID = 20) has the following structure:
下面示例1和2中的原始消息（UID=20）具有以下结构：
multipart/mixed MIME message with two body parts:
包含两个正文部分的多部分/混合MIME消息：
1. text/plain
1. 文本/纯文本
2. application/x-zip-compressed
2. 应用程序/x-zip-compressed
Example 1: The following example demonstrates how a CATENATE client can replace an attachment in a draft message, without the need to download it to the client and upload it back.
示例1：下面的示例演示CATENATE客户端如何替换草稿消息中的附件，而无需将附件下载到客户端并将其上载回。
C: A003 APPEND Drafts (\Seen \Draft $MDNSent) CATENATE
(URL "/Drafts;UIDVALIDITY=385759045/;UID=20/;section=HEADER"
TEXT {42}
S: + Ready for literal data
C:
C: --------------030308070208000400050907
C: URL "/Drafts;UIDVALIDITY=385759045/;UID=20/;section=1.MIME"
URL "/Drafts;UIDVALIDITY=385759045/;UID=20/;section=1" TEXT {42}
S: + Ready for literal data
C:
C: --------------030308070208000400050907
C: URL "/Drafts;UIDVALIDITY=385759045/;UID=30" TEXT {44}
S: + Ready for literal data
C:
C: --------------030308070208000400050907--
C: )
S: A003 OK catenate append completed
C: A003 APPEND Drafts (\Seen \Draft $MDNSent) CATENATE
(URL "/Drafts;UIDVALIDITY=385759045/;UID=20/;section=HEADER"
TEXT {42}
S: + Ready for literal data
C:
C: --------------030308070208000400050907
C: URL "/Drafts;UIDVALIDITY=385759045/;UID=20/;section=1.MIME"
URL "/Drafts;UIDVALIDITY=385759045/;UID=20/;section=1" TEXT {42}
S: + Ready for literal data
C:
C: --------------030308070208000400050907
C: URL "/Drafts;UIDVALIDITY=385759045/;UID=30" TEXT {44}
S: + Ready for literal data
C:
C: --------------030308070208000400050907--
C: )
S: A003 OK catenate append completed
Example 2: The following example demonstrates how the CATENATE extension can be used to replace edited text in a draft message, as well as header fields for the top level message part (e.g., Subject has changed). The previous version of the draft is marked as \Deleted. Note that the server also supports the UIDPLUS extension, so the APPENDUID response code is returned in the successful OK response to the APPEND command.
示例2：下面的示例演示了如何使用CATENATE扩展来替换草稿邮件中的编辑文本，以及顶级邮件部分的标题字段（例如，主题已更改）。草稿的早期版本标记为\已删除。请注意，服务器还支持UIDPLUS扩展，因此在对APPEND命令的成功OK响应中返回APPENDUID响应代码。
C: A003 APPEND Drafts (\Seen \Draft $MDNSent) CATENATE (TEXT {738}
S: + Ready for literal data
C: Return-Path: <bar@example.org>
C: Received: from [127.0.0.2]
C: by rufus.example.org via TCP (internal) with ESMTPA;
C: Thu, 11 Nov 2004 16:57:07 +0000
C: Message-ID: <419399E1.6000505@example.org>
C: Date: Thu, 12 Nov 2004 16:57:05 +0000
C: From: Bob Ar <bar@example.org>
C: X-Accept-Language: en-us, en
C: MIME-Version: 1.0
C: To: foo@example.net
C: Subject: About our holiday trip
C: Content-Type: multipart/mixed;
C: boundary="------------030308070208000400050907"
C:
C: --------------030308070208000400050907
C: Content-Type: text/plain; charset=us-ascii; format=flowed
C: Content-Transfer-Encoding: 7bit
C:
C: Our travel agent has sent the updated schedule.
C:
C: Cheers,
C: Bob
C: --------------030308070208000400050907
C: URL "/Drafts;UIDVALIDITY=385759045/;UID=20/;Section=2.MIME"
URL "/Drafts;UIDVALIDITY=385759045/;UID=20/;Section=2" TEXT {44}
S: + Ready for literal data
C:
C: --------------030308070208000400050907--
C: )
S: A003 OK [APPENDUID 385759045 45] append Completed
C: A004 UID STORE 20 +FLAGS.SILENT (\Deleted)
S: A004 OK STORE completed
C: A003 APPEND Drafts (\Seen \Draft $MDNSent) CATENATE (TEXT {738}
S: + Ready for literal data
C: Return-Path: <bar@example.org>
C: Received: from [127.0.0.2]
C: by rufus.example.org via TCP (internal) with ESMTPA;
C: Thu, 11 Nov 2004 16:57:07 +0000
C: Message-ID: <419399E1.6000505@example.org>
C: Date: Thu, 12 Nov 2004 16:57:05 +0000
C: From: Bob Ar <bar@example.org>
C: X-Accept-Language: en-us, en
C: MIME-Version: 1.0
C: To: foo@example.net
C: Subject: About our holiday trip
C: Content-Type: multipart/mixed;
C: boundary="------------030308070208000400050907"
C:
C: --------------030308070208000400050907
C: Content-Type: text/plain; charset=us-ascii; format=flowed
C: Content-Transfer-Encoding: 7bit
C:
C: Our travel agent has sent the updated schedule.
C:
C: Cheers,
C: Bob
C: --------------030308070208000400050907
C: URL "/Drafts;UIDVALIDITY=385759045/;UID=20/;Section=2.MIME"
URL "/Drafts;UIDVALIDITY=385759045/;UID=20/;Section=2" TEXT {44}
S: + Ready for literal data
C:
C: --------------030308070208000400050907--
C: )
S: A003 OK [APPENDUID 385759045 45] append Completed
C: A004 UID STORE 20 +FLAGS.SILENT (\Deleted)
S: A004 OK STORE completed
Example 3: The following example demonstrates how the CATENATE extension can be used to strip attachments. Below, a PowerPoint attachment was replaced by a small text part explaining that the attachment was stripped.
示例3：下面的示例演示如何使用CATENATE扩展来剥离附件。下面，一个PowerPoint附件被一个小文本部分替换，说明附件已被剥离。
C: A003 APPEND Drafts (\Seen \Draft $MDNSent) CATENATE
(URL "/Drafts;UIDVALIDITY=385759045/;UID=21/;section=HEADER"
TEXT {42}
S: + Ready for literal data
C:
C: --------------030308070208000400050903
C: URL "/Drafts;UIDVALIDITY=385759045/;UID=21/;section=1.MIME"
URL "/Drafts;UIDVALIDITY=385759045/;UID=21/;section=1" TEXT {255}
S: + Ready for literal data
C:
C: --------------030308070208000400050903
C: Content-type: text/plain; charset="us-ascii"
C: Content-transfer-encoding: 7bit
C:
C: This body part contained a Power Point presentation that was
C: deleted upon your request.
C: --------------030308070208000400050903--
C: )
S: A003 OK append Completed
C: A003 APPEND Drafts (\Seen \Draft $MDNSent) CATENATE
(URL "/Drafts;UIDVALIDITY=385759045/;UID=21/;section=HEADER"
TEXT {42}
S: + Ready for literal data
C:
C: --------------030308070208000400050903
C: URL "/Drafts;UIDVALIDITY=385759045/;UID=21/;section=1.MIME"
URL "/Drafts;UIDVALIDITY=385759045/;UID=21/;section=1" TEXT {255}
S: + Ready for literal data
C:
C: --------------030308070208000400050903
C: Content-type: text/plain; charset="us-ascii"
C: Content-transfer-encoding: 7bit
C:
C: This body part contained a Power Point presentation that was
C: deleted upon your request.
C: --------------030308070208000400050903--
C: )
S: A003 OK append Completed
Example 4: The following example demonstrates a failed APPEND command. The server returns the BADURL response code to indicate that one of the provided URLs is invalid. This example also demonstrates how the CATENATE extension can be used to construct a digest of several messages.
示例4：下面的示例演示了一个失败的APPEND命令。服务器返回BADURL响应代码以指示提供的URL之一无效。此示例还演示了如何使用CATENATE扩展来构造多条消息的摘要。
C: A003 APPEND Sent (\Seen $MDNSent) CATENATE (TEXT {541}
S: + Ready for literal data
C: Return-Path: <foo@example.org>
C: Received: from [127.0.0.2]
C: by rufus.example.org via TCP (internal) with ESMTPA;
C: Thu, 11 Nov 2004 16:57:07 +0000
C: Message-ID: <419399E1.6000505@example.org>
C: Date: Thu, 21 Nov 2004 16:57:05 +0000
C: From: Farren Oo <foo@example.org>
C: X-Accept-Language: en-us, en
C: MIME-Version: 1.0
C: To: bar@example.org
C: Subject: Digest of the mailing list for today
C: Content-Type: multipart/digest;
C: boundary="------------030308070208000400050904"
C:
C: --------------030308070208000400050904
C: URL "/INBOX;UIDVALIDITY=785799047/;UID=11467" TEXT {42}
S: + Ready for literal data
C:
C: --------------030308070208000400050904
C: URL "/INBOX;UIDVALIDITY=785799047/;UID=113330/;section=1.5.9"
TEXT {42}
S: + Ready for literal data
C:
C: --------------030308070208000400050904
C: URL "/INBOX;UIDVALIDITY=785799047/;UID=11916" TEXT {44}
S: + Ready for literal data
C:
C: --------------030308070208000400050904--
C: )
S: A003 NO [BADURL "/INBOX;UIDVALIDITY=785799047/;UID=113330;
section=1.5.9"] CATENATE append has failed, one message expunged
C: A003 APPEND Sent (\Seen $MDNSent) CATENATE (TEXT {541}
S: + Ready for literal data
C: Return-Path: <foo@example.org>
C: Received: from [127.0.0.2]
C: by rufus.example.org via TCP (internal) with ESMTPA;
C: Thu, 11 Nov 2004 16:57:07 +0000
C: Message-ID: <419399E1.6000505@example.org>
C: Date: Thu, 21 Nov 2004 16:57:05 +0000
C: From: Farren Oo <foo@example.org>
C: X-Accept-Language: en-us, en
C: MIME-Version: 1.0
C: To: bar@example.org
C: Subject: Digest of the mailing list for today
C: Content-Type: multipart/digest;
C: boundary="------------030308070208000400050904"
C:
C: --------------030308070208000400050904
C: URL "/INBOX;UIDVALIDITY=785799047/;UID=11467" TEXT {42}
S: + Ready for literal data
C:
C: --------------030308070208000400050904
C: URL "/INBOX;UIDVALIDITY=785799047/;UID=113330/;section=1.5.9"
TEXT {42}
S: + Ready for literal data
C:
C: --------------030308070208000400050904
C: URL "/INBOX;UIDVALIDITY=785799047/;UID=11916" TEXT {44}
S: + Ready for literal data
C:
C: --------------030308070208000400050904--
C: )
S: A003 NO [BADURL "/INBOX;UIDVALIDITY=785799047/;UID=113330;
section=1.5.9"] CATENATE append has failed, one message expunged
Note that the server could have validated the URLs as they were received and therefore could have returned the tagged NO response with BADURL response-code in place of any continuation request after the URL was received.
请注意，服务器可以在接收URL时验证URL，因此可以在接收URL后返回带有BADURL响应代码的标记NO响应，而不是任何继续请求。
[1] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[1] Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 35012003年3月。
[2] Newman, C., "IMAP URL Scheme", RFC 2192, September 1997.
[2] 纽曼，C.，“IMAP URL方案”，RFC 2192，1997年9月。
[3] Crispin, M., "Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension", RFC 3502, March 2003.
[3] Crispin，M.，“因特网消息访问协议（IMAP）-多附加扩展”，RFC 35022003年3月。
[4] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[4] Resnick，P.，“互联网信息格式”，RFC 2822，2001年4月。
[5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[5] Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第一部分：互联网邮件正文格式”，RFC 20451996年11月。
[6] Crispin, M., "Internet Message Access Protocol (IMAP) - UIDPLUS extension", RFC 4315, December 2005.
[6] Crispin，M.，“互联网消息访问协议（IMAP）-UIDPLUS扩展”，RFC 4315，2005年12月。
[7] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[7] Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 42342005年10月。
[8] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF", RFC 4466, April 2006.
[8] Melnikov，A.和C.Daboo，“IMAP4 ABNF的扩展集”，RFC4466，2006年4月。
Author's Address
作者地址
Peter W. Resnick QUALCOMM Incorporated 5775 Morehouse Drive San Diego, CA 92121-1714 US
Peter W.Resnick高通公司美国加利福尼亚州圣地亚哥Morehouse大道5775号，邮编92121-1714
Phone: +1 858 651 4478
EMail: presnick@qualcomm.com
URI: http://www.qualcomm.com/~presnick/
Phone: +1 858 651 4478
EMail: presnick@qualcomm.com
URI: http://www.qualcomm.com/~presnick/
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）提供。