Re: Can we back up a bit and ask some basic questions?

At 13:40 03/02/19 -0800, Paul Hoffman / IMC wrote:

>At 8:03 PM +0000 2/19/03, Roy Badami wrote:
>>I think the only way this would be viable is if it was mandatory to
>>convert to IMAA-ACE rather than bounce.
>
>So we need two mechanisms instead of one? And the advantage of that is...?

So we needed two different mechanisms (QP/base64 and 8-bit MIME)
for body parts. I assume these things were not created without
some good advantages in mind.


>For those of you who didn't follow the IDN WG for the past few years, this 
>is highly analogous to the debate that happened there. The whole idea of a 
>"transition" sounds great until you realize that the second format is 
>going to be with us forever. Given that the transition strategy is harder 
>than simply going with IMAA-ACE, there has to be a good reason for it.
>
>I don't consider "UTF-8 is good" to be a good enough reason.

Of course just saying 'UTF-8 is good' doesn't cut it.
But the same goes for 'ACE is good'.

The best way to explain the advantages of UTF-8, in my view,
are to look at how to work on email data (mailboxes) with
scripts and tools. While this is not laid down in any standard,
and is usually not considered too much in discussions like these,
the whole area of scripts and tools is very important for the
success of a technology. And this definitely was the case for
Internet mail (as opposed, e.g., to some ISO projects in the
same area).

Now being able to more/grep/less/awk/sed/perl/... through
a mailbox is extremely easy as long as everything relevant
stays in US-ASCII. It would also be very easy as long as
everything relevant is in UTF-8. But as soon as things such
as RFC 2047 and ACE come in, things get extremely complicated.
Searching for 'Paul' or 'Hoffman' in email headers is trivial.
Searching for (the native character equivalents of) 'Taro'
or 'Suzuki' in the same headers turns into a major engineering
project. It doesn't need to stay that way.


A different way to explain things:

Ulrich Drepper, of gclib fame, once put it very clearly that
in order to move internationalization forward, he and other
people with his knowledge would work on getting the basics
done (i.e. moving things to UTF-8 or equivalent), and the
people on the other side of the globe could then work on
top of that (localizing applications, language-specific
search,...). The IETF community has formalized this kind
of thinking in a BCP, http://www.ietf.org/rfc/rfc2277.txt,
(and look who is at the top of that document!)
which says:

   "Protocols MUST be able to use the UTF-8 charset,"...

While the IETF is very well known for its flexibility,
RFC 2277 should not be something that is easily dismissed.
Indeed, the burden should be on people to prove that UTF-8
does not work at all (which I haven't seen argued here yet),
without constantly trying to turn around the burden of proof.


>(And before anyone here calls me "anti-UTF-8", please look at the top of 
>the first page of the UTF-8 RFC.)

Sorry, but http://www.ietf.org/rfc/rfc2279.txt lists Francois Yergeau
as its only author. Same for the next version that is in the works
(http://www.ietf.org/internet-drafts/draft-yergeau-rfc2279bis-03.txt).
That one lists you in the acknowledgements.

You have co-authored the RFC on UTF-16 (http://www.ietf.org/rfc/rfc2781.txt).
That's something different.


Regards,   Martin.