Subject: [NNTP] NNTP Compression

From: Ken Murchison <[email-masked]>
Date: Thu, 07 Jan 2010 16:49:55 -0500

I mentioned this to Russ earlier today and was informed that there has 
been ietf-nntp list traffic on just such a topic.  I was unaware because 
I think I had somehow become unsubscribed to the list, or the messages 
sent to me were going into the bit-bucket.

I just read the list traffic, and IMHO doing this on a per-command basis 
is a non-starter.  I think doing this at the protocol level (or below) 
makes the most sense.  There are two ways to do this, either leverage 
the existing TLS compression, or add an NNTP command which enables its 
own compression.  I have been scolded in the past for suggesting that 
every site implement TLS because of the overhead, so an NNTP command 
seems to make the most sense here.

Below is the spec that the Lemonade WG did for IMAP and I think 
something similar would work for NNTP.  This could work for 
Client->Server traffic and/or Peer->Peer traffic.  I'd be willing to 
write up an I-D if folks think it would be useful.  Cyrus IMAP and 
Mozilla T-Bird v3 both support it and it works great.

http://tools.ietf.org/html/rfc4978

FYI, since all of our components in Cyrus use the same low-level 
protocol I/O layer (plaintext, TLS, SASL, COMPRESS=DEFLATE), I can have 
both a client and server NNTP implementation available in about 5min.

-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University

---

From: Julien ÉLIE <[email-masked]>
Date: Sat, 9 Jan 2010 22:52:44 +0100

Hi Ken,

> Below is the spec that the Lemonade WG did for IMAP and I think something similar would work for NNTP.  This could work for 
> Client->Server traffic and/or Peer->Peer traffic.  I'd be willing to write up an I-D if folks think it would be useful.  Cyrus 
> IMAP and Mozilla T-Bird v3 both support it and it works great.
>

I think it would be useful to have a similar capability for NNTP.

As it was noted in the previous discussion, clients may want to
use compression only for a few commands.  Wouldn't it be wise
to have an NNTP command that can both activate and deactivate
the compression?

For instance:

[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] AUTHINFO USER SASL
[S] COMPRESS DEFLATE LZMA LZMA2
[S] HDR
[S] LIST ACTIVE COUNTS HEADERS NEWSGROUPS OVERVIEW.FMT
[S] OVER
[S] READER
[S] SASL GSSAPI OTP PLAIN NTLM LOGIN DIGEST-MD5 CRAM-MD5
[S] STARTTLS
[S] .
[C] COMPRESS LZMA2 ON
[S] 202 Let's talk compressed
-- now compressed --
[C] LIST COUNTS
[S] 215 List of newsgroups follows
[S] misc.test 3002322 3000234 1234 y
[S] .
[C] LIST NEWSGROUPS
[S] 215 List of descriptions follows
[S] misc.test General Usenet testing
[S] .
[C] GROUP misc.test
[S] 211 1234 3000234 3002322 misc.test
[C] OVER 3000234-3002322
[S] 224 Overview information follows
...
[S] .
[C] COMPRESS LZMA2 OFF
[S] 202 Let's talk uncompressed
-- now uncompressed --
[C] ARTICLE 3000234
[S] 220 3000234 <[email-masked]>
...
[S] .
[C] ARTICLE 3000235
...

Note that the syntax is just a suggestion and can be criticized.
I do not know what is the right second digit in the answer.
8 is for authentication and privacy.  So it may be 0?
Or create a meaning for 7?

I see that RFC 4978 (COMPRESS for IMAP) defines strategies
to find out incompressible attachments but it may not always
be possible to be sure we do not have to compress (yEnc articles,
base64 articles, etc.).  So maybe clients may want to retrieve
articles always uncompressed?
Perhaps the response code should be different for ON/OFF.

If we do not support OFF, then STARTCOMPRESSED or something similar
would be a better name because we already have STARTTLS.

> FYI, since all of our components in Cyrus use the same low-level protocol I/O layer (plaintext, TLS, SASL, COMPRESS=DEFLATE), I 
> can have both a client and server NNTP implementation available in about 5min.

That's great!

-- 
Julien ÉLIE

« -- Essayons d'interroger ce garde habilement sans éveiller ses soupçons...
  -- Hep ! Où est enfermé Assurancetourix ? » (Astérix)

---

From: Ade Lovett <[email-masked]>
Date: Sun, 10 Jan 2010 02:03:30 -0800

> to have an NNTP command that can both activate and deactivate

From a server perspective, absolutely not.  Switching in and out of compression state is simply insane.  Those clients likely to be wanting to use both compressed and uncompressed streams simultaneously will almost certainly already be opening up multiple connections to the server endpoint, and thus can coordinate accordingly.

Quite frankly, compression for NNTP in this day an age is a solution looking for a problem.  The heavy downloading is coming off of already compressed data, and we're really not sitting at the end of 300baud teletypes for reading text.  Implement a 'ok, I want the session to be compressed/encrypted/whatever until it dies' option if you will, but switching back and forth?  Madness.  Not to mention, pointless.

-aDe

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Sun, 10 Jan 2010 10:41:07 +0000

> From a server perspective, absolutely not.  Switching in and out of compression state is simply insane.  Those clients likely to be wanting to use both compressed and uncompressed streams simultane…

From where I'm sitting, which is at this very moment trying to find a portable way to implement a version of the GigaNews Accelerator (I'll call it "GigaNoise"), it would be most welcome!  As it stands, I have to track what state the client and server are in, filter out capabilities, and whatnot, and all because the compression isn't clearly and obviously negotiated, and at what point I'll be getting compressed versus regular output (ARTICLE, for example, is still sent uncompressed).  And I'm not sure precisely what it is about toggling compression that's so terrible, because you haven't explained it.

> Quite frankly, compression for NNTP in this day an age is a solution looking for a problem.  The heavy downloading is coming off of already compressed data, and we're really not sitting at the end…

Look, I just spent half an hour downloading the headers of alt.binaries.cd.image.  I just reassured myself that the 400+ MB of raw XOVER information could, in fact, be reduced to the about 55MB that zlib deflate offers, and that it cuts the download time to about a tenth.  I'm sorry, mate, but you aren't telling me, now, that I can't find a use for this feature.  I will not wait another second for my newsreader to download uncompressed, easily-compressed article headers when my CPU can probably burn the entire compressed stream while it's being held in memory!!!

Ironically, the only time I don't consider compression is when I'm on my 400MHz Pentium-II box; then the overhead of decompression fails utterly to overtake the raw 20mbit connection I have here (of which probably only a fraction is used, both because of my ISP's utter failure to deliver as promised and because of basic properties of TCP).

I will paste the Tcl script that did the tests.  Try it for yourself.  It writes the XOVER output to stdout.  Modify to fit your GigaNews account.  Uncomment the lines that send and get the compression feature negotiation to enable it.  Run with and without compression, use time.  Compare the data sizes and times.  They will speak for themselves.

Cheers,
Sabahattin

#!/usr/bin/tclsh
set sock [socket news-europe.giganews.com 80]
# Remove "-europe" above if in US
fconfigure $sock -encoding binary -translation crlf -buffering none
gets $sock
puts $sock "authinfo user gn453599"
gets $sock
puts $sock "authinfo pass xxxxxxxx"
gets $sock
# Uncomment to enable compression
#puts $sock "xfeature compress gzip"
#gets $sock
puts $sock "group alt.binaries.cd.image"
gets $sock
puts $sock "xover 1-"
puts stderr [gets $sock]
# This means there's a very small trailer, ignored for stats for simplicity's sake to avoid nonblocking complexity
puts $sock quit
fconfigure stdout -buffering none -encoding binary -translation crlf
puts -nonewline [read $sock]

---

From: Ade Lovett <[email-masked]>
Date: Sun, 10 Jan 2010 04:16:37 -0800

On Jan 10, 2010, at 02:41 , Sabahattin Gucukoglu wrote:
> From where I'm sitting, which is at this very moment trying to find a portable way to implement a version of the GigaNews Accelerator (I'll call it "GigaNoise"), it would be most welcome!  As it stands, I have to track what state the client and server are in, filter out capabilities, and whatnot, and all because the compression isn't clearly and obviously negotiated, and at what point I'll be getting compressed versus regular output (ARTICLE, for example, is still sent uncompressed).

That would be an issue you would need to take up with your NSP of choice, and not relevant to protocol discussion.

> And I'm not sure precisely what it is about toggling compression that's so terrible, because you haven't explained it.

Simplicity.  Either a stream is negotiated compressed, or it isn't.  You mention having to track state as being an issue, now view that from the point of view of a server farm, dealing with tens of thousands of simultaneous connections, potentially flipping in and out of compression.  Why?  You have, essentially, unlimited connections, so use a couple for compression, and the rest normal.  Trivial state tracking on both ends.  If it is needed ...

> Look, I just spent half an hour downloading the headers of alt.binaries.cd.image.  I just reassured myself that the 400+ MB of raw XOVER information could, in fact, be reduced to the about 55MB that zlib deflate offers, and that it cuts the download time to about a tenth.  I'm sorry, mate, but you aren't telling me, now, that I can't find a use for this feature.

Sure you can.  In the degenerate case of exceptionally large binary groups, use one of the many indexer sites out there, pull the NZB file, and pull down the articles via message ID that you actually want.  Or autogenerate the DMCA takedown notice from the NZB file (code available on request for the right price).

> Ironically, the only time I don't consider compression is when I'm on my 400MHz Pentium-II box; then the overhead of decompression fails utterly to overtake the raw 20mbit connection I have here (o…

And this is where we go back to the age old "server vs client author wars" :)  Whilst I'm sure your home system has more than enough capability to hold terabytes of data, with on-the-fly compression, for _home_ needs, scale that up to what you're talking to on the other end, and it becomes non-trivial very very quickly.

> I will paste the Tcl script that did the tests.

Sadly, irrelevant.

1.  Show a _real_world_ case, of relevance to the protocol in its entirety, and not a subset, where compression is useful at all, given the major burden it will put on the server side.

2.  Show a case why compression (in whatever form) should be able to be toggled within a single stream.

-aDe

---

From: Antti-Juhani Kaijanaho <[email-masked]>
Date: Sun, 10 Jan 2010 15:03:16 +0200

On Sun, Jan 10, 2010 at 04:16:37AM -0800, Ade Lovett wrote:
> Simplicity.  Either a stream is negotiated compressed, or it isn't.  You
> mention having to track state as being an issue, now view that from the point
> of view of a server farm, dealing with tens of thousands of simultaneous
> connections, potentially flipping in and out of compression.

Sounds like the on/off-switch should be optional, if included at all.
Making it optional would allow a server farm not implement it, while allowing
smaller servers to implement it, no?

-- 
Antti-Juhani Kaijanaho, Jyväskylä, Finland
http://antti-juhani.kaijanaho.fi/newblog/
http://www.flickr.com/photos/antti-juhani/

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Sun, 10 Jan 2010 14:18:25 +0000

> That would be an issue you would need to take up with your NSP of choice, and not relevant to protocol discussion.

The details of Giganews' implementation are indeed an issue for Giganews, the point that I made, which was that simple negotiation is better than non-simple negotiation, makes sense in protocol discussion.  This simply takes needless logic of the "Upper layer" out of the discussion (though if compression ever happens it will probably mean servers have to restrict how it's used, so there'll probably have to be some way to tell the client what is and isn't acceptable).  Even then there are flip sides to this, as we know from SASL, mostly relating to post-negotiation logic.  Usual trials, usual tribulations.  But in any case it was just an illustration of how keeping state out of it is a good thing, and nothing's been set in stone yet.  I just think that when multiple NSPs do it differently, we better pay attention.

> Simplicity.  Either a stream is negotiated compressed, or it isn't.  You mention having to track state as being an issue, now view that from the point of view of a server farm, dealing with tens of…
I can disable compression as easily as I enable it.  So can servers, which already manage countless clients' states.  This is an issue of implementation, not protocol design.  You can choose not to support the features if it hurts to do so.  I merely insist that the state tracking be straightforward, not requiring advance knowledge of when to expect compression and when not to and other such unspecified nonsense.  Perhaps it could be as simple as returning separate response codes to indicate whether the data following is compressed or not.

> Sure you can.  In the degenerate case of exceptionally large binary groups, use one of the many indexer sites out there, pull the NZB file, and pull down the articles via message ID that you actual…
You're right, of course, that was just a convenient example -- but you're still passing the buck to suggest it only applies to binary groups.  It doesn't, in fact, since there are often as many retained articles on heavy text groups, retained for longer because their size allows for it.  In any event, it's a failure case that can be addressed using compression.

> And this is where we go back to the age old "server vs client author wars" :)  Whilst I'm sure your home system has more than enough capability to hold terabytes of data, with on-the-fly compressio…
I have minimal storage requirements and fairly low-end hardware, because most of my subscriptions are text groups, and until recently I wasn't in for large, modern disks.  I'm almost not on fortunate income, and subscribe to the lowest tier my NSP offers.  My NSP, on the other hand, is still looking for customers (many of them ISPs or x-ISP customers whose original Usenet service forsook them) because all the binaries it carries, plus the support that it has for compressing headers, apparently doesn't bother it in the least.  It keeps getting bigger and hungrier and more aggressive, it consistently maintains its top spot on top1000.org, it's always favourite among the binary downloader darlings - in short, it defies anybody (and I know how much of an advertisement this is turning into) to challenge its storage and CPU requirements by suggesting that it is incapable of selling what it markets at premium prices. :-)

> 2.  Show a case why compression (in whatever form) should be able to be toggled within a single stream.

I think these are answered by the above, except to note that GigaNews only does compression on headers, not article bodies.  The toggling is thus implicit, and probably more optimal than an across-the-board compression.  However, we need a simple, uniform way to control compression, and a simple way to get the client and server to agree on what and when, perhaps under the server's control using return codes (as above).

Cheers,
Sabahattin

---

From: Ken Murchison <[email-masked]>
Date: Sun, 10 Jan 2010 15:26:05 -0500

> to have an NNTP command that can both activate and deactivate

I don't think its worth the trouble.  A client could just open another 
NNTP session without activating COMPRESSion.

> articles always uncompressed? 

There are strategies to both determine if the compression level should 
be set to zero (for JPEG, GZIP, etc) attachments, and to reset the 
dictionary (OVER response looks much different from multi-line BODY 
response).

---

From: Ken Murchison <[email-masked]>
Date: Thu, 21 Jan 2010 17:57:38 -0500

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"

---

From: Julien ÉLIE <[email-masked]>
Date: Fri, 22 Jan 2010 22:51:10 +0100

Hi Ken,

> I just submitted a rough I-D of NNTP COMPRESSION.  You can view it here until it 
> is posted:
>

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)

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

---

From: Ken Murchison <[email-masked]>
Date: Sat, 23 Jan 2010 11:29:47 -0500

> but as I do not know zlib APIs, I am unsure it does the same thing.

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.

> It would apply to BODY only (at the start of a multi-line data block).

It would also apply to ARTICLE, POST, IHAVE, TAKETHIS.

> But we usually have a MIME message or yEnc.  Not a binary file.

Correct, so this text can probably be removed.  IMAP has the ability to 
fetch individual MIME parts, and an extension to do so with any CTE 
stripped.

> Maybe yEnc and uuencode should be mentioned, yes.

yEnc and uuencode most likely would be similar to base64 in terms of how 
to handle them.

> LIST answers.  Maybe also NEWNEWS answers.

All NNTP data other than large article bodies fall into the same 
category, so I don't think we need to mention all of them specifically.

> 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.

> 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.

> (case of a transit-only server)

Yes, you're right.  I was trying to keep extra clutter out of the 
examples, but I do need to add reader and/or feeder commands.

> Are there SASL mechanisms that negotiate a compression layer?  I think not,

No currently.  Again, TLS is the preferred method for negotiating 
compression.

---

From: Julien ÉLIE <[email-masked]>
Date: Sun, 24 Jan 2010 01:23:06 +0100

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.

> 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!

> 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.

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

---

From: Ken Murchison <[email-masked]>
Date: Mon, 25 Jan 2010 12:04:50 -0500

Julien ÉLIE wrote:
>> 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.
> 

I'm not saying that we can't still use 207, since the client knows 
whether it sent MODE COMPRESS or COMPRESS DEFLATE.

---

From: Antti-Juhani Kaijanaho <[email-masked]>
Date: Mon, 25 Jan 2010 19:19:31 +0200

> I believe it would be proper.

I believe so, too.

If you have an argument for a command, it suggests extensibility, and
extensibility by keywords suggests a registry.  An conversely, if a registry
makes no sense, perhaps the keyword-argument should be the command.

IIRC, an IANA registry can be extremely conservative in what it accepts, if it
wants to.