[NNTP] New draft for COMPRESS (-01)

[Julien ÉLIE]

Hi Ken,

> http://www.ietf.org/internet-drafts/draft-murchison-nntp-compress-01.txt


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



*  Parameters
      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
   active.

COMPRESS or STARTTLS *(if implemented)* command
Otherwise, it would be 500.



* [C] CAPABILITIES
  [S] 101 Capability list:
  [S] VERSION 2
  [S] READER
  [S] STARTTLS
  [S] AUTHINFO
  [S] COMPRESS DEFLATE
  [S] .

+ 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

Uppercase letter.



* 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

"an NNTP".



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

Shouldn't it also be mentioned in the main description of the COMPRESS
command?

-- 
Julien ÉLIE

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