NetscapeがRSS0.91のDTDファイルを削除してしまう

line 曰く、

/.orgの記事より。deviceforge.comの記事が元ネタです。 Netscapeが作ったRSS 0.91では、その文書構造の定義にDTDが使われています。 この形式でRSSフィードを作ると、そのXMLファイル内でDTDファイルを参照することになります。このDTDファイルはNetscapeのサイトにあったのですが、最近そのファイルが消えてしまいました(rss-0.91.dtd)。こうした経緯で、RSSの構造をDTDを参照して調べるようなRSSリーダには不具合が出るかもしれないそうです。

とは言え大抵のRSSリーダはDTDファイルを読みに行くことまではしないので影響が出ない場合がほとんどですが、例えば Microsoft live.com のRSSリーダは真面目に見てるのか、DTDが見つからないことでフィードの読み込みを拒否されるんだとか。
タレコミ子が live.com でRSSの登録を試したところ、現時点でRSS 0.91形式のフィードは受け付けてもらえませんでした(RSS 1.0はOK)。既に登録されたRSS 0.91のフィードがどうなるのかは分かりません。なお、本家記事ではNetscape社の中の人が現れて「サイト再構成の時にDNSエントリを新しいサーバに向けたけど、古いサーバにあるDTDのことに気づかなかった」と述べています。

DTD の必要性

[Anonymous Coward]

> RSSの構造をDTDを参照して調べるようなRSSリーダには不具合が出るかもしれない

細かな話ですが。

http://slashdot.org/comments.pl?sid=216818&cid=17602710 に書いてあるように、DTD では実態参照の定義も行われます。換言すると、XML 内のテキスト要素を扱うだけであっても DTD の知識が必要です。
なので、今回の話は、汎用性のあるまともな XML パーサを使っている RSS リーダー全般で起こりうる問題だと思います。

Re:DTD の必要性

[yoshidam (2385)]

インターネット経由での外部解析対象実体の取り込みは，
セキュリティホールになりうるので，避けたほうがいいと思われます。

DTDを必要とする場合はアプリケーション内部に持つべきでしょう。

Re:DTD の必要性

[Anonymous Coward]

> インターネット経由での外部解析対象実体の取り込みは，
> セキュリティホールになりうるので，避けたほうがいいと思われます。

どのような場合にセキュリティ上の問題が発生するのでしょうか？

ふつうに開発している限りにおいては、XML パーサが実体参照を解決した後にアプリケーション側で取り扱うことになるでしょうから、なんら問題はないように思えます。
＃それとも、何か別の話？

Re:DTD の必要性

[yoshidam (2385)]

XXE (Xml eXternal Entity) Attack と呼ばれるようです。

http://www.securiteam.com/securitynews/6D0100A5PU.html [securiteam.com]

名前空間とネット上のリソース

[M-FalconSky (8868)]

常にWeb上のリソースが取得できるのがいいんだけど、Webサーバでは閉鎖もありうるわけで、困ったもんですね。

その内URIにDTD:とか定義されて、フォーマル公開識別子(FPI)で検索できるデータベースが必要になりそうだねー

# データベースへの接続は自分で責任もって環境変数URI_SERVER=http://www.w3c.org/dtd/とか定義
## あれ?後退してる?

--
M-FalconSky (暑いか寒い)

Re:名前空間とネット上のリソース

[Anonymous Coward]

こういうのは国連並に生存性のある機関に押し付けるべきだと思う。

最近のサイトは殆どRSS 0.91文書なんて吐いてない、と言っても
RSS 0.91文書は絶滅してはいない。また、太古の昔に生成された
RSS 0.91文書を処理する際に特別な対応を要求されるのは面倒。

そんなわけで、DTDとかを公的財産として登録したい奴から金を取って
永久保存を実行してくれる機関があると便利。料金は一括で受け取って
後はノーベル財団よろしく運用して毎年の維持費を捻出。赤字になったら
公的資金を注入するなり寄付でも募るなりして解決することにしとこう。

この料金システムはまさに墓地永代使用料。そして求めるは情報の墓場。

Re:名前空間とネット上のリソース

[Stealth (5277)]

そのための purl.org (だった) 訳ですが。

Web の情報に関しては W3C は近い存在ですが、外部のものを任意に置くにはちょっと存在的に異なりますね。

Re:名前空間とネット上のリソース

[Anonymous Coward]

purl.orgはリダイレクトするだけで実体を保存してくれないので違う。

そもそも、リダイレクト先の生存性は大抵の場合purl.orgに劣る。
そうでなければpurl.orgを使用する必要性は薄いから。だから、
リダイレクト先が死んでしまった際に、新しいリダイレクト先を
作らなければならない。でも、これにはちょっと問題がある。

まず、誰が新しいサーバを用意しなければならない。──でも誰が？
DTDの登録を依頼した本人は死んじゃってるかもしれないから駄目。
purl.orgにやらせる？なら初めからリダイレクト方式なんて
採用しないで実体を保存して供給してしまった方が話が早い。
「何処かの誰か」に期待してみる？あまりにも不確実。

次に、サーバにアップロードするDTDを用意しなければならない。
これは上の問題と本質的に一緒だから省略するけど、
一体何処の誰がDTDを保存しているの？

Re:名前空間とネット上のリソース

[Anonymous Coward]

>次に、サーバにアップロードするDTDを用意しなければならない。
>これは上の問題と本質的に一緒だから省略するけど、
>一体何処の誰がDTDを保存しているの？

Google先生か、WebArchiver....

Re:名前空間とネット上のリソース

[Anonymous Coward]

ちょっとまった。

そうやって終の棲家を欲しがる生き物は、
長い目で見れば、なにもDTDだけとは限らない、
ってのがこの問題の味噌だと思う。

いや、世の全て(^^;のDTDだけでも、
十分に件数が多すぎて管理に困ると思うんだが、
仮にソレが解決できたとしてもだ、そのうしろには膨大な数／量の
「俺も永代管理してくれ！」系リソースが控えていると思う。

たとえばFREEソフトウェアでお馴染みなネットワークダウンロード。
apt-get とか yumとかruby gemとか。
ああいう奴のダウンロードファイルの、URLって、
ころころ変わられたら面倒だと思わないか？
(まああれ「だけなら」設定ファイルを弄って逃げるという手もあるが…

Re:名前空間とネット上のリソース

[Anonymous Coward]

とりあえずお前がDTDとは何かを理解していないってことはよくわかった。

Re:名前空間とネット上のリソース

[Anonymous Coward]

その内URIにDTD:とか定義されて、フォーマル公開識別子(FPI)で検索できるデータベースが必要になりそうだねー

つ[URN]

ティム・バーナーズ・リー先生も悲しんでおられます [kanzaki.com]。

Re:名前空間とネット上のリソース

[kcg (26566)]

URNのように名前に対して永続的に同一のデータを期待するという事自体がどだい無理な話なのだと思います。
名前とデータの関連付けの情報を別途持たなければなりませんし、関連付け情報を保守するのは大変だからです。

永続的にデータを示したいのであれば、ハッシュ値とハッシュアルゴリズム名で示せば良いと思います。

＃ハッシュアルゴリズム名が実際にどのアルゴリズムを示しているかはそうそう失われる物でもないでしょうし。

Re:名前空間とネット上のリソース

[Anonymous Coward]

それも万全とは言い難いような気がします。
ハッシュのアルゴリズムが失われなかったとしても、弱衝突耐性が突破されてしまえばハッシュとして機能しなくなってしまうのでは？

Re:名前空間とネット上のリソース

[kitsune.info (18329)]

UA に P2P の機能を持たせて、DTD を共有してしまえばいいような気がしてきた。ハッシュアルゴリズムが陳腐化したら、別のより堅実なアルゴリズムに乗り換えていくという前提でクライアントを設計させるとか、そんな感じで改善できないですかね？

--
[わかってもらうことは難しい。わかってあげることは、もっと難しい。]

Re:名前空間とネット上のリソース

[satoshii (16612)]

その内URIにDTD:とか定義されて、フォーマル公開識別子(FPI)で検索できるデータベースが必要になりそうだねー

RFC 3151 [ietf.org] だと urn:publicid:-:Netscape+Communications:DTD+RSS+0.91:EN とか。Category: Informational ですが。

Netscapeその後

[line (17226)]

もう読む人いなんじゃないかと思いつつ。slashdot.orgに現れた中の人が、自らのblogで次の記事を出しています。

To DTD or not to DTD - The Netscape Blog [netscape.com]

これによれば，「2007/07/01までに復活させる。 けど、RSS関係のソフトウェアを開発している人は、 その日までにこのDTDが無くても動くようにソフトを変更してほしい。 コンテンツ配信者は、DTDは別のファイル(webarchive) [archive.org]を使うようにするか、 RSSの読者がそれを読めなくなるかもしれないという認識を持ってほしい」とのこと。

この発言の前には

• RSSリーダは第三者のWebサーバにある静的コンテンツに依存していいのだろうか?
• RSSがパースされるたびに毎回このDTDを要求する必要が本当にあるのだろうか?

という疑問を投げかけており，彼自身は(個人的な意見として)両方にnoと答えています。

以下は私の感想です。

まあ、毎回DTDを取りにいく必要はないですよね。内容が変わるなら別のバージョンのDTDとして出されるべきだし。でも、DTDに別のファイル(webarchiveの中のとか)を使うようにしたら、そのRSSフィードをRSS0.91形式として認識していいのかという問題も。

そもそもRSS 1.0 [kanzaki.com]とかAtom [kanzaki.com]があるしRSS 0.91を使う必要がないとも思う。この際この規格をobsoleteにして他の形式を使いましょうとか言えばよかったのに。

ていうかさ

[Anonymous Coward]

＞RSSの構造をDTDを参照して調べるようなRSSリーダには不具合が出るかもしれないそうです。

こういうのを作って配布しているようなところってあるの？
そんなに凝ったことは、RSSではしないと思うけどな。
全体の1割も無いんじゃないの？

Re:ていうかさ

[Stealth (5277)]

IE 等の Windows 標準の Web モジュールに XML を食わせると DTD を律儀に参照に行って解釈しようとします。その為に IE6 に XHTML 1.1 のファイルを食わせるとレンダリングできなかった (W3C が用意していた DTD 内のコメントを適切に無視せずその中にある参照を見に行き、存在しないためエラーとなっていた) 事があります。

これは IE6 が XML モードとして XHTML 1.1 の文書を解析した結果起きたことで、他にもこうした例がないとは言えません。

RSS のみに限定した場合は RSS の語彙だけを RSS パーサ側が認識して処理してくれると思われますが、一般的な XML パーサを利用して RSS を解釈しようとした場合に、DTD を削除してしまうと同等の問題が出る可能性はあります。

libxslt なども DTD を参照して検証させたりもできるわけで、厳密にチェックを行いたい場面などでは困る事となります。

Re:ていうかさ

[Anonymous Coward]

RSSとしてではなく、一般のXMLとして扱うアプリケーションとか。

古い？

[Anonymous Coward]

RSSで、今どき0.91なんてバージョンを吐き出すブログシステム(ブログに限らないとは思うけど)なんてあるんでしょうか。
日本では、RSS系では 0.92, 2.0が大半でしょう。外国だと違うのかな？

くれぐれも

[Anonymous Coward]

XMLのDTDのURLに自サイトのアドレスで書かないでってこと？ 結構起動時にDTD読み込むオーバーヘッド高いと記憶してるけど