rfc2047.el bug?

[Katsumi Yamaoka <yamaoka@jpl.org>]

Hi,

It actually may not cause a problem, but there's something wrong
in rfc2047.el.  This is an extract from rfc2047.txt:

   An 'encoded-word' may not be more than 75 characters long, including
   'charset', 'encoding', 'encoded-text', and delimiters.  If it is
   desirable to encode more text than will fit in an 'encoded-word' of
   75 characters, multiple 'encoded-word's (separated by CRLF SPACE) may
   be used.

   While there is no limit to the length of a multiple-line header
   field, each line of a header field that contains one or more
   'encoded-word's is limited to 76 characters.

   The length restrictions are included both to ease interoperability
   through internetwork mail gateways, and to impose a limit on the
   amount of lookahead a header parser must employ (while looking for a
   final ?= delimiter) before it can decide whether a token is an
   "encoded-word" or something else.

Gnus sometimes encodes a Japanese-English mixture text to the
line length exceeding 76 characters.  For example:

Subject: 寿ju 限ge 無mu 寿ju 限ge 無mu 五go 劫kou

Subject: =?iso-2022-jp?b?GyRCPHcbKEJqdSAbJEI4QhsoQmdlIBskQkw1GyhCbXUgGyRCPHcbKEJqdQ==?=
 =?iso-2022-jp?b?IBskQjhCGyhCZ2UgGyRCTDUbKEJtdSAbJEI4XhsoQmdvIBskQjllGyhCaw==?=
 =?iso-2022-jp?b?b3U=?=

The following is a case of using FLIM's eword-encode.el:

Subject: =?ISO-2022-JP?b?GyRCPHcbKEJqdSAbJEI4QhsoQmdlIBskQkw1GyhCbXUg?=
 =?ISO-2022-JP?b?GyRCPHcbKEJqdSAbJEI4QhsoQmdlIBskQkw1GyhCbXUgGyRCOF4bKEJn?=
 =?ISO-2022-JP?b?byAbJEI5ZRsoQmtvdQ==?=
-- 
Katsumi Yamaoka <yamaoka@jpl.org>