In <20040214041923(_dot_)GX6151(_at_)dumbo(_dot_)pobox(_dot_)com> Meng Weng
Wong <mengwong(_at_)dumbo(_dot_)pobox(_dot_)com> writes:
A lot of people have pointed out that standards ossify on the Internet.
I've had a lot of people say to me that in standards development, you
have to get it right the first time because on the Net you only get one
chance.
I don't think that's true.
It isn't just the Internet that standards are hard to change and I
think that the point of trying to get it right the first time is very
important.
SPF will break a lot of things. But those things need to be broken.
Interoperability with servers written in 1988 is a nice-to-have, not a
must-have. We can't let old standards suffocate the new.
We also can't go around breaking things constantly.
This is simply a matter of cost vs benefit. Breaking things often
costs a huge amount of money right away, while the benefits accumulate
slowly. If you change something too often, the benefits never have a
chance to accumulate. This is why it is so important to get it right
the first time and why backwards compatibility is so important.
In the case of base64 vs base36, we are talking about 1 bit of
information per character less. That isn't huge, but it will add up
to maybe one extra character to encode the time/hash.
So, the questions are:
How many emails will be rejected because the length of the local part
is one character longer?
How many emails (bounces) will be rejected because the local part
hasn't had it's case preserved?
My gut feel is that the second cost is larger. I don't have data to
back that up though.
-wayne