Re: [idn] Some comments

[ned.freed@innosoft.com]

> > MIME was the right answer.  "just do 8-bit SMTP" was not.
> > The ACE approach is the same paradigm as MIME.

> 10 years ago, 7-bit with 1 bit parity network connections were
> more common. I dont think that is the case any longer.

Actually, while this is perhaps true it is largely irrelevant. The issue 10
years ago wasn't what network connections supported, since IP running over such
things did what was necessary to implement an 8-bit path even back then.

What was relevant is that a significant amount of deployed messaging software
reacted badly to 8-bit data in messages. And although many of the problems with
8-bit data handling were fixed in many software packages around that time, it
took many years for the updated versions of that software to actually deploy.
And when it did deploy, it was largely for other reasons, such as to address
security issues.

It seems like a bad idea to assume that another wave of software
vulnerabilities will once again spur deployment of revised sofware when we need
it...

> MIME was not just a solution for 8-bit data, it also solved the
> issue of multipart data.

And labelling of data and labelling of charsets. Although it sure would  have
been nice if we'd had a universal charset to specify back then -- most of the
problems I see these days have to do with missing or improper labelling, not
encoding, and quite a bit of this could have been avoided by having a universal
charset. And now that we do have such a thing, we're again having considerable
trouble getting meaningful support for it deployed in a timely fashion. This
does not bode well for IDN done initially as infrastructure enhancements.

> > It is the right way to lay an encoding enhancement on an installed base,
> > with the smallest amount of disruption.  It permits incremental adoption,
> > with immediate benefit to participants in the enhancement, and no
> > critical-path changes required of the infrastructure.  Changes to the
> > infrastructure can then happen later and more liesurely.

> I think the end solution should be unicode (utf/ucs/whatever)
> ACE is not part of a migration, it is an alternative.

Not necessarily. ACE is a first step, and I believe it is a necessary first
step. The question of whether or not it is the last step isn't settled at all.
But one of the advantages of ACE is that we don't have to make this choice in
the short term.

> If ACE laid the groundwork for moving to unicode I would
> be much more inclined to accept it for the short term.

Um, careful with your terms here. I think you meant UTF-8 or UTF-16 or some
other charset, not Unicode. ACE does encode the Unicode CCS.

> Infrastructure changes will only happen if there is a need for them.

Actually, they often don't happen even if there's a need for them. What's
hnecessary is for there to be a pressing need that cannot be ignored. And it
isn't clear that IDN represents such a need in many quarters, the demand for it
in others notwithstanding.

> ACE will meet the developers and consumers needs, so changes will
> not happen if it is implemented.

A very telling statement, if I may say so... and one that argues for ACE
being the last step!

				Ned