Re: [idn] Debunking the ACE myth

[ned.freed@mrochek.com]

> I think that was my point.  The people that want "it" will
> upgrade, if they can.   The ISPs who run the servers may not see
> "want" the same way. So, once again, if you want rapid
> deployment, pick a solution that leaves the upgrading in the
> hands of those who need the functionality --the users in this
> case-- rather than entertaining fantasies about what ISPs and
> other server operators will do.

I don't work for an ISP, but I do work on email software that a fair
number of
large ISPs buy. And I believe that John is right on target here.

Here's a specific example. Some time back we released a new version of
our
email software. The primary goal of this particular release was to
improve our
internationalization and localization capabilities. A large number of
enhancements were made and a large number of internationalization bugs
were
fixed. In particular, any number of issues relating to the ability to
handle
non-ASCII user information properly were addressed.

But uptake of this new release has been very slow, even with customers
who said
they urgently needed the new internationalization and localization
support and
bug fixes in this release. And this continues to be the case despite
many
reports from the field saying the new release is actually more stable,
more
reliable, faster, and generally easier to deal with than the old
version.

And even in cases where the new release has been deployed the new
functionality
hasn't always been exposed to end users. This is because having the
support in
the product is only the first step. Provisioning issues have to be dealt
with.
And large ISPs often have their own provisioning tools, some of which
are quite
convoluted, and these tools have to be updated before they can usefully
offer
new functionality.

The bottom line is that large ISPs are conservative. No, make that
*extremely*
conservative. Marketing may be crying for new features, but operations
isn't
willing to sacrifice stability to get those new features. When it comes
to
software deployment they proceed slowly, they test everything six ways
from
Sunday, and even if it all looks good they still wait for an opportune
time to
upgrade cautiously. And at the first sign of trouble they call the whole
thing
off. And then you wait for another windoe in, say, 6 months or so.

And guess what? Even with all the care they take, they still have
problems all
the time. Our industry doesn't exactly have a stellar track record when
it
comes to quality and reliability. So I don't expect any of this to
change any
time soon.

But what if there was a security hole? As it happens I have experience
with
this as well. Happily, we haven't found holes in our code, but we depend
on
lots of other libraries and components from other sources, and several
vulnerabilities have been found in a couple of these. When such things
are
found and found to matter our customers get a patch for the software
they are
running. They don't upgrade to fix security holes. They demand patches.
And
they get them.

Now, you may argue that my experience isn't typical, that experience
with email
deployment says nothing about DNS deployment, that IDN deployment is
somehow
different or whatever. But you now have two people with real world
deployment
experience saying that John's experience in this area matches our own.
Make of
that what you will.

Ned