Mark Crispin writes:
As far as I can tell, the pedigree of 2022-JP is that this is what was
implemented by Japanese terminal manufacturers for use on 7-bit links.
I believe that the terminal manufacturers implemented something that
was closer to ISO 2022 than JUNET's standard is. The JUNET document
specifies that one must shift to ASCII (or JIS Roman) before newlines.
ISO 2022 does not necessitate this. I.e. this rule was "added" by
JUNET. Of course, the terminals do understand the JUNET form.
Hence, it is not an `informal' standard.
It is neither a national nor an international standard.
I don't mind 2022-JP being in a separate document, as long as the name
is still specified and blessed in XXXX so we can use it now instead of
waiting for JUNET to (1) become aware of the need to write the
document (2) to produce a suitably formal document (3) get it through
the Internet standardization process.
OK, how about simply reserving the name "ISO-2022-jp" in RFC-MIME,
with a description saying that the formal spec will be in a different
document, and that implementations need not grok ISO-2022-jp to be
MIME-conformant. This allows 2022-jp senders to add the correct header
to their messages, while not forcing Joe Bloggs in the USofA to be
able to parse it. I.e. delete Appendix F and re-word the section on
2022-jp.
All of this in the interests of reaching closure, of course.
Regards,
Erik