"Ned Freed, Postmaster" <NED(_at_)hmcvax(_dot_)claremont(_dot_)edu>:
I don't see how we could possibly make it mandatory to be able to display
the glyphs from iso-2022-jp. I also would resist the addition of any
such requirement. It is also not required that the glyphs in 8859-n be
displayable.
I agree at this point. My thought all the time was that the RFC is
defining different ways of presenting a message, not defining what
a UA has to be able to display. The requirements that the RFC should
have on the mailing system is that the different character sets
defined (iso-2022-jp and the different 8859-n) CAN occur in a mail
and it must take care of this.
Depart from this the second question is if the UA displays the correct
glyphs and from my point of wiew the RFC can not have such requirements.
If an incoming mail defines that it uses 8859-4 and my dumb terminal
is only able to display 8859-1 (at most) my oppinion is that either
the characters with the eighth bit set could be displayed as anything
at all, as 8859-1 characters or why not include Keld's MNEMONICS
in my UA, so all character sets I don't know about (in this case all
other than 8859-1) is converted to MNEMONICS.
We can NOT stop the usage of 8859-n in mail. Almost all manufactures
that sells sendmails in sweden already put 8859-1 in their outgoing
822-mail on their UNIX-systems. I don't know if you have the same
problem in Japan with 2022, but on the NORDUnet we already have a uge
problem with SMTP and NNTP and 8859-1.
Given the choice between no MIME and MIME without indirect references to
10646, I'll take the latter. We can always reserve the name with IANA and
write a separate informational RFC to describe the planned direction we want
to take.
I agree.
SUMMARY:
Omission of ISO-8859-N support would be a ship-stopper.
It is most definitely a SHIP-STOPPER from the NORDUnet point of view.
In the mail handeling working group in the NETF (Nordunet Engineering
Task Force) in Copenhagen this fall, we agreed that ISO-8859-N MUST be
supported by the RFC. That means that if support for 8859-N is deleted
from the RFC, most certanly you will have an official descision from
the NORDUnet of a SHIP-STOPPER.
Prohibition of ISO-2022-JP support would be a ship-stopper.
Agreed!
RFC-CHAR should be published at least informationally.
Yes!
ISO-10646 should be mentioned in rationale text with
specification and non-experimental use deferred to an RFC
written after it becomes final.
If it is possible to do this I agree. If it is not possible I strongly
recommend moving this text to a separate informational RFC ASAP.
I agree with Ned in this point. Until 10646 or something else
worldwide character set is defined up to the last character, I would
like to recommend Keld's MNEMONICS which is the best uniform character
set we have. Especially when tho character sets "collide" or the
defined set is not supported in the UA.
Use of all other character sets should be explicitly discouraged.
Agreed.
Yes.
Happy New Year everybody!
Patrik