RFC 8054
Network News Transfer Protocol (NNTP) Extension for Compression
RFC 8054: Network News Transfer Protocol (NNTP) Extension for Compression 🎀
okay bestie, this one is from the Internet Engineering Task Force (IETF) and it's RFC 8054 🦋 The title is Network News Transfer Protocol (NNTP) Extension for Compression, and it's a Standards Track document, so it's an official spec and not just an idea someone had.
- Authors: K. Murchison (Carnegie Mellon University) and J. Elie
- Category: Standards Track
- Date: January 2017
- ISSN: 2070-1721
- Obsoletes and updates: the title block doesn't list anything this one obsoletes or updates 💅
Abstract ✨
this doc defines an extension to the Network News Transport Protocol (NNTP) that lets a connection get effectively and efficiently compressed between an NNTP client and server. it's giving compression glow-up 💖
Status of This Memo 📜
this is an Internet Standards Track document 🔥
it's a product of the IETF, so it represents the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). if you want more info on Internet Standards, check Section 2 of RFC 7841 🧚
for the current status, any errata, and how to give feedback, go to 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.
this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they're in effect on the date of publication. please read these carefully, because they describe your rights and restrictions for this document 🫶 Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions. they come without warranty, as described in the 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 . . . . . . . . . . . . . . . . . . . . . . . 231. Introduction ✨
the goal of COMPRESS is to reduce the bandwidth usage of NNTP 🍓
compared to PPP compression [RFC1962] and modem-based compression ([MNP] and [V42bis]), COMPRESS gives you way better 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. 🫶
the whole point of COMPRESS as an NNTP extension is to act as a compression layer, kind of like the security layer you get when you negotiate STARTTLS [RFC4642]. so compression can help every NNTP command that's sent or received after you use COMPRESS 💖 this fills a long-standing need for NNTP to compress data. right now it's only partly covered by unstandardized commands like XZVER, XZHDR, XFEATURE COMPRESS, or MODE COMPRESS. but honestly those aren't wholly satisfying 😭 they only compress the responses the news server sends. COMPRESS is different because it compresses data sent by both the client and the server, and you don't have to build compression into each NNTP command separately 👑 the compression level can also be adjusted and optimized at any time during the connection, which even lets you turn compression off for certain commands if you need to 🧚 if the news client wants to stop compression on a connection, it can just use QUIT ([RFC3977], Section 5.4) and open a new connection. for all these reasons, using other NNTP commands to turn on compression is discouraged once COMPRESS is supported 💅
to help with interoperability, it's better to have as few compression algorithms as possible, so this doc specifies just one 🦋 the DEFLATE algorithm (defined in [RFC1951]) MUST be implemented as part of this extension. it's standard, widely available, and pretty efficient 💜
this spec should be read together with the NNTP base specification [RFC3977]. if these two documents ever conflict, [RFC3977] takes precedence 🎀
1.1. About TLS-Level Compression 🌈
lossless data compression is already possible with NNTP by using TLS [RFC4642], but the best current practice is to turn off TLS-level compression, as explained in Section 3.3 of [RFC7525] 🙈 the COMPRESS command keeps the compression facility inside NNTP and lets you control when it's available during a connection 🫶
compared to TLS-level compression [RFC3749], NNTP COMPRESS has these perks:
- COMPRESS is easy for both NNTP servers and clients to implement 💅
- COMPRESS benefits from really knowing the NNTP protocol's state machine, which allows dynamic and aggressive optimization of the underlying compression algorithm's parameters 🧠
- COMPRESS can be turned on after authentication is complete, which lowers the chances that authentication credentials get leaked through something like a CRIME attack ([RFC7457], Section 2.6) 😭
1.2. Conventions Used in This Document 📖
the notation in this doc is the same as in [RFC3977], and any term that isn't defined here means the same thing it does in that one 💖
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] 🔥
in the examples, commands from the client are marked with [C], and responses from the server are marked with [S]. the client is the one that starts the NNTP connection, and the server is the other endpoint 🍓
2. The COMPRESS Extension 🦋
the COMPRESS extension is used to turn on lossless data compression on an NNTP connection ✨
it adds a new COMPRESS command and has the capability label COMPRESS 💜
2.1. Advertising the COMPRESS Extension 📣
a server that supports the COMPRESS command as defined here advertises the "COMPRESS" capability label in response to the CAPABILITIES command ([RFC3977], Section 5.2). but 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 🫶
the COMPRESS capability label holds a whitespace-separated list of the compression algorithms that are available. this doc defines one compression algorithm: DEFLATE. this algorithm is mandatory to implement, so it MUST be supported and listed in the advertisement of the COMPRESS extension 👑
future extensions may add more compression algorithms to this capability. unrecognized algorithms MUST be ignored by the client 🧚
example time 🎀
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] READER
[S] IHAVE
[S] COMPRESS DEFLATE SHRINK
[S] LIST ACTIVE NEWSGROUPS
[S] .bestie, since COMPRESS is tied to security (it can weaken encryption), cached CAPABILITIES results from a previous session MUST NOT be relied on, as per Section 12.6 of [RFC3977] 🚨
2.2. COMPRESS Command 💅
2.2.1. Usage 🔥
this command MUST NOT be pipelined ❌
Syntax
COMPRESS algorithm
Responses
206 Compression active
403 Unable to activate compression
502 Command unavailable [1]
[1] If a compression layer is already active, COMPRESS is not a valid
command (see Section 2.2.2).
Parameters
algorithm = Name of compression algorithm (e.g., "DEFLATE")2.2.2. Description 💖
okay so the COMPRESS command tells the server to start using the named compression algorithm ("DEFLATE" is the only one defined in this document) 🗜️ for all commands and responses after COMPRESS. it's giving "everything from here on is compressed" energy 💅
the client MUST NOT send any more commands until it has seen the result of COMPRESS. so wait for the answer first, no cap 🫶
if the algorithm name is syntactically incorrect, the server MUST reject the COMPRESS command with a 501 response code ([RFC3977], Section 3.2.1). if the algorithm is invalid (like, not supported 🙅♀️), the server MUST reject it with a 503 response code ([RFC3977], Section 3.2.1). if the server can't turn compression on for any reason (a config or resource problem, for example), the server MUST reject the COMPRESS command with a 403 response code ([RFC3977], Section 3.2.1). otherwise, if no other generic response code fits the situation, the server sends a 206 response code and the compression layer kicks in for both client and server right after the CRLF of the success reply ✨
also, the client MUST NOT issue a MODE READER command after a compression layer is activated, and a server MUST NOT advertise the MODE-READER capability. not me, but that's a hard no 🙈
both the client and the server MUST know whether a compression layer is active (for instance, from an earlier COMPRESS command or from negotiating a TLS-level compression method [RFC3749]). a client MUST NOT try to activate compression (for instance, with COMPRESS) or negotiate a TLS security layer (because STARTTLS [RFC4642] may turn on 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 shows up while a compression layer is already active. double-compression is NOT the vibe 💀
main character security moment 🌈 to help stop authentication credentials from leaking through something like a CRIME attack [CRIME], authentication MUST NOT be attempted after a successful use of the COMPRESS command. so 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 COMPRESS, and that client MUST NOT try to use any AUTHINFO [RFC4643] commands. this also means a server MUST reply with a 502 response code if a syntactically valid AUTHINFO command is received after a successful use of COMPRESS. (side note: this spec doesn't change how AUTHINFO works in [RFC4643] on its own, apart from TLS-level compression. so authentication is still allowed, even though TLS-level compression is active 🔐)
for DEFLATE [RFC1951] (like plenty of other compression algorithms), the sending compressor can trade speed for compression ratio 🏎️ the receiving decompressor MUST automatically adjust to whatever parameters the sender picked. so the client and server are both free to pick the best reasonable rate of compression for the data they send ✨ also, all data that was submitted for compression MUST be included in the compressed output, and appropriately flushed so the receiving decompressor can fully decompress it 📦
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. picture it like this: before data gets sent, it's compressed first 🗜️ second, if a SASL security layer was negotiated, the compressed data is signed and/or encrypted accordingly. third, if a TLS security layer was negotiated, the data from the previous step is signed and/or encrypted accordingly (with a possible extra TLS-level compression). when receiving data, the processing order MUST be reversed. this makes sure that data gets compressed before it gets encrypted, which is the whole point 🔥
lastly, when compression is active and either the client or the server receives invalid or corrupted compressed data, the receiving end immediately closes the connection, and the sending end will do the same 🚪💔
2.2.3. Examples 🎀
okay, examples time, let's go 🍓
Example of layering a TLS security layer and NNTP compression:
[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 compressionExample 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 supportedExample 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 TLSExample of a server refusing to negotiate a TLS security layer after compression has been activated:
[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 activeExample of a server not advertising AUTHINFO arguments after compression has been activated:
[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 active3. Compression Efficiency ✨
This section is informative, not normative. 📚
NNTP poses some unusual problems for a compression layer 🤔
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 the exceptions 👀 clients that send lots of 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, the same way as is recommended for servers later in this document (Section 4).
downstream traffic has the unusual property that several kinds of data are sent, which can possibly confuse a dictionary-based compression algorithm 🌀
first up: NNTP responses that aren't related to article header/body retrieval. compressing NNTP simple responses (e.g., in answer to CHECK [RFC4644], DATE, GROUP, LAST, NEXT, STAT, etc.) generally doesn't save many bytes, unless it's repeated several times in the same NNTP session 😅 on the flip side, most 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.
article headers (as retrieved via the HEAD, HDR, OVER, or ARTICLE commands, for instance) are another type 💌 they're equally compressible, and they benefit from using the same dictionary as the NNTP responses.
a third type is article body text (as retrieved via the BODY or ARTICLE commands, for instance). text is usually fairly short and includes lots of ASCII, so the same compression dictionary will do a good job here too 📝 when multiple messages in the same thread get read at the same time, quoted lines, etc., can often be compressed almost to zero 🫠
finally, non-text article bodies or attachments (as retrieved via the BODY or ARTICLE commands, for instance) are transmitted in encoded form, usually Base64 [RFC4648], UUencode [IEEE.1003.1-2008], or yEnc [yEnc] 📎
when 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 doesn't help much 🥲 the compressor has to adapt its dictionary from NNTP to the attachment's encoding format, and then back again 🔄
when attachments are retrieved in Base64 or UUencode form, Huffman coding usually compresses them to approximately only 75% of their encoding size. 8-bit compression algorithms such as DEFLATE work well on 8-bit file formats, but both Base64 and UUencode transform a file into something resembling 6-bit bytes, which hides most of the 8-bit file format from the compressor 🫣
on the other end, attachments encoded with a method that keeps the full 8-bit spectrum, like yEnc, are much more likely to be incompressible 🧱
4. DEFLATE Specificities ✨
okay bestie, let's talk DEFLATE 🧚 If you're using the zlib library (see [RFC1951]), you only need four functions to build this extension: deflateInit2(), deflate(), inflateInit2(), and inflate(). That's it, no cap 💅
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 won't be able to decompress a stream with a larger window size, which means less interoperability. Lowkey a big deal 💀 deflateParams() can be used to improve compression rate and resource use ✨
Now flushing, which is giving main character energy 👑 The Z_FULL_FLUSH argument to deflate() clears the dictionary, and that usually makes compression less effective than doing a Z_PARTIAL_FLUSH. Why? Because keeping the 32 KB dictionary from previous data, no matter how unrelated it seems, can actually help. If there are no matching strings in there, it just doesn't get referenced, so there's no downside 🦋
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 stops the server from trying to compress incompressible attachments 🫶
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 🌈
5. Augmented BNF Syntax for the COMPRESS Extension 🎀
this section is the formal grammar for COMPRESS, written in ABNF [RFC7405] and [RFC5234]. It extends the syntax in Section 9 of [RFC3977], and any non-terminals not defined here are defined there. So the NNTP ABNF [RFC3977] should be imported first, before you try validating these rules 🧠
5.1. Commands
This syntax extends the non-terminal <command>, which represents an NNTP command 💖
command =/ compress-command
compress-command = "COMPRESS" WS algorithm5.2. Capability Entries
This syntax extends the non-terminal <capability-entry>, which represents a capability that may be advertised by the server 🍓
capability-entry =/ compress-capability
compress-capability = "COMPRESS" 1*(WS algorithm)5.3. General Non-terminals
algorithm = %s"DEFLATE" / 1*20alg-char ; case-sensitive
alg-char = UPPER / DIGIT / "-" / "_"6. Summary of Response Codes 🔥
this section defines one new response code, and it's a simple one. It is not multi-line and has no arguments 🧚
Response code 206
Generated by: COMPRESS
Meaning: compression layer activated7. Security Considerations 🥺🔐
okay, this section is SERIOUS bestie, so read it all 😭 Security issues are discussed throughout this document, and that's the tea ☕
In general, the security considerations of the NNTP core specification ([RFC3977], Section 12) and the DEFLATE compressed data format specification ([RFC1951], Section 6) apply here too 🦋
Implementers need to know that combining compression with encryption like TLS can sometimes reveal information that wouldn't have been revealed without compression, as explained in Section 6 of [RFC3749]. Honestly this is the scariest plot twist 💀 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 this, iykyk 🙈
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 🔒 So 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 means it begins the TLS negotiation immediately upon connection, on a separate port dedicated to NNTP over 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's why this specification only prohibits using AUTHINFO after COMPRESS. But if confidential articles are accessed in private newsgroups, you need to be extra careful 🚨 Implementations SHOULD NOT compress confidential data together with public data when a TLS [RFC5246] or SASL [RFC4422] security layer is active. Why? Because adversaries that observe the length of the compressed data might be able to derive information about the confidential data, when public data (which adversaries know is read) and confidential data get compressed in the same compression session 👀
Also, it's preferable not to compress the contents of two distinct confidential articles together if you can avoid it, because adversaries might be able to derive information about them (for instance, if they share a few header fields or body lines). With DEFLATE, one way to do this is clearing the compression dictionary each time a confidential article is sent. More complex implementations are, of course, possible and encouraged 🫶
Implementations are encouraged to unconditionally allow compression when no security layer is active. They should also support an option to enable or disable compression when a security layer is active. That option could, for instance, have global scope or be server/connection-based 🍓 Besides, compression may in general weaken the confidentiality of a security layer, so 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 carrying confidential data SHOULD be sure to state that this confidential data SHOULD NOT be compressed together with public data when a security layer is active 🧁
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 💀✨
8. IANA Considerations 📋
8.1. "NNTP Compression Algorithms" Registry 🦋
the "NNTP Compression Algorithms" registry is maintained by IANA, and you can find it at <http://www.iana.org/assignments/nntp-parameters> 🌸
The whole point of this registry is not only to make sure values used to name NNTP compression algorithms are unique, but also to give a definitive reference to technical specifications detailing each NNTP compression algorithm available for use on the Internet. Very organized, very iconic 👑
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's a "registered NNTP compression algorithm"). Different entries in the registry MUST use different names 🔒
Private algorithms with unregistered names are allowed, but they SHOULD NOT be used, because it's hard 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 💖
The procedure detailed in Section 8.1.1 is the one to use for registering a value naming a specific individual compression algorithm 🧚
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 🎀
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.1. Algorithm Name Registration Procedure 📝
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 review the claims made in the registration form 🙅♀️
Registering an NNTP compression algorithm is done by filling in the following template and sending it via email to IANA at <iana@iana.org>:
Subject: Registration of NNTP compression algorithm Z
NNTP compression algorithm name:
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 doesn't require expert review, authors of NNTP compression algorithms are encouraged to seek community review and comment whenever that's feasible. Authors can 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 🌈
8.1.2. Comments on Algorithm Registrations 💬
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 🦋
Submitters of comments may, after a reasonable attempt to contact the owner and/or the above mailing list, ask 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 🫶
8.1.3. Change Control 🔄
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 💅
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 ✨
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 🌸
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, and such algorithms will be clearly marked in the registry published by IANA 🪦
The IESG is considered to be the owner of all NNTP compression algorithms that are on the IETF Standards Track 👑
8.2. Registration of the DEFLATE Compression Algorithm ✨
okay so this section is the official registration form for DEFLATE 🧚. Section 8.1.1 says the registry needs a formal definition, so here it is, bestie 💖
NNTP compression algorithm name: DEFLATE
Security considerations: See Section 7 of this document
Published specification: This document
Contact for further information: Authors of this document
Intended usage: COMMON
Owner/Change controller: IESG <iesg@ietf.org>
Note: This algorithm is mandatory to implementWhen it lands in the "NNTP Compression Algorithms" registry, it looks like this 🎀
+------------+------------+--------------+--------------+-----------+
| Algorithm | Intended | Comment | Change | Reference |
| Name | Usage | | Controller | |
+------------+------------+--------------+--------------+-----------+
| DEFLATE | COMMON | Mandatory to | IESG | RFC 8054 |
| | | implement | | |
+------------+------------+--------------+--------------+-----------+8.3. Registration of the NNTP COMPRESS Extension 🦋
this part registers the COMPRESS extension, as required by Section 3.3.3 of [RFC3977]. Get ready for the fine print 💅
- The COMPRESS extension lets an NNTP connection get effectively and efficiently compressed 🗜️✨
- The capability label is "COMPRESS", and its arguments list the compression algorithms that are available 🌸
- This extension adds exactly one new command, COMPRESS. Its behavior, arguments, and responses are all defined in Section 2.2 💜
- It doesn't attach any new responses to commands that already exist in NNTP 🙅♀️
- It does change the overall behavior of both the server and the client. Once COMPRESS has succeeded, everything gets sent in a compressed format, so the whole connection glows up 🔥
- It doesn't change the maximum length of commands or initial response lines 📏
- It doesn't change pipelining, but the COMPRESS command itself can't be pipelined 🚫
- It also changes the capabilities list. Once COMPRESS has been used successfully, the COMPRESS capability can't be advertised by CAPABILITIES anymore. On top of that, the STARTTLS and MODE-READER capabilities MUST NOT be advertised, and after a successful COMPRESS the AUTHINFO capability label MUST either be listed with no arguments or not advertised at all 🥺
- No pre-existing command gets a 401, 480, or 483 response code because of this extension 🙌
- The MODE READER command doesn't affect this extension, BUT it MUST NOT be used in the same session after a successful COMPRESS 🙈
- STARTTLS and AUTHINFO MUST NOT be used in the same session after a successful COMPRESS. Same energy as the last one, honestly 😭
- Published Specification: This document 📜
- Contact for Further Information: Authors of this document 💌
- Change Controller:
IESG <iesg@ietf.org>👑
This registration shows up in the "NNTP Capability Labels" registry, which lives inside the "Network News Transfer Protocol (NNTP) Parameters" registry, like this 🍓
+----------+----------------------------------+-----------+
| Label | Meaning | Reference |
+----------+----------------------------------+-----------+
| COMPRESS | Supported compression algorithms | RFC 8054 |
+----------+----------------------------------+-----------+9. References 📚
9.1. Normative References 💖
These are the must-read ones, bestie 🫶
[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>.
[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>.
[RFC3977] Feather, C., "Network News Transfer Protocol (NNTP)",
RFC 3977, DOI 10.17487/RFC3977, October 2006,
<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>.
[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>.
[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",
RFC 7405, DOI 10.17487/RFC7405, December 2014,
<http://www.rfc-editor.org/info/rfc7405>.9.2. Informative References 🌈
These are the extra-credit reads, and they're totally worth it 🤓✨
[CRIME] Rizzo, J. and T. Duong, "The CRIME Attack", Ekoparty
Security Conference, 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>.
[MNP] Held, G., "The Complete Modem Reference", Second
Edition, John Wiley & Sons, Inc., May 1994.
[RFC1962] Rand, D., "The PPP Compression Control Protocol (CCP)",
RFC 1962, DOI 10.17487/RFC1962, June 1996,
<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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[RFC4978] Gulbrandsen, A., "The IMAP COMPRESS Extension", RFC 4978,
DOI 10.17487/RFC4978, August 2007,
<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>.
[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>.
[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>.
[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>.
[yEnc] Helbing, J., "yEnc - Efficient encoding for Usenet and
eMail", March 2002, <http://www.yenc.org/>.Acknowledgments 🫶
This document is built on a lot of [RFC4978] by Arnt Gulbrandsen, and honestly a big chunk of its text was borrowed straight from that spec 💜
The authors would like to thank the following people for sharing their ideas and reviewing this spec: Mark Adler, Russ Allbery, Stephane Bortzmeyer, Francis Dupont, Angel Gonzalez, Barry Leiba, John Levine, and Brian Peterson 🙌✨
Special thanks to our Document Shepherd, Michael Baeuerle, who made this spec so much better 🌸, and to Stephen Farrell for encouraging us to take on the work of standardizing this NNTP extension 🦋
Many thanks to the Responsible Area Director, Alexey Melnikov, for reviewing and sponsoring this document 👑
Authors' Addresses 💌
Kenneth Murchison
Carnegie Mellon University
5000 Forbes Avenue
Pittsburgh, PA 15213
United States of America
Phone: +1 412 268 1982
Email: murch@andrew.cmu.edu
Julien Elie
10 allee Clovis
Noisy-le-Grand 93160
France
Email: julien@trigofacile.com
URI: http://www.trigofacile.com/📦 where this page comes from
- ietf: rfc8054 2017-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms