Randall writes:
The scope of the RFC should be limited to Internet mail concerns
such as trying to build some facilities for labelling mail encoded in
character sets which are predefined elsewhere (ISO or whoever) AND are
of interest to the Internet community. That a character set standard
is of interest to folks outside the Internet community shouldn't be a
factor. We aren't writing an ISO standard here, we are trying to
solve a real need of Internet users in an upwards-compatible manner.
Well, is EBCDIC interesting to internet people?
I have an IBM 9370 connected to internet (vm.ibt.dk 129.142.116.3)
and there are quite a lot of IBM mainframes directly on
internet in Scandinavia. I think the same is true in Northern America.
We happen to run Danish/Norwegian EBCDIC on our machine.
So is EBCDIC and it variants not of interest to internet community?
Anyway we want to make our specifications as bullet-proof as possible
and IMHO that means that we should try to avoid the problems like with
uuencode/decode - at least when we have the possiblilties like choosing
the 64 characters in a base64 encoding - then we should avoid problem
characters.
I have yet to see any sufficient or detailed justification posted
here for worrying about anything other than US ASCII, ISO 8859/n, and
ISO DIS 10646 (once it becomes ISO 10646 and assumes final form).
There might be others to worry about, but I don't think that EBCDIC should
be one of them based on the historical precedent of RFC 822 selecting
US ASCII only.
I actually agree with you about the selection of character sets
that should be mandatorily supported by the new RFC.
In our other work, however, we should not make specifications giving
cause to problems in the internet community (including those IBM
bastards) which could have been avoided by a little more careful design.
Keld