[NNTP] New draft for COMPRESS (-01)
julien at trigofacile.com
Sat Jan 30 13:28:21 PST 2010
Thanks for your new version.
Here are a few remarks, written in the order of appearance in the draft.
* o COMPRESS benefits from an intimate knowledge of the NNTP
protocol's state machine, allowing for dynamic and aggressive
optimization of the underlying compression algorithm's parameters.
Just a question: when we have a TLS negotiation with compression,
is it possible to change the parameters of the compression as we can
with COMPRESS? If that is not the case, it is better not to use
compression with TLS because it can be less efficient...
But is it possible to specify (in a parameter to a TLS library)
that STARTTLS has to only negotiate a security layer without compression?
(If that's the case, then we cannot say that STARTTLS is an invalid
command when a compression layer is already active.)
* [S] COMPRESS DEFLATE X-SHRINK
Maybe it should be said somewhere that arguments starting with X are
RFC 3977 mentions that only for labels (like COMPRESS):
As described in Section 3.3.3, labels beginning with
X are reserved for private use, while all other names are expected to
be associated with a specification in an RFC on the standards track
or defining an IESG-approved experimental protocol.
algorithm = Name of compression algorithm: "DEFLATE"
I think "DEFLATE" should be removed here. The parameter is now an
algorithm, and not necessarily "DEFLATE".
* If the server is unable to
activate compression for any reason (e.g., a server configuration or
resource problem), the server MUST reject the COMPRESS command with a
403 response ([RFC3977] Section 3.2.1).
Is it clear enough?
I hope people will not understand that 403 should be sent instead
of 480 (authentication), 483 (encryption), etc.
Maybe the sentence should said that it is 403 unless a more appropriate
generic response code can be used?
* a server MUST reply
with a 502 response code if a syntactically valid COMPRESS or
STARTTLS command is received while a compression layer is already
COMPRESS or STARTTLS *(if implemented)* command
Otherwise, it would be 500.
* [C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] COMPRESS DEFLATE
+ LIST ACTIVE NEWSGROUPS
It is mandatory with READER.
In the same example, AUTHINFO USER/PASS is used followed by COMPRESS.
Isn't it better to send again CAPABILITIES? The list may have
changed after AUTHINFO USER/PASS so it is best practice to send
CAPABILITIES again (even though COMPRESS is unlikely to be affected).
You could add POST in return of that new list.
See RFC 4643:
Other capabilities returned in response to a CAPABILITIES
command received after authentication MAY be different from those
returned before authentication.
* Examples of a server refusing to compress twice:
I think the wording should be different. Here, I am under the impression
that a news server can chose to accept or refuse to compress twice.
Maybe "Examples of attempting to compress twice"?
* encodings add another problem. 8-bit compression algorithms such as
Two spaces after the dot.
* 4.2. Capability entries
* algorithm = "DEFLATE" / token
I see that you suggest UTF-8 with the use of a token.
It is also one of your question. Well, I have no preference about that.
I'm fine with a token.
Couldn't other algorithms be defined now? Like LZS or LZMA2?
* name that conforms to the syntax of a NNTP compression algorithm name
* <iana at iana.org>
<ietf-nntp at lists.eyrie.org>
Is it safe (for permanence) to use such addresses?
* Owner/Change controller: IESG <iesg at ietf.org>.
Without a final dot. (Or all the others points should have one.)
* o This extension does not alter pipelining, but the COMPRESS command
cannot be pipelined
Final dot missing.
* the MODE READER command MUST NOT be used in the
same session following a successful execution of the COMPRESS
Shouldn't it also be mentioned in the main description of the COMPRESS
« Les mathématiques peuvent être définies comme une science
dans laquelle on ne sait jamais de quoi on parle, ni si ce qu'on dit
est vrai. » (Bertrand Russell)
More information about the ietf-nntp