Re: Revision of RFC 1494 - Teletex mapping?

"Carl S. Gutekunst" <> Tue, 10 January 1995 17:04 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa05889; 10 Jan 95 12:04 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05885; 10 Jan 95 12:04 EST
Received: from by CNRI.Reston.VA.US id aa09937; 10 Jan 95 12:04 EST
Received: from (actually worldtlk.WORLDTALK.COM) by with SMTP (PP); Tue, 10 Jan 1995 17:41:45 +0100
Received: from by with SMTP ( id AA17454; Tue, 10 Jan 1995 08:36:16 -0800
Received: (from csg@localhost) by (8.6.9/1.5) id IAA28353 for csg; Tue, 10 Jan 1995 08:33:10 -0800
Date: Tue, 10 Jan 1995 08:33:10 -0800
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "Carl S. Gutekunst" <>
Message-Id: <>
To: Christian Huitema <>
Subject: Re: Revision of RFC 1494 - Teletex mapping?
In-Reply-To: Your message of Tue, 10 Jan 1995 15:08:40 +0100 <>

>The MIME translation of a Teletex body part should be an equivalent
>"text/plain; charset=T.61" MIME part, with parameters describing non default
>options if any. And do not dare changing one single character in the encoding!

This is a religious issue that comes up regularly, in this group and others:
Who is responsible for making a body part usable by the recipient?

There is a widespread stance on the net that gateways should perform service
normalizations only; that gateways that muck with the contents, no matter how
well intended, are introducing corruption.  The recipient who really wanted
a faithful transmission will be twarted, unable to recover the original data.
So, when an X.400 user sends a T.61 part to a MIME user, it's the MIME user's
problem to provide a means to convert T.61 into something readable.

This is a nice academic argument that totally disagrees with reality.  People
buy gateways to support interoperability between communities of users.  When
I sell a customer a suite of gateways among MIME, cc:Mail, and X.400 (which is
exactly what I do!), the customer will demand that that the X.400 user be
given text in T.61, cc:Mail in PC437, and MIME in ISO 8859.1 -- even if that
means loss of information.  The customer has no way to modify any of his user
agents, so sending a charset="T.61" to his MIME clients is about as useful as
handing them a deck of 80 column cards.

The obvious exception is backboning, that is, using a single protocol as a
backbone among a large number of messaging systems.  Lots of sites do this
using point gateways; Worldtalk, Innosoft, Wingra, Soft*Switch, and Retix sell
(or used to sell) integrated systems to do this.  Backboning is really easy to
do if you only want an 80% solution.  It's really really hard to get a 100%
solution -- maybe impossible.  That's were the message switch vendors make
their living.  There are just too many different assumptions among too many
disparate systems.  For really transparent backboning, you have to be able to
do message encapsulation.  And when you do encapsulation, the character set
issues take care of themselves.

I'm am not disagreeing with charset="T.61" being specified and available for
MIME gateways (actually, charset=iso-6937); what I am saying is that mapping
to iso-8859-1 is preferable if there is no loss; and if there is loss, what
to do about it is an administrative decision.  The overwhelming majority of
admins are going to choose to map to iso-8859-1, and the loss is just too bad.

I'd also suggest that if you've designed your gateway properly, making this
choice should be straightforward.

>Then, I may be dense, but why would you need something different than a
>"T.61" body part for mapping back to 88?

That's what I was wondering, too.  I don't see good support for GeneralText
among the so-called '88 vendors, and the majority of PTTs are still '84.

Incidentally, charset=iso-6937 has another advantage: no "dot" in the name! :-)