[NNTP] NNTP Compression

[Julien ÉLIE]

Hi Ken,

> I'd have to look at the zlib docs and the actual Diablo code (which I have no 
> desire to do), but tt looks like MODE COMPRESS is actually putting a gzip header 
> on each chunk of compressed data.  The COMPRESS command as standardized by 
> IMAP/NNTP COMPRESS doesn't bother putting an unnecessary header on the data. 
> That's why IMAP/NNTP COMPRESS uses [de|in]flatInit2() calls rather than the 
> simpler [de|in]flateInit(), so it can specify more params rather than using 
> defaults.

OK, then it is better not to use what Diablo implemented.



>> 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).
>
> It would also apply to ARTICLE, POST, IHAVE, TAKETHIS.

My point was that only BODY was concerned by the strategy to check
the first two bytes at the start of a multi-line data block.
Because ARTICLE, HEAD, POST, IHAVE, and TAKETHIS all begin with headers
and headers are not binaries!



>> 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?
>
> Well, IMAP/NNTP COMPRESS are really just stop-gaps until existing TLS 
> implementations support compression.  As mentioned in the text TLS really should 
> be the preferred way to negotiate compression.  So I don't see the need to add 
> more algorithms to NNTP COMPRESS.

So it would imply that peers also use TLS in order to compress articles.
That's not usual practice at all...  While a better algorithm like LZMA2
could be worthwile for peers to send articles.  They do not need TLS and
its overhead.



>> Second [...] Third
>> independent of the order
>>
>> Isn't it better to use "Secondly", "Thirdly"/"Finally", "independently of"?
>
> This text was already approved by the LEMONADE WG and the RFC editor, so I don't 
> see any need to change it.

OK, if both of these expressions are equivalent, I'm fine with that.  I thought
"secondly" and "independently of" were more fluent than "second" and
"independent of", but as you know, I am not an example in English :)



> TLS is the preferred method for negotiating compression.

All right.

-- 
Julien ÉLIE

« -- Maintenant les Romains sont alertés.
  -- En tout cas, ceux-là ne sont plus très alertes ! » (Astérix)