Subject: Re: [NNTP] Draft -03 for COMPRESS

From: Julien ÉLIE <[email-masked]>
Date: Sat, 23 Jul 2016 23:10:51 +0200

Hi all,

> As you may already know, TLS-level compression is no longer possible in
> TLS 1.3 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

Now in -05 version:
     https://tools.ietf.org/html/draft-murchison-nntp-compress-05

If you have any comments, please don't hesitate to tell.

Changes since -04

    o  Reworded a sentence wrongly using "MAY NOT" (not a key word
       defined in [RFC2119]).

    o  Uppercased a "must" and a "should" in Section 3.1.

Changes since -03

    o  Added a naming convention for NNTP compression algorithms.
       Improve the wording of registered vs private compression
       algorithms.

    o  If a registered NNTP compression algorithm is advertised, it MUST
       fully conform with its related specification.

    o  Fixed the wording of security considerations to reflect that the
       threat appears when public and confidential data are compressed
       together inside a security layer.  Thanks to Angel Gonzalez for
       pointing that.

    o  The default configuration SHOULD be disabled compression when a
       security layer is active.

    o  COMPRESS acts as a compression layer, not a transport layer.

    o  Minor editorial changes.

-- 
Julien ÉLIE

« – Tu n'as rien remarqué d'étrange chez cet Arverne ?
   – Oui, son accent. » (Astérix)