Subject: patch for supporting RFC 1557(Korean mail)

From: Jungshik Shin <[email-masked]>
Date: Wed, 10 Jul 1996 08:43:49 -0400 (EDT)

Hello,

  I sent following message to the address for Pine feature suggestion,
but haven't received any response, automatic or human. I understand well
that Pine team can't reply to all individual suggestions, but
automatic(machine) response would be better than no response at all.
Hence, I decided to sent it to pine-info.  I would be very grateful to
Pine team if this patch is accepted and included in upcoming
release(3.95) of Pine. It's for Korean mail exchange compliant to RFC
1557 and dose NOTHING if charset is NOT set to 'iso-2022-kr' (Korean
mail exchange code).

    Jungshik Shin

-------------------
  To whom it may concern:

  First of all, I'd like to express my deep thanks for developing
wonderful mail program, Pine. I have a small patch to
strings.c in Pine 3.94 source to support RFC 1557
(Korean mail exchange standard similar to those for
Japanese - RFC 1468- and Chinese - RFC 1922- mail.).

  RFC 1557 states that Korean message body in EUC-KR (KSC 5601) be
encoded in ISO-2022-KR(again similar to ISO-2022-JP and ISO-2022-CN),
which is 7bit. Body encoding/decoding can be handled by 'sending filter'
and 'displayfilter' and doesn't have any problem with Pine with possible
exception of Pine 3.93 under Solaris 2.4 where my filter program leads
to error.  It's also stated that 8bit EUC-KR in header of a message be
either B encoded or Q encoded with charset name 'EUC-KR'.  However,
'Content-Type:' header is specified to have 'iso-2022-kr' as the value
for the parameter 'charset'. Thus, Korean message header should look
like following

Subject: =?EUC-KR?B?<B encoded euc-kr>?=
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-2022-kr
Content-Transfer-Encoding: 7bit

  Unfortunately, current version of Pine (3.92,3.93,3.94) doesn't offer a
way to specify two different character set names to use in 'charset='
field and encoding of 8bit characters in header. It's understandable
that Pine doesn't have that facility since RFC 1557 is rather peculiar
in this aspect.  RFC 1468 and 1922 don't mention about header. What my
patch to 'strings.c' does is use 'EUC-KR' as 'charset' name in  encoding
of 8bit chars in header IF and ONLY IF 'charset' designated in 'pinerc'
is 'iso-2022-kr'(case insensitive). One more it does is enforce 'B'
encoding of header when 'charset' in 'pinerc' is 'iso-2022-kr'. The
latter is not required by RFC 1557, which specifies that either Q or B
encoding can be used, but is necessary since most of RFC 1557
implementation(modified Sendmail for Korean. MTA-level implementation
was inevitable as  POP3 clients such as Netscape and Eudora don't
support RFC 1557) used in and outside Korea recognize and decode only B
encoding (of course, MIME-capable MUA can handle Q encoding as well).

  My patch has absolutely NO effect at all if 'charset' is NOT
'iso-2022-kr' and accordingly I think it fits well. Before
my patch is accepted and reflected in newer version of Pine,
I'd like to know if I could distribute my patch as 'Pine 3.94K'
('K' for Korean. I think 'L' is too generic).

  Once again, I greatly appreciate you for an excellent  mail
program and wish my patch would be carefully considered.

   Sincerely,

    Jungshik Shin

P.S. For more information on Korean mail exchange, you 
may refer to my Hangul FAQ at 
http://pantheon.cis.yale.edu/~jshin/faq/hmail.html
and http://pantheon.cis.yale.edu/~jshin/faq/qa8.html
and references therein.(e.g. Ken Lunde's CJK info.
or Choi,Woohyung's 'Hangul Sendmail' page - Hangul
is the Korean writting system)

-------- patch  for strings.c in pine-3.94/pine directory --------
-------- generated by 'diff -c strings.c strings-new.c ----------

*** strings.c	Mon Jul  8 09:24:41 1996
--- strings-new.c	Sun Jul  7 16:51:48 1996
***************
*** 1918,1926 ****
  	      enc = (n > (2 * (p - s)) / 3) ? 'B' : 'Q';
  	int   slen;
  
  	while(*s){
  	    sstrcpy(&d, RFC1522_INIT);		/* insert intro header, */
! 	    sstrcpy(&d, charset);		/* character set tag, */
  	    sstrcpy(&d, RFC1522_DLIM);		/* and encoding flavor */
  	    *d++ = enc;
  	    sstrcpy(&d, RFC1522_DLIM);
--- 1918,1933 ----
  	      enc = (n > (2 * (p - s)) / 3) ? 'B' : 'Q';
  	int   slen;
  
+ 
+         if ( ! strcasecmp(charset, "iso-2022-kr") )
+            enc = 'B';
+ 
  	while(*s){
  	    sstrcpy(&d, RFC1522_INIT);		/* insert intro header, */
!             if ( strcasecmp(charset, "iso-2022-kr") )
! 	        sstrcpy(&d, charset);		/* character set tag, */
!             else 
!                 sstrcpy(&d,"EUC-KR");
  	    sstrcpy(&d, RFC1522_DLIM);		/* and encoding flavor */
  	    *d++ = enc;
  	    sstrcpy(&d, RFC1522_DLIM);
***************
*** 1929,1935 ****
  	     * feed lines to encoder such that they're guaranteed
  	     * less than RFC1522_MAXW.
  	     */
! 	    p = rfc1522_encoded_word(s, enc, charset);
  	    if(enc == 'B')			/* insert encoded data */
  	      sstrcpy(&d, t = rfc1522_binary(s, p - s));
  	    else				/* 'Q' encoding */
--- 1936,1945 ----
  	     * feed lines to encoder such that they're guaranteed
  	     * less than RFC1522_MAXW.
  	     */
!             if ( strcasecmp(charset, "iso-2022-kr") )
! 	        p = rfc1522_encoded_word(s, enc, charset);
!             else 
! 	        p = rfc1522_encoded_word(s, enc, "EUC-KR");
  	    if(enc == 'B')			/* insert encoded data */
  	      sstrcpy(&d, t = rfc1522_binary(s, p - s));
  	    else				/* 'Q' encoding */
------------------