[Top] [All Lists]

Re: CTE:

1995-01-05 03:53:19
The point is that people, reportedly, do NOT accept automatic
QP downgrading of MIME and, instead, downgrade the original
text by themselves only to use 7bit.

That is, QP is a failure.

The same thing can you say about other ways of encoding 8-bit characters.

Sure. Why, do you think, we are using purely RFC 822 conformant

Maybe some people like MNEMONICS more than QP, maybe some people
like QP more than MNEMONICS. Maybe some people like some other
encoding more than anything else.

That's already too bad for QP.

Though I can't evaluate how serious the failure is, it is not
surprising to me if people in a small(?) community continues to
just-send-8bit forever.

This might be true, but note that you did write "small".

No. "small(?)".

As the
communication between non-computer-skilled people tend to rise,
the force onto us programmers to develop systems that can pass
email with any character set will rise, and we just have to
implement some systems that both can handle anything, and
is interoperable with everything else. I know that you one again
will talk about ISO-2022 constructions, and that might be
one way of going BUT (please read this BUT, Masataka) you must
label the character set.

What "BUT" means? ISO 2022 is the way to label character sets.

If you don't you will NOT be able
to send you message to any other messaging system, and think
that the message you did send is readable.

Why, do you think, we Japanese can continue to use ISO-2022-JP
without MIME for 10 years? Because labeling capability of ISO 2022
enables us to send our messages to any other messaging system, and 
the messages we did send are readable.

We are NOT using different tools to send English and Japanese mails.

Like that, with ISO 2022, we can freely mix English, Danish, French,
Greman, Chinese, Japanese, Korean, Vietnamese, Russian etc. without
MIME charset label without any difficulty.

So, we have two very, very important rules that we MUST follow:

1) You must be able to send information in a way that the
   receiver can reconstruct the original message.
2) Any user on the Internet must be able to reconstruct
   the message, both in the way of transfer encoding AND
   content format.

To do so for plain text messages, we don't need MIME.

What is your point?

When 8th bit truncated messages are merely just equally unreadable
as QP-downgraded messages, why not try to send as is without

This is completely wrong. The message itself WHILE ENCODED is unreadable,

See the reality of non-MIME users for whom QP is plain unreadable.



but the message is ot destroyed.

Don't say "completely wrong", when I didn't mention "destruction"
at all.

When text is unreadable, it is unreadable. Users don't mind whether
it is destroyed or not.

As long as you have a given
character set which include 8-bit bytes, there is NO WAY of sending
the message without destroying it, if you don't encode it in
some way. Today QP is choosen in sweden, MNEMONICS in denmark,

Completely wrong. Mnemonics are 7bit. ISO-2022-JP is too.

but the
way of doing this is not important, it is the fact that we are
using SOME transport encoding mechanism.

It IS important that people are using 7bit mechanisms and does NOT
reply on ANY special transport encoding mechanism.

In sweden I can see the last year that the rules when buying
email software have changed from "give me a cc-mail system" to
"give me a system that runs on all computers and sends messages
to all over the world without destroying the message". Note that
in the last sentence not even MIME is mentioned, but MIME is
choosen because MIME gives the tools you need to both label the
message with what transfer encoding that is chosen, and what the
message itself is (what character set for example).

Your hidden requirement is merely that "without destroying ISO-8859-1
encoded message", which implies MIME.

Once again, the important thing here is that people first of all
do NOT accept removal of the 8th bit AND they don't give a damn (sorry)
about what the message looks like when it is transferred.

If the requirement is "without destroying the message", the simple
solution of mnemonics and ISO-2022-JP is not to use the 8th bit.

Then, whether 8th bit is removed or not is totally unimportant.

What are you talking about? What MIME capability, do you think,

None, but I know what the people in denmark is doing, and they DO
use MIME as the functionality needed to lable the message with the
information about the MNEMONICS translation.

I don't think so.

Keld, how is it? Are people use MIME labelling for mnemonics?

Do you think all messages
in denmark is in MNEMONICS?

When you can send mixed messages in mnemonics and in ASCII without
charset labeling and reconstruct the original contents without
any difficulty, why do you think people bother to label?

Please read what I did write. I didn't write anything about MIME
in the sentence about the MNEMONIC stuff.

So, as QP is not preffered, MIME, which should have been related,
is made unrelated, which I call failure.

It is not! You MUST have a method of labelling the message with
the information that it is in MNEMONICS format, and they have
chosen MIME. One thing gives the other.

Read RFC 1345.

1) We can easily recognize text in mnemonics without any labelling.

2) If necessary, mnemonics itself has its own mechanism of labelling.

So, we don't have to have a method of labelling the message with
the information that it is in MNEMONICS format at all but have a
method of labelling the message.

What I was arguing about was that noone in daily life should
just-send-8 without first using some ESMTP extension.

In 821-ext context, you are right.

But, in 822-ext context where your choice is between just-send-8bit
and QP-downgrade, the answer in the real world seems to be

Maybe in your world, not mine. Note that you have more choices. You CAN
choose something else than QP.

Of course, strict RFC 822 conformance has been the choice of
us Japanese for these 10 years. QP is hopeless.

                                                        Masataka Ohta

<Prev in Thread] Current Thread [Next in Thread>