Internet Engineering Task Force (IETF) K. Murchison
Request for Comments: 8054 Carnegie Mellon University
Category: Standards Track J. Elie
ISSN: 2070-1721 January 2017
Internet Engineering Task Force (IETF) K. Murchison
Request for Comments: 8054 Carnegie Mellon University
Category: Standards Track J. Elie
ISSN: 2070-1721 January 2017
Network News Transfer Protocol (NNTP) Extension for Compression
用于压缩的网络新闻传输协议（NNTP）扩展
Abstract
摘要
This document defines an extension to the Network News Transport Protocol (NNTP) that allows a connection to be effectively and efficiently compressed between an NNTP client and server.
本文档定义了网络新闻传输协议（NNTP）的扩展，该协议允许在NNTP客户端和服务器之间有效地压缩连接。
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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第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/rfc8054.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8054.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 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许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. About TLS-Level Compression . . . . . . . . . . . . . . . 3
1.2. Conventions Used in This Document . . . . . . . . . . . . 4
2. The COMPRESS Extension . . . . . . . . . . . . . . . . . . . 4
2.1. Advertising the COMPRESS Extension . . . . . . . . . . . 4
2.2. COMPRESS Command . . . . . . . . . . . . . . . . . . . . 5
2.2.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.2. Description . . . . . . . . . . . . . . . . . . . . . 6
2.2.3. Examples . . . . . . . . . . . . . . . . . . . . . . 8
3. Compression Efficiency . . . . . . . . . . . . . . . . . . . 11
4. DEFLATE Specificities . . . . . . . . . . . . . . . . . . . . 12
5. Augmented BNF Syntax for the COMPRESS Extension . . . . . . . 13
5.1. Commands . . . . . . . . . . . . . . . . . . . . . . . . 13
5.2. Capability Entries . . . . . . . . . . . . . . . . . . . 13
5.3. General Non-terminals . . . . . . . . . . . . . . . . . . 13
6. Summary of Response Codes . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8.1. "NNTP Compression Algorithms" Registry . . . . . . . . . 15
8.1.1. Algorithm Name Registration Procedure . . . . . . . . 16
8.1.2. Comments on Algorithm Registrations . . . . . . . . . 17
8.1.3. Change Control . . . . . . . . . . . . . . . . . . . 17
8.2. Registration of the DEFLATE Compression Algorithm . . . . 18
8.3. Registration of the NNTP COMPRESS Extension . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . 20
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. About TLS-Level Compression . . . . . . . . . . . . . . . 3
1.2. Conventions Used in This Document . . . . . . . . . . . . 4
2. The COMPRESS Extension . . . . . . . . . . . . . . . . . . . 4
2.1. Advertising the COMPRESS Extension . . . . . . . . . . . 4
2.2. COMPRESS Command . . . . . . . . . . . . . . . . . . . . 5
2.2.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.2. Description . . . . . . . . . . . . . . . . . . . . . 6
2.2.3. Examples . . . . . . . . . . . . . . . . . . . . . . 8
3. Compression Efficiency . . . . . . . . . . . . . . . . . . . 11
4. DEFLATE Specificities . . . . . . . . . . . . . . . . . . . . 12
5. Augmented BNF Syntax for the COMPRESS Extension . . . . . . . 13
5.1. Commands . . . . . . . . . . . . . . . . . . . . . . . . 13
5.2. Capability Entries . . . . . . . . . . . . . . . . . . . 13
5.3. General Non-terminals . . . . . . . . . . . . . . . . . . 13
6. Summary of Response Codes . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8.1. "NNTP Compression Algorithms" Registry . . . . . . . . . 15
8.1.1. Algorithm Name Registration Procedure . . . . . . . . 16
8.1.2. Comments on Algorithm Registrations . . . . . . . . . 17
8.1.3. Change Control . . . . . . . . . . . . . . . . . . . 17
8.2. Registration of the DEFLATE Compression Algorithm . . . . 18
8.3. Registration of the NNTP COMPRESS Extension . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . 20
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
The goal of COMPRESS is to reduce the bandwidth usage of NNTP.
压缩的目标是减少NNTP的带宽使用。
Compared to PPP compression [RFC1962] and modem-based compression ([MNP] and [V42bis]), COMPRESS offers greater compression efficiency. COMPRESS can be used together with Transport Layer Security (TLS) [RFC5246], Simple Authentication and Security Layer (SASL) encryption [RFC4422], Virtual Private Networks (VPNs), etc.
与PPP压缩[RFC1962]和基于调制解调器的压缩（[MNP]和[V42bis]）相比，压缩提供了更高的压缩效率。COMPRESS可与传输层安全（TLS）[RFC5246]、简单身份验证和安全层（SASL）加密[RFC4422]、虚拟专用网络（VPN）等一起使用。
The point of COMPRESS as an NNTP extension is to act as a compression layer, similar to a security layer like the one negotiated by STARTTLS [RFC4642]. Therefore, compression can be beneficial to all NNTP commands sent or received after the use of COMPRESS. This facility responds to a long-standing need for NNTP to compress data. It is currently addressed only partially by unstandardized commands like XZVER, XZHDR, XFEATURE COMPRESS, or MODE COMPRESS. Yet, these commands are not wholly satisfactory because they enable compression only for the responses sent by the news server. In comparison, the COMPRESS command permits the compression of data sent by both the client and the server, and removes the constraint of having to implement compression separately in each NNTP command. Besides, the compression level can be dynamically adjusted and optimized at any time during the connection, which even allows disabling compression for certain commands, if needed. If the news client wants to stop compression on a particular connection, it can simply use QUIT ([RFC3977], Section 5.4) and establish a new connection. For these reasons, using other NNTP commands than COMPRESS to enable compression is discouraged once COMPRESS is supported.
压缩作为NNTP扩展的要点是充当压缩层，类似于STARTTLS协商的安全层[RFC4642]。因此，压缩可有益于使用压缩后发送或接收的所有NNTP命令。此功能响应NNTP压缩数据的长期需求。目前，非标准命令（如XZVER、XZHDR、xfeaturecompress或modecompress）只能部分解决该问题。然而，这些命令并不完全令人满意，因为它们只对新闻服务器发送的响应启用压缩。相比之下，COMPRESS命令允许压缩客户端和服务器发送的数据，并消除了必须在每个NNTP命令中分别实现压缩的约束。此外，在连接过程中，可以随时动态调整和优化压缩级别，如果需要，甚至可以禁用某些命令的压缩。如果新闻客户端想要停止对特定连接的压缩，它可以简单地使用QUIT（[RFC3977]，第5.4节）并建立一个新连接。由于这些原因，一旦支持压缩，就不鼓励使用压缩以外的其他NNTP命令来启用压缩。
In order to increase interoperability, it is desirable to have as few different compression algorithms as possible, so this document specifies only one. The DEFLATE algorithm (defined in [RFC1951]) MUST be implemented as part of this extension. This compression algorithm is standard, widely available, and fairly efficient.
为了提高互操作性，需要尽可能少地使用不同的压缩算法，因此本文档仅指定一种。DEFLATE算法（在[RFC1951]中定义）必须作为此扩展的一部分实现。这种压缩算法是标准的，可广泛使用，并且相当有效。
This specification should be read in conjunction with the NNTP base specification [RFC3977]. In the case of a conflict between these two documents, [RFC3977] takes precedence.
本规范应与NNTP基本规范[RFC3977]一起阅读。如果这两个文件之间存在冲突，则以[RFC3977]为准。
Though lossless data compression is already possible via the use of TLS with NNTP [RFC4642], the best current practice is to disable TLS-level compression as explained in Section 3.3 of [RFC7525]. The COMPRESS command will permit keeping the compression facility in NNTP, and control when it is available during a connection.
尽管通过将TLS与NNTP结合使用[RFC4642]已经可以实现无损数据压缩，但目前的最佳做法是禁用TLS级压缩，如[RFC7525]第3.3节所述。COMPRESS命令将允许压缩设施保持在NNTP中，并在连接期间控制其可用性。
Compared to TLS-level compression [RFC3749], NNTP COMPRESS has the following advantages:
与TLS级压缩[RFC3749]相比，NNTP压缩具有以下优点：
o COMPRESS can be implemented easily both by NNTP servers and clients.
o 压缩可以很容易地由NNTP服务器和客户端实现。
o COMPRESS benefits from an intimate knowledge of the NNTP protocol's state machine, allowing for dynamic and aggressive optimization of the underlying compression algorithm's parameters.
o 压缩得益于对NNTP协议状态机的深入了解，允许对底层压缩算法的参数进行动态和积极的优化。
o COMPRESS can be activated after authentication has completed, thus reducing the chances that authentication credentials can be leaked via, for instance, a CRIME attack ([RFC7457], Section 2.6).
o 压缩可以在身份验证完成后激活，从而减少身份验证凭据可能通过犯罪攻击等方式泄露的可能性（[RFC7457]，第2.6节）。
The notational conventions used in this document are the same as those in [RFC3977], and any term not defined in this document has the same meaning as it does in that one.
本文件中使用的符号约定与[RFC3977]中的符号约定相同，且本文件中未定义的任何术语具有与该文件中相同的含义。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
In the examples, commands from the client are indicated with [C], and responses from the server are indicated with [S]. The client is the initiator of the NNTP connection; the server is the other endpoint.
在示例中，来自客户端的命令用[C]表示，来自服务器的响应用[S]表示。客户端是NNTP连接的发起方；服务器是另一个端点。
The COMPRESS extension is used to enable lossless data compression on an NNTP connection.
压缩扩展用于在NNTP连接上启用无损数据压缩。
This extension provides a new COMPRESS command and has the capability label COMPRESS.
此扩展提供了一个新的COMPRESS命令，并具有COMPRESS功能标签。
A server supporting the COMPRESS command as defined in this document will advertise the "COMPRESS" capability label in response to the CAPABILITIES command ([RFC3977], Section 5.2). However, this capability MUST NOT be advertised once a compression layer is active (see Section 2.2.2). This capability MAY be advertised both before and after any use of the MODE READER command ([RFC3977], Section 5.3), with the same semantics.
支持本文档中定义的压缩命令的服务器将公布“压缩”能力标签，以响应能力命令（[RFC3977]，第5.2节）。但是，一旦压缩层处于活动状态，则不得公布此功能（见第2.2.2节）。在使用模式读取器命令之前和之后（第5.3节[RFC3977]）都可以以相同的语义公布此功能。
The COMPRESS capability label contains a whitespace-separated list of available compression algorithms. This document defines one compression algorithm: DEFLATE. This algorithm is mandatory to implement; it MUST be supported and listed in the advertisement of the COMPRESS extension.
压缩能力标签包含可用压缩算法的空白分隔列表。本文档定义了一种压缩算法：DEFLATE。该算法是强制实现的；它必须得到支持，并在压缩扩展的广告中列出。
Future extensions may add additional compression algorithms to this capability. Unrecognized algorithms MUST be ignored by the client.
未来的扩展可能会为此功能添加其他压缩算法。客户端必须忽略无法识别的算法。
Example:
例子：
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] READER
[S] IHAVE
[S] COMPRESS DEFLATE SHRINK
[S] LIST ACTIVE NEWSGROUPS
[S] .
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] READER
[S] IHAVE
[S] COMPRESS DEFLATE SHRINK
[S] LIST ACTIVE NEWSGROUPS
[S] .
As the COMPRESS command is related to security because it can weaken encryption, cached results of CAPABILITIES from a previous session MUST NOT be relied on, as per Section 12.6 of [RFC3977].
根据[RFC3977]第12.6节的规定，由于COMPRESS命令与安全性相关，因为它会削弱加密，因此不能依赖上一个会话的缓存结果。
This command MUST NOT be pipelined.
此命令不能通过管道传输。
Syntax COMPRESS algorithm
语法压缩算法
Responses 206 Compression active 403 Unable to activate compression 502 Command unavailable [1]
响应206压缩激活403无法激活压缩502命令不可用[1]
[1] If a compression layer is already active, COMPRESS is not a valid command (see Section 2.2.2).
[1] 如果压缩层已处于活动状态，则“压缩”命令无效（请参阅第2.2.2节）。
Parameters algorithm = Name of compression algorithm (e.g., "DEFLATE")
参数算法=压缩算法的名称（例如，“DEFLATE”）
The COMPRESS command instructs the server to use the named compression algorithm ("DEFLATE" is the only one defined in this document) for all commands and responses after COMPRESS.
COMPRESS命令指示服务器对压缩后的所有命令和响应使用命名压缩算法（“DEFLATE”是本文档中定义的唯一算法）。
The client MUST NOT send any further commands until it has seen the result of COMPRESS.
在看到压缩结果之前，客户端不得发送任何进一步的命令。
If the requested compression algorithm is syntactically incorrect, the server MUST reject the COMPRESS command with a 501 response code ([RFC3977], Section 3.2.1). If the requested compression algorithm is invalid (e.g., is not supported), the server MUST reject the COMPRESS command with a 503 response code ([RFC3977], Section 3.2.1). If the server is unable to activate compression for any reason (e.g., a server configuration or resource problem), the server MUST reject the COMPRESS command with a 403 response code ([RFC3977], Section 3.2.1). Otherwise, in case no other generic response code representing the situation applies, the server issues a 206 response code and the compression layer takes effect for both client and server immediately following the CRLF of the success reply.
如果请求的压缩算法语法不正确，服务器必须使用501响应代码（[RFC3977]，第3.2.1节）拒绝压缩命令。如果请求的压缩算法无效（例如，不受支持），服务器必须使用503响应代码（[RFC3977]，第3.2.1节）拒绝压缩命令。如果服务器因任何原因（例如，服务器配置或资源问题）无法激活压缩，则服务器必须使用403响应代码（[RFC3977]，第3.2.1节）拒绝压缩命令。否则，如果没有代表这种情况的其他通用响应代码，服务器将发出206响应代码，并且压缩层在成功回复的CRLF之后立即对客户端和服务器生效。
Additionally, the client MUST NOT issue a MODE READER command after activating a compression layer, and a server MUST NOT advertise the MODE-READER capability.
此外，客户机在激活压缩层后不得发出模式读取器命令，服务器不得公布模式读取器功能。
Both the client and the server MUST know if there is a compression layer active (for instance, via the previous use of the COMPRESS command or the negotiation of a TLS-level compression method [RFC3749]). A client MUST NOT attempt to activate compression (for instance, via the COMPRESS command) or negotiate a TLS security layer (because STARTTLS [RFC4642] may activate TLS-level compression) if a compression layer is already active. A server MUST NOT return the COMPRESS or STARTTLS capability labels in response to a CAPABILITIES command received after a compression layer is active, and a server MUST reply with a 502 response code if a syntactically valid COMPRESS or STARTTLS command is received while a compression layer is already active.
客户端和服务器都必须知道压缩层是否处于活动状态（例如，通过先前使用COMPRESS命令或协商TLS级压缩方法[RFC3749]）。如果压缩层已处于活动状态，则客户端不得尝试激活压缩（例如，通过COMPRESS命令）或协商TLS安全层（因为STARTTLS[RFC4642]可能会激活TLS级压缩）。在压缩层处于活动状态后，服务器不得返回COMPRESS或STARTTLS功能标签以响应接收到的CAPABILITIES命令，如果在压缩层处于活动状态时接收到语法有效的COMPRESS或STARTTLS命令，则服务器必须使用502响应码进行回复。
In order to help mitigate leaking authentication credentials via, for instance, a CRIME attack [CRIME], authentication MUST NOT be attempted after a successful use of the COMPRESS command. Consequently, a server MUST either list the AUTHINFO capability with no arguments or not advertise it at all, in response to a CAPABILITIES command received from an unauthenticated client after a successful use of the COMPRESS command, and such a client MUST NOT attempt to utilize any AUTHINFO [RFC4643] commands. This implies that a server MUST reply with a 502 response code if a syntactically
为了帮助减少身份验证凭据的泄漏，例如，通过犯罪攻击[CRIME]，在成功使用COMPRESS命令后不得尝试身份验证。因此，在成功使用COMPRESS命令后，服务器必须响应从未经身份验证的客户端接收到的CAPABILITIES命令，列出不带参数的AUTHINFO功能，或者根本不公布该功能，并且此类客户端不得尝试使用任何AUTHINFO[RFC4643]命令。这意味着如果在语法上
valid AUTHINFO command is received after a successful use of the COMPRESS command. (Note that this specification does not change the behavior of AUTHINFO as described in [RFC4643] independently of TLS-level compression. Authentication is therefore still allowed, even though TLS-level compression is active.)
成功使用COMPRESS命令后，将收到有效的AUTHINFO命令。（请注意，本规范不会独立于TLS级压缩而改变[RFC4643]中所述的AUTHINFO行为。因此，即使TLS级压缩处于活动状态，仍允许进行身份验证。）
For DEFLATE [RFC1951] (as for many other compression algorithms), the sending compressor can trade speed against compression ratio. The receiving decompressor MUST automatically adjust to the parameters selected by the sender. Consequently, the client and server are both free to pick the best reasonable rate of compression for the data they send. Besides, all data that was submitted for compression MUST be included in the compressed output, and appropriately flushed so as to ensure that the receiving decompressor can completely decompress it.
对于DEFLATE[RFC1951]（与许多其他压缩算法一样），发送压缩机可以根据压缩比来权衡速度。接收解压缩程序必须自动调整到发送方选择的参数。因此，客户机和服务器都可以为它们发送的数据选择最佳的合理压缩率。此外，提交压缩的所有数据必须包含在压缩输出中，并进行适当的刷新，以确保接收解压器能够完全解压。
When COMPRESS is combined with TLS [RFC5246] or SASL [RFC4422] security layers, the processing order of the three layers MUST be first COMPRESS, then SASL, and finally TLS. That is, before data is transmitted, it is first compressed. Second, if a SASL security layer has been negotiated, the compressed data is then signed and/or encrypted accordingly. Third, if a TLS security layer has been negotiated, the data from the previous step is signed and/or encrypted accordingly (with a possible additional TLS-level compression). When receiving data, the processing order MUST be reversed. This ensures that before sending, data is compressed before it is encrypted.
当COMPRESS与TLS[RFC5246]或SASL[RFC4422]安全层组合时，这三层的处理顺序必须是先压缩，然后是SASL，最后是TLS。也就是说，在传输数据之前，首先对其进行压缩。其次，如果已协商SASL安全层，则压缩数据将被相应地签名和/或加密。第三，如果已协商TLS安全层，则上一步骤中的数据将被相应地签名和/或加密（具有可能的附加TLS级别压缩）。接收数据时，必须颠倒处理顺序。这样可以确保在发送数据之前，数据在加密之前被压缩。
When compression is active and either the client or the server receives invalid or corrupted compressed data, the receiving end immediately closes the connection, in response to which the sending end will do the same.
当压缩处于活动状态且客户端或服务器接收到无效或损坏的压缩数据时，接收端会立即关闭连接，发送端也会相应关闭连接。
Example of layering a TLS security layer and NNTP compression:
TLS安全层分层和NNTP压缩示例：
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] READER
[S] STARTTLS
[S] AUTHINFO
[S] COMPRESS DEFLATE
[S] LIST ACTIVE NEWSGROUPS
[S] .
[C] STARTTLS
[S] 382 Continue with TLS negotiation
[TLS negotiation without compression occurs here]
[Following successful negotiation, all traffic is encrypted]
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] READER
[S] AUTHINFO USER
[S] COMPRESS DEFLATE
[S] LIST ACTIVE NEWSGROUPS
[S] .
[C] AUTHINFO USER fred
[S] 381 Enter passphrase
[C] AUTHINFO PASS flintstone
[S] 281 Authentication accepted
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] READER
[S] POST
[S] COMPRESS DEFLATE
[S] LIST ACTIVE NEWSGROUPS
[S] .
[C] COMPRESS DEFLATE
[S] 206 Compression active
[Henceforth, all traffic is compressed before being encrypted]
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] READER
[S] POST
[S] LIST ACTIVE NEWSGROUPS
[S] .
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] READER
[S] STARTTLS
[S] AUTHINFO
[S] COMPRESS DEFLATE
[S] LIST ACTIVE NEWSGROUPS
[S] .
[C] STARTTLS
[S] 382 Continue with TLS negotiation
[TLS negotiation without compression occurs here]
[Following successful negotiation, all traffic is encrypted]
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] READER
[S] AUTHINFO USER
[S] COMPRESS DEFLATE
[S] LIST ACTIVE NEWSGROUPS
[S] .
[C] AUTHINFO USER fred
[S] 381 Enter passphrase
[C] AUTHINFO PASS flintstone
[S] 281 Authentication accepted
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] READER
[S] POST
[S] COMPRESS DEFLATE
[S] LIST ACTIVE NEWSGROUPS
[S] .
[C] COMPRESS DEFLATE
[S] 206 Compression active
[Henceforth, all traffic is compressed before being encrypted]
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] READER
[S] POST
[S] LIST ACTIVE NEWSGROUPS
[S] .
Example of a server failing to activate compression:
服务器无法激活压缩的示例：
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] IHAVE
[S] COMPRESS DEFLATE
[S] .
[C] COMPRESS DEFLATE
[S] 403 Unable to activate compression
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] IHAVE
[S] COMPRESS DEFLATE
[S] .
[C] COMPRESS DEFLATE
[S] 403 Unable to activate compression
Example of attempting to use an unsupported compression algorithm:
尝试使用不受支持的压缩算法的示例：
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] IHAVE
[S] COMPRESS DEFLATE
[S] .
[C] COMPRESS SHRINK
[S] 503 Compression algorithm not supported
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] IHAVE
[S] COMPRESS DEFLATE
[S] .
[C] COMPRESS SHRINK
[S] 503 Compression algorithm not supported
Example of a server refusing to compress twice:
服务器拒绝压缩两次的示例：
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] IHAVE
[S] STARTTLS
[S] COMPRESS DEFLATE
[S] .
[C] STARTTLS
[S] 382 Continue with TLS negotiation
[TLS negotiation with compression occurs here]
[Following successful negotiation, all traffic is encrypted]
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] IHAVE
[S] .
[C] COMPRESS DEFLATE
[S] 502 Compression already active via TLS
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] IHAVE
[S] STARTTLS
[S] COMPRESS DEFLATE
[S] .
[C] STARTTLS
[S] 382 Continue with TLS negotiation
[TLS negotiation with compression occurs here]
[Following successful negotiation, all traffic is encrypted]
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] IHAVE
[S] .
[C] COMPRESS DEFLATE
[S] 502 Compression already active via TLS
Example of a server refusing to negotiate a TLS security layer after compression has been activated:
激活压缩后，服务器拒绝协商TLS安全层的示例：
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] IHAVE
[S] STARTTLS
[S] COMPRESS DEFLATE
[S] .
[C] COMPRESS DEFLATE
[S] 206 Compression active
[Henceforth, all traffic is compressed]
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] IHAVE
[S] .
[C] STARTTLS
[S] 502 DEFLATE compression already active
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] IHAVE
[S] STARTTLS
[S] COMPRESS DEFLATE
[S] .
[C] COMPRESS DEFLATE
[S] 206 Compression active
[Henceforth, all traffic is compressed]
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] IHAVE
[S] .
[C] STARTTLS
[S] 502 DEFLATE compression already active
Example of a server not advertising AUTHINFO arguments after compression has been activated:
激活压缩后未公布AUTHINFO参数的服务器示例：
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] READER
[S] AUTHINFO USER
[S] COMPRESS DEFLATE
[S] LIST ACTIVE NEWSGROUPS
[S] .
[C] COMPRESS DEFLATE
[S] 206 Compression active
[Henceforth, all traffic is compressed]
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] READER
[S] AUTHINFO
[S] LIST ACTIVE NEWSGROUPS
[S] .
[C] AUTHINFO USER fred
[S] 502 DEFLATE compression already active
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] READER
[S] AUTHINFO USER
[S] COMPRESS DEFLATE
[S] LIST ACTIVE NEWSGROUPS
[S] .
[C] COMPRESS DEFLATE
[S] 206 Compression active
[Henceforth, all traffic is compressed]
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] READER
[S] AUTHINFO
[S] LIST ACTIVE NEWSGROUPS
[S] .
[C] AUTHINFO USER fred
[S] 502 DEFLATE compression already active
This section is informative, not normative.
本节内容丰富，不规范。
NNTP poses some unusual problems for a compression layer.
NNTP为压缩层带来了一些不寻常的问题。
Upstream traffic is fairly simple. Most NNTP clients send the same few commands again and again, so any compression algorithm that can exploit repetition works efficiently. The article posting and transfer commands (e.g., POST, IHAVE, and TAKETHIS [RFC4644]) are exceptions; clients that send many article posting or transfer commands may want to surround large multi-line data blocks with a dictionary flush and/or, depending on the compression algorithm, a change of compression level in the same way as is recommended for servers later in this document (Section 4).
上游交通相当简单。大多数NNTP客户端一次又一次地发送相同的几个命令，因此任何可以利用重复的压缩算法都能有效地工作。物品过帐和转移命令（例如POST、IHAVE和TAKETHIS[RFC4644]）是例外；发送许多文章投递或传输命令的客户端可能希望使用字典刷新和/或（取决于压缩算法）更改大型多行数据块，更改压缩级别的方式与本文档后面（第4节）建议的服务器相同。
Downstream traffic has the unusual property that several kinds of data are sent, possibly confusing a dictionary-based compression algorithm.
下游流量有一个不寻常的特性，即发送多种数据，这可能会混淆基于字典的压缩算法。
NNTP responses that are not related to article header/body retrieval are one type. Compressing NNTP simple responses (e.g., in answer to CHECK [RFC4644], DATE, GROUP, LAST, NEXT, STAT, etc.) generally does not save many bytes, unless repeated several times in the same NNTP session. On the contrary, most of the NNTP multi-line responses (e.g., in answer to LIST, LISTGROUP, NEWGROUPS, NEWNEWS, etc.) are highly compressible; using its least CPU-intensive setting, zlib compresses typical responses to 25-40% of their original size.
与文章标题/正文检索无关的NNTP响应是一种类型。压缩NNTP简单响应（例如，在应答检查[RFC4644]、日期、组、最后一个、下一个、状态等）通常不会保存很多字节，除非在同一NNTP会话中重复多次。相反，大多数NNTP多行响应（例如，回复列表、列表组、新组、新新闻等）是高度可压缩的；zlib使用最少的CPU密集设置，将典型响应压缩到原始大小的25-40%。
Article headers (as retrieved, for instance, via the HEAD, HDR, OVER, or ARTICLE commands) are another type. These are equally compressible, and benefit from using the same dictionary as the NNTP responses.
文章标题（例如，通过HEAD、HDR、OVER或Article命令检索）是另一种类型。它们同样可压缩，并受益于使用与NNTP响应相同的字典。
A third type is article body text (as retrieved, for instance, via the BODY or ARTICLE commands). Text is usually fairly short and includes much ASCII, so the same compression dictionary will do a good job here, too. When multiple messages in the same thread are read at the same time, quoted lines, etc., can often be compressed almost to zero.
第三种类型是文章正文文本（例如，通过body或article命令检索）。文本通常比较短，并且包含很多ASCII码，因此相同的压缩字典在这里也可以做得很好。当同一线程中的多条消息同时被读取时，带引号的行等通常会被压缩到几乎为零。
Finally, non-text article bodies or attachments (as retrieved, for instance, via the BODY or ARTICLE commands) are transmitted in encoded form, usually Base64 [RFC4648], UUencode [IEEE.1003.1-2008], or yEnc [yEnc].
最后，非文本文章正文或附件（例如，通过正文或文章命令检索）以编码形式传输，通常为Base64[RFC4648]、UUencode[IEEE.1003.1-2008]或yEnc[yEnc]。
When such non-text article bodies or attachments are retrieved, a compression algorithm may be able to compress them, but the format of their encoding is usually not NNTP-like, so the dictionary built while compressing NNTP does not help much. The compressor has to adapt its dictionary from NNTP to the attachment's encoding format, and then back.
检索此类非文本文章正文或附件时，压缩算法可能能够对其进行压缩，但其编码格式通常与NNTP不同，因此在压缩NNTP时生成的词典没有多大帮助。压缩器必须将其字典从NNTP调整为附件的编码格式，然后再重新调整。
When attachments are retrieved in Base64 or UUencode form, the Huffman coding usually compresses those to approximately only 75% of their encoding size. 8-bit compression algorithms such as DEFLATE work well on 8-bit file formats; however, both Base64 and UUencode transform a file into something resembling 6-bit bytes, hiding most of the 8-bit file format from the compressor.
当以Base64或UUencode形式检索附件时，哈夫曼编码通常将附件压缩到其编码大小的75%左右。8位压缩算法（如DEFLATE）在8位文件格式上运行良好；但是，Base64和UUencode都将文件转换为类似于6位字节的内容，从而对压缩器隐藏了大部分8位文件格式。
On the other end, attachments encoded using a compression algorithm that retains the full 8-bit spectrum, like yEnc, are much more likely to be incompressible.
另一方面，使用保留完整8位频谱的压缩算法编码的附件（如yEnc）更可能是不可压缩的。
When using the zlib library (see [RFC1951]), the functions deflateInit2(), deflate(), inflateInit2(), and inflate() suffice to implement this extension.
使用zlib库（请参见[RFC1951]）时，函数deflateInit2（）、deflate（）、inflateInit2（）和inflate（）足以实现此扩展。
The windowBits value MUST be in the range -8 to -15 for deflateInit2(), or else it will use the wrong format. The windowBits value SHOULD be -15 for inflateInit2(), or else it will not be able to decompress a stream with a larger window size, thus reducing interoperability. deflateParams() can be used to improve compression rate and resource use. Regarding flush operations, the Z_FULL_FLUSH argument to deflate() permits to clear the dictionary, which generally results in compression that is less effective than performing a Z_PARTIAL_FLUSH. As a matter of fact, keeping the 32 KB dictionary from previous data, no matter how unrelated, can be of help (if there are no matching strings in there, then it is simply not referenced).
对于deflateInit2（），windowBits值必须在-8到-15范围内，否则将使用错误的格式。对于inflateInit2（），windowBits值应为-15，否则它将无法解压缩具有较大窗口大小的流，从而降低互操作性。deflateParams（）可用于提高压缩率和资源利用率。关于刷新操作，deflate（）的Z_FULL_flush参数允许清除字典，这通常会导致压缩效果不如执行Z_PARTIAL_flush。事实上，将32KB的字典与以前的数据保持一致，不管它们之间有多么不相关，都会有帮助（如果没有匹配的字符串，那么它就不会被引用）。
A server can improve downstream compression and the CPU efficiency of both the server and the client if it adjusts the compression level (e.g., using the deflateParams() function in zlib) at the start and end of large non-text multi-line data blocks (before and after 'content-lines' in the definition of 'multi-line-data-block' in [RFC3977], Section 9.8). This mechanism prevents the server from trying to compress incompressible attachments.
如果服务器在大型非文本多行数据块（在[RFC3977]中的“多行数据块”定义中的“内容行”之前和之后）的开始和结束处调整压缩级别（例如，使用zlib中的deflateParams（）函数），则服务器和客户端都可以提高下游压缩和CPU效率，第9.8节）。此机制可防止服务器尝试压缩不可压缩的附件。
A very simple strategy is to change the compression level to 0 at the start of an incompressible multi-line data block, for instance when encoded using yEnc [yEnc], and to keep it at 1-5 the rest of the time. More complex strategies are, of course, possible and encouraged.
一个非常简单的策略是在不可压缩的多行数据块开始时将压缩级别更改为0，例如使用yEnc[yEnc]编码时，并在其余时间将其保持在1-5。当然，更复杂的战略是可能的，也是鼓励的。
This section describes the formal syntax of the COMPRESS extension using ABNF [RFC7405] and [RFC5234]. It extends the syntax in Section 9 of [RFC3977], and non-terminals not defined in this document are defined there. The NNTP ABNF [RFC3977] should be imported first, before attempting to validate these rules.
本节使用ABNF[RFC7405]和[RFC5234]描述压缩扩展的形式语法。它扩展了[RFC3977]第9节中的语法，本文件中未定义的非终端在此定义。在尝试验证这些规则之前，应首先导入NNTP ABNF[RFC3977]。
This syntax extends the non-terminal <command>, which represents an NNTP command.
此语法扩展了表示NNTP命令的非终端<command>。
command =/ compress-command
command=/compress命令
compress-command = "COMPRESS" WS algorithm
compress命令=“compress”WS算法
This syntax extends the non-terminal <capability-entry>, which represents a capability that may be advertised by the server.
此语法扩展了非终端的<capability entry>，它表示服务器可能公布的功能。
capability-entry =/ compress-capability
能力条目=/压缩能力
compress-capability = "COMPRESS" 1*(WS algorithm)
压缩能力=“压缩”1*（WS算法）
algorithm = %s"DEFLATE" / 1*20alg-char ; case-sensitive
alg-char = UPPER / DIGIT / "-" / "_"
algorithm = %s"DEFLATE" / 1*20alg-char ; case-sensitive
alg-char = UPPER / DIGIT / "-" / "_"
This section defines the following new response code. It is not multi-line and has no arguments.
本节定义了以下新的响应代码。它不是多行的，没有参数。
Response code 206 Generated by: COMPRESS Meaning: compression layer activated
响应代码206生成者：压缩含义：压缩层激活
Security issues are discussed throughout this document.
本文档中讨论了安全问题。
In general, the security considerations of the NNTP core specification ([RFC3977], Section 12) and the DEFLATE compressed data format specification ([RFC1951], Section 6) are applicable here.
一般来说，NNTP核心规范（[RFC3977]，第12节）和DEFLATE压缩数据格式规范（[RFC1951]，第6节）的安全注意事项适用于此处。
Implementers should be aware that combining compression with encryption like TLS can sometimes reveal information that would not have been revealed without compression, as explained in Section 6 of [RFC3749]. As a matter of fact, adversaries that observe the length of the compressed data might be able to derive information about the corresponding uncompressed data. The CRIME and the BREACH attacks ([RFC7457], Section 2.6) are examples of such case.
实施者应该意识到，将压缩与TLS等加密相结合有时会泄露未经压缩不会泄露的信息，如[RFC3749]第6节所述。事实上，观察压缩数据长度的对手可能能够获得有关相应未压缩数据的信息。犯罪和违规攻击（[RFC7457]，第2.6节）就是此类案件的例子。
In order to help mitigate leaking authentication credentials, this document states in Section 2.2.2 that authentication MUST NOT be attempted after a successful use of COMPRESS. Therefore, when a client wants to authenticate, compress data, and negotiate a TLS security layer (without TLS-level compression) in the same NNTP connection, it MUST use the STARTTLS, AUTHINFO, and COMPRESS commands in that order. Of course, instead of using the STARTTLS command, a client can also use implicit TLS, that is to say it begins the TLS negotiation immediately upon connection on a separate port dedicated to NNTP over TLS.
为了帮助减少身份验证凭据泄漏，本文档在第2.2.2节中规定，在成功使用COMPRESS后，不得尝试身份验证。因此，当客户机希望在同一NNTP连接中验证、压缩数据和协商TLS安全层（无TLS级别压缩）时，它必须按顺序使用STARTTLS、AUTHINFO和compress命令。当然，客户机也可以使用隐式TLS，而不是使用STARTTLS命令，也就是说，它在通过TLS连接NNTP专用的单独端口时立即开始TLS协商。
NNTP commands other than AUTHINFO are not believed to divulge confidential information as long as only public Netnews newsgroups and articles are accessed. That is why this specification only prohibits the use of AUTHINFO after COMPRESS. In case confidential articles are accessed in private newsgroups, special care is needed: implementations SHOULD NOT compress confidential data together with public data when a TLS [RFC5246] or SASL [RFC4422] security layer is active. As a matter of fact, adversaries that observe the length of the compressed data might be able to derive information about it, when public data (that adversaries know is read) and confidential data are compressed in the same compression session.
只要只访问公共网络新闻新闻组和文章，就不认为AUTHINFO以外的NNTP命令会泄露机密信息。这就是为什么本规范仅禁止在压缩后使用AUTHINFO。如果在私人新闻组中访问机密文章，则需要特别注意：当TLS[RFC5246]或SASL[RFC4422]安全层处于活动状态时，实现不应将机密数据与公共数据一起压缩。事实上，当在同一压缩会话中压缩公共数据（对手知道的数据）和机密数据时，观察压缩数据长度的对手可能能够获得有关压缩数据的信息。
Additionally, it is preferable not to compress the contents of two distinct confidential articles together if it can be avoided, as adversaries might be able to derive information about them (for instance, if they have a few header fields or body lines in common). This can be achieved, for instance, with DEFLATE by clearing the compression dictionary each time a confidential article is sent. More complex implementations are, of course, possible and encouraged.
此外，如果可以避免的话，最好不要将两个不同的机密文章的内容压缩在一起，因为对手可能能够获得关于它们的信息（例如，如果它们有几个共同的标题字段或正文行）。例如，可以通过每次发送机密文章时清除压缩字典来使用DEFLATE实现这一点。当然，更复杂的实现是可能的，并且受到鼓励。
Implementations are encouraged to unconditionally allow compression when no security layer is active, and to support an option to enable or disable compression when a security layer is active. Such an option could, for instance, have global scope or be server/ connection-based. Besides, as compression may in general weaken the confidentiality of a security layer, implementations SHOULD NOT automatically enable compression when a security layer is active unless the user explicitly enabled it with this knowledge.
鼓励实现在没有安全层处于活动状态时无条件地允许压缩，并支持在安全层处于活动状态时启用或禁用压缩的选项。例如，这样的选项可以是全局范围的，也可以是基于服务器/连接的。此外，由于压缩通常会削弱安全层的机密性，因此在安全层处于活动状态时，实现不应自动启用压缩，除非用户使用此知识显式启用它。
Future extensions to NNTP that define commands conveying confidential data SHOULD be sure to state that these confidential data SHOULD NOT be compressed together with public data when a security layer is active.
NNTP的未来扩展（定义传递机密数据的命令）应确保声明，当安全层处于活动状态时，这些机密数据不应与公共数据一起压缩。
Last but not least, careful consideration should be given to protections against implementation errors that introduce security risks with regards to compression algorithms. See, for instance, the part of Section 6 of [RFC3749] about compression algorithms that can occasionally expand, rather than compress, input data.
最后但并非最不重要的一点是，应仔细考虑防止实现错误的保护措施，这些错误会给压缩算法带来安全风险。例如，请参阅[RFC3749]第6节中关于压缩算法的部分，该算法有时会扩展而不是压缩输入数据。
The "NNTP Compression Algorithms" registry is maintained by IANA. The registry is available at <http://www.iana.org/assignments/nntp-parameters>.
“NNTP压缩算法”注册表由IANA维护。注册处可于<http://www.iana.org/assignments/nntp-parameters>.
The purpose of this registry is not only to ensure uniqueness of values used to name NNTP compression algorithms, but also to provide a definitive reference to technical specifications detailing each NNTP compression algorithm available for use on the Internet.
此注册表的目的不仅是确保用于命名NNTP压缩算法的值的唯一性，还提供详细说明可在Internet上使用的每个NNTP压缩算法的技术规范的明确参考。
An NNTP compression algorithm is either a private algorithm, or its name is included in the IANA "NNTP Compression Algorithms" registry (in which case it is a "registered NNTP compression algorithm"). Different entries in the registry MUST use different names.
NNTP压缩算法是私有算法，或者其名称包含在IANA“NNTP压缩算法”注册表中（在这种情况下，它是“注册的NNTP压缩算法”）。注册表中的不同条目必须使用不同的名称。
Private algorithms with unregistered names are allowed, but SHOULD NOT be used because it is difficult to achieve interoperability with them.
允许使用未注册名称的私有算法，但不应使用，因为很难实现与它们的互操作性。
The 206, 403, and 502 response codes that a news server answers to the COMPRESS command using a private compression algorithm MUST have the same meaning as the one documented in Section 2.2 of this document.
新闻服务器使用专用压缩算法响应压缩命令的206、403和502响应代码必须与本文档第2.2节中记录的代码具有相同的含义。
The procedure detailed in Section 8.1.1 is to be used for registration of a value naming a specific individual compression algorithm.
第8.1.1节中详述的程序将用于注册命名特定单独压缩算法的值。
Any name that conforms to the syntax of an NNTP compression algorithm name (Section 5.3) can be used. Especially, NNTP compression algorithms are named by strings, from 1 to 20 characters in length, consisting of uppercase letters, digits, hyphens, and/or underscores.
可以使用符合NNTP压缩算法名称语法（第5.3节）的任何名称。特别是，NNTP压缩算法由字符串命名，长度从1到20个字符，由大写字母、数字、连字符和/或下划线组成。
Comments may be included in the registry as discussed in Section 8.1.2 and may be changed as discussed in Section 8.1.3.
注释可包括在第8.1.2节讨论的注册表中，并可根据第8.1.3节讨论的内容进行更改。
IANA will register new NNTP compression algorithm names on a First Come First Served basis, as defined in BCP 26 [RFC5226]. IANA has the right to reject obviously bogus registration requests, but will not perform a review of claims made in the registration form.
IANA将按照BCP 26[RFC5226]中的定义，以先到先得的方式注册新的NNTP压缩算法名称。IANA有权拒绝明显虚假的注册请求，但不会对注册表格中的申请进行审查。
Registration of an NNTP compression algorithm is requested by filling in the following template and sending it via electronic mail to IANA at <iana@iana.org>:
通过填写以下模板并通过电子邮件发送给IANA，请求注册NNTP压缩算法<iana@iana.org>:
Subject: Registration of NNTP compression algorithm Z
主题：NNTP压缩算法Z的注册
NNTP compression algorithm name:
NNTP压缩算法名称：
Security considerations:
安全考虑：
Published specification (recommended):
已发布规范（推荐）：
Contact for further information:
有关更多信息，请联系：
Intended usage: (One of COMMON, LIMITED USE, or OBSOLETE)
预期用途：（通用、有限用途或过时）
Owner/Change controller:
业主/变更控制人：
Note: (Any other information that the author deems relevant may be added here.)
注：（作者认为相关的任何其他信息可在此添加。）
While this registration procedure does not require expert review, authors of NNTP compression algorithms are encouraged to seek community review and comment whenever that is feasible. Authors may seek community review by posting a specification of their proposed algorithm as an Internet-Draft. NNTP compression algorithms intended for widespread use should be standardized through the normal IETF process, when appropriate.
虽然该注册程序不需要专家审查，但鼓励NNTP压缩算法的作者在可行的情况下寻求社区审查和评论。作者可以通过将他们提出的算法的规范发布为互联网草稿来寻求社区审查。适用时，应通过正常的IETF过程对广泛使用的NNTP压缩算法进行标准化。
Comments on a registered NNTP compression algorithm should first be sent to the "owner" of the algorithm and/or to the mailing list for the now concluded NNTPEXT working group (<ietf-nntp@lists.eyrie.org>) of the IETF.
关于已注册的NNTP压缩算法的评论应首先发送给算法的“所有者”和/或现在结束的NNTPEXT工作组的邮件列表（<ietf-nntp@lists.eyrie.org>)IETF的。
Submitters of comments may, after a reasonable attempt to contact the owner and/or the above mailing list, request IANA to attach their comment to the NNTP compression algorithm registration itself by sending mail to <iana@iana.org>. At IANA's sole discretion, IANA may attach the comment to the NNTP compression algorithm's registration.
在合理尝试联系所有者和/或上述邮件列表后，意见提交人可要求IANA通过向发送邮件将其意见附加到NNTP压缩算法注册本身<iana@iana.org>. IANA可自行决定将注释附加到NNTP压缩算法的注册中。
Once an NNTP compression algorithm registration has been published by IANA, the owner may request a change to its definition. The change request follows the same procedure as the initial registration request.
IANA发布NNTP压缩算法注册后，所有者可要求更改其定义。变更请求遵循与初始注册请求相同的程序。
The owner of an NNTP compression algorithm may pass responsibility for the algorithm to another person or agency by informing IANA; this can be done without discussion or review.
NNTP压缩算法的所有者可以通过通知IANA将算法的责任转交给另一个人或机构；这可以在不进行讨论或审查的情况下完成。
The IESG may reassign responsibility for an NNTP compression algorithm. The most common case of this will be to enable changes to be made to algorithms where the owner of the registration has died, has moved out of contact, or is otherwise unable to make changes that are important to the community.
IESG可以重新分配NNTP压缩算法的责任。最常见的情况是，当注册所有者去世、失去联系或无法进行对社区重要的更改时，允许对算法进行更改。
NNTP compression algorithm registrations MUST NOT be deleted; algorithms that are no longer believed appropriate for use can be declared OBSOLETE by a change to their "intended usage" field; such algorithms will be clearly marked in the registry published by IANA.
不得删除NNTP压缩算法注册；不再被认为适合使用的算法可以通过更改其“预期用途”字段宣布为过时；这些算法将在IANA发布的注册表中明确标记。
The IESG is considered to be the owner of all NNTP compression algorithms that are on the IETF Standards Track.
IESG被认为是IETF标准轨道上所有NNTP压缩算法的所有者。
This section gives a formal definition of the DEFLATE compression algorithm as required by Section 8.1.1 for the IANA registry.
本节给出了IANA注册第8.1.1节要求的DEFLATE压缩算法的正式定义。
NNTP compression algorithm name: DEFLATE
NNTP压缩算法名称：DEFLATE
Security considerations: See Section 7 of this document
安全注意事项：见本文件第7节
Published specification: This document
已发布规范：本文件
Contact for further information: Authors of this document
更多信息请联系：本文件作者
Intended usage: COMMON
预期用途：普通
Owner/Change controller: IESG <iesg@ietf.org>
Owner/Change controller: IESG <iesg@ietf.org>
Note: This algorithm is mandatory to implement
注意：此算法是强制实现的
This registration appears as follows in the "NNTP Compression Algorithms" registry:
此注册在“NNTP压缩算法”注册表中显示如下：
+------------+------------+--------------+--------------+-----------+
| Algorithm | Intended | Comment | Change | Reference |
| Name | Usage | | Controller | |
+------------+------------+--------------+--------------+-----------+
| DEFLATE | COMMON | Mandatory to | IESG | RFC 8054 |
| | | implement | | |
+------------+------------+--------------+--------------+-----------+
+------------+------------+--------------+--------------+-----------+
| Algorithm | Intended | Comment | Change | Reference |
| Name | Usage | | Controller | |
+------------+------------+--------------+--------------+-----------+
| DEFLATE | COMMON | Mandatory to | IESG | RFC 8054 |
| | | implement | | |
+------------+------------+--------------+--------------+-----------+
This section gives a formal definition of the COMPRESS extension as required by Section 3.3.3 of [RFC3977] for the IANA registry.
本节给出了[RFC3977]第3.3.3节要求的IANA注册表压缩扩展的正式定义。
o The COMPRESS extension allows an NNTP connection to be effectively and efficiently compressed.
o 压缩扩展允许有效地压缩NNTP连接。
o The capability label for this extension is "COMPRESS", whose arguments list the available compression algorithms.
o 此扩展的功能标签为“COMPRESS”，其参数列出了可用的压缩算法。
o This extension defines one new command, COMPRESS, whose behavior, arguments, and responses are defined in Section 2.2.
o 此扩展定义了一个新命令COMPRESS，其行为、参数和响应在第2.2节中定义。
o This extension does not associate any new responses with pre-existing NNTP commands.
o 此扩展不会将任何新响应与预先存在的NNTP命令相关联。
o This extension does affect the overall behavior of both server and client, in that after successful use of the COMPRESS command, all communication is transmitted in a compressed format.
o 此扩展确实会影响服务器和客户端的整体行为，因为成功使用COMPRESS命令后，所有通信都以压缩格式传输。
o This extension does not affect the maximum length of commands or initial response lines.
o 此扩展不影响命令或初始响应行的最大长度。
o This extension does not alter pipelining, but the COMPRESS command cannot be pipelined.
o 此扩展不会改变管道化，但不能对COMPRESS命令进行管道化。
o Use of this extension does alter the capabilities list; once the COMPRESS command has been used successfully, the COMPRESS capability can no longer be advertised by CAPABILITIES. Additionally, the STARTTLS and MODE-READER capabilities MUST NOT be advertised, and the AUTHINFO capability label MUST either be listed with no arguments or not advertised at all after a successful execution of the COMPRESS command.
o 使用此扩展不会改变功能列表；一旦COMPRESS命令被成功使用，COMPRESS功能就不能再由COMPRESS功能播发。此外，STARTTLS和MODE-READER功能不得公布，并且AUTHINFO功能标签必须不带参数列出，或者在成功执行COMPRESS命令后根本不公布。
o This extension does not cause any pre-existing command to produce a 401, 480, or 483 response code.
o 此扩展不会导致任何预先存在的命令生成401、480或483响应代码。
o This extension is unaffected by any use of the MODE READER command; however, the MODE READER command MUST NOT be used in the same session following a successful execution of the COMPRESS command.
o 此扩展不受任何使用模式读取器命令的影响；但是，在成功执行COMPRESS命令后，不能在同一会话中使用MODE READER命令。
o The STARTTLS and AUTHINFO commands MUST NOT be used in the same session following a successful execution of the COMPRESS command.
o 成功执行COMPRESS命令后，不能在同一会话中使用STARTTLS和AUTHINFO命令。
o Published Specification: This document.
o 已发布规范：本文件。
o Contact for Further Information: Authors of this document.
o 更多信息请联系：本文件作者。
o Change Controller: IESG <iesg@ietf.org>
o 更改控制器：IESG<iesg@ietf.org>
This registration will appear as follows in the "NNTP Capability Labels" registry contained in the "Network News Transfer Protocol (NNTP) Parameters" registry:
此注册将显示在“网络新闻传输协议（NNTP）参数”注册表中包含的“NNTP能力标签”注册表中，如下所示：
+----------+----------------------------------+-----------+
| Label | Meaning | Reference |
+----------+----------------------------------+-----------+
| COMPRESS | Supported compression algorithms | RFC 8054 |
+----------+----------------------------------+-----------+
+----------+----------------------------------+-----------+
| Label | Meaning | Reference |
+----------+----------------------------------+-----------+
| COMPRESS | Supported compression algorithms | RFC 8054 |
+----------+----------------------------------+-----------+
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, DOI 10.17487/RFC1951, May 1996, <http://www.rfc-editor.org/info/rfc1951>.
[RFC1951]Deutsch，P.，“DEFLATE压缩数据格式规范1.3版”，RFC 1951，DOI 10.17487/RFC1951，1996年5月<http://www.rfc-editor.org/info/rfc1951>.
[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>.
[RFC3977] Feather, C., "Network News Transfer Protocol (NNTP)", RFC 3977, DOI 10.17487/RFC3977, October 2006, <http://www.rfc-editor.org/info/rfc3977>.
[RFC3977]Feather，C.，“网络新闻传输协议（NNTP）”，RFC 3977，DOI 10.17487/RFC3977，2006年10月<http://www.rfc-editor.org/info/rfc3977>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，DOI 10.17487/RFC5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[RFC5234] 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>.
[RFC5234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，DOI 10.17487/RFC5234，2008年1月<http://www.rfc-editor.org/info/rfc5234>.
[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", RFC 7405, DOI 10.17487/RFC7405, December 2014, <http://www.rfc-editor.org/info/rfc7405>.
[RFC7405]Kyzivat，P.，“ABNF中的区分大小写字符串支持”，RFC 7405，DOI 10.17487/RFC7405，2014年12月<http://www.rfc-editor.org/info/rfc7405>.
[CRIME] Rizzo, J. and T. Duong, "The CRIME Attack", Ekoparty Security Conference, 2012.
[犯罪]Rizzo，J.和T.Duong，“犯罪袭击”，Ekoparty安全会议，2012年。
[IEEE.1003.1-2008] IEEE, "Information Technology - Portable Operating System Interface (POSIX(R))", IEEE Standard 1003.1-2008, DOI 10.1109/IEEESTD.2016.7582338, 2008, <https://standards.ieee.org/findstds/ standard/1003.1-2008.html>.
[IEEE.1003.1-2008]IEEE，“信息技术-便携式操作系统接口（POSIX（R））”，IEEE标准1003.1-2008，DOI 10.1109/IEEESTD.2016.7582338，2008<https://standards.ieee.org/findstds/ 标准/1003.1-2008.html>。
[MNP] Held, G., "The Complete Modem Reference", Second Edition, John Wiley & Sons, Inc., May 1994.
[MNP]Hold，G.“完整的调制解调器参考”，第二版，约翰·威利父子公司，1994年5月。
[RFC1962] Rand, D., "The PPP Compression Control Protocol (CCP)", RFC 1962, DOI 10.17487/RFC1962, June 1996, <http://www.rfc-editor.org/info/rfc1962>.
[RFC1962]兰德，D.，“PPP压缩控制协议（CCP）”，RFC 1962，DOI 10.17487/RFC1962，1996年6月<http://www.rfc-editor.org/info/rfc1962>.
[RFC3749] Hollenbeck, S., "Transport Layer Security Protocol Compression Methods", RFC 3749, DOI 10.17487/RFC3749, May 2004, <http://www.rfc-editor.org/info/rfc3749>.
[RFC3749]Hollenbeck，S.，“传输层安全协议压缩方法”，RFC 3749，DOI 10.17487/RFC3749，2004年5月<http://www.rfc-editor.org/info/rfc3749>.
[RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, DOI 10.17487/RFC4422, June 2006, <http://www.rfc-editor.org/info/rfc4422>.
[RFC4422]Melnikov，A.，Ed.和K.Zeilenga，Ed.，“简单身份验证和安全层（SASL）”，RFC 4422，DOI 10.17487/RFC4422，2006年6月<http://www.rfc-editor.org/info/rfc4422>.
[RFC4642] Murchison, K., Vinocur, J., and C. Newman, "Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP)", RFC 4642, DOI 10.17487/RFC4642, October 2006, <http://www.rfc-editor.org/info/rfc4642>.
[RFC4642]Murchison，K.，Vinocur，J.，和C.Newman，“通过网络新闻传输协议（NNTP）使用传输层安全（TLS）”，RFC 4642，DOI 10.17487/RFC4642，2006年10月<http://www.rfc-editor.org/info/rfc4642>.
[RFC4643] Vinocur, J. and K. Murchison, "Network News Transfer Protocol (NNTP) Extension for Authentication", RFC 4643, DOI 10.17487/RFC4643, October 2006, <http://www.rfc-editor.org/info/rfc4643>.
[RFC4643]Vinocur，J.和K.Murchison，“用于认证的网络新闻传输协议（NNTP）扩展”，RFC 4643，DOI 10.17487/RFC4643，2006年10月<http://www.rfc-editor.org/info/rfc4643>.
[RFC4644] Vinocur, J. and K. Murchison, "Network News Transfer Protocol (NNTP) Extension for Streaming Feeds", RFC 4644, DOI 10.17487/RFC4644, October 2006, <http://www.rfc-editor.org/info/rfc4644>.
[RFC4644]Vinocur，J.和K.Murchison，“流式提要的网络新闻传输协议（NNTP）扩展”，RFC 4644，DOI 10.17487/RFC4644，2006年10月<http://www.rfc-editor.org/info/rfc4644>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <http://www.rfc-editor.org/info/rfc4648>.
[RFC4648]Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC 4648，DOI 10.17487/RFC4648，2006年10月<http://www.rfc-editor.org/info/rfc4648>.
[RFC4978] Gulbrandsen, A., "The IMAP COMPRESS Extension", RFC 4978, DOI 10.17487/RFC4978, August 2007, <http://www.rfc-editor.org/info/rfc4978>.
[RFC4978]Gulbrandsen，A.，“IMAP压缩扩展”，RFC 4978，DOI 10.17487/RFC4978，2007年8月<http://www.rfc-editor.org/info/rfc4978>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，DOI 10.17487/RFC5246，2008年8月<http://www.rfc-editor.org/info/rfc5246>.
[RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, February 2015, <http://www.rfc-editor.org/info/rfc7457>.
[RFC7457]Sheffer，Y.，Holz，R.，和P.Saint Andre，“总结对传输层安全（TLS）和数据报TLS（DTLS）的已知攻击”，RFC 7457，DOI 10.17487/RFC7457，2015年2月<http://www.rfc-editor.org/info/rfc7457>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <http://www.rfc-editor.org/info/rfc7525>.
[RFC7525]Sheffer，Y.，Holz，R.，和P.Saint Andre，“安全使用传输层安全性（TLS）和数据报传输层安全性（DTLS）的建议”，BCP 195，RFC 7525，DOI 10.17487/RFC7525，2015年5月<http://www.rfc-editor.org/info/rfc7525>.
[V42bis] International Telecommunications Union, "Data compression procedures for data circuit-terminating equipment (DCE) using error correction procedures", ITU-T Recommendation V.42bis, January 1990, <http://www.itu.int/rec/T-REC-V.42bis>.
[V42bis]国际电信联盟，“使用纠错程序的数据电路终端设备（DCE）的数据压缩程序”，ITU-T建议V.42bis，1990年1月<http://www.itu.int/rec/T-REC-V.42bis>.
[yEnc] Helbing, J., "yEnc - Efficient encoding for Usenet and eMail", March 2002, <http://www.yenc.org/>.
[yEnc]Helbing，J.，“yEnc-Usenet和电子邮件的有效编码”，2002年3月<http://www.yenc.org/>.
Acknowledgments
致谢
This document draws heavily on ideas in [RFC4978] by Arnt Gulbrandsen; a large portion of this text was borrowed from that specification.
本文件大量借鉴了Arnt Gulbrandsen在[RFC4978]中的观点；本文的大部分内容是从该规范中借来的。
The authors would like to thank the following individuals for contributing their ideas and reviewing this specification: Mark Adler, Russ Allbery, Stephane Bortzmeyer, Francis Dupont, Angel Gonzalez, Barry Leiba, John Levine, and Brian Peterson.
作者要感谢以下个人贡献了他们的想法并审查了本规范：Mark Adler、Russ Allbery、Stephane Bortzmeyer、Francis Dupont、Angel Gonzalez、Barry Leiba、John Levine和Brian Peterson。
Special thanks to our Document Shepherd, Michael Baeuerle, who significantly helped to increase the quality of this specification, and to Stephen Farrell for his encouragement to pursue the efforts in standardizing this NNTP extension.
特别感谢我们的文档守护者Michael Baeuerle，他极大地帮助提高了本规范的质量，并感谢Stephen Farrell鼓励他努力实现NNTP扩展的标准化。
Many thanks to the Responsible Area Director, Alexey Melnikov, for reviewing and sponsoring this document.
非常感谢区域负责人Alexey Melnikov审查和赞助本文件。
Authors' Addresses
作者地址
Kenneth Murchison Carnegie Mellon University 5000 Forbes Avenue Pittsburgh, PA 15213 United States of America
肯尼斯·默奇森卡内基·梅隆大学美国宾夕法尼亚州匹兹堡福布斯大道5000号，邮编15213
Phone: +1 412 268 1982
Email: murch@andrew.cmu.edu
Phone: +1 412 268 1982
Email: murch@andrew.cmu.edu
Julien Elie 10 allee Clovis Noisy-le-Grand 93160 France
Julien Elie 10 allee Clovis喧闹勒格兰德93160法国
Email: julien@trigofacile.com
URI: http://www.trigofacile.com/
Email: julien@trigofacile.com
URI: http://www.trigofacile.com/