Trackback vs Pingbackを読んだだけで、元文章はどっちも読んでいないんだけど、ひとまずtrackbackとpingbackを比べてみると、

• trackback
  • いいところ
    • 実装・利用例が多く、すでにデファクトスタンダード化している
    • （URLのみやりとりするping backと比べると）得られる情報量が多い
  • 悪いところ
    • 仕様レベルでノーセキュリティ。SPAM対策が難しい。
    • trackback ping URLの仕様うざ。機械専用の情報を人間様に入力させようとは、何事か。
    • auto discoveryの仕様もうざ。ないよりはましだし、動くことは動くけど。
    • trackback ping URLのせいで、リンク先URL、通知先（ping）URLを二重管理しなければならない。しかもその二つを結ぶラインは、auto discoveryという非常に弱いラインしかない。
    • 文字コード問題には現行仕様では対応している（結局初期の頃にshiroさんが言っていた仕様になったってことか）けど、実装レベルで対応しているところはほとんどなさそう。仕様のアップデートに関するアナウンスよわっ。
• pingback
  • いいところ
    • シンプル＆スマート。逆に言うと、必要最低限。
    • 人間は単にリンクするだけでOK（どこにどうやって送信するかなんて意識しなくていい）。
    • URLと受信するサーバーとが切り離されている（HEADなどに受信サーバーURL（固定）を入れておくだけでいい。trackbackもある程度は切り離せるけど、エントリー単位の情報は共有する必要がある）
  • 悪いところ
    • ほとんど使われていない。
    • これも特にセキュリティはないな。利用例が少ないからターゲットになっていないだけだろう。
    • 情報量が少ない（URL情報しか持っていない）。

ちなみにpingbackは2、3年前に調べて以来全然見ていないから、現行仕様では何か変わっているのかもしれない（けど、きっと変わってないと思う）。

とか書いていて思ったけど、trackbackはWindowsライクな仕様（リッチだけど穴を塞ぐのが難しい設計）で、pingbackはUNIXライク（シンプルなツールを、外部と（パイプで）つないで使いこなしてね）な仕様、なんてイメージが重なるな。

現行trackbackの利点って、すでにデファクトスタンダード化しているところだけって気もするし、いろいろ問題点を解消しようとした結果、現行仕様と互換性がなくなったりするようならば、何もtrackbackにこだわる必要はないよなー、とは思う。

っつーか今更URLをキーにつながるなんてチープなことは考えずに、みんなHyper Estraierの全文検索機能を持って、P2P連携を使って全文検索でつながっちゃったほうが話が早いじゃん、ってのはどうだろう。まあP2P連携もそんなに大量のノードはつなげられないだろうから（ってHyper EstraierのP2P連携機能は使ったことないけど）、動的ノード解決の仕組みを考える必要があるかな。

ってなんだかずいぶん話が発散したな。