FLIM 1.13.2 message/external-body parsing

[守岡 知彦 / MORIOKA Tomohiko]

>>>>> In [emacs-mime-ja : No.00376] 
>>>>>	"Yoshiki" = Yoshiki Hayashi <t90553 ＠ mail.ecc.u-tokyo.ac.jp> wrote:

Yoshiki> FLIM 1.13.2, EMY 1.13.2 (ほぼ確実にどの SEMI を使っても同じ)
Yoshiki> を使うと、

Yoshiki> Content-Type: Message/External-body;
Yoshiki>         access-type="mail-server";
Yoshiki>         server="mailserv ＠ ietf.org"

Yoshiki> Content-Type: text/plain
Yoshiki> Content-ID:     <20000127125821.I-D ＠ ietf.org>

Yoshiki> ENCODING mime
Yoshiki> FILE /internet-drafts/draft-ietf-drums-msg-fmt-08.txt

Yoshiki> というのが、

Yoshiki> [2.1.2.1  ([mail-server] mailserv ＠ ietf.org)]
Yoshiki> [2.1.2.1.1  <text/plain (7bit)>]
Yoshiki> ENCODING mime
Yoshiki> FILE /internet-drafts/draft-ietf-drums-msg-fmt-08.txt

Yoshiki> と表示されます。本当は multipart ではないものが multipart の
Yoshiki> ように扱われるのは気持悪いです。

Yoshiki> これは、flim/mime-def.el の

Yoshiki> (luna-define-method mime-entity-children ((entity mime-entity))
Yoshiki>   (let* ((content-type (mime-entity-content-type entity))
Yoshiki> 	 (primary-type (mime-content-type-primary-type content-type)))
Yoshiki>     (cond ((eq primary-type 'multipart)
Yoshiki> 	   (mime-parse-multipart entity)
Yoshiki> 	   )
Yoshiki> 	  ((and (eq primary-type 'message)
Yoshiki> 		(memq (mime-content-type-subtype content-type)
Yoshiki> 		      '(rfc822 news external-body)
Yoshiki> 		      ))
Yoshiki> 	   (mime-parse-encapsulated entity)
Yoshiki> 	   ))
Yoshiki>     ))

Yoshiki> で、external-body を message/rfc822 と同等に扱っているからです。

Yoshiki> 質問なのですが、message/external-body を multipart/messageと
Yoshiki> 同等として parse するというのは仕様でしょうか? そうすると、
Yoshiki> SEMI 層では message/external-body が来たときは children が実
Yoshiki> 際の body だと思って操作することになります。できれば、
Yoshiki> children にしない方がきれいで良いと思うのですが、どうでしょ
Yoshiki> うか?

上記修正を行ったのは小林君だったと思うので、実際の所は判らないのですが
（と、逃げを打っておく(^_^;;;）、MIME 的には message/external-body は
body が外部にある entity で、そのことを除けば message/rfc822 と同様な
のは自然だと思います。FLIM 的には message/external-body の children
entity 自体は常に生成可能で、それに対する header に関する要求は常に成
功し、body や内容に関する要求は失敗するかも知れないということになると
思います。

ところで、message/external-body を mime-parse-encapsulated で parse す
るのは正しいかというと、私は正しくないと思います。この body の意味は
message/rfc822 と異なるからです。そういう訳で、FLIM 1.14 では

(luna-define-method mime-entity-children ((entity mime-entity))
  (let* ((content-type (mime-entity-content-type entity))
	 (primary-type (mime-content-type-primary-type content-type))
	 sub-type)
    (cond ((eq primary-type 'multipart)
	   (mime-parse-multipart entity))
	  ((eq primary-type 'message)
	   (setq sub-type (mime-content-type-subtype content-type))
	   (cond ((eq sub-type 'external-body)
		  (mime-parse-external entity))
		 ((memq sub-type '(rfc822 news))
		  (mime-parse-encapsulated entity)
		  ;; [tomo] Should we make a variable to specify
		  ;; encapsulated media-types?
		  ))))))

みたいにし、mime-parse-external で該当する class の entity を生成し、
実際の挙動はその class を実装する mm-backend で決まるという風になる予
定です。(Chao 1.14 では anon-ftp の場合のみ動いています)


FLIM 的には要求されれば message/external-body の children entity を作
るのは正しいと思います。よって、問題は SEMI もしくは SEMI と FLIM の連
携にあるのだと思います。従来のように問答無用に children を手繰るのでは
なく、状況に応じて手繰るかどうかを SEMI 側で決めるようにするのが良いと
思います。これはおそらく IMAP4 環境でも重要なことだと思います。

;; message/external-body 用の表示・再生 method は（少なくとも anon-ftp 
;; のようなのでは）要らなくなります。ただ、access-type="mail-server" 
;; の場合、FLIM で mail を送るというのも変な感じなので、MUA 固有の 
;; entity 用 method や mm-backend を差し込むか、あるいは、その 
;; access-type 用の表示・再生 method を設定することになるでしょう。

-- 
===『幾千億の分子に分かれても ========================================
     決して忘れない。    
     この宇宙が終るまで』              守岡 知彦 (MORIOKA Tomohiko)
======================================== Email: <tomo ＠ etl.go.jp> =====