Re: [NNTP] New draft for COMPRESS (-01)

Julien =C9LIE wrote:
> Hi Ken,
>=20
>>   A server MUST NOT return the COMPRESS or
>>   STARTTLS capability labels in response to a CAPABILITIES command
>>   received after a compression layer is active, and a server MUST repl=
y
>>   with a 502 response code if a syntactically valid COMPRESS or
>>   STARTTLS command is received while a compression layer is already
>>   active.
>=20
> I think it is too strong and that STARTTLS may be returned by a server
> that knows it can negotiate a TLS layer without compression.
>=20
> See for instance in OpenSSL 1.0.0 (yes, the new upcoming version):
>=20
>  *) New option SSL_OP_NO_COMP to disable use of compression selectively
>     in SSL structures.  New SSL ctrl to set maximum send fragment size.
>     Save memory by seeting the I/O buffer sizes dynamically instead of
>     using the maximum available value.
>     [Steve Henson]
>=20
>=20
> So a news server can decide to return STARTTLS if SSL_OP_NO_COMP
> is available.  Otherwise, it does not return it after a successful
> use of COMPRESS.

The problem is that whether or not TLS compression is supported and/or=20
it can be dynamically [en|dis]abled and/or the compression parameters=20
can be dynamically changed is completely dependent on the TLS=20
implementation.  I don't want, nor do I think we should, write a=20
specification that has different rules depending on what capabilities=20
the TLS implementation possesses.

The IMAP COMPRESS spec has a simpler rule in that COMPRESS can only be=20
used after authentication.  Since TLS, if used, MUST occur before=20
authentication, it also MUST occur before COMPRESS.  I'm trying to=20
follow the same principal with NNTP COMPRESS, but the fact that=20
authentication isn't required makes things difficult.

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