[NNTP] Draft -03 for COMPRESS

Julien ÉLIE julien at trigofacile.com
Fri Jun 10 13:43:04 PDT 2016


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 at 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 at 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 at 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)


More information about the ietf-nntp mailing list