Subject: mimehead1.2 -- ISO-2022-JP encoder/decoder
From: ysato@etl.go.jp (Yutaka Sato =?ISO-2022-JP?B?GyRCGyRAOjRGI0stGyhK?=)
Date: Thu Feb 24 06:22:30 JST 1994
Organization: Electrotechnical Laboratory, Tsukuba Science City

先日 mime-MLで提案した、ISO-2022-JP 固有のスペースのエンコーディング規則
(B案)を、toMime/fromMimeに組み込んでみました。コマンドライン引数を指定す
れば、この規則を使わないようにもできます。

    fromMime [-s] [-h] [in-file]

    toMime [-s] [in-file]

-s をつけると、B規則を使わず、従来の通りに動作します。
-h をつけると、ヘッダのみを出力します。

この他に mimehead1.1 では、連続するencoded-wordの間に「もともと」存在
していた空白（も、RFC1522により削除さてしまう）を、encoded-wordの中に
表現するようにしています。これらにより、以下のような JIS/ASCII混じり
文中の空白情報を忠実に転送できます。

Summary: aあb, aあ b, a あb, a あ b, あ い う

┰── ─┰─ ┰　　  ／／＼^^   ..
┠─++佐藤＠ＥＴＬ　／  876m＼  (- @)Э
┸── 　┸　 ┸────────────────────────────┘
---------------------------------------------------------------------------
X-Seqno: 1132
Date: Sat, 19 Feb 94 16:40:15 JST
Return-Path: <ysato@etl.go.jp>
Mime-Version: 1.0 (generated by vin2.0)
Content-Type: text/plain; charset=ISO-2022-JP
To: mime@etl.go.jp
Subject: [MIME] ISO-2022-JP local rule for space encoding
From: ysato@etl.go.jp (Yutaka Sato =?ISO-2022-JP?B?GyRAOjRGI0stGyhK?=)
Organization: Electrotechnical Laboratory, Tsukuba Science City
Message-Id: <jPO9q.ysato@etl.go.jp>

電総研の佐藤です。

metamail-2.7 の公開が近づいて来たので、しばらく離れていたRFC1522エンコー
ダ、デコーダをいじり始めました。プログラムを直しながら、以前から積み残さ
れている空白情報のエンコーディング規則を考え直してみたところ、以前の案と
全く違う方式が出て来ました(^_^;)

そんなわけで、これをＢ案としてＭＬに提出します。（以前の案を、Ａ案と呼ぶ
ことにします）

============================================================================
　ISO-2022-JPのためのRFC1522エンコーディング規則 (Ｂ案 version B.1, 940219)
============================================================================

１．方針

Ａ案とは１８０度方針を転換して、元テキストの中の空白を encoded-word の外部
に残すことを考えてみました。

エンコーダは、挿入した空白の存在を、ISO-2022-JP encoded-text の先頭において
「余分なISO-2022の文字セット切り替えシーケンス」で指示することにします。
デコーダはこの指示に基づいて、挿入された空白の削除を行うことになります。


２．エンコーディング規則

encoded-word の前後に接する空白の削除のための指示コードとして、以下のような
ISO-2022 の文字セット切り替えコードを使用することにします。

                        削除指示
      略記  指示コード　 前　 後
      ----  ----------  ---- ----
       Ａ   なし　　  　 0　  0
       Ｂ   ESC $ B　  　0    1
       Ｃ   ESC $ @　  　1    0
       Ｄ   ESC ( J　    1    1
     　Ｅ   ESC ( B　   (未使用)


これを用いて、例えば以下の src のような文字列を、 dst のような文字列にエン
コードします。（{text} は textの encoded-word を表すものとします）

         src            dst
       --------    --------------
　(1) 　a あ b 　　a {ＢあＥ} b
　(2) 　aあ b　　　a {ＢＢあＥ} b
　(3) 　a あb　　　a {ＣＢあＥ} b
　(4) 　aあb 　　　a {ＤＢあＥ} b
　　　　　
明示的に空白情報の削除を指示することにより、本規則を用いたエンコーダとデコ
ーダの間では、空白情報が忠実に転送されます。


３．互換性

互換性の観点から、本規則を用いたエンコーダ・デコーダと、そうでないエンコー
ダ・デコーダとの間で encoded-word が渡された時に、余分な空白の挿入や必要な
空白の削除が起こらないことが必要です。

以下では簡略化のために、エンコーダ、デコーダを次のように略記します。

　　NE  本規則を用いないエンコーダ
　　SE  本規則を用いたエンコーダ
　　ND  本規則を用いないデコーダ
　　SD  本規則を用いたデコーダ

　NEの出力を読むND,SDの等価性
　　NEは、上記の (1-4).src の全てを (1).dst の形式にエンコードする。
　　(1).dst を入力する ND, SD はともに (1).src を出力する。したがって、
　　NE から見て ND と SD は等価である。

　NDの入力としてのNE,SEの等価性
　　ND は、SE の出力 (1-4).dst を全て (1).src にデコードする。すなわち
    SE の出力 (1-4).dst  は、NE の出力 (1).dst と等価である。したがって、
　　ND から見て SE と NE は等価である。

（なんか説明が変かな？）
以上により、異種のエンコーダ、デコーダの間での等価性が保たれます。


４．評価

本案は、Ａ案の2.(0-6)にあげた要求を満たしており、Ａ案のような例外規則がなく、
また互換性についての問題を解消しています。また、encoded-wordに接する空白が
存在する時に、Ａ案では encoded-wordの外と内の両方に表現する必要だったのが
本案では外側だけで済みます。ただし、encoded-wordに接する空白が存在しない時、
空白削除指示コードの分、表現効率は悪くなります。というこで、元テキストがこ
のどちらを多く含むかによりますが、総体的に見て表現効率はコンパラブルになる
のではないかと思います。

古株の方はお気づきと思いますが(^_^)、実際のところこの案は、Ａ案より前に
（最初に）検討された方法を焼き直したものであります。
============================================================================

この案にコメントいただけると幸いです。（今から実装に入ります^_^）


┰── ─┰─ ┰　　  ／／＼^^   ..　　　★ｏｎｅｗ2.2+ｊｖｉｍ2.0発売中★
┠─++佐藤＠ＥＴＬ　／  876m＼  (- @)Э　 etlport.etl.go.jp:pub/onew/*.gz
┸── 　┸　 ┸────────────────────────────┘

******************** 参考 (Ａ案) **************************************
X-Seqno: 1005
Date: Wed, 13 Oct 93 22:12:49 JST
Return-Path: <ysato@etl.go.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-2022-JP
To: mime@etl.go.jp
Subject: [MIME] Re: ISO-2022-JP local rule for space encoding
From: ysato@etl.go.jp (Yutaka Sato =?ISO-2022-JP?B?GyRAOjRGI0stGyhK?=)
Organization: Electrotechnical Laboratory, Tsukuba Science City
Message-Id: <ikzrj.ysato@etl.go.jp>
References: <199310120913.SAA29464@alps.msr.mei.co.jp> 
	<ikdRH.ysato@etl.go.jp> <9310130343.AA12997@seraph.ntt.jp> 
	<ikws+.ysato@etl.go.jp>

空白のエンコーディングに関してのこれまでの議論をまとめてみました。
コメントをお願いします。

                                              93-10-13  ysato@etl.go.jp
========================================================================
　　ISO-2022-JPローカルRFC1522エンコーディング規則（第１次案）
========================================================================
０．はじめに

以下では、ISO-2022-JP(RFC1468)のテキストを、MIME-PART2(RFC1522)により
RFC822メッセージヘッダ中に表現する際、空白情報を損なわずにエンコード／
デコードするための、ISO-2022-JPにローカルな規則について提案する。
なお、以下で「空白」とは、RFC822で言う"linear-white-space"を指す。


１．問題

RFC1522では、RFC822フィールド内でのencoded-wordの検出を確実かつ容易に
するために、原則としてencoded-wordの前後に空白を必要とする。ところが、
ISO-2022-JPでは、ASCII文字に（間に空白を挟まずに）非ASCII文字列が接す
るテキストが現れる。そこで、このようなテキストをエンコードする際には、
ASCII文字と encoded-word化された非ASCII文字列との間に特別な空白を挿入
し、デコード時に除去しなければならない。一方で、このようにエンコード
時に挿入された空白と、元のテキストに存在した空白とは区別されなければ
ならない。現状では、１）を表現することができず、１）と２）を区別でき
ない。

　１）日/英　　→　=?J?B?日?= / =?J?B?英?=　→　日 / 英
　２）日 / 英　→　=?J?B?日?= / =?J?B?英?=　→　日 / 英


また、規格がRFC1342からRFC1522に修正された段階で、「連続するencoded-
wordの間の空白情報は、全て無視する」という規則が導入された。これは、
複数のencoded-wordに分割されて表現されたencoded-textの再結合のための
規則であるが、これにより、元のテキストの中にあった「非ASCII文字列の
間に挟まれた空白」(例 "戸村 哲")を、encoded-wordの外で表現できなく
なった。本規則は、この問題も含めた解決策である。現状では、以下の３）
を表すことができず、３）と４）を区別できない。

　３）日 英　　→　=?J?B?日英?=　　　　　　→　日英
　４）日英　　 →　=?J?B?日?= =?J?B?英?= 　→　日英


２．方針

上記の問題を解決するために、エンコーダとデコーダとの間で、ISO-2022-JPの
テキストを扱う場合に限ったローカルな規則を導入する。この規則は、以下の
条件を満たさなければならない。

　(０) 空白情報を保存してエンコーダからデコーダに伝えられること
  (１) エンコード結果が、本規則に従わないデコーダに害を与えないこと
　(２) 本規則に従わないエンコーダの出力をデコードしても障害のないこと
　(３) 厳密なRFC822に限らず、慣習化した表現なら、それを損なわないこと
　(４) エンコード結果が、RFC1522のencoded-wordの表現の規約に従うこと

また、以下のことが望まれる

　(５) ASCIIで書かれた部分、例えばローマ字/漢字併記で書かれたローマ
　　　字Subjectなどの部分は、なるべくエンコードしないこと。
　　　これは非MIMEなMUAのために望ましい。
　(６) RFC822のフィールドや詳細な構的を知らずに、エンコードができる
　　　こと。これは、エンコーダの簡便な実現のために望ましい。


３．規則

　(１) ISO-2022-JP encoded-text

元のテキスト中で、encodeされるべきテキストに接して存在した空白情報は、
encoded-textの中に表現することとする。したがって、charsetがISO-2022-JPの
encoded-wordの外に隣接する空白情報は、エンコーダまたは転送経路の MTAなど
によって挿入されたものと見なされ、デコーダによって除去されることを原則と
する。ただし、フィールド名の後の":"の直後に接する空白につていは、従来の
MTAやMUA、および 本規則に従わないRFC1522エンコーダ／デコーダの安全のため
に、この挿入・除去規則を適用しない。

  (２) エンコード

(2-a) フィールド名":"の直後にある空白までは、エンコーディングの
　　　対象としない。すなわち(2-b)を適用しない。
(2-b) encodeされるべきテキストに空白が接している場合：
　　　その空白を残すとともに、encoded-textの中にもエンコードする。
(2-c) encodeされるべきテキストに空白が接していない場合：
　　　encoded-wordに接する部分に、空白を挿入する。

  (３) デコード

(3-a) フィールド名の後の":"の直後にある空白までは、デコーディング
　　　の対象としない。すなわち、(3-b)を適用しない。
(3-b) encoded-wordに接する空白は全て除去する


４．補足

上記(2-a)および(3-a)は、本規則に従わないエンコーダによる結果を本規則で
デコードした場合、あるいはその逆に、本規則に従ってエンコードされた結果
をそうでないデコーダでデコードした場合の安全のために導入された例外規則
である。フィールド名の後の":"に続く空白は、RFC822上では不要なものである
が、慣習的に広く用いられているため、この空白の存在を前提としている MTA
やMUAが存在し得る。そのため、この部分の空白情報については、本規則の採用
の有無に関わらず保存されることが重要であると考え、上記の例外規則が導入
された。

また、ISO-2022-JPはUS_ASCIIをサブセットとして含むため、1.(1-4)の問題の
多くは、ASCII部分も含めてencoded-textにすることで、解決が可能である。
これを2.(5-6)の要求を満たしつつ実現するような「かしこいな」エンコーダが
作られることに対して、本規則は何んら否定するものではなく、また併用にも
問題がないと考えられる。また、そのようなインテリジェンとな方法でも、
RFC822の構文要素となっている文字との間に要求される空白は、RFC1522によ
り要求されるため、元テキストに空白が存在しない場合の挿入と除去が必要
であることに変わりはない（＊）。

５．検討

ISO-2022-JPのMIMEエンコーディングに限らず、従来のRFC821/822の実装におい
て一般に、空白情報の忠実な伝達は保証されていない。ヘッダ中の空白情報を
置き換えたり、折り返しの位置を変更するような MTA/MUA は少なからず知られ
ている。これらに対処する上でも、本規則の導入は意味のあるものと考える。

この規則が普及するまでの過渡的な状況においては、この規則に準拠するコー
ダとそうでないものとの間で通信が行われる。この際起こる不整合の問題と
して、以下の２つが考えられる。

(1) 本規則に準拠しないエンコーダの結果が、本規則に従ってデコードされた場合
　　・元のテキストにあった空白が失われる

　　例）日 / 英　→　=?J?B?日?= / =?J?B?英?=　　→　日/英

(2) 本規則に準拠するエンコーダの結果が、そうでないデコーダに渡された場合
　　・余分な空白が挿入される

　　例）日 / 英　→　=?J?B?日 ?= / =?J?B? 英?=　→　日  /  英

以上の問題があるが、これらはもともと空白情報の伝達が保証されていない
状況において、許容し得るものと考える。


６．経緯

ここで述べた、空白の挿入・削除規則は、RFC1522のdraft standard化にあたり
元規格に導入することが検討されたが、すでに広まっていたRFC1342との非互換
性の問題、およびISO-2022-JP以外では必要性が薄いことなどから、ISO-2022-JP
のローカルルールとしての採用を検討することになったものである。

MIMEメイリングリストでは、この規則をISO-2022-JP(RFC1468)へ反映させる
べく検討を続けてきた。これはそれらの検討の結果をまとめた、第１次案である。

========================================================================
******************** 参考 ***********************************************
