IETF Logo Mail Archive

Re: Thoughts about characters transmission

Keld J|rn Simonsen <keld@dkuug.dk> Sat, 10 July 1993 08:41 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00741; 10 Jul 93 4:41 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00734; 10 Jul 93 4:41 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02344; 10 Jul 93 4:41 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00721; 10 Jul 93 4:41 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00690; 10 Jul 93 4:32 EDT
Received: from dkuug.dk by CNRI.Reston.VA.US id aa02242; 10 Jul 93 4:32 EDT
Received: by dkuug.dk id AA21717 (5.65c8/IDA-1.4.4j for ietf@cnri.reston.va.us); Sat, 10 Jul 1993 10:31:56 +0200
Message-Id: <199307100831.AA21717@dkuug.dk>
X-Orig-Sender: ietf-request@IETF.CNRI.Reston.VA.US
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Keld J|rn Simonsen <keld@dkuug.dk>
Date: Sat, 10 Jul 1993 10:31:56 +0200
In-Reply-To: Andr'e PIRARD <PIRARD@vm1.ulg.ac.be> "Thoughts about characters transmission" (Jul 9, 18:04)
X-Charset: ASCII
X-Char-Esc: 29
Mime-Version: 1.0
Content-Type: Text/Plain; Charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
Mnemonic-Intro: 29
X-Mailer: Mail User's Shell (7.2.2 4/12/91)
To: Andr'e PIRARD <PIRARD@vm1.ulg.ac.be>, "Robert G. Moskowitz" <0003858921@mcimail.com>, ietf-charsets@innosoft.com, ietf-822@dimacs.rutgers.edu, ietf@CNRI.Reston.VA.US, WG-CHAR@rare.nl, Multi-byte Code Issues <ISO10646@jhuvm.rare.nl>
Subject: Re: Thoughts about characters transmission

Andr'e PIRARD writes:

> The _most_important_point_ is that a single common representation code
> be defined _for_the_line_ (suiting the purpose, namely to cover all national
> languages in one single way) and that people be instructed that every bit
> of text should travel in that code on the wire, whatever_the_protocol_is.

I agree to most of what Andre'' is saying and I have an additional
point here: that the single common representation code should be something
that can be handled by existing software and hardware, because it
will take a long time before the conversion software is installed
on all machines, or even a large share of the installed base.
Also I would like to emphasis the need for world-wide solutions.
This would mean that ISO 8859-1 would not be a good candidate,
we need something ASCII based (or even with a smaller repertoire
than ASCII to cover the problems with EBCDIC and national ISO 646 
variants).

I have proposed such a solution in RFC1345.

Keld

v2.23.0 | Report a Bug | By Email