Thoughts about characters transmission
Andr'e PIRARD <PIRARD <at> vm1.ulg.ac.be>
1993-07-09 16:25:04 GMT
I have not much time to spend on this subject, but I would have felt bad
not to express these opinions once.
I have learned with much interest that people envision solutions for
international characters data exchange with a wider point of view than
usually heard in the networking sphere.
I have been spending quite a time of my life with such problems.
I thought I could contribute with a small text explaining the way
I have finally come to think of the problem.
Nothing totally new, probably, but a different shed of light, maybe.
The text may sound theoretical at first. It is just terse. The ideas are
based on experience. They have been put to use in the field of 8-bit
characters. I participated to the design of Kermit multinational 8-bit
characters support and the TCP/IP network I work for is well on the way
towards the the same theory that every character on the communication
line is ISO 8859-1. Any exception to this, like translating EBCDIC directly
to PC code on one machine, is considered harmful to our internetworking,
even if convenient.
Every piece working towards a common well defined goal finally pays more
when all parts start to clutch than wandering for immediate interest.
And I hope that saying that my language is French will make the ideas
in a difficult to write text even more convincing, despite being short.
Networking has had for long the problem of a common representation of
computer-specific data (numbers, bit strings...) on the wire (rather, on the
connection), because different computers had different conventions for them.
To solve this problem, rules like XDR (external data representation) have
been devised, and, because it was so important, the rules have been adopted.
Character data caused little problem because ASCII was assumed, full stop.
(Continue reading)
The draft is available in the usual places, with the filename "draft-ietf-822ext-microsoft-window-00.txt". If there is enough demand, I'll send a copy to the list. In brief, the intention (of the final RFC) is to register Content-Types for a number of file formats used in the Microsoft Windows environment and to specify conversions that can be performed to aid interoperability. The list of Content-Types is by no means complete, and further additions are welcome, provided that descriptions of additional formats already exist in other places (SDK manuals, etc). Cheers, Rhys.
RSS Feed