Hi John,
To move the discussion along, here's a draft for the CDAT compressed
data command.
https://datatracker.ietf.org/doc/draft-levine-smtp-compress/?include_text=1
I see that the draft has recently expired. Are there any news about it?
In case a -01 version is scheduled, I would like to point out a fairly
recent updated draft regarding the COMPRESS extension for NNTP:
https://tools.ietf.org/html/draft-murchison-nntp-compress-05
Section 3 about "Compression Efficiency" may be of interest, especially
if you wish to add something like that in your draft.
Of course Section 6 about "Security Considerations" could also be a
useful source of inspiration for SMTP (notably the advice not to
compress two different messages together, so as not to possibly leak
information about them, as they should be considered "private"). You
could say it explicitly: when you have an end-marker (LAST), the
reset-marker (RESET) is mandatory. At least, if I read well the ABNF
syntax.
As for your "open issues":
o Is it worth making provision for multiple compression schemes?
After 20 years, there still isn't anything much better than
DEFLATE and zlib.
=> COMPRESS for IMAP permits to use other compression schemes. We also
permit that for NNTP. Better foresee future better algorithms from the
start.
o If a server supports both COMPRESS and CHUNKING [RFC3030], can you
mix compressed and uncompressed chunks of data? I don't see why
not, but ugh.
=> Whatever the final choice is (to allow or not to allow), I believe it
should be explicitly mentioned in the draft.
o Do we need new 5xx codes for bad compressed data, or can we use
554 for bad data and 552 for too big?
=> According to RFC 5321:
552 Requested mail action aborted: exceeded storage allocation
554 Transaction failed (Or, in the case of a connection-opening
response, "No SMTP service here")
Both of these codes are valid in response to a DATA command, so I think
it is OK to use them for CDAT compression errors.
Incidentally, are you sure a separate CDAT command is the wisest
solution for SMTP (instead of a compression layer, like TLS)?
Keep in mind that one of the advantages of a compression layer is that
you can also decide not to compress data (setting the compression level
at 0 for commands or answers that do not need being compressed). The
client may know that the contents is already compressed (jpg or zip
attachment for instance) and decide not to compress it again.
As far as NNTP is concerned, we already had separate commands like
XZVER, XZHDR or XFEATURE COMPRESS (enabling compression for a subset of
subsequent NNTP commands). The problem is that they do not work for new
NNTP extensions; one has to create again other separate commands dealing
with compression. That's why I reckon a more global solution (like a
compression layer) should really be encouraged. Or, if you really want,
both CDAT and COMPRESS :)
--
Julien ÉLIE
« Il ne faut jamais pleurer d'avoir perdu la lune car les larmes
empêchent de voir les étoiles. »
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp