On Apr 25, 8:43am, Greg Vaudreuil wrote:
Subject: Re: support for all content types
% I have only concern for text. I see no way around the necessity to
% ask if you are capable of "advanced" functionality. I simply do not
% see plain text (even in other character sets) as advanced
% functionality.
I don't think that there is any practical way to force any MUA to
support all the conceivable types. If the commonly used text types
are defined then the MUAs and gateways have the opportunity of doing
things correctly. I would hope that getting the "basic" functionality
correct is the primary concern as Greg suggests.
% Well, if you can convert from ISO 10646 to national 646-n, and then
% display 646-n on your dumb terminal, then I'd say you can handle
% 10646. You can do something with it, even if you must suffer info
% loss for Kanji.
This isn't possible even for all of the Romanised languages. For
example, Vietnamese is (mostly) supported by DIS 10646 but cannot be
represented _correctly_ in any of the ISO 8859 or any of the ISO 646
character set standards. It can be approximated in ASCII or ISO
8859-1 though I don't think that kind of conversion ability should be
mandated.
% This is precisely what I'm getting at. If I pick a series of
% codesets, like MAILASCII, Latin-1 and ISO 10646, they are all upwardly
% compatable. If I send Japanese, I must use ISO 10646. I have no
% option. If I send English in ASCII, I can use 10646, but I can subset
% it to ASCII. If I send French, I can use either 10646, or subset it
% to Latin-1.
(Latin-1 is ISO 8859-1 )
% There is a big difference between implementing this series of
% character sets and asking that I implement (or be able to convert to
% and from) Unicode, 646-n, and iso10646. With the former series, I
% implement the level of functionality I need. By allowing any arbitrary
% character set, I must implement all sets that can possibly give me
% the functionality I need, because must expect any one of them.
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.
% 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 above simply for reason of
inter-operability with the above networks.
It still isn't clear to me how it is practical to enforce support for
any character set encoding for all hosts. After all, there are a lot
of systems still running that don't use the DNS.
Randall Atkinson
randall(_at_)Virginia(_dot_)EDU