FLIM 1.14 / SEMI 1.14 (Re: close-parentheses)

[守岡 知彦 / MORIOKA Tomohiko]

>>>>> In [emacs-mime-ja : No.00283] 
>>>>>	"圭一" = Keiichi Suzuki <keiichi ＠ nanap.org> wrote:

守岡> parameter extension に関しては一度過去に因われず API を検討して
守岡> みようかなと思っています。また、header を表現するデータ構造を 
守岡> luna を使って作り、mm-backend から分離したらどうかななんてことも
守岡> 思っています。parameter に関しても

守岡> ・header の構文
守岡> ・presentation を伴わない MIME 処理
守岡> ・presentation

守岡> を分離するという観点から flim-1_13-rfc2231 を整理できれば良いな
守岡> あと思っています。

圭一> luna を使って書いてみようかとも、ちらっと頭をよぎったのですが、
圭一> 使い方を理解していないもので、安直な方向に流れてしまいました。 
圭一> ^^;;;

いえいえ、現時点ではあれが現実的だったんだと思います。

ただ、message header object を作って std11 にかぶせるという構想は前々
から頭をよぎっていたんですが、面倒でずっとやってこなかったことなんです。
また、MIME-Edit で presentation と representation が明確に別れていなかっ
たために、面倒だったと言うこともあります。

しかし、parameter や Date 問題といった具体的な問題も出て来たし、
MIME-Edit で presentation と representation を分離するなら、message
header 関連の界面を整理する良い機会なんじゃないかと思う訳です。


守岡> header の filtering/sort も再検討しましょう。

圭一> これに関わってくると思いますが、先日から思っているのは X-Face の 
圭一> RGB 判などでは、同じ field name のものがつきますが、これはよろし
圭一> くないのではないかと思います。

圭一> そこで、たくさんある場合は X-Face, X-Face-2, X-Face-3 というよう
圭一> に連番をつけていくのはどうでしょうか?

圭一> 代表選手としてのものに X-Face 、RGB のものは X-Face-R/G/B 、動画
圭一> のものはX-Face-1..n というのも良いかもしれません。

何らかの形で違う field name にすることに大賛成です。これは RFC 822 の
観点でも重要なことだと思います。

;; 私が従来この種の X-Face の変種に冷やかだったのはこの点に依るので、
;; これが解消されるなら応援したいです。

-- 
┯━…‥・懐かしい未来の記憶をふと思い出しかけた・‥…━━┯━━━┯━
││ ─ │  ─  ／    ─   ┼─     ┬                ─   ─┼ ┬┴─
┼┼─┼|〓━─┼ 守岡 知彦 (MORIOKA Tomohiko) <tomo ＠ etl.go.jp>─ ─┬
┻┻━┻━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━━