アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日本発のオープンソースソフトウェアは42件 -- ある官僚
メールの仕様も息長いね (スコア:0)
DoCoMo :RFC仕様内だが無用なmultipart/mixedを付けた
FOMA :multipart/mixedを添付ありと判断した
RFC :本文、添付と区分けする定義が無い
本文の定義はmultipartでは明確ではなくて、
添付メールだとText + エンコードデータが
バウンダリ分割して送られてきますが、
HTMLメールだとText + HTMLソースが
バウンダリ分割して送られてきます。
RFC仕様内ではText + Textを
バウンダリ分割して送る事も可能です。
おまけ:uuencode時代はText内に添付データを
入れたり
Re:メールの仕様も息長いね (スコア:0)
無用であることには同意しますが、これと
>FOMA :multipart/mixedを添付ありと判断した
これって「悪い」の種類が全然違うと思うのですけど。
>RFC :本文、添付と区分けする定義が無い
RFCで区別する必要なんかあるんでしょうか? 携帯での課金の都合に合わせてそんな概念を導入する必要なんて感じませんけど。どれが本文でどれが添付かなんて主観の問題じゃないでしょうか。
>添付メールだとText + エンコードデータが
>バウンダリ分割して送られてきますが、
textを添付する場合にはエンコードしないで欲しい
Re:メールの仕様も息長いね (スコア:0)
>これって「悪い」の種類が全然違うと思うのですけど。
multipart/mixedは添付ファイルがある事の証明ではないです。
>>RFC :本文、添付と区分けする定義が無い
>RFCで区別する必要なんかあるんでしょうか?
>携帯での課金の都合に合わせてそんな概念を導入する必要なんて感じませんけど。
>どれが本文でどれが添付かなんて主観の問題じゃないでしょうか。
それが問題で今回の話がでたのです。
携帯電話の都合の範囲内の話ではないです。元に書いた例はそれを説明したものです。
主観の問題で済む方法は
multi
Re:メールの仕様も息長いね (スコア:0)
「添付ファイル」はどうだかしりませんが、少なくとも一つのbody partが含まれていることの宣言ではあります。
>主観の問題で済む方法は
>multipart/alternative
>を使うべきです。
どちらが主でどちらが従かが主観の問題であると言っているのであって、主従が存在しない(同じものの別表現である)場合に使うalternativeはこの場合無関係だと思うのですが。
>テキストファイルでも添付時はエンコードしますよ。(BASE64、BinHexなど)
別にエンコードなんぞせずとも添付できますよ。もしかして、添
Re:メールの仕様も息長いね (スコア:0)
>添付ファイルかそうでないかの判定基準にするわけにはいかないでしょ。
いったいいつの時代のどこまで下位互換のどの機能をサポートしたメールを使っているんですか?
今回の話題は
・FOMAは添付ファイルで課金するためにMultipart/mixedで判断した。
・私が書いたのはMultipart/mixedは添付「ファイル」の判断にはならないという事を書いた。
・私はContent-Disposition: attachment;が現時点で無難だと提案した。
>Content-Type:さえ付いていればファイルタイプはわかりますし。
・私はContent-Typeは信用できない内容をリンクした。
いったいどんな方法でファイルが有るという判断が理想的だと
考えますか?ファイル名はどれから取るんですか?
Re:メールの仕様も息長いね (スコア:1)
文中のFOMAはDDIPと間違えてますです。
それはそれとして、
>いったいいつの時代のどこまで下位互換のどの機能をサポートしたメールを使っているんですか?
ここでいうメールってMUAですか?
それが何の関係があるんですか?
逆にお聞きしますが、どんなメール(MUA? MTA?)なら、
Content-Disposition: attachment;が添付ファイルがあることを保証してくれるのでしょうか?
Multipart/mixedが添付ファイルの判断にならないのと同じくらい
Content-Disposition: attachment;もあてにならないと思いますよ。
#そもそも付けてこないやつらはたくさんいるし
>信用できない内容
「そんなくずメーラーを前提にしてもしょうがない」んではないでしょうか。
Content-Disposition: attachment;をつけてこない(解釈できない)メールはけちょんけちょんで、
こっちはおっけーでは話が成り立ってないでしょう。
>いったいどんな方法でファイルが有るという判断が理想的だと
>考えますか?ファイル名はどれから取るんですか?
中身をチェックするしかないんではないでしょうか?
紹介していただいたMewのページでも、ヘッダで違う宣言してても中身みて判断しろよって言ってますしね。 ^^;
理想的には全ての環境でContent-Disposition: attachment;のようなものを確実にサポートすることでしょうかねぇ。
ただし、現状でそんな判断の仕方をするのは危険で無謀ですね。
はぁ~ (スコア:0)
Re:はぁ~ (スコア:0)
いずれにせよ「添付」されるからといってファイル名が必要なわけではないですよ。添付にはファイル名が必要であるというのはどこから出てくる発想なのでしょう?
Re:はぁ~ (スコア:0)
http://www.ddipocket.co.jp/h_link/light_email.html
>RFCで区別する必要なんかあるんでしょうか?
>Content-Type:さえ付いていれば
>optionalなんだからいくらでも抜け道ができますよ
>Content-Type:が信用できないのなら、Content-Disposition:
>なんてもっと信用できないと思うのですが。
>#そもそも付けてこないやつらはたくさんいるし
>中身をチェックするしかないんではないでしょうか
>理想的には全ての環境でContent-Disposition: attachment;の
>ようなものを確実にサポートすることでしょうかねぇ。
Re:はぁ~ (スコア:0)
そのようなサービスをするのなら、そのサービスにおける「添付ファイル」の定義を利用者に提示すべきでしょうね。約款とかに書いてあったりしないのかな?
>実装を無視してRFC
Re:はぁ~ (スコア:1)
>実装を無視して
腐った実装という現実から目を背けているからため息なんかつく羽目になるんですよ。 (^^)
Re:はぁ~ (スコア:0)
>実装を無視してRFCを読みつづけてください。
それほど多くは無いですが、いまだにファイル名なしの添付ファイルを受け取ることがありますよ。(別にPHSで受信するわけではないが)
私にはあなたの方が実装を無視しているように思えるのですが。
Re:はぁ~ (スコア:0)