Re: I-D ACTION:draft-palme-e-mail-translation-03.txt

> At 17.15 -0500 02-01-15, Keith Moore wrote:
> >how present mail UAs handle this is irrelevant, because they
> >don't handle any other scheme for language selection either.
> >
> >the only question for IETF is - what's the best way to do this
> >in MIME protocol?  and nobody has come up with a better alternative
> >(so to speak) than multipart/alternative.

> When the MIME standard was introduced, the handling by
> present mail was central in the design of mail. For example,
> the QUOTED-PRINTABLE format was chosen, because messages
> encoded in this format would be at least partly readable
> for recipients with old mailers.

First of all, the primary reason for including encodings in MIME was to insure
backwards compatibility with deployed messaging _standards_, not deployed
messaging _systems_. It is one thing to avoid breaking implementations coded in
good faith to the standards of the time, it is quite another thing to attempt
to cater to implementations that weren't coded very well to begin with.

Second, in the case of quoted-printable, we also attempted to finesse the
backwards compatibility issue somewhat by defing an encoding that would be
partly readable. However, this attempt was, in retrospect, a nearly complete
failure. In hindsight, it may have been more trouble than it was worth.

In summary, you win few if any points in this debate by comparing what you're
proposing to quoted-printable.

> Why should not a graceful downgrading to existing mailers
> be important for language translation in e-mail, when
> it was so very important in the design of MIME itself?

See above -- the comparison isn't as apt as you seem to think, and even if it
were apt you're basically saying we should repeat something that didn't work
the first time.

An additional point. The pent up demand for MIME in the early 90s was enormous.
A standardized message format for internationalized text and material other
than text was urgently needed. This more than anything else drove the
deployment of MIME support, and even then deployment was pretty slow. By
contrast, the demand for language translation support in email is minimal at
best. I know it is something you want very badly, but how many other people
want it? Uptake of other MIME enhancements or extensions that require
substantial UA changes has been sporadic at best, and seems largely related to
the perceived needs of the vendors themselves, not a desire for full standards
compliance.

Because of this I fear that any proposal you make (other than one where you
simply use multipart/mixed rather than multipart/alternative) is going to
suffer the same fate as the attempt to use content-language fields to select
between alternative parts. Simply put, while what you are doing is arguably
a legitimate standards exercise, I see little chance of change in the real
world because of it.

There are, however, two alternate approaches that immediately come to mind
that might work better:

(1) Do some coding work yourself. There are plenty of open source UAs in use
    today and several other UAs provide hooks for extensibility. Have you
    tried coding honest to goodness alternative language support for these?
    Doing so and proving the value of such capabilities might help your cause.
    (Several MIME compliant mail systems were released at the same time the
    MIME RFCs came out. This helped enormously in getting MIME started.)

(2) Work the problem from the other end. Efforts are under way to develop
    and deploy facilities for determining the recipient characteristics and
    sending messages that match those characteristics. I don't know if these
    efforts are going to be successful, but if they are and language
    selection is included in the initial rollout you might get something
    deployed, albeit vicariously.

There are probably others, not to mention variants on these themes. Sometimes
the way to win is not to play.

				Ned

Received on Wednesday, 16 January 2002 12:48:55 UTC