[NNTP] Draft -03 for COMPRESS
Julien ÉLIE <julien@trigofacile.com> Fri, 10 June 2016 20:43 UTC
Return-Path: <ietf-nntp-bounces+nntpext-archive=ietf.org@lists.eyrie.org>
X-Original-To: ietfarch-nntpext-archive@ietfa.amsl.com
Delivered-To: ietfarch-nntpext-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6118A12D943 for <ietfarch-nntpext-archive@ietfa.amsl.com>; Fri, 10 Jun 2016 13:43:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.325
X-Spam-Level:
X-Spam-Status: No, score=-2.325 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_HOME=1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPDOHvFzB3f6 for <ietfarch-nntpext-archive@ietfa.amsl.com>; Fri, 10 Jun 2016 13:43:12 -0700 (PDT)
Received: from hope.eyrie.org (hope.eyrie.org [IPv6:2001:470:30:84:e276:63ff:fe62:3535]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 780E212D734 for <nntpext-archive@ietf.org>; Fri, 10 Jun 2016 13:43:11 -0700 (PDT)
Received: from hope.eyrie.org (localhost [IPv6:::1]) by hope.eyrie.org (Postfix) with ESMTP id 96C6167D16 for <nntpext-archive@ietf.org>; Fri, 10 Jun 2016 13:43:10 -0700 (PDT)
X-Original-To: ietf-nntp@lists.eyrie.org
Delivered-To: ietf-nntp@lists.eyrie.org
Received: from smtp.smtpout.orange.fr (smtp07.smtpout.orange.fr [80.12.242.129]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by hope.eyrie.org (Postfix) with ESMTPS id E65F867D07 for <ietf-nntp@lists.eyrie.org>; Fri, 10 Jun 2016 13:43:06 -0700 (PDT)
Received: from macbook-pro-de-julien-elie.home ([92.170.5.52]) by mwinf5d42 with ME id 58j41t00A17Lgi4038j5iu; Fri, 10 Jun 2016 22:43:05 +0200
X-ME-Helo: macbook-pro-de-julien-elie.home
X-ME-Auth: anVsaWVuLmVsaWVAd2FuYWRvby5mcg==
X-ME-Date: Fri, 10 Jun 2016 22:43:05 +0200
X-ME-IP: 92.170.5.52
To: ietf-nntp@lists.eyrie.org
From: Julien ÉLIE <julien@trigofacile.com>
Organization: TrigoFACILE -- http://www.trigofacile.com/
Message-ID: <4f965bda-00f7-cd34-3697-2b1ae0350576@trigofacile.com>
Date: Fri, 10 Jun 2016 22:43:04 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Subject: [NNTP] Draft -03 for COMPRESS
X-BeenThere: ietf-nntp@lists.eyrie.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: NNTP protocol discussion <ietf-nntp.lists.eyrie.org>
List-Unsubscribe: <https://lists.eyrie.org/mailman/options/ietf-nntp>, <mailto:ietf-nntp-request@lists.eyrie.org?subject=unsubscribe>
List-Archive: <https://lists.eyrie.org/pipermail/ietf-nntp/>
List-Post: <mailto:ietf-nntp@lists.eyrie.org>
List-Help: <mailto:ietf-nntp-request@lists.eyrie.org?subject=help>
List-Subscribe: <https://lists.eyrie.org/mailman/listinfo/ietf-nntp>, <mailto:ietf-nntp-request@lists.eyrie.org?subject=subscribe>
Errors-To: ietf-nntp-bounces+nntpext-archive=ietf.org@lists.eyrie.org
Sender: ietf-nntp <ietf-nntp-bounces+nntpext-archive=ietf.org@lists.eyrie.org>
Hi all, As you may already know, TLS-level compression is no longer possible in TLS 1.2 whereas NNTP was relying on this feature provided by previous TLS versions to compress data. We agreed that the right move was to standardize a new NNTP command. It is what we finally did with the COMPRESS extension. Interoperability is proven: two news servers (INN, Cyrus NNTP) and a news client (flnews) have already implemented it. It also works fine with Python nntplib+zlib libraries. Here is the latest version of the draft: https://tools.ietf.org/html/draft-murchison-nntp-compress-03 If you have any comments, please don't hesitate to tell. Changes since -02: o Added text stating that the receiving end SHOULD terminate the connection when receiving invalid or corrupted compressed data. o Explained why COMPRESS permits to do better than existing unstandardized commands like XZVER, XZHDR, MODE COMPRESS, and XFEATURE GZIP. o The LIST capability label was missing in the examples when READER was also advertised. o Improved an example to send CAPABILITIES after successful authentication. o Mentioned that COMPRESS is related to security. CAPABILITIES is therefore sent again after COMPRESS. o Re-added discussion of attachments in binary form and incompressible file formats. Improve the discussion about flushes, and add a specific section about DEFLATE. o Change a MUST NOT to SHOULD NOT for the use of AUTHINFO after COMPRESS. o Algorithm names are case-insensitive. o Mentioned the use of the 501 response code. o Added the Security Considerations Section. o Added Julien Elie as co-author of this document. o Minor editorial changes. Issues to be addressed o How are TLS (and SASL) specific exchanges supposed to be handled? Should it be mentioned in the RFC that they are outside the scope of NNTP compression? (I speak of stuff like TLS handshakes, renegotiations, etc. that can occur after the use of COMPRESS. OpenSSL may use SSL_read/SSL_write on its own, mayn't it? And it does not know that it should compress data...) => Question asked to the UTA and TLS IETF WG. But in case you have an idea of response, you can of course give it. o Anything to add to the Security Considerations section? Whom should we get a review from? o Should we add a naming convention for private compression algorithms? (I am unsure that saying it begins with "X" is a good idea, though; we may one day see a standardized compression algorithm with such a name - XZ for instance, though LZMA2 would be its real name.) => Suggestion of not enforcing any naming convention (except that the name complies with the syntax of 20 alphanumeric chars, "-" and "_"). We've asked IANA to create a registry for compression algorithms. If you have any comment about the registration procedure, please tell. Notably, this IETF NNTP mailing-list is explicitly mentioned in Section 7.1.2. 7.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 perform no review of claims made in the registration form. 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>: Subject: Registration of NNTP compression algorithm X 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 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 mechanism as an Internet-Draft. NNTP compression algorithms intended for widespread use should be standardized through the normal IETF process, when appropriate. 7.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 <ietf-nntp@lists.eyrie.org> mailing list. Submitters of comments may, after a reasonable attempt to contact the owner, 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. 7.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; 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. Thanks again for your useful comments! -- Julien ÉLIE « Pourvu que ça dure ! » (Letizia Bonaparte)
- Re: [NNTP] Draft -03 for COMPRESS Julien ÉLIE
- [NNTP] Draft -03 for COMPRESS Julien ÉLIE
- Re: [NNTP] Draft -03 for COMPRESS Julien ÉLIE