[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