[NNTP] NNTP Compression

[Julien ÉLIE]

Hi Ken,

> I just submitted a rough I-D of NNTP COMPRESSION.  You can view it here until it 
> is posted:
>
> http://www.contrib.andrew.cmu.edu/~murch/draft-murchison-nntp-compress-00.html
>
> Obviously, I'm most interested in feedback on "Issues to be Addressed"


Oh, that was quick!  Thanks for your I-D proposal.  It looks very great!
Here are a few remarks.



> * What 2xx code should we use when compression is activated?
> 20x, 28x, 29x?

Well, I would suggest 20x.  Maybe 207?
Why?  Because Diablo and NNTPRelay answer 207 to MODE COMPRESS.

But can we re-use 207 here for COMPRESS when it is still used by Diablo 5.1-REL
nowadays for MODE COMPRESS?  Should it be documented?  (like MODE STREAM is
mentioned in RFC 4644)

Does MODE COMPRESS do the same thing as COMPRESS?  I see an explanation here:
    http://sedore.com/nntprelay/compressed-nntp-not.htm
but as I do not know zlib APIs, I am unsure it does the same thing.



> * Should failure to activate compression result in a 4xx or 5xx code?

4xx is for failure.  I think the suggested 403 is fine.



> * Do we need a special error code for an unknown compression algorithm?

I think the generic 503 response code is the best.  As it is done in RFC 4643:

   If the requested authentication mechanism is
   invalid (e.g., is not supported), the server rejects the AUTHINFO
   SASL command with a 503 reply (see Section 3.2.1 of [NNTP]).

   mechanism = 1*20mech-char
   mech-char = UPPER / DIGIT / "-" / "_"


Incidentally, it is true that RFC 4643 does not explicitly mention that
"AUTHINFO UNKNOWN" should return 501 (syntax error)...

Maybe we should define a syntax for a compression algorithm.  So that
we could know that "COMPRESS ALGO+" should lead to 501 (?)



> * Should we have separate 5xx codes when TLS compression is already
> active vs. when NNTP COMPRESS is already active?

I do not think so.  502 seems fine.



> * Do we setup an IANA registery of supported compression algorithms?
> I don't think we need/want more than DEFLATE.

I believe it would be proper.

I see these:
    <http://www.iana.org/assignments/http-parameters>
    (mentioned earlier by Russ)

    <http://www.iana.org/assignments/pgp-parameters/pgp-parameters.xhtml#pgp-parameters-15>

but I believe we would need one for NNTP.
Too bad there is not a global IANA registry for compression algorithms,
like the one for SASL mechanisms!  Why couldn't they create one?



> * The text referring to attachments needs work. Should we discuss yEnc
> and/or uuencode? I'm not sure the text regarding binary form even applies
> to NNTP.

When you say:

    > A very simple strategy is to change the level to 0 at the start of
    > a multi-line data block provided the first two bytes are either
    > 0x1F 0x8B (as in deflate-compressed files) or 0xFF 0xD8 (JPEG),
    > and to keep it at 1-5 the rest of the time.

It would apply to BODY only (at the start of a multi-line data block).
But we usually have a MIME message or yEnc.  Not a binary file.  (INN has
the XBATCH command that can send real binaries -- usually gzipped rnews
articles).

Maybe yEnc and uuencode should be mentioned, yes.

Besides, in Section 3 about compression efficiency, can another type
of data be mentioned?  I think about overview data (OVER), HDR and
LIST answers.  Maybe also NEWNEWS answers.



> Conventions Used in this Document

"This" with an uppercase letter?



> Transport Security Layer (TLS)

"Transport Layer Security".



> Simple Authentication and Security layer (SASL)

"Layer".



> In order to increase interoperability, it is desirable to have as few
> different compression algorithms as possible, so this document specifies
> only one.

Why couldn't we define several algorithms (some are more efficient than
DEFLATE, for instance LZMA or LZMA2) and say that DEFLATE *MUST* be
implemented when COMPRESS is implemented?
Also see my comment at the beginning of this mail.



> NNTP clients MAY use either COMPRESS or TLS compression, however, if the
> client and server support both, it is RECOMMENDED that the client choose
> TLS compression.

Could a reference to RFC 4642 (defining STARTTLS) be made here, in the
introduction?
I would also suggest a dot, or a semi-colon before "however".



> ([RFC3977] Section 5.2)
> ([RFC3977] section 5.3)

It should be homogenized.  I suggest:
(see Section x.x of [RFC3977])



> [1] If a compression layer is already active, COMPRESS is not a valid
>     command (see Section 2.2).

Section 2.2.2?



> a server MUST reply with a 502 response code if a COMPRESS or STARTTLS
> command is received while a compression layer is already active.

If a *syntactically valid* COMPRESS or STARTTLS command is received.



> When decompressing there isn't much of a tradeoff.
> That is, before data is transmitted it is first compressed.
> quoted lines etc. can often be compressed almost to zero

Comma after "decompressing", "transmitted", "lines".



> Second [...] Third
> independent of the order

Isn't it better to use "Secondly", "Thirdly"/"Finally", "independently of"?



> Example of a server failing to activate compression:
>
> [C] CAPABILITIES
> [S] 101 Capability list:
> [S] VERSION 2
> [S] COMPRESS DEFLATE
> [S] .

That example is weird:  a news server that requires compression to show
other commands.  Maybe IHAVE and STREAMING should also be advertised?
(case of a transit-only server)



> [C] CAPABILITIES
> [S] 101 Capability list:
> [S] VERSION 2
> [S] .

Similar remark.



> [C] COMPRESS DEFLATE
> [S] 291 Compression active
> [C] CAPABILITIES
> [S] 101 Capability list:
> [S] VERSION 2
> [S] .

Similar remark.
Besides, I think you should add the following comment after the 291 line:

[From this point on, all traffic is compresssed]



> A possible boundary is 5k.

Is it standard?  Not "5 kb" or something else?


Are there SASL mechanisms that negotiate a compression layer?  I think not,
but better ask...

-- 
Julien ÉLIE

« Boire du café empêche de dormir. Par contre, dormir empêche
  de boire du café. » (Philippe Geluck)