ietf-822
[Top] [All Lists]

RE: Upgrading to UTF-8

2003-02-10 20:00:57

The IETF has a simple policy: Never break standards-compliant deployed software. We also try not to break non-standards-compliant deployed software when reasonable, but that is a second priority. This policy results in cruft and junk in protocols. It's ugly and unpleasant to implement as you correctly point out. So here's how to succeed at cruft removal:
----
Guide to removing cruft from standard protocols:

1. Write a standard extension to negotiate use of the less-crufty protocol, and explain how to downconvert to the fully-interoperable crufty protocol.

2. Deploy standards-compliant servers and clients that accept the less-crufty protocol, down-convert if necessary, and will generate the less-crufty protocol only if negotiated. These interoperate with all software.

3. Deploy non-standard software that generates only the less-crufty protocol. This software isn't guaranteed to interoperate with everything, but plays an important role as it creates pressure to upgrade to software from step 2.

4. Over time, more and more developers will not bother to implement the downconversion and cruft-support. Eventually the amount of software requiring the downconversion is close enough to zero that the standards can be changed to drop the requirement.
----

The 8BITMIME SMTP extension did steps 1-3 and is in the middle of step 4. Most of the delay in deploying 8BITMIME was fighting between the "interoperability with deployed standards" and "cruft removal" camps. As soon as the latter camp gave in, both camps started to get what they wanted.


Bottom line: if you want UTF-8 in headers, write the spec for negotiated UTF-8 in headers as SMTP, IMAP and POP extensions with downconversion to 2047/2231. When that's written and both camps agree, then we can move forward to steps 2-4.

If we continue to argue, we will be stuck with the cruft indefinitely.

               - Chris

begin quotation by David Barr on 2003/2/10 12:54 -0600:


And if you had a shred of competency as an engineer or
protocol designer you'd be working on solutions to the very
real problems rather than trying to pretend that they don't exist.

The fact that there are almost a dozen different (and in many cases
horribly broken) encoding formats that are required now to implement an
email client/web browser is not a real problem?  The fact that messages
floating around often have to go through transformation after
transformation, encoding after encoding, just to get from one place to
another, and that *any* bugs or gaps with encoding along the way result
in real breakage? That is not a real problem?  The fact that because of
typical
desgin-by-committee and generational effects we now have a series of
protocols layered on top of each other that are horribly complex, vague,
and broken?  And the fact that the vast majority of these problems would
be solved simply by having the balls to once and for all say "we shalt
transition all this shit to UTF-8"?

Rather than actually solve problems, the IETF would rather add more duct
tape to an already structurally unsound system.  This disturbs me.

--Dave





<Prev in Thread] Current Thread [Next in Thread>