ietf-822
[Top] [All Lists]

Re: interoperablity

1994-09-16 11:58:38
However, on reflection it does appear that (in particular) 
quoted-printable was not as well accepted as was anticipated.
People who were used to seeing correctly formed characters 
did not react favorably to instead seeing =XX, even if =XX 
occurred seldom enough that the text could still be understood.

Then, how can you begin mnemonic?

If you don't know the answer to this, read Keld's RFC.

Ohta-san's approach works okay for people who are displaying messages 
on terminals that support ISO-2022 escape sequences.  Either of them 
will work if there is appropriate decoding/display software on the
recipient end.

As described in our drafft, MULE (Multilingual emacs) is such an
editor which support all the character sets of ISO-2022-INT-* and more.

Okay.  But what percentage of the installed base is using MULE?

Neither of them works well
for everyone, and neither of the schemes will work (without additional
encoding) for message headers.

ISO-2022-JP as is without any encoding is ACTUALLY WORKING NOW completely
well for unstructured message headers. So is ISO-2022-INT-*.

Working compared to what?  And for what percentage of the installed base?
And how many vendors are currently developing support for ISO-2022-INT-*?

ISO-2022-INT-* "works" for a very small class of users.  It will
probably fail for any one who:

+ reads mail from a terminal that doesn't support the escape sequences
  that it uses, or using a PC terminal program that doesn't support those
  escape sequences
+ reads mail using a user agent that parses the headers and extracts
  the relevant fields and displays them in fields on a screen.
+ reads mail on the other side of a gateway

Taken together, this probably is the vast majority of Internet email
users!

I *like* the approach that ISO-2022-INT-* takes, but (like mnemonic)
it's not really very compatible with the installed base when taken
as a whole.

I don't mind so much if we can't use internationalized encoding for the
time being. I don't mind so much either if we must use QP encoding for
the structured headers ONLY.

That just makes things more confusing for the user, who doesn't know
which fields are structured and which ones aren't.

QP decoding is merely CTE decoding. Further decoding is necessary if
local convention to represent some charset is different from
that used in message, which has been happening in Japan for
more than 10 years. 

Yes, but that is true regardless of which charset is used in the
canonical form.  You always have the potential need to translate
from the local charset to a standard charset (before encoding)
when sending a message, and to translate from the standard charset
(after decoding) to whatever your display hardware can cope with.
That's an inherent part of the internet email model.

If the "standard" charset were ISO-2022-INT-*, some people's
mailers wouldn't have to do the translations...but many others
(probably the majority) would still require it.

Thus, using ISO-2022-INT-* does not add anything about the complexity
of local decoding.

No.  But neither does it help much.  

You can think of bare MIME as a "worst case" solution.  It is somewhat 
ugly and it is somewhat painful to migrate to it, but it is also very
general and it provides a smooth mechanism to migrate to future 
extensions.

Future extension? No, that is the wrong way.

Well if you want such changes now, you're going to convince EVERY 
SINGLE ONE of a large number of people to abandon several years of
investment in the way MIME currently works.  Not to mention the
amount of commercial investment in MIME products, many of which are
just starting to appear.

It's not going to happen.

And even if people were willing, it would take several *more* years to get
people to agree on any successor to MIME which wasn't compatible with MIME. 

So any such effort is going to result in a "future extension".

Now is the time to have a dedeployment plan for MIME to REMOVE
ugliness, that is, to REMOVE ugly ffeatures, as much as possible.

This won't happen until the email infrastructure is upgraded for everyone, so
that we don't *need* the ugliness to preserve the contents of the message.

Removing charset and CTE should be a good starter.

Why aren't you pushing X.400 then?

Keith

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