Doug,
I know many don't like being so 1970ish, but to conserve DNS payload
space, here is one example. Introducing this change when going to the
binary key seems like a good choice.
While in principle I agree with you - in fact I was looking at ways to
compress other components of the record, I think we have to be careful
not to go too far down the line - the real boundary is 512 bytes. That
gets us easily to key sizes of 2048 and probably 3072 if desired. 4096
is just not an option without either going to TCP or EDNS0, no matter
the key size. My point is I think this might be a bit of
over-optimizing. I would be more interested in making the record easier
to parse, but even here I'm not too concerned.
Eliot
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html