[NNTP] Compressed LIST (and other commands) answers

Ade Lovett ade at lovett.com
Wed Dec 2 01:35:27 PST 2009


On Dec 01, 2009, at 17:25 , Jeffrey M. Vinocur wrote:
> A third (probably also bad) option would be to have something like "MODE
> COMPRESS" that a client could send, after which the semantics of
> multi-line responses would change (i.e. instead of just dot stuffing, 
> the server/client would apply a more complex transformation) but all of 
> the commands and response codes could stay the same.

As you said, "bad".  This would be an utter nightmare to implement.

>> I have a vague memory that we discussed this during the development of
>> 3977, and decided that this was the direction to go. In additon, TLS
>> already does compression, so we don't even need to invent anything.
> 
> I agree in princple, but am curious where this stands in terms of SASL 
> which should be our long-term framework -- Ken, do you have any thoughts?

If we _really_ want compression, then it should be here, in SASL, where things are relatively well-defined, as opposed to trying to retrofit something into a _very_ simple protocol (NNTP).

> Hmmm doesn't HTTP have a way to do encryption within the protocol (as a 
> content encoding or something?) that is fairly widely used?

Yes, but that's done at a layer above generic-HTTP.  Pass some magic keywords around in the initial request, and assuming the server understands them, everything goes compressed.

The _key_ point here is that HTTP itself says _nothing_ about compression, it's up to a handshake between client and server to then decide to talk in compressed bits as opposed to regular 1's and 0's.

So, if someone wants to come up with an overlay concept whereby a modified client + server starts talking compressed for some or all of the transaction, I'm all for it.

However, it SHOULD NOT (in the RFC terminology) be part of the protocol itself.

-aDe



More information about the ietf-nntp mailing list