The use of the "multipart" media type with only a single body part
may be useful in certain contexts, and is explicitly permitted.
NOTE: Experience has shown that a "multipart" media type with a
single body part is useful for sending non-text media types. It has
the advantage of providing the preamble as a place to include
decoding instructions
DDIは悪くないんじゃ? (スコア:0)
ドコモが一方的に悪いように感じるけど?
Re:DDIは悪くないんじゃ? (スコア:2, すばらしい洞察)
2.受信する側の「(ユーザに)やさしくない」仕様
どっちもどっちだと思うよ。
ドコモがなんでもかんでもドンブリで出すのもアレだと思いますが、
課金する/しないの垣根の仕様はDDIが作ってるわけで、そこが野放図なのはDDIの責任でしょ。
さらに、Eメールのサイズオーバーと判断する仕様は言うに及ばずって感じで。
Re:DDIは悪くないんじゃ? (スコア:0)
Re:DDIは悪くないんじゃ? (スコア:1)
なにかと迷惑なドコモ。
ほとんど関係ないが、しばらく前まで、うちの鯖(postfix)からメイルを送信すると高い確率で遅延するのがドコモ(非FOMA)だった。
Re:DDIは悪くないんじゃ? (スコア:0)
Re:DDIは悪くないんじゃ? (スコア:0)
Re:DDIは悪くないんじゃ? (スコア:1)
そもそも、誤ったContent-Typeを付けているのだから悪いのはドコモだと思います
リンクしてある記事には、DDI側は、「ヘッダ情報を信じきってしまっている」と書かれていて、それがいけないことのように書かれていますが、それは、間違いでしょう
メールのヘッダは、ボディの構成やエンコード方法などボディ部分を正しく再現するための情報なのだから、PHSがこれらの情報を信用してメールを表示することは、正しい動きだと思います
Re:DDIは悪くないんじゃ? (スコア:0)
Content-Type:image/gif
となっちゃうと、読めないケータイというのがありました(添付無しになるんだったかな..)。
で、そのすぐしたに、ファイル名が書いてあるんです(どんなヘッダだったか、忘れてしまいました)
Content-Type:image/gif hoge.gif
み
Re:DDIは悪くないんじゃ? (スコア:1, 参考になる)
# DDI-Pっていう方が、一般的なんですかね?それとも、ただ「ポケット」?
# 「エッジ」の方が、良いのか....。
Content-Type: image/gif
Content-Disposition: attachment; filename=hoge.gif
が、正解だと思います。
Re:DDIは悪くないんじゃ? (スコア:0)
RFC2046対応してないのかちゃんと検証したの? (スコア:0)
規格を乱用するのがいけないのか、規格から勝手な仮定を導いちゃんと実装して いないのがいけないのか…。 MIME規格の詳しい人の助言希望。
Re:RFC2046対応してないのかちゃんと検証したの? (スコア:2, 参考になる)
The use of the "multipart" media type with only a single body part
may be useful in certain contexts, and is explicitly permitted.
NOTE: Experience has shown that a "multipart" media type with a
single body part is useful for sending non-text media types. It has
the advantage of providing the preamble as a place to include
decoding instructions
とあります。かいつまむと、
・パートが一つだけの"multipart"はOK
・non-textなデータを送る時に便利だよ
だからRFC2046的にはDocomoもDDIもハズしてる…?
同感。 (スコア:0)
DDIはそれを正しく解釈しているだけ。
それなのに何処が手抜きなのか。
添付のあるなしを確認しろといいたいだけなんだろうけど。ラEはヘッダでしか確認できない仕様なのでは。
関係ないですが、DDIで絵文字入力してドコモにメール送ると、ドコモ側に添付ファイルがどうこうって表示されるそうです。
Re:同感。 (スコア:1)
嘘は書いてない。
厳密でないだけ。
>DDIはそれを正しく解釈しているだけ。
唯一正しい解釈というわけではない。
ある解を決め付けているだけ。
「新宿で待ち合わせ」といって西口と東口にいるようなもんだよ。
Re:同感。 (スコア:0)
> 厳密でないだけ。
ちゃんと読んだ?
嘘書いてんだよ。
「このメールは添付ファイルつきです」って。
それで添付ファイルは付いてない。
> 唯一正しい解釈というわけではない。
> ある解を決め付けているだけ。
「添付ファイルをつけてある」と明示しているから
添付ファイルがあるというのは正しい解釈では?
Re:同感。 (スコア:1, 興味深い)
>「このメールは添付ファイルつきです」って。
>それで添付ファイルは付いてない。
ここでの添付ファイルとやらが何を指しているのかわかりませんが、Content-Type: multipartは一つ以上のbody partを含むものとして定義されていますから、#103498 [srad.jp]での報告を見る限り、FOMAのメールはRFC2046に厳密に従っていますし、もちろん嘘もついてませんよ。
>「添付ファイルをつけてある」と明示しているから
>添付ファイルがあるというのは正しい解釈では?
「添付ファイル」がbody partのことを指すのなら、いわゆる「本文」もContent-Type: text/plainな「添付ファイル」ですし、Content-Disposition: attachmentなbody partのことを指すなら、必ずしも付いているとは限りませんよ。
不必要にmultipartメールにしていることの是非は確かにありますが、嘘をついているわけではないですよ。
Re:同感。 (スコア:1)
そんなことはドコモは言ってません。
ドコモが言っているのは、「このメールには添付ファイルがついている場合もあります」程度です。
>添付ファイルがあるというのは正しい解釈では?
いいえ。
「ついている場合もある」→「必ずついている」という変換をしているのはDDIPです。
ここまでなら、まあお互い様とも思うのですが、#103642 [srad.jp]によるとさらに惨たらしい仕様らしいので、
DDIPの方がより手抜きってことで。
#思いっきりユーザサイドで手を抜くとは何考えてるんだ?
>なんか頓珍漢な喩えを言っているところを見ると、きちんと話を
>読んでいないと思われ。
どっからくるんだよぉ、その自信は。 ^^;
Re:同感。 (スコア:0)
結局ドコモのいい加減な仕様が問題であるということだと思うのですが
ドコモ>DDIPとお考えのようですが
客観的に見れば同列かと
Re:同感。 (スコア:0)
不必要なことをしているとはいえ、ドコモは規格を守っているのですから、
>客観的に見れば同列かと
同列に扱うのはドコモに対して酷かと。
Re:同感。 (スコア:1)
規格に反してるとも言えないけど、規格の意図を踏まえてるとも言えない。
同列に扱って良いと思う。
#実装の負担まで考えるとドコモの過失の方が大きい、と個人的には思う。
Re:同感。 (スコア:1)
Re:同感。 (スコア:1)
non-textなデータを送る時便利なんだよ、とRFC2046には書いてあります
(#103159 [srad.jp]を見てください)。
ここを指して規格の「意図」と表現したのですが、分かりにくかったですか。
#私も煽り抜きで聞きたいのですが、なにかしら意図を持たせていない規格
ってあるんですか?勝手に意図を読み込むのはもちろんいけませんが。
Re:同感。 (スコア:1)
ほとんどないと思います。
ただ、その意図が明確に記されていない部分を補うのはよろしくないとも思います。
今回の場合、「踏まえている」は言えたとしても「踏まえてない」は言えないのではないかと思いまして。
#煽りぬきとかわざわざ書かないといけないのはアレですねぇ ^^;