Randall Atkinson writes:
Greg Vaudreuil writes:
% This is very much a message format issue. RFC explicity addressed
% this issue. It said, "you must use ASCII". If it is not a 822 issue,
% then is it an topic for a separate implementor agreement? NETF
% specified use of latin-1 on there networks, NSFnet specifies ISO 10646
% for the US scientific community, and Japan specifies 2022-n for
% internal use and ISO 10646 for external use.... This is a nightmare
% that the IETF/IAB/Internet community has never had to deal with.
This seems to indicate that the RFC should at least include type
definitions for the sets in my paragraph [below] simply for reason of
inter-operability with the above networks.
Wait a second. You aren't assuming that what Greg said about NETF,
NSFnet and Japan is true, are you? Greg was just hypothesizing. Japan
has not specified 2022 for internal use and 10646 for external use.
Japan has not specified anything for internal use (i.e. within
organizations), but it has specified a form of ISO 2022 for external
use.
This seems to present a case for restricting the draft RFC's type
definitions to only the US-ASCII (X3.4-1986), ISO 646-N, ISO 8859-N,
and ISO DIS 10646 standards. This would be easier to implement as
well as addressing the problems of Internationalisation.
Why not include the Japanese form of ISO 2022 in your list? It's
certainly not any harder to `implement' (whatever *that* means) than
10646, and moreover, there's a large installed base of software in
Japan that understands this encoding.
Well, perhaps some of the non-Japanese on this list would object to an
RFC that says that ISO 2022 *must* be supported, but I think it is
important to remember what Ned wrote about this:
# Thus, the conclusion that we're requiring support for all of the
# content-types mentioned in the RFC is invalid. We aren't. What we are
# saying is "if you export material of this type, do it this way".
Erik