出沢です

mew のほうの ML で聞いて、明確になりました。

ユーザが入れた 空白(改行を含む)も、MUA が入れる 空白 とは
区別できない。そして復号時にどちらも削って良い。

とのことです。
これで encode は楽になりました。
その代わり、復号時にどのように空白を消すべきか、という
あらたな問題が出て来てしまいましたが。
消さないでも RFC 的には問題ないのですが、それだと
もともと 1行のものが2、3行に別れてしまうので、、、

週末には出せるでしょう。 Subject とか アドレスfield用には。

MIME パラメータ用は、行を分ける時の作法が新たに定義されて
いるのですね。 RFC2231

        Content-Type: message/external-body; access-type=URL;
         URL*0="ftp://";
         URL*1="cs.utk.edu/pub/moore/bulk-mailer/bulk-mailer.tar"

   is semantically identical to

        Content-Type: message/external-body; access-type=URL;
          URL="ftp://cs.utk.edu/pub/moore/bulk-mailer/bulk-mailer.tar"

これら用にはどういう仕様がよいか、それらは別にすべきか?

もっとも、 RFC2231はまだちゃんと読んでいないので、ここに B encode や 
Q encodeを "" で挟んで!! 入れて良いとされているかどうか未確認です。
もし駄目よ、ってことなら mime.rb の というか、{en,de}code64 の
範疇ではないから今回は気にしない。
     
dezawa> 一応 「仕様です」以外の BUG はなくなった様なのですが、
dezawa> 仕様です 部分に付いての御意見を。
dezawa> 
dezawa>      53_bytes_ASCII_string_with/without_white_space あ
dezawa>     あ 53_bytes_ASCII_string_with/without_white_space
dezawa> 
dezawa> このような行をencodeするとき、
dezawa>   1 decode したら空白も含め元通りになり、
dezawa>   2 ASCII だけの所を encode する事はやらない
dezawa>   3 76Byte制限を守り、
dezawa> 
dezawa> という条件を満たす事が出来ません。守るべき優先順は
dezawa> どのようにしたいでしょうか。