ietf-openpgp
[Top] [All Lists]

Re: OpenPGP conformance : MUSTS found in RFC2440

1999-07-21 14:39:08
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