From Erik:
What about all the other Content-Types in the draft? Should all
implementations support all types, including SGML, audio, and what
have you?
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.
So, I think you should relax the displayability requirement, and just
say that the UAs must be able to interconvert between the listed
codesets. Of course, there will be messages that cannot be converted
to one of the desired codesets. In these cases, I would suggest not
converting at all, perhaps telling the user that it couldn't be
converted.
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.
On the other hand, I can fully understand your desire for
interoperability. But I don't think we can really expect everyone to
have all fonts. There will always be at least a small number of people
with dumb terminals that can only display e.g. ASCII. Or people with
1.5 Megabyte RAM X terminals, that can't display Japanese.
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.
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.
Is this really the province of an 822-like RFC? 822 seems to me to be
more like something that specifies the format of messages, including
the header names, how to write headers, etc.
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.
Telnet is a good example of a protocol with lots of options. If I
implement the required functionality, I can get info back and forth.
I may not be able to do fancy stuff, but I can negotiate for advanced
features. There is no negotiation at the 822-UA level, so we must
specify required functionality.
Greg V.