FLIM 1.14 API (Re: flim-1_13-rfc2231 vs flim-1_14-rfc2231)

[守岡 知彦 / MORIOKA Tomohiko]

>>>>> <86vgno8cu0.fsf_-_ ＠ aqua.ocn.ne.jp> にて
>>>>> “修平”= Shuhei KOBAYASHI <shuhei ＠ aqua.ocn.ne.jp> さま曰く:

修平> > FLIM の RFC 2231 対応の main trunk への merge を検討しているの
修平> > ですが...

修平> これに関連するのですが, FLIM-API.en に関していくつか質問があります.

まず最初に述べておきたいのですが、この文書は表題にあるように原案です。


修平> `mime-parse-Content-Type' に関する記述が 2 か所に出てきますが,

修平> | * MIME content information
修平> | 
修平> | ** How to use
修平> | 
修平> | (require 'mime)
修平> | 
修平> | 
修平> | ** Content-Type
修平> | 
修平> | [Function] mime-parse-Content-Type (string)
修平> |   Parse STRING as field-body of Content-Type field, and
修平> |   return the result as `mime-content-type' structure.

修平> [...]

修平> | * MIME Field parsing
修平> | 
修平> | ** How to use
修平> | 
修平> | (require 'mime)
修平> | 
修平> | 
修平> | ** Level 2 features
修平> [...]
修平> | [Function] mime-parse-Content-Type (string)
修平> |   Parse STRING as field-body of Content-Type field.
修平> | 
修平> | Return value is
修平> |     (PRIMARY-TYPE SUBTYPE (NAME1 . VALUE1)(NAME2 . VALUE2) ...)
修平> | or nil.  PRIMARY-TYPE and SUBTYPE are symbol and NAME_n and VALUE_n
修平> | are string.

修平> Q1. "Level 2 features" って何ですか?

修平> std11 の方には "Level 1 features" という記述もあるみたいですね.

「実装水準 1」「実装水準 2」という形式で書こうとしていた頃の名残です。
現在では意味がありません。

これは新しい形式に直し切れてない部分です。mime-parse-Content-Type は
[Suggest] と思ってください。


修平> Q2. ("Level 2 features" では?) `mime-content-type' 型の構造まで定めて
修平>     しまうのですか?

修平> Q2-1. 現在の FLIM 1.14 実装とは `mime-content-type' の構造が異なって
修平>       いますが, これは FLIM 1.14 実装の bug なのでしょうか?

これは FLIM-API.en の bug, というか作業途中の部分です。

;; 冒頭の形式になっていない部分は作業途中であると考えられます。


修平> Q2-2. IMAP4 では parameter list を alist ではなく plist で表現してい
修平>       ますが, FLIM の特定の実装でも同様に plist を採用するというのは
修平>       許容されないのでしょうか?

許されるでしょう。

少なくとも私の方針としては、FLIM API では必須の service (総称関数) と
method を定めるだけにしたいと思っています。


修平> Q2-3. `mime-content-type-parameters' の返り値の型は?

修平> | [Inline function] mime-content-type-parameters (content-type)
修平> |   Return parameters of CONTENT-TYPE.

修平> `mime-content-type' 型の構造が API に含まれないとなれば, この関
修平> 数の返り値の型は実装依存になりますね.

そうなりますね。

`mime-parameters' 型が満たすべき条件と `mime-parameters' 型に関する
API を追加するのが良いと思っています。
 
修平> そもそも, `mime-content-type-parameter' と
修平> `mime-content-type-parameters' の両方があるのは冗長ではないです
修平> か?

冗長ですが、そのことが問題だとは思いません。


修平> >>>>> In <861yqc9ue3.fsf ＠ aqua.ocn.ne.jp>,
修平> >>>>> Shuhei KOBAYASHI <shuhei ＠ aqua.ocn.ne.jp> wrote:
修平> > このため flim-1_13-rfc2231 とは異なり, API の拡張[*]は不要になっ
修平> > ています.

修平> flim-1_13-rfc2231 が「API の拡張」と呼ぶところの変更は 
修平> `parameters' を外に見せているために必要となったもので,
修平> `mime-content-type-parameter'だけを使用していれば API の変更は不
修平> 要ではないでしょうか?
修平> ;; language info 関連を除く.

修平> あ, "[Inline function]" と規定しているのも問題ですね.
修平> `mime-content-type' 型の詳細を隠蔽できなくなってしまいます.
修平> 守岡さんは(or FLIM API では) *.elc の互換性は気にしないのでしたっけ?

問題があれば修正してください。


修平> Q3. `make-mime-content-type' は API に含まれないのですか?
修平>     `make-mime-content-disposition' は? (現在の FLIM 1.14 実装では未定義)

必要なら追加してください。


修平> RFC 2231 からは離れますが,

修平> | [Function] mime-entity-encoding (entity &optional default-encoding)

修平> | [Function] mime-read-Content-Transfer-Encoding (&optional default-encoding)

修平> Q4. `default-encoding' は不要ではないでしょうか?
修平>     実際, FLIM 1.14 でも `(or (mime-entity-encoding entity) "7bit")' の
修平>     ような書き方がされています.

Content-Transfer-Encoding 欄が無かった時に "7bit" を返すようにしようか
と思ってた頃の名残ですね。

nil を返すように定義するならばそれで良いと思います。

修平> ちなみに, flim-1_14-rfc2231 では `default-encoding' をこっそりと廃止して
修平> あったのですが, 問題があるという報告は出ていません;-)


修平> FLIM-API.en には他にも気になる点がありますが, とりあえずここまで.

別文書で書き足していた部分を早急に merge します。

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