From tomo ＠ kanji.zinbun.kyoto-u.ac.jp Tue May 1 12:25:57 2001 From: tomo ＠ kanji.zinbun.kyoto-u.ac.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiA=?= =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko) Date: 01 May 2001 12:25:57 +0900 Subject: Why `capitalize' twice? In-Reply-To: Shuhei KOBAYASHI's message of "27 Apr 2001 22:27:04 +0900" References: <86u23axyl3.fsf@aqua.ocn.ne.jp> Message-ID: >>>>> <86u23axyl3.fsf ＠ aqua.ocn.ne.jp> にて >>>>> “修平”= Shuhei KOBAYASHI さま曰く: 修平> 前々から気になっていたのですが, `(capitalize (capitalize 修平> field-name))'のように capitalize を二度行なうのは何のおまじない修平> なのでしょうか? 修平> (capitalize "content-type") => "Content-Type" 修平> (capitalize "Content-Type") => "Content-Type" 修平> | % cd flim-1_14 修平> | % grep -n -e capitalize *.el 修平> [...] 修平> | mime.el:335: (intern (capitalize (capitalize field-name)))))) 修平> | mmbuffer.el:178: (intern (capitalize (capitalize field-name))))) 修平> | mmexternal.el:160: (intern (capitalize (capitalize field-name))))) 修平> | mmgeneric.el:62: (setq field-name (intern (capitalize (capitalize field-name))))) 修平> [...] 記憶にありません。修平> flim-1_14, flim-1_14-rfc2231, clime-1_14 に対する修正を commit します. ありがとうございます。 -- ┯━…‥・懐かしい未来の記憶をふと思い出しかけた・‥…━━┯━━━┯━ ││ ─ │ ─ ／ ─ ┼─ ┬ ─ ─┼ ┬┴─ ┼┼─┼|〓━─┼ 守岡知彦 (MORIOKA Tomohiko) ─ ─┬ ┻┻━┻━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ From tomo ＠ kanji.zinbun.kyoto-u.ac.jp Tue May 1 13:18:08 2001 From: tomo ＠ kanji.zinbun.kyoto-u.ac.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiA=?= =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko) Date: 01 May 2001 13:18:08 +0900 Subject: FLIM 1.14 API (Re: flim-1_13-rfc2231 vs flim-1_14-rfc2231) In-Reply-To: Shuhei KOBAYASHI's message of "29 Apr 2001 15:00:39 +0900" References: <86pug42otj.fsf@aqua.ocn.ne.jp> <861yqc9ue3.fsf@aqua.ocn.ne.jp> <86vgno8cu0.fsf_-_@aqua.ocn.ne.jp> Message-ID: >>>>> <86vgno8cu0.fsf_-_ ＠ aqua.ocn.ne.jp> にて >>>>> “修平”= Shuhei KOBAYASHI さま曰く: 修平> > 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 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) ─ ─┬ ┻┻━┻━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ From yoshiki ＠ xemacs.org Tue May 1 20:52:19 2001 From: yoshiki ＠ xemacs.org (Yoshiki Hayashi) Date: 01 May 2001 20:52:19 +0900 Subject: How to handle S/MIME on Emacs (Gnus/SEMI/FLIM...) In-Reply-To: (Tatsuya Ichikawa's message of "Tue, 24 Apr 2001 23:19:57 -0500") References: Message-ID: <87k841mglo.fsf@sodan.org> Tatsuya Ichikawa writes: > 時代の流れと言うか何と言うか、社内でのメールにいよいよ暗号化メールが > 採用される事になり、それが何と S/MIME (PGP ぢゃ無い)何です。 > 所で、Gnus/SEMI/FLIM 等から S/MIME message を扱うためには、私なりに > 調べたんですが > > 1. SEMI Variants で対応しているものは EMIKO/EMY がある > 2. smime tool が必要 (http://www.bacus.pt/Net_SSLeay/smime.html) > 3. smime tool をcompile するのに > OpenSSL http://www.openssl.org/ > Cons http://www.dsmit.com/cons/ > が必要… > > とまでは分かりました。 > 現状、EMY を利用しているんですが、これで S/MIME の message を扱った > 実績はあるんでしょうか? 残念ながら無いです。(;_;) S/MIME 部分はそっくり EMIKO から頂いているので、私が merge したときに変なことをしていない限りそれなりには動くのではないか、とは思っています。 > それと、扱うための Document はありますか? ## 言いだしっぺの法則... :-P -- Yoshiki Hayashi From shuhei ＠ aqua.ocn.ne.jp Tue May 1 19:58:57 2001 From: shuhei ＠ aqua.ocn.ne.jp (Shuhei KOBAYASHI) Date: 01 May 2001 19:58:57 +0900 Subject: FLIM 1.14 API (Re: flim-1_13-rfc2231 vs flim-1_14-rfc2231) References: <86pug42otj.fsf@aqua.ocn.ne.jp> <861yqc9ue3.fsf@aqua.ocn.ne.jp> <86vgno8cu0.fsf_-_@aqua.ocn.ne.jp> Message-ID: <86g0ep5o9a.fsf@aqua.ocn.ne.jp> >>>>> In , >>>>> tomo ＠ kanji.zinbun.kyoto-u.ac.jp (守岡知彦 / MORIOKA Tomohiko) wrote: > > Q3. `make-mime-content-type' は API に含まれないのですか? > > `make-mime-content-disposition' は? (現在の FLIM 1.14 実装では未定義) > 必要なら追加してください。 [...] > > | [Function] mime-entity-encoding (entity &optional default-encoding) > > | [Function] mime-read-Content-Transfer-Encoding (&optional default-encoding) > > Q4. `default-encoding' は不要ではないでしょうか? > Content-Transfer-Encoding 欄が無かった時に "7bit" を返すようにしようか > と思ってた頃の名残ですね。 > nil を返すように定義するならばそれで良いと思います。 flim-1_14-rfc2231 を merge することになれば, そのときに FLIM-API.en も修正します. -- Shuhei KOBAYASHI From ichikawa ＠ jpl.org Wed May 2 16:42:53 2001 From: ichikawa ＠ jpl.org (Tatsuya Ichikawa) Date: 02 May 2001 02:42:53 -0500 Subject: How to handle S/MIME on Emacs (Gnus/SEMI/FLIM...) In-Reply-To: <87k841mglo.fsf@sodan.org> (Yoshiki Hayashi's message of "01 May 2001 20:52:19 +0900") References: <87k841mglo.fsf@sodan.org> Message-ID: 市川です。 ;; 反応が遅くてすみません… >>>>> In [emacs-mime-ja : No.00858] >>>>> Yoshiki Hayashi wrote: 林> > 時代の流れと言うか何と言うか、社内でのメールにいよいよ暗号化メー林> > ルが採用される事になり、それが何と S/MIME (PGP ぢゃ無い)何です。林> > 所で、Gnus/SEMI/FLIM 等から S/MIME message を扱うためには、私林> > なりに調べたんですが [...] 林> > 現状、EMY を利用しているんですが、これで S/MIME の message を林> > 扱った実績はあるんでしょうか? 林> 残念ながら無いです。(;_;) ぐっすん… 実績は無いんですか… 林> S/MIME 部分はそっくり EMIKO から頂いているので、私が merge 林> したときに変なことをしていない限りそれなりには動くのではない林> か、とは思っています。と言うことは…上野さんが確かめた限りでは(^^) OK なんですか? 林> > それと、扱うための Document はありますか? 林> ## 言いだしっぺの法則... :-P 薮蛇… (;_;) 確かめたいんですが、署名やら何やらで確かめる方法を確立しなきゃダメですよね。署名は無料では発行してくれませんし(年間 $15 だったかな??)… でも Gnus にも smime.el なんてのがありませんか? 名前が思いっきり重なってますが、まずいでしょう。 ;; 今まで問題にならないのは誰も使っていないからか… -- Tatsuya - Tim - Ichikawa From kose ＠ yk.NetLaputa.ne.jp Thu May 3 12:41:00 2001 From: kose ＠ yk.NetLaputa.ne.jp (=?ISO-2022-JP?B?GyRCPi40WBsoQiAbJEI1SEInGyhC?= (KOSEKI Yoshinori)) Date: Thu, 3 May 2001 12:41:00 +0900 (JST) Subject: How to handle S/MIME on Emacs (Gnus/SEMI/FLIM...) In-Reply-To: (Tatsuya Ichikawa's message of "02 May 2001 02:42:53 -0500") References: <87k841mglo.fsf@sodan.org> Message-ID: <20010503hez3np75.kose@yk.NetLaputa.ne.jp> >>>>> In [emacs-mime-ja : No.00860] >>>>> “Tim” = Tatsuya Ichikawa wrote: Tim> 確かめたいんですが、署名やら何やらで確かめる方法を確立しなきゃダメで Tim> すよね。確かめる方法ってのは、Internet Explorer(Outlook) や Mozilla と暗号、署名のメールを相互にやりとりできれば良い、んだよね。 PGP と違って IE と Mozilla 間の相互接続性は良好でしたよ。 ;; 今でも Oort Gnus と T-gnus 間の日本語での PGP の署名は ;; bad signature のままなのかな。(日本ローカルルールだからし ;; かたがないのかもしれないが。) Tim> 署名は無料では発行してくれませんし(年間 $15 だったかな??)… え ??? >>>>> In [emacs-mime-ja : No.00850] >>>>> “Tim” = Tatsuya Ichikawa wrote: Tim> 時代の流れと言うか何と言うか、社内でのメールにいよいよ暗号化メールが Tim> 採用される事になり、それが何と S/MIME (PGP ぢゃ無い)何です。なので、証明書(デジタルID)はもう会社で用意してくれたんじゃないんですか? ;; その昔とある仕事で少しだけ IE と Mozilla で試したことがあ ;; ります。VeriSign のを持ってたけど期限切れになってしまった ;; しなぁ。 ;; そうだ、emacs-mime-ja で CA を立ち上げて実験するというの ;; も楽しいかもしれない。PGP よりも楽しい(実用的)かもよ。 -- こせき @ Meadow のページも作成中 http://www.NetLaputa.ne.jp/~kose/Emacs/Meadow/ kose ＠ yk.NetLaputa.ne.jp From ichikawa ＠ jpl.org Thu May 3 15:44:18 2001 From: ichikawa ＠ jpl.org (Tatsuya Ichikawa) Date: 03 May 2001 01:44:18 -0500 Subject: How to handle S/MIME on Emacs (Gnus/SEMI/FLIM...) In-Reply-To: <20010503hez3np75.kose@yk.NetLaputa.ne.jp> (=?ISO-2022-JP?B?GyRCPi40WBsoQiAbJEI1SEInGyhC?= (KOSEKI Yoshinori)'s message of "Thu, 3 May 2001 12:41:00 +0900 (JST)") References: <87k841mglo.fsf@sodan.org> <20010503hez3np75.kose@yk.NetLaputa.ne.jp> Message-ID: 市川です。 >>>>> In [emacs-mime-ja : No.00861] >>>>> 小関吉則 (KOSEKI Yoshinori) wrote: Tim> 確かめたいんですが、署名やら何やらで確かめる方法を確立しなきゃ Tim> ダメですよね。小関> 確かめる方法ってのは、Internet Explorer(Outlook) や Mozilla 小関> と暗号、署名のメールを相互にやりとりできれば良い、んだよね。具体的には Outlook ですね。 ;; どうしても会社は「標準 E-mail Client」として Outlook を使用させたい ;; らしい… 小関> PGP と違って IE と Mozilla 間の相互接続性は良好でしたよ。ふむ…それは Emacs <-> Outlook 間ですか? Tim> 署名は無料では発行してくれませんし(年間 $15 だったかな??)… 小関> え ??? 小関> >>>>> In [emacs-mime-ja : No.00850] 小関> >>>>> “Tim” = Tatsuya Ichikawa wrote: Tim> 時代の流れと言うか何と言うか、社内でのメールにいよいよ暗号化メー Tim> ルが採用される事になり、それが何と S/MIME (PGP ぢゃ無い)何です。小関> なので、証明書(デジタルID)はもう会社で用意してくれたんじゃな小関> いんですか? いえ、「こうしますよ」と話が来ただけです。でもって、今後読めなくなると「反 Emacs 派」の私の上司から「ほれ見ろ、 Emacs なんて時代に逆行した物使っているから読めないじゃないか!!」と言われるのが嫌で、今から下調べをしようと思っているんです。間違っても Outlook なんぞ使用したくないですから… ;; その上司はこうやって引用文の間にコメントを書くことも嫌います。 ;; 10 年前の手法だって… ;; 何しろ Outlook 以外の Mail を受け取ったことがないらしいですから… ;; ぐちぐち… 小関> ;; そうだ、emacs-mime-ja で CA を立ち上げて実験するというの小関> ;; も楽しいかもしれない。PGP よりも楽しい(実用的)かもよ。 (^^) 実用的ですよね…(思いっきり自己中心モード) -- Tatsuya - Tim - Ichikawa From mit ＠ nines.nec.co.jp Fri May 4 11:23:38 2001 From: mit ＠ nines.nec.co.jp (Mito) Date: Fri, 04 May 2001 11:23:38 +0900 Subject: How to handle S/MIME on Emacs (Gnus/SEMI/FLIM...) In-Reply-To: References: <87k841mglo.fsf@sodan.org> <20010503hez3np75.kose@yk.NetLaputa.ne.jp> Message-ID: ※ "市" こと ichikawa ＠ jpl.org さんの『Re: How to handle S/MIME on Emacs (Gnus/SEMI/FLIM...)』より Tim> 署名は無料では発行してくれませんし(年間 $15 だったかな??)… 小関> え ??? 小関> >>>>> In [emacs-mime-ja : No.00850] 小関> >>>>> “Tim” = Tatsuya Ichikawa wrote: Tim> 時代の流れと言うか何と言うか、社内でのメールにいよいよ暗号化メー Tim> ルが採用される事になり、それが何と S/MIME (PGP ぢゃ無い)何です。小関> なので、証明書(デジタルID)はもう会社で用意してくれたんじゃな小関> いんですか? 市> いえ、「こうしますよ」と話が来ただけです。 http://digitalid.verisign.com/client/enroll.htm でブラウザを選択後、「Choose a Full-service Class 1 Digital ID, or a 60-day Trial Class 1 Digital ID」という選択肢がありますので、 Trial Class を選択すると無料で発行してくれるんじゃないかなぁと思うのですが...。ご存知かもしれませんが、Mew 付属の contrib/mew-smime-ja に松本隆太郎さんが Mew にS/MIME をサポートした際の info があります。この中で紹介されている証明機関からでも取得できると思います。＃この info には OpenSSL で digital cert. を使う方法とか色々＃と有用なことが書かれていると思います。＃＃私には難しすぎてほんとに有用なのかどうかの判断さえつき＃＃ませんが。^^;;; -- 5/4 11:23頃 NECソフトウェア新潟水戸 From ueno ＠ unixuser.org Fri May 4 21:16:55 2001 From: ueno ＠ unixuser.org (Daiki Ueno) Date: 04 May 2001 21:16:55 +0900 Subject: How to handle S/MIME on Emacs (Gnus/SEMI/FLIM...) In-Reply-To: (Tatsuya Ichikawa's message of "02 May 2001 02:42:53 -0500") References: <87k841mglo.fsf@sodan.org> Message-ID: >>>>> In [emacs-mime-ja : No.00860] >>>>> Tatsuya Ichikawa wrote: 林> S/MIME 部分はそっくり EMIKO から頂いているので、私が merge 林> したときに変なことをしていない限りそれなりには動くのではない林> か、とは思っています。市川> と言うことは…上野さんが確かめた限りでは(^^) OK なんですか? smime tools に附属のテストケースに限り、動いたような記憶はありますが、実績としては限りなくゼロに近いです。市川> 確かめたいんですが、署名やら何やらで確かめる方法を確立しなきゃダメで市川> すよね。市川> 署名は無料では発行してくれませんし(年間 $15 だったかな??)… 市川> でも Gnus にも smime.el なんてのがありませんか? 市川> 名前が思いっきり重なってますが、まずいでしょう。 Gnus 附属の smime.el を優先し、現状の smime.el は破棄する方向で作業してくださる方がいると助かるのですが、どなたかやりませんか? 市川> ;; 今まで問題にならないのは誰も使っていないからか… [Mew-dist 16589] S/MIME support in SEMI にて、詳細なレポートを頂いています。 ;; が、どうも僕の心の中では、実用性と時間に対する楽しさの変化率は反比例 ;; しているようなので…期待はしないでください。 -- Daiki Ueno From ueno ＠ unixuser.org Sun May 6 05:42:06 2001 From: ueno ＠ unixuser.org (Daiki Ueno) Date: 06 May 2001 05:42:06 +0900 Subject: How to handle S/MIME on Emacs (Gnus/SEMI/FLIM...) In-Reply-To: (Daiki Ueno's message of "04 May 2001 21:16:55 +0900") References: <87k841mglo.fsf@sodan.org> Message-ID: >>>>> In [emacs-mime-ja : No.00864] >>>>> Daiki Ueno wrote: 上野> Gnus 附属の smime.el を優先し、現状の smime.el は破棄する方向で作業して上野> くださる方がいると助かるのですが、どなたかやりませんか? 片手間で sync してみました。(emiko-1_14 枝) ほとんどテストしていないので、きちんとした環境で試して頂ける方を募集しています。やりかたは Gnus に附属の smime.el のコメント、および Mew の contrib に含まれる mew-smime-ja.texi を参考にされると良いと思います。 -- Daiki Ueno From shuhei ＠ aqua.ocn.ne.jp Tue May 1 19:58:57 2001 From: shuhei ＠ aqua.ocn.ne.jp (Shuhei KOBAYASHI) Date: 01 May 2001 19:58:57 +0900 Subject: FLIM 1.14 API (Re: flim-1_13-rfc2231 vs flim-1_14-rfc2231) References: <86pug42otj.fsf@aqua.ocn.ne.jp> <861yqc9ue3.fsf@aqua.ocn.ne.jp> <86vgno8cu0.fsf_-_@aqua.ocn.ne.jp> Message-ID: <86elu2x1ha.fsf@aqua.ocn.ne.jp> ;; [emacs-mime-ja:00859] (Message-Id: <86g0ep5o9a.fsf ＠ aqua.ocn.ne.jp>) と ;; 共に送った 3 通が戻ってこないので再送します. (守岡さんには届きました?) >>>>> In , >>>>> tomo ＠ kanji.zinbun.kyoto-u.ac.jp (守岡知彦 / MORIOKA Tomohiko) wrote: > これは新しい形式に直し切れてない部分です。mime-parse-Content-Type は > [Suggest] と思ってください。 "[Suggest]" ですが... | ILEVEL specifies implementation level: | | Required: Must implement | Suggest: Should implement | Optional: Optional | | ULEVEL specifies implementation level: | | Suggest: Should use | Not Suggest: Should not use | Obsolete: Should not use (historical) RFC 2119 ("Key words for use in RFCs to Indicate Requirement Levels") の表記に慣れているので "Suggest" や "Not Suggest" に違和感があります. ;; 辞書を見ると "suggest" は "should" よりも弱い表現のようです. ILEVEL REQUIRED: FLIM implementation MUST implement it. RECOMMENDED: FLIM implementation SHOULD implement it. OPTIONAL: FLIM implementation MAY implement it. ULEVEL (引用部の "implementation level" は "use level"(?) の誤りですか?) RECOMMENDED: FLIM application SHOULD use it. DISCOURAGED: FLIM application SHOULD NOT use it. OBSOLETE: FLIM application SHOULD NOT use it. It's historical. というのはどうでしょうか? ;; "DISCOURAGED" は RFC 2119 用語ではないのですね... -- Shuhei KOBAYASHI From shuhei ＠ aqua.ocn.ne.jp Tue May 1 19:58:57 2001 From: shuhei ＠ aqua.ocn.ne.jp (Shuhei KOBAYASHI) Date: 01 May 2001 19:58:57 +0900 Subject: FLIM 1.14 API (Re: flim-1_13-rfc2231 vs flim-1_14-rfc2231) References: <86pug42otj.fsf@aqua.ocn.ne.jp> <861yqc9ue3.fsf@aqua.ocn.ne.jp> <86vgno8cu0.fsf_-_@aqua.ocn.ne.jp> <867kzux1d4.fsf@aqua.ocn.ne.jp> Message-ID: <861yq2x1b0.fsf@aqua.ocn.ne.jp> >>>>> In , >>>>> tomo ＠ kanji.zinbun.kyoto-u.ac.jp (守岡知彦 / MORIOKA Tomohiko) wrote: > > あ, "[Inline function]" と規定しているのも問題ですね. > > `mime-content-type' 型の詳細を隠蔽できなくなってしまいます. > > 守岡さんは(or FLIM API では) *.elc の互換性は気にしないのでしたっけ? > 問題があれば修正してください。 API 中の inline function を全て通常の function に修正してもいいのですか? >>>>> In <87wvy6icj4.fsf ＠ pc-hrvoje.srce.hr>, >>>>> Hrvoje Niksic wrote: > Bad bad bad. defsubst'ing a function is almost always wrong. に賛同する私としては, FLIM API に含まれる inline function が展開されて API に含まれない部分が *.elc に残るのは問題があると思っているのですが, FLIM API が提供する互換性は *.el だけのものか, *.elc の互換性も保証するのかは議論されていないですよね? ;; FLIM 実装を差し替えても SEMI やその上の application を再 compile し ;; たくはないということです. flim-1_14-rfc2231 の lazy に decode する ;; version を試作した時に SEMI の再 compile が必要になったので. -- Shuhei KOBAYASHI From shuhei ＠ aqua.ocn.ne.jp Tue May 1 19:58:57 2001 From: shuhei ＠ aqua.ocn.ne.jp (Shuhei KOBAYASHI) Date: 01 May 2001 19:58:57 +0900 Subject: FLIM 1.14 API (Re: flim-1_13-rfc2231 vs flim-1_14-rfc2231) References: <86pug42otj.fsf@aqua.ocn.ne.jp> <861yqc9ue3.fsf@aqua.ocn.ne.jp> <86vgno8cu0.fsf_-_@aqua.ocn.ne.jp> <86elu2x1ha.fsf@aqua.ocn.ne.jp> Message-ID: <867kzux1d4.fsf@aqua.ocn.ne.jp> >>>>> In , >>>>> tomo ＠ kanji.zinbun.kyoto-u.ac.jp (守岡知彦 / MORIOKA Tomohiko) wrote: > > `mime-content-type' 型の構造が API に含まれないとなれば, この関数 > > の返り値の型は実装依存になりますね. > そうなりますね。 > `mime-parameters' 型が満たすべき条件と `mime-parameters' 型に関する > API を追加するのが良いと思っています。 [...] > > そもそも, `mime-content-type-parameter' と > > `mime-content-type-parameters' の両方があるのは冗長ではないですか? > 冗長ですが、そのことが問題だとは思いません。ところで, `mime-parameters' 型の導入は FLIM 1.14 では行なわないという事になっていませんでしたっけ? flim-1_13-rfc2231 の merge が保留になっていた理由のひとつがこれだったような気がするのですが... `mime-parameters' 型の導入は FLIM 1.14 で行なうが, API に関する検討が未だ行なわれていないというだけだったかもしれませんがよく憶えていません. -- Shuhei KOBAYASHI From ueno ＠ unixuser.org Mon May 7 11:00:37 2001 From: ueno ＠ unixuser.org (Daiki Ueno) Date: 07 May 2001 11:00:37 +0900 Subject: How to handle S/MIME on Emacs (Gnus/SEMI/FLIM...) In-Reply-To: (Daiki Ueno's message of "06 May 2001 05:42:06 +0900") References: <87k841mglo.fsf@sodan.org> Message-ID: >>>>> In [emacs-mime-ja : No.00865] >>>>> Daiki Ueno wrote: 上野> Gnus 附属の smime.el を優先し、現状の smime.el は破棄する方向で作業して上野> くださる方がいると助かるのですが、どなたかやりませんか? 上野> 片手間で sync してみました。(emiko-1_14 枝) 大元の Gnus の smime.el のバグで、復号化できないことが判明しました。(;_;) というわけで、やはり、semi-1_14 に含まれる smime.el を pgg-smime.el などと改名し、OpenSSL 対応にする方針に切り換えたほうが良いように思い始めました。 ;; ちなみに smime.el の作者さんは、最近では↓のようなことを手掛けている ;; らしいです。NSS の API はよく知らないのですが、S/MIME あたりも ;; Mozilla などと設定を共通化できるようになるのでしょうか。 ;; http://josefsson.org/emacs-security/ ;; どなたか試しませんか？ -- Daiki Ueno From tomo ＠ kanji.zinbun.kyoto-u.ac.jp Mon May 7 21:23:26 2001 From: tomo ＠ kanji.zinbun.kyoto-u.ac.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiA=?= =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko) Date: 07 May 2001 21:23:26 +0900 Subject: FLIM 1.14 API (Re: flim-1_13-rfc2231 vs flim-1_14-rfc2231) In-Reply-To: Shuhei KOBAYASHI's message of "01 May 2001 19:58:57 +0900" References: <86pug42otj.fsf@aqua.ocn.ne.jp> <861yqc9ue3.fsf@aqua.ocn.ne.jp> <86vgno8cu0.fsf_-_@aqua.ocn.ne.jp> <86elu2x1ha.fsf@aqua.ocn.ne.jp> Message-ID: >>>>> [emacs-mime-ja : No.00866] にて >>>>> “修平”= Shuhei KOBAYASHI さま曰く: 修平> ;; [emacs-mime-ja:00859] (Message-Id: 修平> ;; <86g0ep5o9a.fsf ＠ aqua.ocn.ne.jp>) と共に送った 3 通が戻ってこ修平> ;; ないので再送します. (守岡さんには届きました?) ;; 届いてました。反応悪くてごめんなさい。修平> >>>>> In , 修平> >>>>> tomo ＠ kanji.zinbun.kyoto-u.ac.jp (守岡知彦 / MORIOKA 修平> >>>>> Tomohiko) wrote: 修平> > これは新しい形式に直し切れてない部分です。修平> > mime-parse-Content-Type は[Suggest] と思ってください。修平> "[Suggest]" ですが... 修平> | ILEVEL specifies implementation level: 修平> | 修平> | Required: Must implement 修平> | Suggest: Should implement 修平> | Optional: Optional 修平> | 修平> | ULEVEL specifies implementation level: 修平> | 修平> | Suggest: Should use 修平> | Not Suggest: Should not use 修平> | Obsolete: Should not use (historical) 修平> RFC 2119 ("Key words for use in RFCs to Indicate Requirement 修平> Levels") の表記に慣れているので "Suggest" や "Not Suggest" に違修平> 和感があります. 修平> ;; 辞書を見ると "suggest" は "should" よりも弱い表現のようです. 修平> ILEVEL 修平> REQUIRED: FLIM implementation MUST implement it. 修平> RECOMMENDED: FLIM implementation SHOULD implement it. 修平> OPTIONAL: FLIM implementation MAY implement it. 修平> ULEVEL (引用部の "implementation level" は "use level"(?) の誤り修平> ですか?) ;; 文書の性格を物語っていますね。(^_^;;; 修平> RECOMMENDED: FLIM application SHOULD use it. 修平> DISCOURAGED: FLIM application SHOULD NOT use it. 修平> OBSOLETE: FLIM application SHOULD NOT use it. It's historical. 修平> というのはどうでしょうか? 賛成します。修平> ;; "DISCOURAGED" は RFC 2119 用語ではないのですね... ふむ。 -- ┯━…‥・懐かしい未来の記憶をふと思い出しかけた・‥…━━┯━━━┯━ ││ ─ │ ─ ／ ─ ┼─ ┬ ─ ─┼ ┬┴─ ┼┼─┼|〓━─┼ 守岡知彦 (MORIOKA Tomohiko) ─ ─┬ ┻┻━┻━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ From tomo ＠ kanji.zinbun.kyoto-u.ac.jp Mon May 7 21:25:18 2001 From: tomo ＠ kanji.zinbun.kyoto-u.ac.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiA=?= =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko) Date: 07 May 2001 21:25:18 +0900 Subject: FLIM 1.14 API (Re: flim-1_13-rfc2231 vs flim-1_14-rfc2231) In-Reply-To: Shuhei KOBAYASHI's message of "01 May 2001 19:58:57 +0900" References: <86pug42otj.fsf@aqua.ocn.ne.jp> <861yqc9ue3.fsf@aqua.ocn.ne.jp> <86vgno8cu0.fsf_-_@aqua.ocn.ne.jp> <86elu2x1ha.fsf@aqua.ocn.ne.jp> <867kzux1d4.fsf@aqua.ocn.ne.jp> Message-ID: >>>>> [emacs-mime-ja : No.00868] にて >>>>> “修平”= Shuhei KOBAYASHI さま曰く: 修平> > > `mime-content-type' 型の構造が API に含まれないとなれば, この関数修平> > > の返り値の型は実装依存になりますね. 修平> > そうなりますね。修平> > `mime-parameters' 型が満たすべき条件と `mime-parameters' 型に関する修平> > API を追加するのが良いと思っています。修平> [...] 修平> > > そもそも, `mime-content-type-parameter' と修平> > > `mime-content-type-parameters' の両方があるのは冗長ではないですか? 修平> > 冗長ですが、そのことが問題だとは思いません。修平> ところで, `mime-parameters' 型の導入は FLIM 1.14 では行なわない修平> という事になっていませんでしたっけ? flim-1_13-rfc2231 の merge 修平> が保留になっていた理由のひとつがこれだったような気がするのですが... 修平> `mime-parameters' 型の導入は FLIM 1.14 で行なうが, API に関する修平> 検討が未だ行なわれていないというだけだったかもしれませんがよく憶修平> えていません. 覚えていません。ただ、alist としての実装を容認する形で mime-parameter 型に関する規定を FLIM 1.14 API に追加するのが望ましいと思います。 -- ┯━…‥・懐かしい未来の記憶をふと思い出しかけた・‥…━━┯━━━┯━ ││ ─ │ ─ ／ ─ ┼─ ┬ ─ ─┼ ┬┴─ ┼┼─┼|〓━─┼ 守岡知彦 (MORIOKA Tomohiko) ─ ─┬ ┻┻━┻━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ From shuhei ＠ aqua.ocn.ne.jp Tue May 8 22:06:29 2001 From: shuhei ＠ aqua.ocn.ne.jp (Shuhei KOBAYASHI) Date: 08 May 2001 22:06:29 +0900 Subject: FLIM 1.14 API (Re: flim-1_13-rfc2231 vs flim-1_14-rfc2231) References: <86pug42otj.fsf@aqua.ocn.ne.jp> <861yqc9ue3.fsf@aqua.ocn.ne.jp> <86vgno8cu0.fsf_-_@aqua.ocn.ne.jp> <86elu2x1ha.fsf@aqua.ocn.ne.jp> Message-ID: <86d79kuh0q.fsf@aqua.ocn.ne.jp> >>>>> In , >>>>> tomo ＠ kanji.zinbun.kyoto-u.ac.jp (守岡知彦 / MORIOKA Tomohiko) wrote: > > ;; [emacs-mime-ja:00859] (Message-Id: <86g0ep5o9a.fsf ＠ aqua.ocn.ne.jp>) と > > ;; 共に送った 3 通が戻ってこないので再送します. (守岡さんには届きました?) > ;; 届いてました。反応悪くてごめんなさい。 ;; Gnus の draft buffer を使い回したら 4 通共同じ Message-ID になってし ;; まったのですが, m17n.org の方(fml?)で reject されたということかなぁ? > > ULEVEL (引用部の "implementation level" は "use level"(?) の誤りですか?) > ;; 文書の性格を物語っていますね。(^_^;;; ん, 結局 "ULEVEL" は何の略なのでしょうか? よくわからないので, > RECOMMENDED: FLIM implementation SHOULD implement it. [...] > RECOMMENDED: FLIM application SHOULD use it. に合わせて [ILEVEL] とにしてしまってもよいでしょうか? [ILEVEL] indicates requirement level of FLIM implementation. REQUIRED: FLIM implementation MUST implement it. RECOMMENDED: FLIM implementation SHOULD implement it. OPTIONAL: FLIM implementation MAY implement it. indicates requirement level of FLIM application. RECOMMENDED: FLIM application SHOULD use it. DISCOURAGED: FLIM application SHOULD NOT use it. OBSOLETE: FLIM application SHOULD NOT use it. It's historic. > > OBSOLETE: FLIM application SHOULD NOT use it. It's historical. つられて "historical" と書いたけど, "historic" が正しい? (自信なし) -- Shuhei KOBAYASHI From tomo ＠ kanji.zinbun.kyoto-u.ac.jp Wed May 9 13:57:29 2001 From: tomo ＠ kanji.zinbun.kyoto-u.ac.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiA=?= =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko) Date: 09 May 2001 13:57:29 +0900 Subject: FLIM 1.14 API (Re: flim-1_13-rfc2231 vs flim-1_14-rfc2231) In-Reply-To: Shuhei KOBAYASHI's message of "01 May 2001 19:58:57 +0900" References: <86pug42otj.fsf@aqua.ocn.ne.jp> <861yqc9ue3.fsf@aqua.ocn.ne.jp> <86vgno8cu0.fsf_-_@aqua.ocn.ne.jp> <867kzux1d4.fsf@aqua.ocn.ne.jp> <861yq2x1b0.fsf@aqua.ocn.ne.jp> Message-ID: >>>>> [emacs-mime-ja : No.00867] にて >>>>> “修平”= Shuhei KOBAYASHI さま曰く: 修平> > > あ, "[Inline function]" と規定しているのも問題ですね. 修平> > > `mime-content-type' 型の詳細を隠蔽できなくなってしまいます. 修平> > > 守岡さんは(or FLIM API では) *.elc の互換性は気にしないので修平> > > したっけ? 修平> > 問題があれば修正してください。修平> API 中の inline function を全て通常の function に修正してもいい修平> のですか? 結論からいえば、上記に反対しません。但し、inline function という範疇は残した方が良いと思います。（字面上の）機能の呼出し方にも関わりますので。修平> >>>>> In <87wvy6icj4.fsf ＠ pc-hrvoje.srce.hr>, 修平> >>>>> Hrvoje Niksic wrote: 修平> > Bad bad bad. defsubst'ing a function is almost always wrong. 修平> に賛同する私としては, FLIM API に含まれる inline function が展開修平> されてAPI に含まれない部分が *.elc に残るのは問題があると思って修平> いるのですが, FLIM API が提供する互換性は *.el だけのものか, 修平> *.elc の互換性も保証するのかは議論されていないですよね? （私の当てにならない記憶によれば）API が *.elc の互換性を保証するかという問題に関してはまだ議論されていないと思います。ただ、私の当初の考えでは、FLIM API そのものは *.elc の互換性に関して言及しないものとしていました。即ち、字面上の機能の使用法のみを規定し、どう compile されるかとか ABI に関しては規定しないという立場です。Emacs 18 でも JEmacs でも Guile でも実装可能であって欲しいと思うので。修平> ;; FLIM 実装を差し替えても SEMI やその上の application を再修平> ;; compile したくはないということです. flim-1_14-rfc2231 の修平> ;; lazy に decode するversion を試作した時に SEMI の再 compile 修平> ;; が必要になったので. ただ、このことは理解できます。FLIM ABI for GNU Emacs 20/21 とか FLIM ABI for XEmacs とかを作るのはおそらくやりすぎでしょうから、inline function に制限を加えることは現実的だと思います。１つは API 上、inline function/macro を一切使わないということだと思いますが、macro を使わないとできないこととかもあるかも知れないので、そう規定するのは留保したいです。もう一つは、inline function が実際に展開される関数として実現されている場合に、展開された結果利用される関数を規定するということです。例えば、 (mime-entity-media-type entity) は (mime-content-type-primary-type (mime-entity-content-type entity)) のように、mime-entity-content-type と mime-content-type-primary-type に展開され得ると規定します。この場合、mime-content-type-primary-type は function とします。macro もできる限り展開先の関数を規定することにします。いかがでしょうか？ -- ┯━…‥・懐かしい未来の記憶をふと思い出しかけた・‥…━━┯━━━┯━ ││ ─ │ ─ ／ ─ ┼─ ┬ ─ ─┼ ┬┴─ ┼┼─┼|〓━─┼ 守岡知彦 (MORIOKA Tomohiko) ─ ─┬ ┻┻━┻━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ From shuhei ＠ aqua.ocn.ne.jp Wed May 9 19:29:39 2001 From: shuhei ＠ aqua.ocn.ne.jp (Shuhei KOBAYASHI) Date: 09 May 2001 19:29:39 +0900 Subject: FLIM 1.14 API (Re: flim-1_13-rfc2231 vs flim-1_14-rfc2231) References: <86pug42otj.fsf@aqua.ocn.ne.jp> <861yqc9ue3.fsf@aqua.ocn.ne.jp> <86vgno8cu0.fsf_-_@aqua.ocn.ne.jp> <86elu2x1ha.fsf@aqua.ocn.ne.jp> <86d79kuh0q.fsf@aqua.ocn.ne.jp> Message-ID: <86d79iu86k.fsf@aqua.ocn.ne.jp> >>>>> In <86d79kuh0q.fsf ＠ aqua.ocn.ne.jp>, >>>>> Shuhei KOBAYASHI wrote: > [ILEVEL] indicates requirement level of FLIM implementation. > > REQUIRED: FLIM implementation MUST implement it. > RECOMMENDED: FLIM implementation SHOULD implement it. > OPTIONAL: FLIM implementation MAY implement it. ひとつ忘れていましたが, "[REQUIRED]" ではない API を利用しようとする FLIM application はどのようにしてその API の存在を確認したらよいのでしょうか? (使う前に fboundp で確認しないと駄目とか?) -- Shuhei KOBAYASHI おまけ: | (Usage: SEMI 1.14 MIME-View) "Usage:" という表現に違和感を受けました. 「使用法」かと思ってしまった. "disk usage" のように「使用の度合い」という意味もあるみたいですが, 今開いている辞書には「"USE" の御用という意見も多い」と書かれています. "Used by ..." と書くのがわかりやすくて好みです. From shuhei ＠ aqua.ocn.ne.jp Wed May 9 19:09:40 2001 From: shuhei ＠ aqua.ocn.ne.jp (Shuhei KOBAYASHI) Date: 09 May 2001 19:09:40 +0900 Subject: FLIM 1.14 API (Re: flim-1_13-rfc2231 vs flim-1_14-rfc2231) References: <86pug42otj.fsf@aqua.ocn.ne.jp> <861yqc9ue3.fsf@aqua.ocn.ne.jp> <86vgno8cu0.fsf_-_@aqua.ocn.ne.jp> <867kzux1d4.fsf@aqua.ocn.ne.jp> <861yq2x1b0.fsf@aqua.ocn.ne.jp> Message-ID: <86eltyu93v.fsf@aqua.ocn.ne.jp> >>>>> In , >>>>> tomo ＠ kanji.zinbun.kyoto-u.ac.jp (守岡知彦 / MORIOKA Tomohiko) wrote: > １つは API 上、inline function/macro を一切使わないということだと思い > ますが、macro を使わないとできないこととかもあるかも知れないので、そう > 規定するのは留保したいです。 macro でなければできないこともあるので, inline function とは分けて考えましょう. (FLIM API に含まれる macro の必然性については未検討なので...) > もう一つは、inline function が実際に展開される関数として実現されている > 場合に、展開された結果利用される関数を規定するということです。この事は考えてみたのですが, 「展開された結果利用される関数を規定する」というのでは不十分なのですよ. 利用のされ方まで規定しないと意味がないです. 単純な例でいうと | (defun make-mime-content-type (type subtype &optional parameters) | (cons (cons 'type type) | (cons (cons 'subtype subtype) | parameters))) と | (defun make-mime-content-type (type subtype &optional parameters) | (cons type (cons subtype parameters))) の二通りの `mime-content-type' に対する `mime-content-type-primary-type' を inline function として定義すると, それぞれ | (defsubst mime-content-type-primary-type (content-type) | "Return primary-type of CONTENT-TYPE." | (cdr (car content-type))) と | (defsubst mime-content-type-primary-type (content-type) | "Return primary-type of CONTENT-TYPE." | (car content-type))) になり, 展開された結果利用される関数を `car' と `cdr' に制限したところで互換性は得られませんよね? また, ある実装では互換性に影響しないということで展開した関数が, 別の実装では展開の結果が内部構造に依存してしまうかもしれません. そんなわけで, API 上, inline function は一切使わないことにしたいです. -- Shuhei KOBAYASHI おまけ: (defsubst luna-arglist-to-arguments (arglist) (let (dest) (while arglist (let ((arg (car arglist))) (or (memq arg '(&optional &rest)) (setq dest (cons arg dest)))) (setq arglist (cdr arglist))) (nreverse dest))) `luna-arglist-to-arguments' は macro の展開時(byte-compile 時)に使用される関数で, inline function にする意味は全くないですよね? こんな使い方を目にすると, inline function なんてやめてしまえと思ってしまいます;-p ちなみに, `luna-arglist-to-arguments' は (defun luna-arglist-to-arguments (arglist) (delq '&optional (delq '&rest (copy-sequence arglist)))) で済みますよね? From shuhei ＠ aqua.ocn.ne.jp Wed May 9 20:23:18 2001 From: shuhei ＠ aqua.ocn.ne.jp (Shuhei KOBAYASHI) Date: 09 May 2001 20:23:18 +0900 Subject: FLIM 1.14 API (Re: flim-1_13-rfc2231 vs flim-1_14-rfc2231) References: <86pug42otj.fsf@aqua.ocn.ne.jp> <861yqc9ue3.fsf@aqua.ocn.ne.jp> <86vgno8cu0.fsf_-_@aqua.ocn.ne.jp> <86elu2x1ha.fsf@aqua.ocn.ne.jp> <867kzux1d4.fsf@aqua.ocn.ne.jp> Message-ID: <867kzqu5p5.fsf@aqua.ocn.ne.jp> >>>>> In , >>>>> tomo ＠ kanji.zinbun.kyoto-u.ac.jp (守岡知彦 / MORIOKA Tomohiko) wrote: > `mime-parameters' 型が満たすべき条件と `mime-parameters' 型に関する > API を追加するのが良いと思っています。 >>>>> In , >>>>> tomo ＠ kanji.zinbun.kyoto-u.ac.jp (守岡知彦 / MORIOKA Tomohiko) wrote: > ただ、alist としての実装を容認する形で mime-parameter 型に関する規定を > FLIM 1.14 API に追加するのが望ましいと思います。後者の引用部も正しくは mime-parameter*s* 型ですよね? 私の方に誤解があったみたいなので念のため. 私が問題にしているのは mime-content-type-parameters 等の返り値の型 (mime- parameters 型) ですが, flim-1_13-rfc2231 で追加されたのは mime-parameter 型でした. 混同したまま flim-1_13-rfc2231 について書いた部分があったかも. -- Shuhei KOBAYASHI From tomo ＠ kanji.zinbun.kyoto-u.ac.jp Wed May 9 21:23:00 2001 From: tomo ＠ kanji.zinbun.kyoto-u.ac.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiA=?= =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko) Date: 09 May 2001 21:23:00 +0900 Subject: FLIM 1.14 API (Re: flim-1_13-rfc2231 vs flim-1_14-rfc2231) In-Reply-To: Shuhei KOBAYASHI's message of "09 May 2001 20:23:18 +0900" References: <86pug42otj.fsf@aqua.ocn.ne.jp> <861yqc9ue3.fsf@aqua.ocn.ne.jp> <86vgno8cu0.fsf_-_@aqua.ocn.ne.jp> <86elu2x1ha.fsf@aqua.ocn.ne.jp> <867kzux1d4.fsf@aqua.ocn.ne.jp> <867kzqu5p5.fsf@aqua.ocn.ne.jp> Message-ID: >>>>> [emacs-mime-ja : No.00876] にて >>>>> “修平”= Shuhei KOBAYASHI さま曰く: 修平> >>>>> In , 修平> >>>>> tomo ＠ kanji.zinbun.kyoto-u.ac.jp (守岡知彦 / MORIOKA Tomohiko) wrote: 修平> > `mime-parameters' 型が満たすべき条件と `mime-parameters' 型に修平> > 関するAPI を追加するのが良いと思っています。修平> >>>>> In , 修平> >>>>> tomo ＠ kanji.zinbun.kyoto-u.ac.jp (守岡知彦 / MORIOKA Tomohiko) wrote: 修平> > ただ、alist としての実装を容認する形で mime-parameter 型に関す修平> > る規定をFLIM 1.14 API に追加するのが望ましいと思います。修平> 後者の引用部も正しくは mime-parameter*s* 型ですよね? 修平> 私の方に誤解があったみたいなので念のため. はい、その通りです。書き間違えてごめんなさい。 ;; 帰りのバスの時間が迫ってたので。(^_^;（でも、結局乗り遅れた(;_;)。 ;; すると近鉄京都線と橿原線 (cf. $(FLIM_SRC)/VERSION) の接続が極端に悪 ;; くなって、帰宅に２時間以上かかってしまう）修平> 私が問題にしているのは mime-content-type-parameters 等の返り値の修平> 型 (mime-parameters 型) ですが, flim-1_13-rfc2231 で追加された修平> のは mime-parameter 型でした. 混同したまま flim-1_13-rfc2231 につ修平> いて書いた部分があったかも. mime-parameter 型は mime-parameter 型で考えないといけないという話はありますが、FLIM 1.14 では見送りたいです。ちなみに、GNU Emacs 21 の RMAIL に SEMI を使って MIME 化するための基盤となる code が merge されました。これは Semi-gnus 等のように、network 表現を表す rmail-buffer と presentation を表す rmail-view-buffer を区別し、また、SEMI などの MIME 実装を呼び出すための変数を追加したような修正です。これに伴い、leim のような形で、FLIM, SEMI, EMH, Semi-RMAIL などを含んだ package を release する予定です。また、これに収録する予定の FLIM/SEMI を 1.14.X の安定版として release したいと思っています。そういう訳で、bug fix, merge 等ありましたらお早めにお願いします（私としては 5/19 から 6 月上旬まで作業する予定です）。また、STD 11 関連機能の luna 化と mime-entity 系 API での header の扱いの再検討を FLIM 1.15 で行いたいと思っています。では。 -- ┯━…‥・懐かしい未来の記憶をふと思い出しかけた・‥…━━┯━━━┯━ ││ ─ │ ─ ／ ─ ┼─ ┬ ─ ─┼ ┬┴─ ┼┼─┼|〓━─┼ 守岡知彦 (MORIOKA Tomohiko) ─ ─┬ ┻┻━┻━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ From shuhei ＠ aqua.ocn.ne.jp Sat May 26 17:54:17 2001 From: shuhei ＠ aqua.ocn.ne.jp (Shuhei KOBAYASHI) Date: 26 May 2001 17:54:17 +0900 Subject: mime-parameters API (Re: FLIM 1.14 API (Re: flim-1_13-rfc2231 vs flim-1_14-rfc2231)) References: <86pug42otj.fsf@aqua.ocn.ne.jp> <861yqc9ue3.fsf@aqua.ocn.ne.jp> <86vgno8cu0.fsf_-_@aqua.ocn.ne.jp> <86elu2x1ha.fsf@aqua.ocn.ne.jp> <867kzux1d4.fsf@aqua.ocn.ne.jp> Message-ID: <86g0dswkw6.fsf@aqua.ocn.ne.jp> >>>>> In , >>>>> tomo ＠ kanji.zinbun.kyoto-u.ac.jp (守岡知彦 / MORIOKA Tomohiko) wrote: > `mime-parameters' 型が満たすべき条件と `mime-parameters' 型に関する > API を追加するのが良いと思っています。 >>>>> In , >>>>> tomo ＠ kanji.zinbun.kyoto-u.ac.jp (守岡知彦 / MORIOKA Tomohiko) wrote: > ただ、alist としての実装を容認する形で mime-parameter 型に関する規定を > FLIM 1.14 API に追加するのが望ましいと思います。必要な API はまず, * ある parameter の値を取得する. それと, mmedit(?) が導入された時に必要になりそうなのが, * ある parameter の値を設定する. さらに, `mime-content-type-parameters' の使われ方を調べてみると, * 全ての parameter に対して何らかの処理をする. というのが必要になるでしょうか. まずは parameter を取得 / 設定する関数の方から. 案 A: TYPE-SLOT / TYPE-set-SLOT に合わせると, * (mime-parameters-parameter PARAMETERS ATTRIBUTE) => VALUE * (mime-parameters-set-parameter PARAMETERS ATTRIBUTE NEW-VALUE) => ? "parameters-parameter" というのが気持ち悪いですね. ;; `parameter' という SLOT があるわけではないという話もありますし... 案 B: それでは, plist-get / plist-put みたいに, * (mime-parameters-get PARAMETERS ATTRIBUTE) => VALUE * (mime-parameters-put PARAMETERS ATTRIBUTE NEW-VALUE) => ? おっと, 案 A, B では parameter の削除ができませんね. ;; NEW-VALUE に nil を与えた場合を削除とみなすという手もありますが... 案 C: では, add-text-properties / remove-text-properties のように, * (mime-parameters-get-parameter PARAMETERS ATTRIBUTE) => VALUE * (mime-parameters-add-parameter PARAMETERS ATTRIBUTE NEW-VALUE) => ? * (mime-parameters-remove-parameter PARAMETERS ATTRIBUTE) => ? ん, これでもまだ mime-parameters 型が alist(や plist) の場合には先頭の parameter を削除できないという問題がありますね. parameter を設定する関数の返り値は更新された mime-parameters であると定義し, mime-parameters を設定する場合には (setq parameters (mime-parameters-add-parameter PARAMETERS ATTRIBUTE NEW-VALUE)) や (mime-content-type-set-parameters CONTENT-TYPE (mime-parameters-remove-parameter PARAMETERS ATTRIBUTE)) のようにしなければ変更が反映されない(かもしれない)と定めるのが良いかな? 全ての parameter に対して何らかの処理をする関数の方は, * (mime-parameters-for-each-parameter FUNC PARAMETERS) => (FUNC ATTRIBUTE VALUE) => でどうでしょうか? 結論として, mime-parameters API として, * (mime-parameters-get-parameter PARAMETERS ATTRIBUTE) => VALUE * (mime-parameters-add-parameter PARAMETERS ATTRIBUTE NEW-VALUE) => NEW-PARAMETERS * (mime-parameters-remove-parameter PARAMETERS ATTRIBUTE) => NEW-PARAMETERS * (mime-parameters-for-each-parameter FUNC PARAMETERS) => (FUNC ATTRIBUTE VALUE) => を提案します. ;; s/add/set/ や s/remove/delete/ という variant も可. ;;;; Lisp community での remove と delete の使い分けはどうなっていたっけ? また, `mime-content-type-parameters' や `mime-content-disposition-parameters' に対応する (mime-content-type-set-parameters CONTENT-TYPE NEW-PARAMETERS) や (mime-content-disposition-set-parameters CONTENT-DISPOSITION NEW-PARAMETERS) も追加する必要がありますね. -- Shuhei KOBAYASHI From shuhei ＠ aqua.ocn.ne.jp Tue May 29 19:36:38 2001 From: shuhei ＠ aqua.ocn.ne.jp (Shuhei KOBAYASHI) Date: 29 May 2001 19:36:38 +0900 Subject: flim-1_13-rfc2231 vs flim-1_14-rfc2231 (Re: flim-1_14-rfc2231) References: <86pug42otj.fsf@aqua.ocn.ne.jp> <861yqc9ue3.fsf@aqua.ocn.ne.jp> Message-ID: <86wv70v3ux.fsf@aqua.ocn.ne.jp> >>>>> In <861yqc9ue3.fsf ＠ aqua.ocn.ne.jp>, >>>>> Shuhei KOBAYASHI wrote: > FLIM の RFC 2231 対応の main trunk への merge を検討しているのですが... 突然ですが, 5/31 の朝までに反論がなければ flim-1_14-rfc2231 を main trunk に merge しようと思います. 1. 現在の flim-1_14-rfc2231 の内容を main trunk にそのまま merge. この段階では commit しないかも. 2. 試験的な code を除去. この時点で flim-1_14-rfc2231-merged の tag を付ける. 3. FLIM-API.en の flim-1_14-rfc2231 関連部分のみを update. mime-parameters API は flim-1_14-rfc2231 とは直接関連しないので保留. これだけの作業を(GMT で) 5/31 日中に行なうつもりです. ;; 反論があった場合には作業は無期延期します. 時間があれば Emacs-MIME(or LEMI?) への sync も同日中に行ないます. > 守岡さん >>>>> In , >>>>> tomo ＠ kanji.zinbun.kyoto-u.ac.jp (守岡知彦 / MORIOKA Tomohiko) wrote: > また、STD 11 関連機能の luna 化と mime-entity 系 API での header の扱 > いの再検討を FLIM 1.15 で行いたいと思っています。 ;; 次期 std11.el では To:(or Cc:) をたくさんつけたヘボいメールへの対策 ;; を行ないましょうと話してからだいぶ時間が経ってしまいましたね. ;; (RFC2822 も先に出てしまったし.) -- Shuhei KOBAYASHI From tomo ＠ kanji.zinbun.kyoto-u.ac.jp Tue May 29 20:35:12 2001 From: tomo ＠ kanji.zinbun.kyoto-u.ac.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiA=?= =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko) Date: 29 May 2001 20:35:12 +0900 Subject: flim-1_13-rfc2231 vs flim-1_14-rfc2231 (Re: flim-1_14-rfc2231) In-Reply-To: Shuhei KOBAYASHI's message of "29 May 2001 19:36:38 +0900" References: <86pug42otj.fsf@aqua.ocn.ne.jp> <861yqc9ue3.fsf@aqua.ocn.ne.jp> <86wv70v3ux.fsf@aqua.ocn.ne.jp> Message-ID: >>>>> [emacs-mime-ja : No.00879] にて >>>>> “修平”= Shuhei KOBAYASHI さま曰く: 修平> >>>>> In <861yqc9ue3.fsf ＠ aqua.ocn.ne.jp>, 修平> >>>>> Shuhei KOBAYASHI wrote: 修平> > FLIM の RFC 2231 対応の main trunk への merge を検討しているのですが... 修平> 突然ですが, 5/31 の朝までに反論がなければ flim-1_14-rfc2231 を修平> main trunkに merge しようと思います. 修平> 1. 現在の flim-1_14-rfc2231 の内容を main trunk にそのまま merge. 修平> この段階では commit しないかも. 修平> 2. 試験的な code を除去. 修平> この時点で flim-1_14-rfc2231-merged の tag を付ける. 修平> 3. FLIM-API.en の flim-1_14-rfc2231 関連部分のみを update. 修平> mime-parameters API は flim-1_14-rfc2231 とは直接関連しないので保留. 修平> これだけの作業を(GMT で) 5/31 日中に行なうつもりです. 修平> ;; 反論があった場合には作業は無期延期します. 修平> 時間があれば Emacs-MIME(or LEMI?) への sync も同日中に行ないます. 修平> > 守岡さん賛成します。よろしくお願いします。 ;; mail の返事が滞っていてすみません。なのにまた仕事が増えてしまった。 ;; (;_;) とりあえず、SEMI 関連では、rmail-mime の bug をもう一つ片付け ;; て、rmail の patch を feedback して、LEMI (Emacs 21 用の中盛り ;; package) の beta test を開始したいと思っています。修平> >>>>> In , 修平> >>>>> tomo ＠ kanji.zinbun.kyoto-u.ac.jp (守岡知彦 / MORIOKA Tomohiko) wrote: 修平> > また、STD 11 関連機能の luna 化と mime-entity 系 API での修平> > header の扱いの再検討を FLIM 1.15 で行いたいと思っています。修平> ;; 次期 std11.el では To:(or Cc:) をたくさんつけたヘボいメールへ修平> ;; の対策を行ないましょうと話してからだいぶ時間が経ってしまいま修平> ;; したね. 修平> ;; (RFC2822 も先に出てしまったし.) ;; 全く申し訳ないです。私事ながら、UTF-2000 用文字データベースがもう少 ;; ししたら一段落するのでそうすると FLIM/SEMI に回せる時間が若干増える ;; かも知れません（まあ、私のようなへぼが出て来ない方が良いような気も ;; しますが(^_^;）。 -- ┯━…‥・懐かしい未来の記憶をふと思い出しかけた・‥…━━┯━━━┯━ ││ ─ │ ─ ／ ─ ┼─ ┬ ─ ─┼ ┬┴─ ┼┼─┼|〓━─┼ 守岡知彦 (MORIOKA Tomohiko) ─ ─┬ ┻┻━┻━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ From shuhei ＠ aqua.ocn.ne.jp Tue May 29 23:16:06 2001 From: shuhei ＠ aqua.ocn.ne.jp (Shuhei KOBAYASHI) Date: 29 May 2001 23:16:06 +0900 Subject: flim-1_13-rfc2231 vs flim-1_14-rfc2231 (Re: flim-1_14-rfc2231) References: <86pug42otj.fsf@aqua.ocn.ne.jp> <861yqc9ue3.fsf@aqua.ocn.ne.jp> <86wv70v3ux.fsf@aqua.ocn.ne.jp> Message-ID: <86pucsutp5.fsf@aqua.ocn.ne.jp> >>>>> In , >>>>> tomo ＠ kanji.zinbun.kyoto-u.ac.jp (守岡知彦 / MORIOKA Tomohiko) wrote: > > 突然ですが, 5/31 の朝までに反論がなければ flim-1_14-rfc2231 を > > main trunkに merge しようと思います. すみませんが, 5/30 の夜までということにさせてください. ;; テレホーダイ(フレッツはまだ来ていない)を活用して未明に作業するつもり. > > ;; 次期 std11.el では To:(or Cc:) をたくさんつけたヘボいメールへの > > ;; 対策を行ないましょうと話してからだいぶ時間が経ってしまいましたね. > > ;; (RFC2822 も先に出てしまったし.) > ;; 全く申し訳ないです。これを書いたきっかけは某所で間接的に std11.el がヘボいと言われたことで, 遅れを非難する意図は全くありません. FLIM 1.14 に間に合わせたかったら, 自分で作業して「こんなの出来ましたけど」と言って branch 作って放り込んでしまえば良かったと知っていますから;-) ;; その後 ietf-822 にはいくつか mail が流れたけど, RFC822 では multiple ;; fields の扱いは unspecified となっていて, To:(or Cc:) をたくさんつけ ;; ても確実に処理されるとは期待できないのに, それを送ってしまうのが一番 ;; ヘボいということにはもう気付いたかしら? -- Shuhei KOBAYASHI From koichiro ＠ ctc-g.co.jp Thu May 31 10:01:38 2001 From: koichiro ＠ ctc-g.co.jp (Koichiro Ohba) Date: Thu, 31 May 2001 10:01:38 +0900 Subject: m17n.org ViewCVS error Message-ID: 大場です。どこに問い合わせたよいのかわからないのですが…。適切なところへ振っていただけるとありがたいです。 Wanderlust elmo-lunafy 枝を取り出そうと http://cvs.m17n.org/cgi-bin/viewcvs/wanderlust/wanderlust.tar.gz?tarball=1&only_with_tag=elmo-lunafy をすると以下のような Exception で止まります。 -------------- next part -------------- Python Exception Occurred Traceback (innermost last): File "viewcvs.py", line 2514, in run_cgi main() File "viewcvs.py", line 2500, in main download_tarball(request) File "viewcvs.py", line 2422, in download_tarball generate_tarball(fp, os.path.basename(directory), directory, tag) File "viewcvs.py", line 2406, in generate_tarball generate_tarball(out, relative + '/' + subdir, directory + '/' + subdir, tag, stack) File "viewcvs.py", line 2366, in generate_tarball for file, pathname, isdir in get_file_data(directory + '/Attic'): File "viewcvs.py", line 635, in get_file_data files = os.listdir(full_name) OSError: [Errno 2] No such file or directory -------------- next part -------------- -- KOICHIRO, Ohba (大場光一郎) / mailto:koichiro ＠ ctc-g.co.jp From akr ＠ m17n.org Thu May 31 11:50:32 2001 From: akr ＠ m17n.org (Tanaka Akira) Date: 31 May 2001 11:50:32 +0900 Subject: m17n.org ViewCVS error In-Reply-To: (Koichiro Ohba's message of "Thu, 31 May 2001 10:01:38 +0900") References: Message-ID: In article , Koichiro Ohba writes: > Wanderlust elmo-lunafy 枝を取り出そうと > > http://cvs.m17n.org/cgi-bin/viewcvs/wanderlust/wanderlust.tar.gz?tarball=1&only_with_tag=elmo-lunafy 直しました。 -- [田中哲][たなかあきら][Tanaka Akira] 「ふえろ! わかめちゃん作戦です?」(Little Worker, 桂遊生丸) From shuhei ＠ aqua.ocn.ne.jp Thu May 31 12:26:47 2001 From: shuhei ＠ aqua.ocn.ne.jp (Shuhei KOBAYASHI) Date: 31 May 2001 12:26:47 +0900 Subject: flim-1_13-rfc2231 vs flim-1_14-rfc2231 (Re: flim-1_14-rfc2231) References: <86pug42otj.fsf@aqua.ocn.ne.jp> <861yqc9ue3.fsf@aqua.ocn.ne.jp> <86wv70v3ux.fsf@aqua.ocn.ne.jp> Message-ID: <864ru2gpvs.fsf@aqua.ocn.ne.jp> >>>>> In <86wv70v3ux.fsf ＠ aqua.ocn.ne.jp>, >>>>> Shuhei KOBAYASHI wrote: > 1. 現在の flim-1_14-rfc2231 の内容を main trunk にそのまま merge. > 2. 試験的な code を除去. > 3. FLIM-API.en の flim-1_14-rfc2231 関連部分のみを update. 予定とはちょっと異なりましたが, これらを全て行なった段階で commit し, flim-1_14-rfc2231-merged の tag を付けました. ;; tests/test-rfc2231.el の commit 時に error が出たため, それ以外の ;; 部分の commit mail が流れなかったみたいです. LIMIT 方面の方へ: (simm さんと kaoru さん?) MIME parameter value の独自拡張(encoded-word や生の ISO-2022-JP, Shift_ JIS を使用するもの)を decode するための code を comment として入れておきました. ただし, decode に使用する charset の選択には検討の余地があると思います. MIME parameter value の独自拡張への対処は, 以前に守岡さんと話した時は * mime-parse-* では対処しない. * mime-entity-filename で救済する. のが良いのではないかという話になったのですが, 今回の作業で, RFC2231 の拡張が使われていない場合(上記の comment 部分)に限って独自拡張の decoder を呼び出すのが良いのではないかと思うようになりました. もうひとつ. flim-1_13-rfc2231 にあって flim-1_14-rfc2231 にはなかった >>>>> In <861yqc9ue3.fsf ＠ aqua.ocn.ne.jp>, >>>>> Shuhei KOBAYASHI wrote: > 1. RFC 2231 とは無関係なもの. [...] > b. eword-decode の structured-field 系 decoder が parse に失敗した > 場合に unstructured-field として強制的に decode する. が埋もれたままになるのは惜しいので, LIMIT で採り入れて開発の前線に戻していただくのが良いと思うのですがどうでしょうか? -- Shuhei KOBAYASHI From shuhei ＠ aqua.ocn.ne.jp Thu May 31 21:42:38 2001 From: shuhei ＠ aqua.ocn.ne.jp (Shuhei KOBAYASHI) Date: 31 May 2001 21:42:38 +0900 Subject: Bug? Xemacs 21.1/Flim 1.14.2: mel-b-el.elc not installed correctly References: Message-ID: <86zobtg05d.fsf@aqua.ocn.ne.jp> emacs-mime-en より: >>>>> In , >>>>> Katsumi Yamaoka wrote: > By the way, it seems that mel-b-el is out of support in FLIM 1.14.2 > because it does not require `pces' even if it is needed to byte- > compile mel-b-el.el. Morioka-san? mel-b-el -> mime-def -> mcharset -> pces と require していたものが, 以下の変更で mcharset が pces を require しなくなったために動かなくなったみたいですね. 2000-12-28 MORIOKA Tomohiko * mcharset.el (default-mime-charset-for-write): Use `mime-charset-p' instead of `find-coding-system'; don't require `pces'. Index: mcharset.el =================================================================== RCS file: /cvs/root/apel/mcharset.el,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- mcharset.el 2000/12/28 04:58:17 1.10 +++ mcharset.el 2000/12/28 05:03:03 1.11 @@ -39,8 +39,7 @@ (require 'mcs-ltn1))) (defcustom default-mime-charset-for-write - (if (and (require 'pces) ; for find-coding-system - (mime-charset-p 'utf-8)) + (if (mime-charset-p 'utf-8) 'utf-8 default-mime-charset) "Default value of MIME-charset for encoding. この変更自体は正しい([apel-ja:00517])ということと, LEMI (Emacs 21 用の中盛り package)に向けて mime-def.el に APEL 依存部を増やすべきではないのでは? ということから, as-binary 系の関数や macro を使用している個々の MEL module で pces を require するという対処が良いのではないでしょうか? -- Shuhei KOBAYASHI