home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
archives
/
protocol.zip
/
charset.txt
< prev
next >
Wrap
Text File
|
1990-08-17
|
3KB
|
58 lines
PROPOSED ADDITION TO "ISO-KERMIT" PROPOSAL
This discussion applies to the "Level 1" part of the proposal, in which
a single character set is used in Kermit's transfer syntax.
What happens when the file character set and the transfer character don't
match? For example, when the current file character set is, say, the 7-bit
SWISS NRC, and the transfer character set is, say, CYRILLIC? The draft did
not consider the possibility that there might not be a translation for each
conceivable pair of file and transfer character sets. Let's consider this
issue from each angle.
1. The file sender. One solution is obvious: as soon as the user gives the
SEND command, the program issues an error message: "Inappropriate Transfer
Character Set" and returns to the prompt.
2. A Kermit server that receives a GET command could issue the same error
message, but in an error packet. Then the user would have to issue a REMOTE
SET TRANSFER CHARACTER SET xxx command, and then reissue the GET command.
3. A Kermit receiver can issue an error message when the user gives the
RECEIVE command if the current file and transfer character sets don't jibe.
But any transfer character set specified in the incoming attribute packet (if
use of attribute packets has been negotiated) will override the current global
setting. If it is inappropriate for the current file character set, the
receiver can issue an error packet and the user will have to give SET commands
to fix things. (It's not OK to simply cancel the current file using "X" in
the ACK, because the user will have no idea why this happened.)
In these circumstances, can the Kermit program adjust itself automatically,
rather than failing? Let's look at each case.
1. User gives SEND command. So far, no protocol has taken place, so there is
no reason not to tell the user something is wrong and let the user take
corrective action. After all, how could the program decide whether the file
character set or transfer character set should take priority?
2. Server gets GET command. Same reasoning as (1). No automatic recovery.
3. Receiver gets Attribute packet. In this case, we can decide to trust the
transfer character set given in the A-packet. If we do, we can change our
file character set automatically to the one that best accommodates the data
that is being transferred.
To accomplish (3), each implementation of Kermit will need a list of
permissible file character sets for each transfer character set. When a file
arrives with a particular transfer character set X, if the the current file
character set is not on X's list, the program picks one from the list. Which
one? If the computer does not have any character sets that include Latin-1 as
a subset (including Latin-1 itself), then it must pick a more restricted set
based on some criterion. Perhaps this should be the SET LANGUAGE command.
For example, if the incoming file is Latin-1, it could contain text in any of
at least 15 different languages. If we are using a 7-bit NRC, then this would
tell us which one to translate the Latin-1 into.
Comments?