idnits 2.17.1 draft-murchison-nntp-compress-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 26, 2010) is 5197 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'C' is mentioned on line 325, but not defined == Missing Reference: 'S' is mentioned on line 326, but not defined -- Looks like a reference, but probably isn't: '1' on line 183 ** Downref: Normative reference to an Informational RFC: RFC 1951 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Independent Submission K. Murchison 3 Internet-Draft Carnegie Mellon University 4 Intended status: Standards Track January 26, 2010 5 Expires: July 30, 2010 7 Network News Transfer Protocol (NNTP) Extension for Compression 8 draft-murchison-nntp-compress-01.txt 10 Abstract 12 This memo defines an extension to the Network News Transport Protocol 13 (NNTP) to allow a connection to be effectively and efficiently 14 compressed. 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on July 30, 2010. 39 Copyright Notice 41 Copyright (c) 2010 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 58 2. The COMPRESS Extension . . . . . . . . . . . . . . . . . . . . 4 59 2.1. Advertising the COMPRESS Extension . . . . . . . . . . . . 4 60 2.2. COMPRESS Command . . . . . . . . . . . . . . . . . . . . . 4 61 2.2.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.2.2. Description . . . . . . . . . . . . . . . . . . . . . 5 63 2.2.3. Examples . . . . . . . . . . . . . . . . . . . . . . . 6 64 3. Compression Efficiency . . . . . . . . . . . . . . . . . . . . 9 65 4. Augmented BNF Syntax for the COMPRESS Extension . . . . . . . 11 66 4.1. Commands . . . . . . . . . . . . . . . . . . . . . . . . . 11 67 4.2. Capability entries . . . . . . . . . . . . . . . . . . . . 11 68 4.3. General Non-terminals . . . . . . . . . . . . . . . . . . 11 69 5. Summary of Response Codes . . . . . . . . . . . . . . . . . . 12 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 72 7.1. NNTP Compression Algorithm Registry . . . . . . . . . . . 14 73 7.1.1. Algorithm Name Registration Procedure . . . . . . . . 14 74 7.1.2. Comments on Algorithm Registrations . . . . . . . . . 15 75 7.1.3. Change Control . . . . . . . . . . . . . . . . . . . . 15 76 7.2. Registration of the DEFLATE Compression Algorithm . . . . 16 77 7.3. Registration of the NNTP COMPRESS Extension . . . . . . . 16 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 79 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 80 8.2. Informative References . . . . . . . . . . . . . . . . . . 18 81 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 20 82 Appendix B. Document History (to be removed by RFC Editor 83 before publication) . . . . . . . . . . . . . . . . . 21 84 B.1. Changes since -00 . . . . . . . . . . . . . . . . . . . . 21 85 Appendix C. Issues to be addressed . . . . . . . . . . . . . . . 22 86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 88 1. Introduction 90 The goal of COMPRESS is to reduce the bandwidth usage of NNTP. 92 Compared to PPP compression [RFC1962] and modem-based compression 93 ([MNP] and [V42bis]), COMPRESS offers greater compression efficiency. 94 COMPRESS can be used together with Transport Layer Security (TLS) 95 [RFC5246], Simple Authentication and Security Layer (SASL) encryption 96 [RFC4422], Virtual Private Networks (VPNs), etc. 98 Compared to TLS compression [RFC3749], NNTP COMPRESS has the 99 following advantages: 101 o COMPRESS can be implemented easily both by NNTP servers and 102 clients. 104 o COMPRESS benefits from an intimate knowledge of the NNTP 105 protocol's state machine, allowing for dynamic and aggressive 106 optimization of the underlying compression algorithm's parameters. 108 and the following disadvantages: 110 o When the TLS layer implements compression, any protocol using that 111 layer can transparently benefit from that compression (e.g., SMTP 112 and NNTP). COMPRESS is specific to NNTP. 114 In order to increase interoperability, it is desirable to have as few 115 different compression algorithms as possible, so this document 116 specifies only one. The DEFLATE algorithm (defined in [RFC1951]) is 117 standard, widely available and fairly efficient, and MUST be 118 implemented as part of this extension. 120 1.1. Conventions Used in This Document 122 The notational conventions used in this document are the same as 123 those in [RFC3977] and any term not defined in this document has the 124 same meaning as in that one. 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in [RFC2119]. 130 In the examples, commands from the client are indicated with [C], and 131 responses from the server are indicated with [S]. 133 2. The COMPRESS Extension 135 The COMPRESS extension is used to enable data compression on an NNTP 136 connection. 138 This extension provides a new COMPRESS command and has capability 139 label COMPRESS. 141 2.1. Advertising the COMPRESS Extension 143 A server supporting the COMPRESS command as defined in this document 144 will advertise the "COMPRESS" capability label in response to the 145 CAPABILITIES command ([RFC3977] Section 5.2). This capability MAY be 146 advertised both before and after any use of the MODE READER command 147 ([RFC3977] Section 5.3), with the same semantics. 149 The COMPRESS capability label contains a whitespace-separated list of 150 available compression algorithms. This document defines one 151 compression algorithm: DEFLATE. This algorithm is mandatory to 152 implement and MUST be supported in order to advertise the COMPRESS 153 extension. 155 Future extensions may add additional compression algorithms to this 156 capability. Unrecognized algorithms MUST be ignored by the client. 158 Example: 160 [C] CAPABILITIES 161 [S] 101 Capability list: 162 [S] VERSION 2 163 [S] READER 164 [S] IHAVE 165 [S] COMPRESS DEFLATE X-SHRINK 166 [S] LIST ACTIVE NEWSGROUPS 167 [S] . 169 2.2. COMPRESS Command 171 2.2.1. Usage 173 This command MUST NOT be pipelined. 175 Syntax 176 COMPRESS algorithm 178 Responses 179 291 Compression active 180 403 Unable to activate compression 181 502 Command unavailable [1] 183 [1] If a compression layer is already active, COMPRESS is not a valid 184 command (see Section 2.2.2). 186 Parameters 187 algorithm = Name of compression algorithm: "DEFLATE" 189 2.2.2. Description 191 The COMPRESS command instructs the server to use the named 192 compression algorithm ("DEFLATE" is the only one defined in this 193 document) for all commands and/or responses after COMPRESS. 195 The client MUST NOT send any further commands until it has seen the 196 result of COMPRESS. 198 If the requested compression algorithm is invalid (e.g., is not 199 supported), the server MUST reject the COMPRESS command with a 503 200 response ([RFC3977] Section 3.2.1). If the server is unable to 201 activate compression for any reason (e.g., a server configuration or 202 resource problem), the server MUST reject the COMPRESS command with a 203 403 response ([RFC3977] Section 3.2.1). Otherwise, the server issues 204 a 291 response and the compression layer takes effect for both client 205 and server immediately following the CRLF of the success reply. 207 Both the client and the server MUST know if there is a compression 208 layer active. A client MUST NOT attempt to activate compression (via 209 either the COMPRESS or STARTTLS [RFC4642] commands) if a compression 210 layer is already active. A server MUST NOT return the COMPRESS or 211 STARTTLS capability labels in response to a CAPABILITIES command 212 received after a compression layer is active, and a server MUST reply 213 with a 502 response code if a syntactically valid COMPRESS or 214 STARTTLS command is received while a compression layer is already 215 active. 217 For DEFLATE [RFC1951] (as for many other compression mechanisms), the 218 compressor can trade speed against quality. The decompressor MUST 219 automatically adjust to the parameters selected by the sender. 220 Consequently, the client and server are both free to pick the best 221 reasonable rate of compression for the data they send. 223 When COMPRESS is combined with TLS [RFC5246] or SASL [RFC4422] 224 security layers, the processing order of the three layers MUST be 225 first COMPRESS, then SASL, and finally TLS. That is, before data is 226 transmitted it is first compressed. Second, if a SASL security layer 227 has been negotiated, the compressed data is then signed and/or 228 encrypted accordingly. Third, if a TLS security layer has been 229 negotiated, the data from the previous step is signed and/or 230 encrypted accordingly. When receiving data, the processing order 231 MUST be reversed. This ensures that before sending, data is 232 compressed before it is encrypted, independent of the order in which 233 the client issues the COMPRESS, AUTHINFO SASL [RFC4643], and STARTTLS 234 [RFC4642] commands. 236 2.2.3. Examples 238 Example of layering TLS and NNTP compression: 240 [C] CAPABILITIES 241 [S] 101 Capability list: 242 [S] VERSION 2 243 [S] READER 244 [S] STARTTLS 245 [S] AUTHINFO 246 [S] COMPRESS DEFLATE 247 [S] . 248 [C] STARTTLS 249 [S] 382 Continue with TLS negotiation 250 [TLS negotiation without compression occurs here] 251 [Following successful negotiation, all traffic is encrypted] 252 [C] CAPABILITIES 253 [S] 101 Capability list: 254 [S] VERSION 2 255 [S] READER 256 [S] AUTHINFO USER 257 [S] COMPRESS DEFLATE 258 [S] . 259 [C] AUTHINFO USER fred 260 [S] 381 Enter passphrase 261 [C] AUTHINFO PASS flintstone 262 [S] 281 Authentication accepted 263 [C] COMPRESS DEFLATE 264 [S] 291 Compression active 265 [From this point on, all traffic is compresssed before being encrypted] 267 Example of a server failing to activate compression: 269 [C] CAPABILITIES 270 [S] 101 Capability list: 271 [S] VERSION 2 272 [S] IHAVE 273 [S] COMPRESS DEFLATE 274 [S] . 275 [C] COMPRESS DEFLATE 276 [S] 403 Unable to activate compression 278 Example of attempting to use an unsupported compression algorithm: 280 [C] CAPABILITIES 281 [S] 101 Capability list: 282 [S] VERSION 2 283 [S] IHAVE 284 [S] COMPRESS DEFLATE 285 [S] . 286 [C] COMPRESS X-SHRINK 287 [S] 503 Compression algorithm not supported 289 Examples of a server refusing to compress twice: 291 [C] CAPABILITIES 292 [S] 101 Capability list: 293 [S] VERSION 2 294 [S] IHAVE 295 [S] STARTTLS 296 [S] COMPRESS DEFLATE 297 [S] . 298 [C] STARTTLS 299 [S] 382 Continue with TLS negotiation 300 [TLS negotiation with compression occurs here] 301 [Following successful negotiation, all traffic is protected by TLS] 302 [C] CAPABILITIES 303 [S] 101 Capability list: 304 [S] VERSION 2 305 [S] IHAVE 306 [S] . 307 [C] COMPRESS DEFLATE 308 [S] 502 Compression already active via TLS 310 [C] CAPABILITIES 311 [S] 101 Capability list: 312 [S] VERSION 2 313 [S] IHAVE 314 [S] STARTTLS 315 [S] COMPRESS DEFLATE 316 [S] . 317 [C] COMPRESS DEFLATE 318 [S] 291 Compression active 319 [From this point on, all traffic is compresssed] 320 [C] CAPABILITIES 321 [S] 101 Capability list: 322 [S] VERSION 2 323 [S] IHAVE 324 [S] . 325 [C] STARTTLS 326 [S] 502 DEFLATE compression already active 328 3. Compression Efficiency 330 This section is only informative. 332 NNTP poses some unusual problems for a compression layer. 334 Upstream traffic is fairly simple. Most NNTP clients send the same 335 few commands again and again, so any compression algorithm that can 336 exploit repetition works efficiently. The article posting and 337 transfer commands (e.g., POST, IHAVE, and TAKETHIS [RFC4644]) are an 338 exception; clients that send many article posting or transfer 339 commands may want to surround large multi-line data blocks with 340 flushes in the same way as is recommended for servers later in this 341 section. 343 Downstream traffic has the unusual property that several kinds of 344 data are sent, confusing all dictionary-based compression algorithms. 346 One type is NNTP simple responses and NNTP multi-line responses not 347 related to article header/body retrieval (e.g, CAPABILITIES, GROUP, 348 NEXT, STAT, DATE, NEWNEWS, LIST, OVER, CHECK [RFC4644], etc). These 349 are highly compressible; zlib using its least CPU-intensive setting 350 compresses typical responses to 25-40% of their original size. 352 Another type is article headers (as retrieved via the HEAD or ARTICLE 353 commands). These are equally compressible, and benefit from using 354 the same dictionary as the NNTP responses. 356 A third type is article body text (as retrieved via the BODY or 357 ARTICLE commands). Text is usually fairly short and includes much 358 ASCII, so the same compression dictionary will do a good job here, 359 too. When multiple messages in the same thread are read at the same 360 time, quoted lines, etc. can often be compressed almost to zero. 362 Finally, attachments (non-text article bodies retrieved via the BODY 363 and ARTICLE commands) are transmitted in encoded form, usually Base64 364 [RFC4648], UUencode [IEEE.1003-2.1992], or yEnc [yEnc]. 366 When attachments are retrieved, DEFLATE may be able to compress them, 367 but the format of the attachment's encoding is usually not NNTP-like, 368 so the dictionary built while compressing NNTP does not help. The 369 compressor has to adapt its dictionary from NNTP to the attachment's 370 encoding format, and then back. 372 When attachments are retrieved in Base64 or UUencode form, these 373 encodings add another problem. 8-bit compression algorithms such as 374 DEFLATE work well on 8-bit file formats, however both Base64 and 375 UUencode transform a file into something resembling 6-bit bytes, 376 hiding most of the 8-bit file format from the compressor. 378 When using the zlib library (see [RFC1951]), the functions 379 deflateInit2(), deflate(), inflateInit2(), and inflate() suffice to 380 implement this extension. The windowBits value must be in the range 381 -8 to -15, or else deflateInit2() uses the wrong format. 382 deflateParams() can be used to improve compression rate and resource 383 use. The Z_FULL_FLUSH argument to deflate() can be used to clear the 384 dictionary (the receiving peer does not need to do anything). 386 A server can improve downstream compression if it hints to the 387 compressor that the data type is about to change strongly, e.g., by 388 sending a Z_FULL_FLUSH at the start and end of large non-text multi- 389 line data blocks (before and after 'content-lines' in the definition 390 of 'multi-line-data-block' in [RFC3977] Section 9.8). Small multi- 391 line data blocks are best left alone. A possible boundary is 5kB. 393 4. Augmented BNF Syntax for the COMPRESS Extension 395 This section describes the syntax of the COMPRESS extension using 396 ABNF [RFC5234]. It extends the syntax in Section 9 of [RFC3977], and 397 non-terminals not defined in this document are defined there. The 398 [RFC3977] ABNF should be imported first before attempting to validate 399 these rules. 401 4.1. Commands 403 This syntax extends the non-terminal "command", which represents an 404 NNTP command. 406 command =/ compress-command 408 compress-command = "COMPRESS" WS algorithm 410 4.2. Capability entries 412 This syntax extends the non-terminal "capability-entry", which 413 represents a capability that may be advertised by the server. 415 capability-entry =/ compress-capability 417 compress-capability = "COMPRESS" *(WS algorithm) 419 4.3. General Non-terminals 421 algorithm = "DEFLATE" / token 423 5. Summary of Response Codes 425 This section contains a list of each new response code defined in 426 this document and indicates whether it is multi-line, which commands 427 can generate it, what arguments it has, and what its meaning is. 429 Response code 291 430 Generated by: COMPRESS 431 Meaning: Compression layer activated 433 6. Security Considerations 435 As for TLS compression [RFC3749]. 437 7. IANA Considerations 439 7.1. NNTP Compression Algorithm Registry 441 The NNTP Compression Algorithm registry will be maintained by IANA. 442 The registry will be available at 443 . 445 The purpose of this registry is not only to ensure uniqueness of 446 values used to name NNTP compression algorithms, but also to provide 447 a definitive reference to technical specifications detailing each 448 NNTP compression algorithm available for use on the Internet. 450 There is no naming convention for NNTP compression algorithms; any 451 name that conforms to the syntax of a NNTP compression algorithm name 452 can be registered. 454 The procedure detailed in Section 7.1.1 is to be used for 455 registration of a value naming a specific individual mechanism. 457 Comments may be included in the registry as discussed in 458 Section 7.1.2 and may be changed as discussed in Section 7.1.3. 460 7.1.1. Algorithm Name Registration Procedure 462 IANA will register new NNTP compression algorithm names on a First 463 Come First Served basis, as defined in BCP 26 [RFC5226]. IANA has 464 the right to reject obviously bogus registration requests, but will 465 perform no review of claims made in the registration form. 467 Registration of an NNTP compression algorithm is requested by filling 468 in the following template: 470 Subject: Registration of NNTP compression algorithm X 472 NNTP compression algorithm name: 474 Security considerations: 476 Published specification (recommended): 478 Contact for further information: 480 Intended usage: (One of COMMON, LIMITED USE, or OBSOLETE) 482 Owner/Change controller: 484 Note: (Any other information that the author deems relevant may be 485 added here.) 487 and sending it via electronic mail to IANA at . 489 While this registration procedure does not require expert review, 490 authors of NNTP compression algorithms are encouraged to seek 491 community review and comment whenever that is feasible. Authors may 492 seek community review by posting a specification of their proposed 493 mechanism as an Internet-Draft. NNTP compression algorithms intended 494 for widespread use should be standardized through the normal IETF 495 process, when appropriate. 497 7.1.2. Comments on Algorithm Registrations 499 Comments on a registered NNTP compression algorithm should first be 500 sent to the "owner" of the algorithm and/or to the 501 mailing list. 503 Submitters of comments may, after a reasonable attempt to contact the 504 owner, request IANA to attach their comment to the NNTP compression 505 algorithm registration itself by sending mail to . At 506 IANA's sole discretion, IANA may attach the comment to the NNTP 507 compression algorithm's registration. 509 7.1.3. Change Control 511 Once an NNTP compression algorithm registration has been published by 512 IANA, the author may request a change to its definition. The change 513 request follows the same procedure as the registration request. 515 The owner of an NNTP compression algorithm may pass responsibility 516 for the algorithm to another person or agency by informing IANA; this 517 can be done without discussion or review. 519 The IESG may reassign responsibility for an NNTP compression 520 algorithm. The most common case of this will be to enable changes to 521 be made to algorithms where the author of the registration has died, 522 has moved out of contact, or is otherwise unable to make changes that 523 are important to the community. 525 NNTP compression algorithm registrations may not be deleted; 526 algorithms that are no longer believed appropriate for use can be 527 declared OBSOLETE by a change to their "intended usage" field; such 528 algorithms will be clearly marked in the lists published by IANA. 530 The IESG is considered to be the owner of all NNTP compression 531 algorithms that are on the IETF standards track. 533 7.2. Registration of the DEFLATE Compression Algorithm 535 This section gives a formal definition of the DEFLATE compression 536 algorithm as required by Section 7.1.1 for the IANA registry. 538 NNTP compression algorithm name: DEFLATE 540 Security considerations: See Section 6 of this document 542 Published specification: This document 544 Contact for further information: Author of this document 546 Intended usage: COMMON 548 Owner/Change controller: IESG . 550 Note: This algorithm is mandatory to implement 552 7.3. Registration of the NNTP COMPRESS Extension 554 This section gives a formal definition of the COMPRESS extension as 555 required by Section 3.3.3 of [RFC3977] for the IANA registry. 557 o The COMPRESS extension allows an NNTP connection to be effectively 558 and efficiently compressed. 560 o The capability label for this extension is "COMPRESS", whose 561 arguments list the available compression algorithms. 563 o This extension defines one new command, COMPRESS, whose behavior, 564 arguments, and responses are defined in Section 2.2. 566 o This extension does not associate any new responses with pre- 567 existing NNTP commands. 569 o This extension does affect the overall behavior of both server and 570 client, in that after successful use of the COMPRESS command, all 571 communication is transmitted in a compressed format. 573 o This extension does not affect the maximum length of commands or 574 initial response lines. 576 o This extension does not alter pipelining, but the COMPRESS command 577 cannot be pipelined 579 o Use of this extension does alter the capabilities list; once the 580 COMPRESS command has been used successfully, the COMPRESS 581 capability can no longer be advertised by CAPABILITIES. 582 Additionally, the STARTTLS and MODE-READER capabilities MUST NOT 583 be advertised after successful execution of the COMPRESS command. 585 o This extension does not cause any pre-existing command to produce 586 a 401, 480, or 483 response. 588 o This extension is unaffected by any use of the MODE READER 589 command, however the MODE READER command MUST NOT be used in the 590 same session following a successful execution of the COMPRESS 591 command. 593 o The STARTTLS command MUST NOT be used in the same session 594 following a successful execution of the COMPRESS command. 596 o Published Specification: This document. 598 o Contact for Further Information: Author of this document. 600 o Change Controller: IESG . 602 8. References 604 8.1. Normative References 606 [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification 607 version 1.3", RFC 1951, May 1996. 609 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 610 Requirement Levels", BCP 14, RFC 2119, March 1997. 612 [RFC3977] Feather, C., "Network News Transfer Protocol (NNTP)", 613 RFC 3977, October 2006. 615 [RFC4642] Murchison, K., Vinocur, J., and C. Newman, "Using 616 Transport Layer Security (TLS) with Network News Transfer 617 Protocol (NNTP)", RFC 4642, October 2006. 619 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 620 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 621 May 2008. 623 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 624 Specifications: ABNF", STD 68, RFC 5234, January 2008. 626 8.2. Informative References 628 [IEEE.1003-2.1992] 629 Institute of Electrical and Electronics Engineers, 630 "Information Technology - Portable Operating System 631 Interface (POSIX) - Part 2: Shell and Utilities (Vol. 1)", 632 IEEE Standard 1003.2, 1992. 634 [MNP] Held, G., "The Complete Modem Reference", Second 635 Edition, Wiley Professional Computing, May 1994. 637 [RFC1962] Rand, D. and K. Fox, "The PPP Compression Control Protocol 638 (CCP)", RFC 1962, June 1996. 640 [RFC3749] Hollenbeck, S., "Transport Layer Security Protocol 641 Compression Methods", RFC 3749, May 2004. 643 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 644 Security Layer (SASL)", RFC 4422, June 2006. 646 [RFC4643] Vinocur, J. and K. Murchison, "Network News Transfer 647 Protocol (NNTP) Extension for Authentication", RFC 4643, 648 October 2006. 650 [RFC4644] Vinocur, J. and K. Murchison, "Network News Transfer 651 Protocol (NNTP) Extension for Streaming Feeds", RFC 4644, 652 October 2006. 654 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 655 Encodings", RFC 4648, October 2006. 657 [RFC4978] Gulbrandsen, A., "The IMAP COMPRESS Extension", RFC 4978, 658 August 2007. 660 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 661 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 663 [V42bis] International Telecommunications Union, "Data compression 664 procedures for data circuit-terminating equipment (DCE) 665 using error correction procedures", ITU-T Recommendation 666 V.42bis, January 1990. 668 [yEnc] Helbing, J., "yEnc - Efficient encoding for Usenet and 669 eMail", http://www.yenc.org. 671 Appendix A. Acknowledgements 673 This document draws heavily on ideas in [RFC4978] by Arnt Gulbrandsen 674 and a large portion of this text was borrowed from that 675 specification. 677 Special acknowledgement also goes to Julien Elie and others who 678 commented privately on intermediate revisions of this document. 680 Appendix B. Document History (to be removed by RFC Editor before 681 publication) 683 B.1. Changes since -00 685 o Made DEFLATE the mandatory to implement compression algorithm. 687 o Removed the requirement that clients/servers implementing COMPRESS 688 also implement TLS compression. 690 o Added an example of a client trying to use an unsupported 691 compression algorithm. 693 o Rewrote Compression Efficiency (Section 3) as follows: 695 * Included a sample listing of which NNTP commands produce which 696 type of data to be compressed. 698 * Removed discussion of attachments in binary form and 699 incompressible file formats. 701 * Mentioned UUencode and yEnc encoding of attachments. 703 o Added IANA registry of NNTP compression algorithms. 705 o Miscellaneous editorial changes submitted by Julien Elie. 707 Appendix C. Issues to be addressed 709 o What 2xx code should we use when compression is activated? 20x, 710 28x, 29x? 712 o Should we restrict the ABNF for compression algorithms? 714 Author's Address 716 Kenneth Murchison 717 Carnegie Mellon University 718 5000 Forbes Avenue 719 Cyert Hall 285 720 Pittsburgh, PA 15213 721 US 723 Phone: +1 412 268 2638 724 Email: murch@andrew.cmu.edu