Internet Engineering Task Force (IETF) A. Melnikov, Ed.
Request for Comments: 7888 Isode Ltd
Obsoletes: 2088 May 2016
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) A. Melnikov, Ed.
Request for Comments: 7888 Isode Ltd
Obsoletes: 2088 May 2016
Category: Standards Track
ISSN: 2070-1721
IMAP4 Non-synchronizing Literals
IMAP4非同步文本
Abstract
摘要
The Internet Message Access Protocol (RFC 3501) contains the "literal" syntactic construct for communicating strings. When sending a literal from client to server, IMAP requires the client to wait for the server to send a command continuation request between sending the octet count and the string data. This document specifies an alternate form of literal that does not require this network round trip.
Internet消息访问协议（RFC 3501）包含用于通信字符串的“文字”语法结构。当从客户端向服务器发送文本时，IMAP要求客户端在发送八位字节计数和字符串数据之间等待服务器发送命令继续请求。本文档指定了不需要此网络往返的文本的替代形式。
This document specifies 2 IMAP extensions: LITERAL+ and LITERAL-. LITERAL+ allows the alternate form of literals in all IMAP commands. LITERAL- is the same as LITERAL+, but it disallows the alternate form of literals unless they are 4096 bytes or less.
本文档指定了两个IMAP扩展：LITERAL+和LITERAL-。LITERAL+允许在所有IMAP命令中使用文字的替代形式。LITERAL-与LITERAL+相同，但它不允许文本的替代形式，除非它们是4096字节或更少。
This document obsoletes RFC 2088.
本文件淘汰了RFC 2088。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7888.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7888.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Considerations on When to Use and Not to Use Synchronizing
Literals . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. LITERAL- Capability . . . . . . . . . . . . . . . . . . . . . 5
6. Interaction with BINARY Extension . . . . . . . . . . . . . . 6
7. Interaction with MULTIAPPEND Extension . . . . . . . . . . . 6
8. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 6
9. Security Considerations . . . . . . . . . . . . . . . . . . . 7
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
11.1. Normative References . . . . . . . . . . . . . . . . . . 7
11.2. Informative References . . . . . . . . . . . . . . . . . 8
Appendix A. Changes since RFC 2088 . . . . . . . . . . . . . . . 9
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Considerations on When to Use and Not to Use Synchronizing
Literals . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. LITERAL- Capability . . . . . . . . . . . . . . . . . . . . . 5
6. Interaction with BINARY Extension . . . . . . . . . . . . . . 6
7. Interaction with MULTIAPPEND Extension . . . . . . . . . . . 6
8. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 6
9. Security Considerations . . . . . . . . . . . . . . . . . . . 7
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
11.1. Normative References . . . . . . . . . . . . . . . . . . 7
11.2. Informative References . . . . . . . . . . . . . . . . . 8
Appendix A. Changes since RFC 2088 . . . . . . . . . . . . . . . 9
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
The Internet Message Access Protocol [RFC3501] contains the "literal" syntactic construct for communicating strings. When sending a literal from client to server, IMAP requires the client to wait for the server to send a command continuation request between sending the octet count and the string data. This document specifies an alternate form of literal that does not require this network round trip.
Internet消息访问协议[RFC3501]包含用于通信字符串的“文字”语法结构。当从客户端向服务器发送文本时，IMAP要求客户端在发送八位字节计数和字符串数据之间等待服务器发送命令继续请求。本文档指定了不需要此网络往返的文本的替代形式。
This document specifies 2 IMAP extensions: LITERAL+ and LITERAL-. LITERAL+ allows the alternate form of literals (called "non-synchronized literals" below) in all IMAP commands. LITERAL- is the same as LITERAL+, but it disallows the alternate form of literals unless they are 4096 bytes or less.
本文档指定了两个IMAP扩展：LITERAL+和LITERAL-。LITERAL+允许在所有IMAP命令中使用替代形式的文字（下面称为“非同步文字”）。LITERAL-与LITERAL+相同，但它不允许文本的替代形式，除非它们是4096字节或更少。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
In examples, "C:" and "S:" indicate lines sent by the client and server, respectively. If a single "C:" or "S:" label applies to multiple lines, then the line breaks between those lines are for editorial clarity only and are not part of the actual protocol exchange.
在示例中，“C:”和“S:”分别表示客户端和服务器发送的行。如果单个“C:”或“S:”标签适用于多行，则这些行之间的换行符仅用于编辑清晰性，不属于实际协议交换的一部分。
The non-synchronizing literal is added as an alternate form of literal, and it may appear in communication from client to server instead of the IMAP [RFC3501] form of literal. The IMAP form of literal, used in communication from client to server, is referred to as a synchronizing literal. The non-synchronizing literal form MUST NOT be sent from server to client.
非同步文字作为文字的另一种形式添加，它可能出现在从客户端到服务器的通信中，而不是IMAP[RFC3501]形式的文字。在从客户端到服务器的通信中使用的IMAP形式的文本称为同步文本。非同步文字表单不能从服务器发送到客户端。
Non-synchronizing literals may be used with any IMAP server implementation that returns "LITERAL+" or "LITERAL-" as one of the supported capabilities to the CAPABILITY command. If the server does not advertise either of the above capabilities, the client can only use synchronizing literals. The difference between LITERAL+ and LITERAL- extensions is explained in Section 5.
非同步文本可用于任何将“LITERAL+”或“LITERAL-”作为支持的功能之一返回给CAPABILITY命令的IMAP服务器实现。如果服务器未公布上述任一功能，则客户端只能使用同步文本。第5节解释了LITERAL+和LITERAL-扩展之间的区别。
The non-synchronizing literal is distinguished from the original synchronizing literal by having a plus ('+') between the octet count and the closing brace ('}'). The server does not generate a command
非同步文字与原始同步文字的区别在于八位字节计数和右大括号（'}'）之间有一个加号（'+'）。服务器不生成命令
continuation request in response to a non-synchronizing literal, and clients are not required to wait before sending the octets of a non-synchronizing literal.
响应非同步文本的继续请求，客户端不需要在发送非同步文本的八位字节之前等待。
The protocol receiver of an IMAP server MUST check the end of every received line (a sequence of octets that ends with a CRLF) for an open brace ('{') followed by an octet count, a plus ('+'), and a close brace ('}') immediately preceding the CRLF. This sequence (if found by the receiver) is the octet count of a non-synchronizing literal, and the server MUST treat the specified number of following octets and the following line (as defined in [RFC3501]) as part of the same command.
IMAP服务器的协议接收器必须检查每个接收到的行（以CRLF结尾的八位字节序列）的末尾是否有一个开大括号（“{”）后跟一个八位字节计数、一个加号（“+”）和一个紧大括号（“}”）。该序列（如果接收方发现）是非同步文本的八位字节计数，服务器必须将指定数量的后续八位字节和后续行（如[RFC3501]中定义）视为同一命令的一部分。
It's important to note that the literal is not delimited by CRLF. It ends after the number of bytes specified by the octet count, and the current command continues from there. There might be a CRLF immediately after; it ends the command. Or, there might be more octets, specifying other command parameters, before the CRLF. If a SP (space) character is needed between parameters, it's important that the SP appear after the literal, in its appropriate place.
需要注意的是，文本不是由CRLF分隔的。它在八位字节计数指定的字节数之后结束，当前命令从此处继续。之后可能立即出现CRLF；命令结束。或者，在CRLF之前可能有更多的八位字节，指定其他命令参数。如果参数之间需要SP（空格）字符，则SP必须出现在文字后面的适当位置。
A server MAY still process commands and reject errors on a line-by-line basis, as long as it checks for non-synchronizing literals at the end of each line.
服务器仍然可以逐行处理命令和拒绝错误，只要它检查每行末尾的非同步文本。
Example:
例子：
C: A001 LOGIN {11+}
C: FRED FOOBAR {7+}
C: fat man
S: A001 OK LOGIN completed
C: A001 LOGIN {11+}
C: FRED FOOBAR {7+}
C: fat man
S: A001 OK LOGIN completed
This is semantically equivalent to this version that uses quoted strings instead of literals:
这在语义上等同于使用带引号的字符串而不是文字的版本：
C: A001 LOGIN "FRED FOOBAR" "fat man"
S: A001 OK LOGIN completed
C: A001 LOGIN "FRED FOOBAR" "fat man"
S: A001 OK LOGIN completed
Note that the space after FOOBAR in the first version corresponds to the space between the two quoted strings in the second.
请注意，第一个版本中FOOBAR后面的空格对应于第二个版本中两个带引号的字符串之间的空格。
Understanding of this section is important for both client and server developers of this IMAP extension.
理解本节对于此IMAP扩展的客户机和服务器开发人员都很重要。
While non-synchronizing literals have clear advantages for clients, such as simplicity of use, they might be more difficult to handle on the server side. When a client uses a non-synchronizing literal that is too big for the server to accept, a server implementation that is compliant with LITERAL+ has to make a choice between a couple non-optimal choices:
虽然非同步文本对于客户端有明显的优势，例如使用简单，但它们在服务器端可能更难处理。当客户端使用的非同步文本太大，服务器无法接受时，符合literal+的服务器实现必须在两个非最佳选择之间做出选择：
1. Read the number of bytes specified in the non-synchronizing literal and reject the command that included the literal anyway. (The server is allowed to send the tagged BAD/NO response before reading the whole non-synchronizing literal.) This is quite wasteful of bandwidth if the literal is large.
1. 读取非同步文本中指定的字节数，并无论如何拒绝包含该文本的命令。（允许服务器在读取整个非同步文本之前发送标记为BAD/NO的响应。）如果文本较大，这将相当浪费带宽。
2. Send an untagged BYE response explaining the reason for rejecting the literal (possibly accompanied by an ALERT response code in another response) and close the connection. This will force the client to reconnect or report the error to the user. In the latter case, the error is unlikely to be understandable to the user. Additionally, some naive clients are known to blindly reconnect in this case and repeat the operation that caused the problem, introducing an infinite loop.
2. 发送一个未标记的BYE响应，解释拒绝文本的原因（可能在另一个响应中附带警报响应代码），然后关闭连接。这将强制客户端重新连接或向用户报告错误。在后一种情况下，用户不太可能理解错误。此外，在这种情况下，一些天真的客户机会盲目地重新连接，并重复导致问题的操作，从而引入无限循环。
The problem described above is most common when using the APPEND command, because most commands don't need to send lots of data from the client to the server. Some server implementations impose limits on literals (both synchronizing and non-synchronizing) accepted from clients in order to defend against denial-of-service attacks. Implementations can generally impose much lower limits on literal sizes for all commands other than APPEND. In order to address literal size issue in APPEND, this document introduces a new extension LITERAL-, described in Section 5.
上述问题在使用APPEND命令时最常见，因为大多数命令不需要从客户端向服务器发送大量数据。一些服务器实现对从客户端接受的文本（同步和非同步）施加限制，以抵御拒绝服务攻击。对于除APPEND以外的所有命令，实现通常可以对文字大小施加更低的限制。为了解决APPEND中的文本大小问题，本文引入了一个新的扩展literal-，如第5节所述。
The situation can also be improved by implementing support for the APPENDLIMIT extension [RFC7889], which allows a server to advertise its APPEND limit, so that well-behaved clients can check it and avoid uploading big messages in the first place.
这种情况也可以通过实现对APPENDLIMIT扩展[RFC7889]的支持来改善，该扩展允许服务器公布其APPENDLIMIT，以便行为良好的客户端可以检查它并避免首先上传大消息。
The LITERAL- extension is almost identical to LITERAL+, with one exception: when LITERAL- is advertised, non-synchronizing literals used in any command MUST NOT be larger than 4096 bytes. Any literal larger than 4096 bytes MUST be sent as a synchronizing literal as
LITERAL-extension几乎与LITERAL+相同，但有一个例外：当播发LITERAL-时，任何命令中使用的非同步文本不得大于4096字节。任何大于4096字节的文字必须作为同步文字发送，如下所示：
specified in RFC 3501. A server that is compliant with LITERAL- and encounters a non-synchronizing literal larger than 4096 bytes proceeds as described in Section 4. If responding to an APPEND command, the tagged BAD response MUST contain the TOOBIG response code [RFC4469]. If responding with an untagged BYE response, it SHOULD include the TOOBIG response code. Note that the form of the non-synchronizing literal does not change: it still uses the "+" in the literal itself, even if the applicable extension is LITERAL-.
在RFC 3501中规定。与文本兼容并遇到大于4096字节的非同步文本的服务器将按照第4节所述进行操作。如果响应APPEND命令，标记的错误响应必须包含TOOBIG响应代码[RFC4469]。如果使用未标记的BYE响应进行响应，则应包含TOOBIG响应代码。请注意，非同步文本的形式没有改变：它仍然在文本本身中使用“+”，即使适用的扩展名是literal-。
Because LITERAL- is a more restricted version of LITERAL+, IMAP servers MUST NOT advertise both of these capabilities at the same time. (A server implementation can choose to have a configuration option to indicate which one to advertise.)
因为LITERAL-是LITERAL+的一个更受限制的版本，所以IMAP服务器不能同时公布这两种功能。（服务器实现可以选择具有一个配置选项，以指示要发布的配置。）
[RFC4466] updated the non-terminal "literal8" defined in [RFC3516] to allow for non-synchronizing literals if both BINARY [RFC3516] and LITERAL+ extensions are supported by the server.
[RFC4466]更新了[RFC3516]中定义的非终端“literal8”，以便在服务器同时支持二进制[RFC3516]和LITERAL+扩展的情况下允许非同步文字。
This document also allows use of this extended "literal8" syntax when both BINARY [RFC3516] and LITERAL- extensions are supported by the server.
当服务器同时支持二进制[RFC3516]和文本扩展时，本文档还允许使用这种扩展的“literal8”语法。
[RFC3502] describes MULTIAPPEND extension and how it can be used with LITERAL+. The LITERAL- extension can be used with the MULTIAPPEND extension in the same way.
[RFC3502]介绍了多附加扩展以及如何将其与文字+一起使用。LITERAL-extension可以以相同的方式与MULTIAPPEND扩展一起使用。
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [ABNF].
以下语法规范使用[ABNF]中指定的增广Backus Naur Form（ABNF）表示法。
Non-terminals referenced but not defined below are as defined by [RFC3501].
以下引用但未定义的非端子由[RFC3501]定义。
literal = "{" number ["+"] "}" CRLF *CHAR8
; Number represents the number of CHAR8 octets
literal = "{" number ["+"] "}" CRLF *CHAR8
; Number represents the number of CHAR8 octets
CHAR8 = <defined in RFC 3501>
CHAR8 = <defined in RFC 3501>
literal8 = <defined in RFC 4466>
literal8 = <defined in RFC 4466>
Use of non-synchronizing literals can consume extra resources (e.g. memory) on IMAP servers and can be used for denial-of-service attacks. The LITERAL- extension partially improved this situation.
使用非同步文字可能会消耗IMAP服务器上的额外资源（如内存），并可用于拒绝服务攻击。文字扩展部分改善了这种情况。
This document doesn't raise any security concerns beyond those raised by [RFC3501].
除[RFC3501]提出的安全问题外，本文件未提出任何安全问题。
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/imap-capabilities>.
IMAP4功能通过发布标准跟踪或IESG批准的实验RFC进行注册。注册处目前位于<http://www.iana.org/assignments/imap-capabilities>.
IANA has updated the above registry so that the reference for "LITERAL+" points to this document.
IANA已更新了上述注册表，因此“LITERAL+”的引用指向此文档。
IANA has added the "LITERAL-" capability to the above registry, with this document as the reference.
IANA已将“LITERAL-”功能添加到上述注册表中，并将此文档作为参考。
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[ABNF]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，DOI 10.17487/RFC5234，2008年1月<http://www.rfc-editor.org/info/rfc5234>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, <http://www.rfc-editor.org/info/rfc3501>.
[RFC3501]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 3501，DOI 10.17487/RFC3501，2003年3月<http://www.rfc-editor.org/info/rfc3501>.
[RFC3516] Nerenberg, L., "IMAP4 Binary Content Extension", RFC 3516, DOI 10.17487/RFC3516, April 2003, <http://www.rfc-editor.org/info/rfc3516>.
[RFC3516]Nerenberg，L.，“IMAP4二进制内容扩展”，RFC 3516，DOI 10.17487/RFC3516，2003年4月<http://www.rfc-editor.org/info/rfc3516>.
[RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF", RFC 4466, DOI 10.17487/RFC4466, April 2006, <http://www.rfc-editor.org/info/rfc4466>.
[RFC4466]Melnikov，A.和C.Daboo，“IMAP4 ABNF的收集扩展”，RFC 4466，DOI 10.17487/RFC4466，2006年4月<http://www.rfc-editor.org/info/rfc4466>.
[RFC4469] Resnick, P., "Internet Message Access Protocol (IMAP) CATENATE Extension", RFC 4469, DOI 10.17487/RFC4469, April 2006, <http://www.rfc-editor.org/info/rfc4469>.
[RFC4469]Resnick，P.，“互联网消息访问协议（IMAP）连锁扩展”，RFC 4469，DOI 10.17487/RFC4469，2006年4月<http://www.rfc-editor.org/info/rfc4469>.
[RFC3502] Crispin, M., "Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension", RFC 3502, DOI 10.17487/RFC3502, March 2003, <http://www.rfc-editor.org/info/rfc3502>.
[RFC3502]Crispin，M.，“互联网消息访问协议（IMAP）-多附加扩展”，RFC 3502，DOI 10.17487/RFC3502，2003年3月<http://www.rfc-editor.org/info/rfc3502>.
[RFC7889] SrimushnamBoovaraghamoorthy, J. and N. Bisht, "The IMAP APPENDLIMIT Extension", RFC 7889, DOI 10.17487/RFC7889, May 2016, <http://www.rfc-editor.org/info/rfc7889>.
[RFC7889]SrimushnamBoovaraghamoorthy，J.和N.Bisht，“IMAP附录限制扩展”，RFC 7889，DOI 10.17487/RFC7889，2016年5月<http://www.rfc-editor.org/info/rfc7889>.
Added IANA registration.
增加了IANA注册。
Updated references. Also updated considerations about interactions of IMAP extensions.
更新参考资料。还更新了有关IMAP扩展交互的注意事项。
Added implementation considerations based on the IMAP mailing list discussions.
添加了基于IMAP邮件列表讨论的实现注意事项。
Added description of a new capability: LITERAL-.
添加了对新功能的描述：LITERAL-。
Acknowledgments
致谢
John G. Myers edited the original LITERAL+ extension.
John G.Myers编辑了原始文本+扩展名。
Valuable comments, both in agreement and in dissent, were received from Dave Cridland, Michael M. Slusarz, Arnt Gulbrandsen, Jayantheesh SrimushnamBoovaraghamoorthy, Jamie Nicolson, Barry Leiba, and SM.
Dave Cridland、Michael M.Slusarz、Arnt Gulbrandsen、Jayantheeesh SrimushnamBoovaraghamoorthy、Jamie Nicolson、Barry Leiba和SM提出了有价值的意见，无论是一致意见还是不同意见。
Author's Address
作者地址
Alexey Melnikov (editor) Isode Ltd 14 Castle Mews Hampton, Middlesex TW12 2NP United Kingdom
Alexey Melnikov（编辑）Isode有限公司14 Castle Mews Hampton，米德尔塞克斯TW12 2NP英国
Email: Alexey.Melnikov@isode.com
Email: Alexey.Melnikov@isode.com