Abstract:
:> 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.
:
:So, imporve THE INFRASTRUCTURE. That is ALREADY DONE mostly on 8bitness
:with netnews.
The actual replay begins here.
Then, how can you begin mnemonic?
If you don't know the answer to this, read Keld's RFC.
I don't need the answer as I know it's worse than QP.
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?
Larger than MIME, I think.
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?
Compared to what? Why you want to compare? It is working completely well.
And for what percentage of the installed base?
All.
And how many vendors are currently developing support for ISO-2022-INT-*?
What support?
I know almost all the vendors are supporting ISO 2022.
I know ISO-2022-INT-* needs, unlike MIME, no specific transport support.
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
OK, you think MIME charset is a failure exactly with the same reason.
But, I expect mail users use terminal emulators which support languages
they can read.
+ reads mail using a user agent that parses the headers and extracts
the relevant fields and displays them in fields on a screen.
What are you talking about? As long as ISO-2022-INT-* is used
with RFFC 822, any user agent can parse and diplay any header.
+ reads mail on the other side of a gateway
That's another fatal-by-your-definition problem of MIME.
Unlike MIME, ISO -2022-INT-* needs no specific transport support.
Taken together, this probably is the vast majority of Internet email
users!
Thanks for your explanation why MIME has failed.
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.
Which install base?
ISO-2022-JP has been compatible with the existing installed base since
the day 1. So is and will be ISO-2022-INT-*.
So, could you say something based on real experiences?
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.
UA should know it.
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.
So, use the canonical form.
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.
I don't mind if majority of people are using local encoding forever.
As the majority (or all) of people can use ASCII and their local
encoding mixed freely, they can use ISO-2022-INT-* and their local
encoding mixed freely.
So, if someone want to use charcters not contained in their local
encoding, they should extend their local encoding also recongnize
ISO-2022-INT-* without sacrificing the capability to continue to use
the local encoding.
Thus, using ISO-2022-INT-* does not add anything about the complexity
of local decoding.
No. But neither does it help much.
It does help much to extend the local encoding wihtout introducing
a lot of interoperability issues.
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.
Saying "we don't need it anymore though you may still accept it"
requires no such things.
Not to mention the
amount of commercial investment in MIME products, many of which are
just starting to appear.
Not to mention the
amount of commercial investment in OSI products, many of which are
just starting to appear.
It's not going to happen.
No.
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.
And even if people were willing, it would take several *more* years to get
people to agree on any successor to OSI which wasn't compatible with OSI.
So any such effort is going to result in a "future extension".
May OSI and MIME extend without any limit.
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.
So, imporve THE INFRASTRUCTURE. That is ALREADY DONE mostly with
netnews.
Removing charset and CTE should be a good starter.
Why aren't you pushing X.400 then?
Do you want to say X.400 is less uglier and a lot simpler than MIME that
I should push it? Why aren't you pushing X.400 then?
Masataka Ohta