On 12/9/94 at 12:47 AM, Masataka Ohta wrote:
I think the important facts are these:
Not.
Ohta-san, you are just a rude, impolite human being. Your flip, undefended
answers are insulting.
I just treat narrow-sighted MIME worshippers who can't respect someone
else's language accordingly.
Many people in this discussion (including myself) have endlessly tried to
understand your arguments and be sympathetic to your cause. We are met with
disrespect by you. I personally have tried to take into account your views
and have tried to understand your meaning. I have now been met with
rudeness.
If someone can't respect our culture, I shall not treat the one as
a human being.
Do not expect respect if you cannot give it.
i) much of the world does not understand ISO-2022, therefore if you send
Much of the MIME implementation does not understand ISO-2022.
Both statements are equally true. Most MIME implementations do not
understand ISO-2022. Most mail programs do not understand 2022. I do not
see your point here. Explain yourself.
Almost all mail programs pass 2022 as is. There is no point to request
mail programs understand 2022. People who don't know such a basic fact
of life in non-ASCII environment may ask a question. But, do so
politely.
When I said that a "mail program" did not understand ISO 2022, the meaning
was that user display programs for mail did not understand ISO 2022. Many,
many programs are unable to display ISO 2022 properly. Many, many terminals
are unable to display ISO 2022 properly. This has been said repeatedly, and
politely, and you have chosen to ignore the meaning of the words we are
using.
By using ISO 2022 to label, the recipient has a way to know (at least,
and maybe see) what we intended.
This is absolutely false.
OK. I am too polite to tolerate your arrogance, here.
I am arrogant? I have ISO 2022 sitting here on my lap, and you have the
audacity to say:
If you don't know about ISO 2022, read ISO 2022. Still, if
you can't understand some point, then, ask me.
IETF is not the place of education. Certain amount of technical knowledge
is expected.
It is quite clear to me what ISO 2022 says. Yet, you do not reply to my
arguments by answering my questions, but instead attack my knowledge and
insulting me. You are very unprofessional.
For your home work, can I ask how MIME can labell itself in
EBCDIC environment?
Easily. The answer, however, depends on where in this "EBCDIC enviroment"
you want to talk about the message. Do we want to talk about the message as
it exists coming in to the TCP/IP process of the machine, where it is
expressed in ASCII character codes? If so, then it labels itself using the
ASCII codes for CRLF followed by the codes for "MIME-Version: 1.0" (or
legitmate variations of such characters as specified by RFC 1521). Do we
want to talk about the message as a text file stored on a VM file system in
which the characters are stored in EBCDIC format. If so, then it labels
itself by having a record which begins with the EBCDIC characters
"MIME-Version: 1.0" (or legitmate variations of such characters as
specified by RFC 1521), only substituting corresponding EBCDIC values for
ASCII characters. Of course, in each case, we must first assume that the
message is a legal RFC 822 message. But once we have established that, we
can relatively easily determine whether it is a MIME message.
But now I want answers to my questions. Once you have established that a
message is an RFC 822 message, how is it distinguishable in the character
stream that the message contains ISO-2022 characters, as opposed to any
other interpretation of exactly the same data? What RFC document can help
me identify the unique information in the RFC 822 message that shows me it
contains ISO 2022 characters? I put forward again:
I want you to give direct answers to the following questions:
1. Does ISO-2022 label itself as ISO-2022? If so, how?
2. If you do not know that a message is encoded in ISO-2022, is there any
way to discover this from the message itself. If so, how?
3. Does your entire argument rest on the assumption that every mail program
should automatically assume ISO-2022? If not, how can mailers figure out if
ISO-2022 is being used?
These questions are not answered by mere reference to "read ISO 2022".
For my multilingual single text, I will use ICODE (the encoding scheme
which you describe in the draft of your paper). Is your mail program
currently able to display it? If not, can you program it to do so?
Mail programs does not display anything....
Again, when I said "mail programs", I was referring to user programs that
display mail. In that sense, many mail programs are directly responsible
for displaying characters. Just because you use a terminal emulator to
display your mail does not mean the rest of us do.
...while I can program my terminal emulator to do so.
You can program your terminal emulator to display ICODE? It is a 21bit
code. How is it sent to your terminal emulator?
BTW, ICODE is 21bit code. How can you include it in mails?
Oh, I'm glad you asked. I plan to send you ICODE as a series of ASCII
characters, where each ICODE character is represented by three 7bit ASCII
characters. Of course, to conform to RFC 822, I will have to come up with
some sort of encoding to make sure that everything shows up in short lines
terminated by CRLF, and no characters in the stream can be confused as CRLF
characters. But I will let you know what encoding I will use.
Unfortunately, I will not label the character set as ICODE. It is up to
your terminal emulator program to distinguish it properly from ISO 2022.
I assume your shallow understanding confuse ICODE and IUTF.
You assumed wrong.
If I send you one message in ICODE and one message in ISO-2022, without any
distingishing labels, will your mail program be able to tell which one I
used and display it correctly every time?
Didn't I say ISO-2022-INT-* is designed carefully?
Yes, you can mix ISO-2022-INT-* and IUTF freely and the result
is mechanically distinguishable.
I didn't ask that. I asked if you could mechanically distinguish ISO-2022
from ANY encoding of characters I give you in an unlabeled message. Can
you?
(but many people will not be able to read your messages).
Are you saying you can read Japanese message if and only if it
is labelled by MIME?
The only way you can read an ISO-2022 encoded message that is *NOT*
I don't think you can read Japanese.
It is true that there are very few Japanese characters I recognize. There
are even fewer Japanese words I can properly speak. But how did you
determine that from the sentence fragment you quote there, where I say that
the only way you can read an ISO-2022 encoded message that is not labeled
is by assuming ISO-2022? Or was it that you were just trying to insult me?
You have again succeeded in using insults rather than explaining your
apparently weak position. In most debate circles, making ad hominem
arguments is a sure sign that you cannot defend your position. Should we
make that assumption and therefore stop listening to you, or will you
instead defend your statements?
ISO 2022 is not distinguishable in an RFC 822 message from all possible
other encodings of characters without some sort of label, be it MIME or
otherwise. If you think that statement is false, explain why.
pr
--
Pete Resnick - presnick(_at_)qualcomm(_dot_)com
QUALCOMM Incorporated
Home:(217)337-1905 / Fax: (217)337-1980