I remain concerned that there needs to be more explanation and definition
of the ISO-2022-JP encodings. I would be satisfied with explicit references
to the JIS documents, explicit reference to the ISO-2022 document, and some
definition of what the initial character set and state are for that type.
Could Mark or someone please come up with at least that much as text
that could be inserted into the RFC-XXXX in the appropriate place ??
If we can't get that much, I'd rather omit it from RFC-XXXX and say that
it shouldn't be used until _some_ RFC documents the mechanism and the
relevant JIS and ISO standards used. The problem isn't with getting the
Japanese to implement it properly -- the problem is getting folks outside
Japan (like major system vendors in the Silicon Valley) to implement
it properly. To do this successfully, more detailed information is needed.
On another note, I too am uncomfortable with the size of RFC-XXXX. I'd
prefer a slimmer document without so many untried features (though I'm not
eager to get into feature politics). Similarly, I think that RFC-XXXX should
only deal with message body extensions. Message Header extensions belong
in a separate (possibly concurrently worked on) RFC so that the lack of
consensus there doesn't slow things down for RFC-XXXX.
Ran
atkinson(_at_)itd(_dot_)nrl(_dot_)navy(_dot_)mil