Network Working Group L. Nerenberg
Request for Comments: 3516 Orthanc Systems
Category: Standards Track April 2003
Network Working Group L. Nerenberg
Request for Comments: 3516 Orthanc Systems
Category: Standards Track April 2003
IMAP4 Binary Content Extension
IMAP4二进制内容扩展
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 (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
This memo defines the Binary extension to the Internet Message Access Protocol (IMAP4). It provides a mechanism for IMAP4 clients and servers to exchange message body data without using a MIME content-transfer-encoding.
此备忘录定义了Internet消息访问协议（IMAP4）的二进制扩展。它为IMAP4客户端和服务器提供了一种机制，可以在不使用MIME内容传输编码的情况下交换消息正文数据。
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in [KEYWORD].
本文件中的关键词“必须”、“不得”、“应该”、“不应该”和“可能”应按照[关键词]中所述进行解释。
The abbreviation "CTE" means content-transfer-encoding.
缩写“CTE”表示内容传输编码。
The MIME extensions to Internet messaging allow for the transmission of non-textual (binary) message content [MIME-IMB]. Since the traditional transports for messaging are not always capable of passing binary data transparently, MIME provides encoding schemes that allow binary content to be transmitted over transports that are not otherwise able to do so.
Internet消息传递的MIME扩展允许传输非文本（二进制）消息内容[MIME-IMB]。由于用于消息传递的传统传输并不总是能够透明地传递二进制数据，因此MIME提供了编码方案，允许二进制内容通过传输进行传输，否则无法这样做。
The overhead of MIME-encoding this content can be considerable in some contexts (e.g., slow radio links, streaming multimedia). Reducing the overhead associated with CTE schemes such as base64
MIME编码此内容的开销在某些情况下可能相当大（例如，慢速无线电链接、流媒体）。减少与诸如base64之类的CTE方案相关的开销
can give a noticeable reduction in resource consumption. The Binary extension lets the server perform CTE decoding prior to transmitting message data to the client.
可以显著减少资源消耗。二进制扩展允许服务器在将消息数据传输到客户端之前执行CTE解码。
Every IMAP4 body section has a MIME content-transfer-encoding. (Those without an explicit Content-Transfer-Encoding header are implicitly labeled as "7bit" content.) In the terminology of [MIME-IMB], the CTE specifies both a decoding algorithm and the domain of the decoded data. In this memo, "decoding" refers to the CTE decoding step described in [MIME-IMB].
每个IMAP4正文部分都有一个MIME内容传输编码。（没有显式内容传输编码头的内容隐式标记为“7bit”内容。）在[MIME-IMB]术语中，CTE指定解码算法和解码数据的域。在本备忘录中，“解码”指[MIME-IMB]中描述的CTE解码步骤。
Certain CTEs use an identity encoding transformation. For these CTEs there is no decoding required, however the domain of the underlying data may not be expressible in the IMAP4 protocol (e.g., MIME "binary" content containing NUL octets). To accommodate these cases the Binary extension introduces a new type of literal protocol element that is fully eight bit transparent.
某些CTE使用身份编码转换。对于这些CTE，不需要解码，但是基础数据的域可能无法在IMAP4协议中表达（例如，包含NUL八位字节的MIME“二进制”内容）。为了适应这些情况，二进制扩展引入了一种新型的文本协议元素，它是完全8位透明的。
Thus, server processing of the FETCH BINARY command involves two logical steps:
因此，FETCH BINARY命令的服务器处理涉及两个逻辑步骤：
1) perform any CTE-related decoding
1) 执行任何与CTE相关的解码
2) determine the domain of the decoded data
2) 确定解码数据的域
Step 2 is necessary to determine which protocol element should be used to transmit the decoded data. (See FETCH Response Extensions for further details.)
步骤2是确定应该使用哪个协议元素来传输解码数据所必需的。（有关更多详细信息，请参阅获取响应扩展。）
This memo defines the following extensions to [IMAP4rev1].
本备忘录定义了[IMAP4rev1]的以下扩展。
IMAP4 servers that support this extension MUST include "BINARY" in the response list to the CAPABILITY command.
支持此扩展的IMAP4服务器必须在CAPABILITY命令的响应列表中包含“BINARY”。
This extension defines three new FETCH command data items.
此扩展定义了三个新的FETCH命令数据项。
BINARY<section-binary>[<partial>]
BINARY<section-binary>[<partial>]
Requests that the specified section be transmitted after performing CTE-related decoding.
请求在执行CTE相关解码后发送指定部分。
The <partial> argument, if present, requests that a subset of the data be returned. The semantics of a partial FETCH BINARY command are the same as for a partial FETCH BODY command, with the exception that the <partial> arguments refer to the DECODED section data.
<partial>参数（如果存在）请求返回数据的子集。部分FETCH二进制命令的语义与部分FETCH BODY命令的语义相同，但<partial>参数引用的是解码的节数据。
BINARY.PEEK<section-binary>[<partial>]
BINARY.PEEK<section-binary>[<partial>]
An alternate form of FETCH BINARY that does not implicitly set the \Seen flag.
FETCH二进制文件的另一种形式，它不隐式设置\Seen标志。
BINARY.SIZE<section-binary>
二进制。大小<节二进制>
Requests the decoded size of the section (i.e., the size to expect in response to the corresponding FETCH BINARY request).
请求段的解码大小（即，响应相应的获取二进制请求所期望的大小）。
Note: client authors are cautioned that this might be an expensive operation for some server implementations. Needlessly issuing this request could result in degraded performance due to servers having to calculate the value every time the request is issued.
注意：客户机作者需要注意的是，对于某些服务器实现来说，这可能是一个昂贵的操作。不必要地发出此请求可能会导致性能下降，因为服务器必须在每次发出请求时计算该值。
This extension defines two new FETCH response data items.
此扩展定义了两个新的获取响应数据项。
BINARY<section-binary>[<<number>>]
BINARY<section-binary>[<<number>>]
An <nstring> or <literal8> expressing the content of the specified section after removing any CTE-related encoding. If <number> is present it refers to the offset within the DECODED section data.
一种<nstring>或<literal8>在删除任何与CTE相关的编码后表示指定节的内容。如果存在<number>，则表示解码部分数据内的偏移量。
If the domain of the decoded data is "8bit" and the data does not contain the NUL octet, the server SHOULD return the data in a <string> instead of a <literal8>; this allows the client to determine if the "8bit" data contains the NUL octet without having to explicitly scan the data stream for for NULs.
如果解码数据的域为“8bit”，且数据不包含NUL八位字节，则服务器应以<string>而不是<literal8>的形式返回数据；这允许客户端确定“8位”数据是否包含NUL八位字节，而无需显式扫描数据流中的NUL。
If the server does not know how to decode the section's CTE, it MUST fail the request and issue a "NO" response that contains the "UNKNOWN-CTE" extended response code.
如果服务器不知道如何解码节的CTE，则必须使请求失败，并发出包含“UNKNOWN-CTE”扩展响应代码的“NO”响应。
BINARY.SIZE<section-binary>
二进制。大小<节二进制>
The size of the section after removing any CTE-related encoding. The value returned MUST match the size of the <nstring> or <literal8> that will be returned by the corresponding FETCH BINARY request.
删除任何CTE相关编码后的节大小。返回的值必须与相应的获取二进制请求返回的<nstring>或<literal8>的大小匹配。
If the server does not know how to decode the section's CTE, it MUST fail the request and issue a "NO" response that contains the "UNKNOWN-CTE" extended response code.
如果服务器不知道如何解码节的CTE，则必须使请求失败，并发出包含“UNKNOWN-CTE”扩展响应代码的“NO”响应。
The APPEND command is extended to allow the client to append data containing NULs by using the <literal8> syntax. The server MAY modify the CTE of the appended data, however any such transformation MUST NOT result in a loss of data.
APPEND命令经过扩展，允许客户端使用<literal8>语法追加包含NUL的数据。服务器可以修改附加数据的CTE，但是任何此类转换不得导致数据丢失。
If the destination mailbox does not support the storage of binary content, the server MUST fail the request and issue a "NO" response that contains the "UNKNOWN-CTE" extended response code.
如果目标邮箱不支持存储二进制内容，服务器必须使请求失败，并发出包含“UNKNOWN-CTE”扩展响应代码的“NO”响应。
[MIME-MHE] defines an encoding that allows for non-US-ASCII text in message headers. This encoding is not the same as the content-transfer-encoding applied to message bodies, and the decoding transformations described in this memo do not apply to [MIME-MHE] encoded header text. A server MUST NOT perform any conversion of [MIME-MHE] encoded header text in response to any binary FETCH or APPEND request.
[MIME-MHE]定义了允许在消息头中使用非美国ASCII文本的编码。此编码与应用于消息正文的内容传输编码不同，本备忘录中描述的解码转换不适用于[MIME-MHE]编码的标题文本。服务器不得对[MIME-MHE]编码的头文本执行任何转换，以响应任何二进制获取或追加请求。
Messaging clients and servers have been notoriously lax in their adherence to the Internet CRLF convention for terminating lines of textual data in Internet protocols. When sending data using the Binary extension, servers MUST ensure that textual line-oriented sections are always transmitted using the IMAP4 CRLF line termination syntax, regardless of the underlying storage representation of the data on the server.
众所周知，消息传递客户机和服务器在遵守Internet CRLF协议（用于终止Internet协议中的文本数据行）方面非常松懈。使用二进制扩展发送数据时，服务器必须确保始终使用IMAP4 CRLF行终止语法传输面向文本行的节，而不管服务器上数据的底层存储表示形式如何。
A server may choose to store message body binary content in a non-encoded format. Regardless of the internal storage representation used, the server MUST issue BODYSTRUCTURE responses that describe the message as though the binary-encoded sections are encoded in a CTE
服务器可以选择以非编码格式存储消息正文二进制内容。无论使用何种内部存储表示，服务器都必须发出BODYSTRUCTURE响应，以描述消息，就像二进制编码的部分在CTE中编码一样
acceptable to the IMAP4 base specification. Furthermore, the results of a FETCH BODY MUST return the message body content in the format described by the corresponding FETCH BODYSTRUCTURE response.
可接受IMAP4基本规范。此外，获取正文的结果必须以相应的获取正文结构响应所描述的格式返回消息正文内容。
While the server is allowed to modify the CTE of APPENDed <literal8> data, this should only be done when it is absolutely necessary. Gratuitous encoding changes will render useless most cryptographic operations that have been performed on the message.
虽然允许服务器修改附加的<literal8>数据的CTE，但这只应在绝对必要时进行。无偿的编码更改将导致对消息执行的大多数加密操作无效。
This extension provides an optimization that is useful in certain specific situations. It does not absolve clients from providing basic functionality (content transfer decoding) that should be available in all messaging clients. Clients supporting this extension SHOULD be prepared to perform their own CTE decoding operations.
此扩展提供了在某些特定情况下有用的优化。它并不免除客户机提供所有消息传递客户机都应具备的基本功能（内容传输解码）。支持此扩展的客户端应准备好执行自己的CTE解码操作。
The following syntax specification uses the augmented Backus-Naur Form (ABNF) notation as used in [ABNF], and incorporates by reference the Core Rules defined in that document.
以下语法规范使用[ABNF]中使用的增广Backus Naur Form（ABNF）表示法，并通过引用合并了该文档中定义的核心规则。
This syntax augments the grammar specified in [IMAP4rev1].
此语法扩充了[IMAP4rev1]中指定的语法。
append =/ "APPEND" SP mailbox [SP flag-list] [SP date-time] SP literal8
append=/“append”SP邮箱[SP标志列表][SP日期时间]SP文字8
fetch-att =/ "BINARY" [".PEEK"] section-binary [partial] / "BINARY.SIZE" section-binary
fetch att=/“BINARY”[“.PEEK”]节二进制[部分]/“BINARY.SIZE”节二进制
literal8 = "~{" number "}" CRLF *OCTET ; <number> represents the number of OCTETs ; in the response string.
literal8=“~{“number”}”CRLF*八位字节<number>表示八位字节的数量；在响应字符串中。
msg-att-static =/ "BINARY" section-binary SP (nstring / literal8)
/ "BINARY.SIZE" section-binary SP number
msg-att-static =/ "BINARY" section-binary SP (nstring / literal8)
/ "BINARY.SIZE" section-binary SP number
partial = "<" number "." nz-number ">"
partial = "<" number "." nz-number ">"
resp-text-code =/ "UNKNOWN-CTE"
resp文本代码=/“未知-CTE”
section-binary = "[" [section-part] "]"
section binary=“[”[section part]”
[ABNF] Crocker, D., Editor, and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[ABNF]Crocker，D.，编辑和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[IMAP4rev1] Crispin, M., "Internet Message Access Protocol Version 4rev1", RFC 3501, March 2003.
[IMAP4rev1]Crispin，M.，“互联网消息访问协议版本4rev1”，RFC 35012003年3月。
[KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 211997年3月。
[MIME-IMB] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[MIME-IMB]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
[MIME-MHE] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[MIME-MHE]Moore，K.，“MIME（多用途互联网邮件扩展）第三部分：非ASCII文本的消息头扩展”，RFC 2047，1996年11月。
There are no known additional security issues with this extension beyond those described in the base protocol described in [IMAP4rev1].
除了[IMAP4rev1]中描述的基本协议中描述的安全问题外，此扩展没有已知的其他安全问题。
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息，请参见BCP-11。可从IETF秘书处获得可供发布的权利声明副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涉及实施本标准所需技术的专有权利。请将信息发送给IETF执行董事。
Lyndon Nerenberg Orthanc Systems 1606 - 10770 Winterburn Road Edmonton, Alberta Canada T5S 1T6
Lyndon Nerenberg Orthanc Systems 1606-10770加拿大阿尔伯塔省埃德蒙顿温特伯恩路T5S 1T6
EMail: lyndon@orthanc.ab.ca
EMail: lyndon@orthanc.ab.ca
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。