Subject: features for I18N: TM style charset definition

From: Jungshik Shin <[email-masked]>
Date: 8 Jan 1997 15:11:11 -0500

TM(Tools for MIME) quite widely used by Emacs mania 
have a couple of very useful features mising in Pine.
Not being an Emacs fan, I don't wanna learn Emacs 
to make use of them available in TM. I'd rather see
them implemented in a future version of Pine, my
favorite and (really superb) mail client.  

  Enclosed below is a little bit cryptic(I hope not)
description of features  I'd like Pine developers pay attention
to and implement in next release. In case more elaboration
is necessary, I'll back up later.

------------
  Follow the model of TM(Tool for MIME)

Allows users to define a list of 4-field record for each
charset.

  1. charset name for body
    
     e.g. ISO-8859-1, US-ASCII, EUC-KR, EUC-JP, ISO-8859-7
          KOI-8, etc

      Due to a little bit peculiar char. of Korean mail,
      if charset for body is EUC-KR and available transmission
      level is 7bit(required transmission level for EUC-KR 
      is 8bit), charset name to be put 	in the 'charset' field
      of 'Content-Type: ' header is not EUC-KR but ISO-2022-KR
      and body should be encoded into 7bit ISO-2022-KR.
      Thus, a special treatment harmless to all other cases
      is needed.

  2. optional charset name for header
     if not defined, use the value of the 1st field.

     This option is useful for following two cases. One is
     when different charsets are used in body and header
     (Japanese body and French Subject) as mentioned
     in documents for sendmail 8.8.x by the author of
     sendmail. The other is RFC 1557 conformant
     Korean message which requires ISO-2022-KR body
     and B/Q encoded EUC-KR header.

  3. required transmission level for the charset
     specified in 1. 
      : 8bit, binary, 7bit

   e.g. US-ASCII has required transmission level 7bit
       while most others have 8bit(e.g. ISO-8859-X
       and EUC-{CN,JP,KR}, KOI-8)

  4. whether or not to enforce encoding
     regardless of ESMTP neogotiation result
     if not defined, do not enforce, but follow the
     result of ESMTP negotiation.
     This is useful when using MTAs which are 
     8bit clean , but are not RFC 1651/1642-compliant.
     (e.g. sendmail 8.6.x)

  5. encoding method to use : base64/qp, 7bit
     when required transmission
     level is higher than one available  according
     to the result of ESMTP negotiation

     Default: 7bit for CJK(Chinese,Japanese,Korean
     Refer to RFC 1922,1468 and 1557, respectively)
     and base64/qp for all others.

  6. encoding filter command to use 
     when encoding scheme designated in 5 is not
     supported internally.
     Ignored if specified for base64/qp and other
     internally supported encoding method in 5.

     For instance, 7bit encoding for EUC-KR(Korean)
     charset needs "EUC-KR to ISO-2022-KR" filter
     which may or may not be supported internally
     by a future version of Pine. If not, users
     can specify their own filters. The same is
     true of ISO-2022-JP and ISO-2022-CN. 

Example of pinerc entries are 

mime_charset_definition={us-ascii/us-ascii/7bit///},
       {iso-8859-1/iso-8859-1/8bit/no/qp/},
       {iso-8859-5/iso-8859-5/8bit/no/base64/},
       {hz/hz/7bit/no//},# HZ; 7bit Chinese charset used in alt.talk.chinese.hz
       {euc-kr/euc-kr/8bit/no/7bit/hmconv},
       {iso-2022-jp/iso-2022-jp/7bit/no//} 

  where 'hmconv' is a converter between EUC-KR and ISO-2022-KR.

In composition session,  allows users to interactively change charset
for body thus making switching between one lang/charset and another much
easier and faster than now. Of course,there should be a way to set
default body charset as is currenly the case, so that most users who
never send messages in more than one charset/lang. don't have to bother
with charset setting. Also, let users override default  charset for
headers determined from the value of hdr charset field(item 2) in the
above list corresponding to the body charset specified in composition
session. Need for this arises because charset in header is not
necessarily charset used for body(i.e.  one can send a message with
Korean body and German Subject)

   I wish this proposal would be carefully considered by Pine
development team and would make itself into next release of Pine.

     Jungshik Shin

---

From: Andrej Borsenkow <[email-masked]>
Date: Mon, 13 Jan 1997 12:23:47 +0300 (MSK)

On 8 Jan 1997, Jungshik Shin wrote:

[ the detailed description omited ]

> development team and would make itself into next release of Pine.

And I wish to second this request.

best wishes

-------------------------------------------------------------------------
Andrej Borsenkow 		Fax:   +7 (095) 252 01 05
SNI ITS Moscow			Tel:   +7 (095) 252 13 88

NERV:  borsenkow.msk		E-Mail: [email-masked]
-------------------------------------------------------------------------