[要約] RFC 8054は、NNTPの拡張である圧縮に関する情報を提供します。その目的は、NNTPセッションの効率を向上させるために、データの圧縮と伸張をサポートすることです。
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クライアントとサーバーの間で接続を効果的かつ効率的に圧縮できるようにするNetwork News Transport Protocol（NNTP）の拡張機能を定義します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
The goal of COMPRESS is to reduce the bandwidth usage of NNTP.
COMPRESSの目標は、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はより優れた圧縮効率を提供します。 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拡張機能としてのCOMPRESSのポイントは、STARTTLS [RFC4642]によってネゴシエートされたセキュリティレイヤーのようなセキュリティレイヤーと同様に、圧縮レイヤーとして機能することです。したがって、COMPRESSの使用後に送信または受信されるすべてのNNTPコマンドにとって、圧縮は有益です。この機能は、NNTPがデータを圧縮するという長年のニーズに応えます。現在、XZVER、XZHDR、XFEATURE COMPRESS、またはMODE COMPRESSなどの非標準化されたコマンドによって部分的にのみ対処されています。しかし、これらのコマンドは、ニュースサーバーから送信された応答に対してのみ圧縮を有効にするため、完全に満足できるものではありません。対照的に、COMPRESSコマンドは、クライアントとサーバーの両方から送信されたデータの圧縮を許可し、各NNTPコマンドで個別に圧縮を実装する必要があるという制約を取り除きます。さらに、接続中いつでも圧縮レベルを動的に調整および最適化できるため、必要に応じて特定のコマンドの圧縮を無効にすることもできます。ニュースクライアントが特定の接続で圧縮を停止する場合は、QUIT（[RFC3977]、セクション5.4）を使用して新しい接続を確立するだけです。これらの理由により、COMPRESSがサポートされた後は、COMPRESS以外の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.
相互運用性を高めるためには、異なる圧縮アルゴリズムをできるだけ少なくすることが望ましいため、このドキュメントでは1つだけを指定します。 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]と併せて読む必要があります。これら2つの文書の間に矛盾がある場合は、[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.
NNTPを使用したTLS [RFC4642]を使用すると、ロスレスデータ圧縮がすでに可能ですが、現在のベストプラクティスは、[RFC7525]のセクション3.3で説明されているように、TLSレベルの圧縮を無効にすることです。 COMPRESSコマンドを使用すると、圧縮機能をNNTPに維持し、接続中にいつ使用できるかを制御できます。
Compared to TLS-level compression [RFC3749], NNTP COMPRESS has the following advantages:
TLSレベルの圧縮[RFC3749]と比較すると、NNTP COMPRESSには次の利点があります。
o COMPRESS can be implemented easily both by NNTP servers and clients.
o COMPRESSは、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 COMPRESSは、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 COMPRESSは認証が完了した後にアクティブ化できるため、CRIME攻撃（[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].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこの文書の "は、[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.
COMPRESS拡張機能は、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.
このドキュメントで定義されているCOMPRESSコマンドをサポートするサーバーは、CAPABILITIESコマンド（[RFC3977]、セクション5.2）への応答として「COMPRESS」機能ラベルを通知します。ただし、圧縮層がアクティブになると、この機能をアドバタイズしてはなりません（セクション2.2.2を参照）。この機能は、MODE READERコマンド（[RFC3977]、セクション5.3）を使用する前と後の両方で、同じセマンティクスでアドバタイズできます（MAY）。
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.
COMPRESS機能ラベルには、空白で区切られた使用可能な圧縮アルゴリズムのリストが含まれています。このドキュメントでは、DEFLATEという1つの圧縮アルゴリズムを定義しています。このアルゴリズムは実装に必須です。 COMPRESSエクステンションのアドバタイズメントでサポートおよびリストされている必要があります。
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] .
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].
COMPRESSコマンドは暗号化を弱める可能性があるためセキュリティに関連しているため、[RFC3977]のセクション12.6に従って、以前のセッションからのCAPABILITIESのキャッシュ結果に依存することはできません。
This command MUST NOT be pipelined.
このコマンドはパイプライン処理してはなりません。
Syntax COMPRESS algorithm
構文COMPRESSアルゴリズム
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] 圧縮層がすでにアクティブである場合、COMPRESSは有効なコマンドではありません（セクション2.2.2を参照）。
Parameters algorithm = Name of compression algorithm (e.g., "DEFLATE")
パラメータalgorithm =圧縮アルゴリズムの名前（例： "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コマンドは、COMPRESS後のすべてのコマンドと応答に対して、指定された圧縮アルゴリズム（このドキュメントでは「DEFLATE」のみが定義されている）を使用するようにサーバーに指示します。
The client MUST NOT send any further commands until it has seen the result of COMPRESS.
クライアントは、COMPRESSの結果を確認するまで、それ以上のコマンドを送信してはなりません（MUST NOT）。
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）でCOMPRESSコマンドを拒否する必要があります。要求された圧縮アルゴリズムが無効である（たとえば、サポートされていない）場合、サーバーは503応答コードでCOMPRESSコマンドを拒否する必要があります（[RFC3977]、セクション3.2.1）。サーバーが何らかの理由（サーバーの構成やリソースの問題など）で圧縮をアクティブにできない場合、サーバーは403応答コード（[RFC3977]、セクション3.2.1）でCOMPRESSコマンドを拒否する必要があります。それ以外の場合、状況を表す他の汎用応答コードが適用されない場合、サーバーは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.
さらに、クライアントは圧縮層をアクティブ化した後にMODE READERコマンドを発行してはならず（MUST NOT）、サーバーはMODE-READER機能をアドバタイズしてはなりません（MUST NOT）。
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レベルの圧縮をアクティブにする可能性があるため）。サーバーは、圧縮層がアクティブになった後に受信したCAPABILITIESコマンドに応答してCOMPRESSまたはSTARTTLS機能ラベルを返さないでください。また、圧縮層が有効な間に構文的に有効な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 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.)
たとえば、CRIME攻撃[CRIME]を介した認証資格情報の漏洩を軽減するために、COMPRESSコマンドを正常に使用した後で認証を試みてはなりません。したがって、サーバーは、COMPRESSコマンドを正常に使用した後に非認証クライアントから受信したCAPABILITIESコマンドに応答して、引数なしのAUTHINFO機能をリストするか、まったく通知しないかのいずれかである必要があり、そのようなクライアントは、 AUTHINFO [RFC4643]コマンド。これは、COMPRESSコマンドを正常に使用した後で構文的に有効なAUTHINFOコマンドを受信した場合、サーバーが502応答コードで応答する必要があることを意味します。 （この仕様は、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]セキュリティレイヤーと組み合わせる場合、3つのレイヤーの処理順序は、最初にCOMPRESS、次にSASL、最後にTLSである必要があります。つまり、データが送信される前に、まず圧縮されます。次に、SASLセキュリティレイヤーがネゴシエートされた場合、圧縮されたデータはそれに応じて署名または暗号化されます。 3番目に、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] .
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
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
Example of a server refusing to compress twice:
2回の圧縮を拒否するサーバーの例：
[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
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
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応答は1つのタイプです。同じNTPセッションで数回繰り返さない限り、NNTPの単純な応答を圧縮しても（たとえば、CHECK [RFC4644]、DATE、GROUP、LAST、NEXT、STATなどへの応答で）、通常は多くのバイトが節約されません。それどころか、ほとんどのNNTPマルチライン応答（たとえば、LIST、LISTGROUP、NEWGROUPS、NEWNEWSなどへの応答）は非常に圧縮可能です。 CPU負荷が最も低い設定を使用して、zlibは標準的な応答を元のサイズの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.
3番目のタイプは、記事の本文テキストです（たとえば、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].
最後に、テキスト以外の記事の本文または添付ファイル（たとえば、BODYまたはARTICLEコマンドを介して取得）は、通常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％に圧縮します。 DEFLATEなどの8ビット圧縮アルゴリズムは、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.
一方、yEncのように完全な8ビットスペクトルを保持する圧縮アルゴリズムを使用してエンコードされた添付ファイルは、圧縮できない可能性がはるかに高くなります。
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).
windowBits値はdeflateInit2()の場合は-8から-15の範囲でなければなりません。そうでない場合、間違った形式を使用します。 windowBits値は、inflateInit2()の場合は-15である必要があります。そうでない場合、ウィンドウサイズが大きいストリームを解凍できなくなり、相互運用性が低下します。 deflateParams()を使用して、圧縮率とリソースの使用を改善できます。フラッシュ操作に関しては、deflate()へのZ_FULL_FLUSH引数でディクショナリーをクリアできます。これにより、一般に、Z_PARTIAL_FLUSHを実行するよりも圧縮率が低くなります。実際、32 KBの辞書を以前のデータから遠ざけても、たとえ関係がなくても役に立ちます（一致する文字列がそこにない場合は、単に参照されません）。
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.
サーバーは、大規模な非テキストマルチラインデータブロックの開始と終了で圧縮レベルを調整すると（たとえば、zlibのdeflateParams()関数を使用して）、サーバーとクライアントの両方のダウンストリーム圧縮とCPU効率を改善できます。 （[RFC3977]、セクション9.8の「multi-line-data-block」の定義の「content-lines」の前後）。このメカニズムにより、サーバーは圧縮できない添付ファイルを圧縮しようとしなくなります。
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.
非常に単純な戦略は、たとえばyEnc [yEnc]を使用してエンコードする場合など、非圧縮性の複数行データブロックの開始時に圧縮レベルを0に変更し、残りの時間を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]を使用したCOMPRESS拡張の正式な構文について説明します。 [RFC3977]のセクション9の構文を拡張し、このドキュメントで定義されていない非端末がそこで定義されています。これらのルールを検証する前に、NNTP ABNF [RFC3977]を最初にインポートする必要があります。
This syntax extends the non-terminal <command>, which represents an NNTP command.
この構文は、NNTPコマンドを表す非端末<command>を拡張します。
command =/ compress-command
コマンド= /圧縮コマンド
compress-command = "COMPRESS" WS algorithm
compress-command = "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)
compress-capability = "COMPRESS" 1 *（WSアルゴリズム）
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生成：COMPRESS意味：圧縮層がアクティブ化されました
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.
実装者は、[RFC3749]のセクション6で説明されているように、圧縮をTLSのような暗号化と組み合わせると、圧縮なしでは明らかにされなかった情報が明らかになる場合があることに注意する必要があります。実際のところ、圧縮されたデータの長さを観察する攻撃者は、対応する非圧縮データに関する情報を導出できる可能性があります。 CRIMEとBREACH攻撃（[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コマンドをこの順序で使用する必要があります。もちろん、クライアントはSTARTTLSコマンドを使用する代わりに、暗黙のTLSを使用することもできます。つまり、NNTP over TLS専用の別のポートに接続するとすぐに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コマンドは、公開のNetnewsニュースグループと記事にのみアクセスする限り、機密情報を漏らすとは考えられていません。そのため、この仕様ではCOMPRESS後の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.
さらに、敵がそれらについての情報を引き出せる可能性があるため（たとえば、ヘッダーフィールドや本文行がいくつか共通している場合など）、回避できる場合は、2つの異なる機密記事の内容を一緒に圧縮しないことが推奨されます。これは、たとえば、機密記事が送信されるたびに圧縮辞書をクリアすることにより、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の将来の拡張では、セキュリティレイヤーがアクティブなときに、これらの機密データを公開データと一緒に圧縮しないでください（SHOULD）。
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圧縮アルゴリズムの名前に使用される値の一意性を保証するだけでなく、インターネットで使用できる各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.
ニュースサーバーがプライベート圧縮アルゴリズムを使用してCOMPRESSコマンドに応答する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>:
NNTP圧縮アルゴリズムの登録は、次のテンプレートに入力して電子メールで<iana@iana.org>のIANAに送信することによって要求されます。
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)
使用目的：（COMMON、LIMITED USE、または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圧縮アルゴリズムの作成者は、可能であればコミュニティのレビューとコメントを求めることをお勧めします。著者は、提案されたアルゴリズムの仕様をインターネットドラフトとして投稿することにより、コミュニティレビューを求めることができます。広範な使用を目的としたNNTP圧縮アルゴリズムは、適切な場合、通常のIETFプロセスを通じて標準化する必要があります。
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圧縮アルゴリズムに関するコメントは、最初にアルゴリズムの「所有者」またはIETFの現在締結されているNNTPEXTワーキンググループ（<ietf-nntp@lists.eyrie.org>）のメーリングリストに送信する必要があります。
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@iana.org>にメールを送信することにより、NANA圧縮アルゴリズム登録自体にコメントを添付するようIANAに要求できます。 IANAの独自の裁量により、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.
NNTP圧縮アルゴリズムの登録がIANAによって公開されると、所有者はその定義の変更を要求できます。変更要求は、最初の登録要求と同じ手順に従います。
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圧縮アルゴリズムの登録は削除してはなりません（MUST NOT）。使用に適するとは考えられなくなったアルゴリズムは、「使用目的」フィールドを変更することにより、廃止と宣言できます。そのようなアルゴリズムは、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.
このセクションでは、セクション8.1.1でIANAレジストリーに必要な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
使用目的：COMMON
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 | | |
+------------+------------+--------------+--------------+-----------+
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レジストリについて要求されているCOMPRESS拡張の正式な定義を示します。
o The COMPRESS extension allows an NNTP connection to be effectively and efficiently compressed.
o COMPRESS拡張機能により、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 この拡張機能は、1つの新しいコマンド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機能はCAPABILITIESによってアドバタイズできなくなります。さらに、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 この拡張は、MODE READERコマンドを使用しても影響を受けません。ただし、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 STARTPRESSコマンドとAUTHINFOコマンドは、COMPRESSコマンドの実行が成功した後、同じセッションで使用してはなりません（MUST NOT）。
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 |
+----------+----------------------------------+-----------+
[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 Compressed Data Format Specification version 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。、「Network News Transfer Protocol（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、「RFCで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]クロッカー、D。、エド。および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.
[犯罪]リッツォJ.とT.デュオン、「犯罪」攻撃、エコパーティーセキュリティ会議、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 / standard / 1003.1-2008.html>。
[MNP] Held, G., "The Complete Modem Reference", Second Edition, John Wiley & Sons, Inc., May 1994.
[MNP] G。、「The Complete Modem Reference」、第2版、John Wiley＆Sons、Inc.、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] Rand、D。、「The PPP Compression Control Protocol（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。、「Transport Layer Security Protocol Compression Methods」、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]メルニコフ、A。、エド。 K. Zeilenga編、「Simple Authentication and Security Layer（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、「Using Transport Layer Security（TLS）with Network News Transfer Protocol（NNTP）」、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.マーチソン、「認証のためのネットワークニュース転送プロトコル（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.マーチソン、「ストリーミングフィードのネットワークニュース転送プロトコル（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。、「The 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。、「The IMAP COMPRESS Extension」、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、「The Transport Layer Security（TLS）Protocol Version 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、「Transport Layer Security（TLS）およびDatagram Transport Layer Security（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およびeMailの効率的なエンコーディング」、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氏と、このNNTP拡張機能の標準化への取り組みを推進してくれたStephen Farrell氏に特に感謝します。
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
Julien Elie 10 allee Clovis Noisy-le-Grand 93160 France
Julien Elie 10 allee Clovis Noisy-le-Grand 93160フランス
Email: julien@trigofacile.com
URI: http://www.trigofacile.com/