Re: Revision of RFC 1494 - Teletex mapping?

Ned Freed <NED@sigurd.innosoft.com> Tue, 10 January 1995 22:57 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11480; 10 Jan 95 17:57 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11476; 10 Jan 95 17:57 EST
Received: from survis.surfnet.nl by CNRI.Reston.VA.US id aa19729; 10 Jan 95 17:57 EST
Received: from sigurd.innosoft.com by survis.surfnet.nl with SMTP (PP); Tue, 10 Jan 1995 23:42:04 +0100
Received: from SIGURD.INNOSOFT.COM by SIGURD.INNOSOFT.COM (PMDF V5.0-0 #8790) id <01HLOIK5HY3K8Y53C7@SIGURD.INNOSOFT.COM>; Tue, 10 Jan 1995 14:41:05 -0700 (PDT)
Date: Tue, 10 Jan 1995 12:22:46 -0700
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Ned Freed <NED@sigurd.innosoft.com>
Subject: Re: Revision of RFC 1494 - Teletex mapping?
In-reply-to: Your message dated "Tue, 10 Jan 1995 08:33:10 -0800" <199501101633.IAA28353@hideji.worldtalk.com>
To: csg@hideji.worldtalk.com
Cc: Christian Huitema <Christian.Huitema@sophia.inria.fr>, Harald.T.Alvestrand@uninett.no, mime-mhs@surfnet.nl
Message-id: <01HLOO5W954I8Y53C7@SIGURD.INNOSOFT.COM>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET="US-ASCII"
Content-transfer-encoding: 7bit
References: <"199501101408.AA16010"@mitsou.inria.fr>

> >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.

Ah yes, the purist's view of the net. I always get a chuckle out of this.

The problem, of course, is that out in the real world people don't give a rat's
ass about purity or "simplicity at the core" or any of the other various
arguments I always hear in support of this position. They simply want users to
get messages in formats that they can understand and use. And if vendors don't
offer the necessary services to do this, they won't buy the vendor's product
and will instead choose a product (or protocol suite) that does offer the
capability. End of discussion!

Note also that out in the real world trashing people's messages is even less
acceptable than not doing the right conversions. As such, the accusation that
such organizations that use conversions are frequently guilty of trashing
message is usually without merit.

In fact the irony of the pure approach is that in practice is is often the
minimalist, purest-of-the-pure implementations that do the most damage. These
sorts of implementoration seem to think that they are safe in ignoring safe
transfer of content as an issue, and in so doing they often fail to deal with
boundary conditions properly. The result can be disasterous to the integrity of
messages.

The reality of the situation is that there are lots and lots of products
deployed that perform extensive conversions all the time on all of the messages
they process, and many of these products do all this silently and without
incident, so much so that nobody is really aware of how much of this is going
on.

Don't think I have a problem with this -- I don't. The purist view is useful in
that it reminds us all of where we'd like to be. The only problem I have is
when standards are written that assume this is the way it will be.

> 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.

Exactly right. As you know, I also sell products that do this sort of thing,
and while you do have to enable conversion facilities in our products, most
sites with these sorts of heterogeneous environments do in fact use conversions
pretty much all the time. And their users are usually quite happy with the
result, and we have few if any problems supporting our product in this area.

> 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.

The usual problem with backboning is that the core formats used by the backbone
are not versatile enough to represent the full variety of message types and
contents. This then leads vendors to use proprietary backbone formats, which in
turn severely limits the types of agents you can connect to the backbone.

In particular, X.400-1984 and a lesser extent X.400-1988 lose badly at this.
X.400-1992 (FTBP being the key addition) and MIME, on the other hand, represent
protocols with sufficient flexibility to form true open backbone protocols.

> 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.

The approach we take in PMDF-X400 right now is to convert to charset=t.61 by
default, but we offer the option to convert to iso-8859-1 or any of the 200-odd
other character sets we support if you really want to.

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

Agreed. In our stuff its a one line addition to a configuration file. I
actually think this is too much to ask for some sites and we're taking steps to
add this to our configuration generation procedures in the future.

> > 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.

Well, I like the generaltext idea as an idea,  but in practice I don't know
that it is ever used. Frankly, I cannot recall ever running across a site
that wanted it. The types of X.400 text we usually get asked for are, in
order of frequency:

(1) IA5Text that actually contains ISO-8859-n (yes, I know this is a standards
    violation, but lots of places do it).
(2) T.61.
(3) ISO6937.

(1) and (2) are about tied, while (3) is a long third.

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

? I don't know why this is an issue -- dots are allowed in content-type
parameter values without quoting.

				Ned