Erik van der Poel writes:
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
What Greg wrote is also not true for what NETF decided.
NETF decided to use 10646 compaction method 5, not latin-1.
I wonder if the third example (NSFnet) was hypothetical too.
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.
I second the requirement for Japanese 2022 support.