On Wed, Jul 21, 1999 at 02:03:46PM -0700, Jon Callas wrote:
I think that the wording in 2.3 (MAY) is correct. We don't want to
say SHOULD, I don't think. It is usual, common practice, to compress
messages. I personally encourage implementers to compress, but at
something with a little less volume than SHOULD. Certainly, it is
good practice to compress, and your user community will scream bloody
murder if you don't. But is SHOULD the right word? It's always seemed
a little too strong to me, because I want to allow my mythical
encrypted pager network to not implement compression.
The SHOULD in 9.3 is perhaps a bit problematic. If you implement
compression, ZIP is the algorithm to implement. Perhaps this really
means that the MAY in 2.3 ought to be a SHOULD, and just be done with
it. That's certainly the easiest change to make. The more I think
about this as I write this note, I think that's the correct change to
make -- MAY in 2.3 becomes SHOULD.
Given that whether or not an implementation decides to implement compression
can affect its ability to interoperate, I think it would be better to have
the stronger suggestion that it be implemented. Think "you SHOULD implement
this unless you know what you are doing and can accept the fact that your
implementation will likely not interoperate."
There's a related issue here, too, and that's dealing with the
compression preference. If you *don't* implement compression, you
have to start marking your certs with a compression preference that
says you don't speak compression. If you don't, people will send you
compressed messages that you can't uncompress. Should this be an
implementation note?
I beleive it should be since the decision to not support compression doesn't
mean that you can just ignore the issue all together if you hope to talk to
anyone else besides yourself.
me