On Dec 9, 6:27pm, Satoshi Kinoshita wrote:
} Subject: Re: Internationalization of the Internet
}
} Dave,
}
} ! ASCII defines particular character interpretations for particular bit
} ! patterns
}
} So your interpretation of rfc822 seems to be something like this:
}
} iso-2022-jp is not conformant to rfc822 because it's not strictly ASCII.
}
} If it's right,
} Q encoded iso-8859-1 is also not conformant because of the same reason.
You're right! From the MIME RFC:
STD 11, RFC 822 defines a message representation protocol which
specifies considerable detail about message headers, but which leaves
the message content, or message body, as flat ASCII text. This
document redefines the format of message bodies to allow multi-part
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
textual and non-textual message bodies to be represented and
exchanged without loss of information. [....]
This document describes several mechanisms that combine to solve most
of these problems without introducing any serious incompatibilities
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
with the existing world of RFC 822 mail.
} Interpretation of rfc822 should not depend on the existence of charset label.
It doesn't.
} I think this kind of interpretation is not good for both
} iso-2022-* and MIME charset labeling.
} A little smoother and reasonable consensus of rfc822 is necessary
} so that we can use iso-2022-* or B and Q encoding as a valid body of rfc822.
I respectfully suggest that we've lost track of what the point is here.
Neither a MIME message nor a message containing iso-2022-* text is a
valid RFC 822 message. Granted. This should never have been in dispute.
However, a MIME message isn't *intended* to be valid RFC 822. It is not
bound by the RFC 822 specification except so far as the MIME specification
chooses to bind it. The difference is that a MIME message, by virtue
of the presence of the Mime-Version: header, is announcing that it is
not an RFC 822 message and that it therefore should not be treated as one.
The fact that it *can* be treated as one by most user and transport agents
is a side-effect of the design of MIME, and has no bearing on whether it
is valid RFC 822 format. (The number of gateways that bounce or mangle
MIME messages should be a clear indication that MIME is not RFC 822.)
So far, the iso-2022-* advocates have suggested that it is not necessary
to label messages containing iso-2022-* in any way. From the standpoint
of whether the messages arrive with their contents intact, this is true;
it may even be more true than it is for MIME. From the standpoint of
whether the messages conform to RFC 822, it is irrelevant. The point is
not so much that unlabeled iso-2022-* is not valid RFC 822; the point is
that unlabeled iso-2022-* does not conform to ANY currently-accepted
internet messaging standard. It may not introduce any serious incom-
patibilities, but it can't be claimed that it conforms to a standard.
Sending iso-2022-* without telling the recipient what he's getting is
equivalent to sending B encoded US-ASCII without telling the recipient
that it is B-encoded. Niether of them is valid anything.
The way to make messages containing iso-2022-* valid is to create a new
specification that redefines the format of message bodies, and then to
assert that the iso-2022-* messages conform to that specification. If
that specification is then accepted as a standard, you've solved the
problem.
But wait! There already IS a specification that redefines the format of
message bodies! Slap on a Mime-Version: header and a Content-Type: that
appropriately asserts iso-2022-*, and you have a message that conforms to
that specification! No need to go through all the hassles that others
have already gone through on your behalf. The world is a rosy place, and
we can all get on with the real business at hand, which is communicating
with each other.
--
Bart Schaefer Vice President, Technology, Z-Code Software
schaefer(_at_)z-code(_dot_)com Division of Network Computing
Devices, Inc.
civilization (siv"i-le-za'shen), n., see ISO 2022