IETF-822 people,
Due to problems at UUNET, I didn't receive any mail from outside Japan
for just over a week. If anyone has tried to send me comments on
iso-2022-jp that bounced, I would appreciate if you could resend them.
Sorry about the inconvenience.
Here are the diffs since the last version that I sent to this list
(Dec. 1st). Again, please make comments soon. I would like to have
it turned into an RFC real soon now.
The
use of ISO-2022-JP in RFC 1342 [RFC1342] headers is expected to be
the subject of a separate document.
+ However, experimentation with ISO-2022-JP/RFC1342 headers is
+ encouraged.
This document only describes the encoding of plain text. The encoding
of other subtypes of text, such as richtext, is not discussed here.
+ Again, experimentation with ISO-2022-JP richtext is encouraged.
- Also, the message body must end with CRLF, and there must be a switch
- to ASCII before the last CRLF (if there are any non-ASCII characters
- in the message body).
+ Also, the message body must end in ASCII.
- line = *text *1( *segment single-byte-seq *text ) CRLF
+ message = fields 1*( CRLF *text 1*segment single-byte-seq *text )
+ ; see also [MIME] body-part
+ fields = <header lines (see [RFC822] and [MIME])>
[ASCII] American National Standards Institute, "Coded character set
-- 7-bit American national standard code for information
- interchange", ANSI X3.4-1968
+ interchange", ANSI X3.4-1986
[ISO646] International Organization for Standardization (ISO),
"Information processing -- ISO 7-bit coded character set for
information interchange", International Standard, Ref. No. ISO 646-
- 1983 (E)
+ 1991 (E)
Thanks,
Erik