Takuma-san,
At 4:19 AM 12/1/94, Akira Takuma wrote:
>>sender's intent. Plain US-ASCII text must still be assumed in
I'm afraid of this inconvenient request.
Please understand that the use of ASCII as the character set for Internet
electronic mail messages has been the standard for the entire history of
the Internet. It is explicitly defined in RFC822, published in 1982.
Hence, there is nothing new about this issue.
Naturally, we are Japanese need Japanese subject.
Indeed you do. In fact, it was a desire to response to just such a need
that caused the formation of the Mime effort. Clearly, ASCII is inadequate
for encoding content in most of the world's languages. Over the years,
various communities changed their local use of RFC822 email so that they
used a default other than ASCII. There was no standard way to accomodate
their requirements, so they chose the path of local conventions.
These changes were -- and are -- non-standard. While the problem those
communities were and are trying to solve is clearly and completely
legitimate, the path taken is not standard. The Internet technical
community developed Mime as the standards-based path for this requirement.
Communities are, of course, free to use any conventions and technologies
they wish. However, if they wish to interoperate with the open and global
Internet community, they need to use Internet standards. It is the
essential requirement for interoperability.
The Mime mechanism that was defined -- the charset= facility -- was the
best choice that could be developed, after 18 months of intense discussion
and debate within the IETF's Mime working group. While most, or perhaps
all, of the working group participants were hoping to achieve a single,
universal "solution" to this requirement, the charset= mechanism was the
best we could devise.
If we use MIME-encoding for Japanese message, it'll be difficult
to make communication programs, slow to print messages, may grow
Experience which contributes to an understanding of the deficiencies of
Mime would provide valuable input for any future effort to modify and
enhance it. I encourage you to submit the technical and operational
details of your experience, along with any suggestions you may have for
making improvements, so that the Internet standards process can develop
changes that are responsive to your real-world experiences and the
experiences of other users of Mime. It is the essence of the Internet
standards process.
However, to repeat, I must note that use of a mechanism other than the
charset= parameter in Mime is simply non-standard. Anyone is free to use
other mechanisms within a private community, but public use of it will
defeat the goal of global interoperability.
As a small implementation point, I will note that matters of display
processing and storage efficiency are very much concerns for LOCAL
implementation, rather than global interoperability and that transforming a
Mime-conformant message into a different form for local processing may well
be required for your community's use.
We want to communicate with simple format defined in RFC822.
When the Mime effort was started, we all hoped we could develop a simple
and complete solution to the requirement for supporting international
character sets. I believe most of us view the charset= parameter very much
NOT as a "solution" but rather a compelled compromise. It is not
satisfying but it is the best we could develop.
Dave
--------------------
Dave Crocker
Brandenburg Consulting Phone: +1 408 246 8253
675 Spruce Dr. Fax: +1 408 249 6205
Sunnyvale, CA 94086 Email:
dcrocker(_at_)mordor(_dot_)stanford(_dot_)edu