あけましておめでとうございます。
いやはや、2010年なんですね。ここ/.Jで日記を書き始めたのが2001年12月25日の事なので、最初のエントリを投稿してから丸8年が経ってしまいました。高専に入ったばかりの頃は今頃何をしているかなんて全く想像だにしていませんでしたが、何時の間にやら8年。来るべき所には来るし、行こうとしない所には行けないものですね。

今年、はたしていくつのエントリを投稿する事になるのかは分かりませんが、たまに投稿しているのを見かけられましたら、ああそういえばこんな奴もいたなと思っていただけたらこれ幸いです。

pascalさん、naochaさん、KyaTanakaさん日記経由。

Katuragiさん、亡くなったのか…。まだお若いのに。

直接の関係としては一度お会いしただけだったけれども、快活で行動力のある方という印象でした。

安らかにお眠りください。

久しぶりのタレコミが採用されていました。どうもありがとうございました。

40周年が記念されているRFC 5540ですが、タレコミが採用されるまでの間に翻訳してみました。訳に悩むところはざっくりと訳してしまったので、ツッコミところが多いだろうと思います。何かお気づきの点などありましたら、何かしらの手段でお伝えいただければ幸いです。

1969年4月7日にRFC 1が発行されてから40年を記念するRFCが、RFC 5540: 40 Years of RFCsとして発行されている。この10年間は、1998年10月16日にJon Postelが死去したことにより、それまで個人で行われていたRFCの編集作業に大きな変革がもたらされた10年だった。インターネットの重要性が増すにつれ、RFCの発行数も上昇を続けており、RFC 2555: 30 Years of RFCsからこの10年間で、それまでの30年間に発行されたRFCの数を超える数のRFCが発行されている。

/.J日記ってどこかに「自分が生きた証を残せ」っていう一句が載っていた気がしたんだけど、今は無くなってしまったのかしら。

ストーリーが掲載されるトップページを「表」と称して、その対比として「裏」と称されることもあった/.J日記で、ある種のテーゼのような物として扱われることもあった句だと思っていたので、ちょっと残念な気がする。

どこかにまだ残っていたとしたら幸い。

HTTP-based IETF Namespace URIs at IANA

今の所RFCなんかで使えるNamespaceの為に、urn:ietf:params:xml:ns:...が割り当てられているけど、やっぱりhttp schemeを定義できるようにした方が便利な事も多いよね、という事で、新しく名前空間が創設されるという話。多分、順調にRFCになる気がする。

このI-Dは著者が豪華。IRIのRFCを執筆したり、最近ruby-devでRubyのM17N関係で大量にcommitしているDüerst先生と、知る人ぞ知るTim Bray。

GoogleがIETF Application Architecture Working Group Workshopをhostしたという話がcode.google.comに掲載されている。

この中で、IM, Atom, カレンダーの下に存在するプロトコルとして、HTTPとかと肩を並べてBEEPが存在しているのが面白い。重厚な割に機能面がいまいちな感が否めないので、すっかり忘れ去られたプロトコルなんだとばかり思ってた。まだまだ健在なようで何より。

前回書いたエントリのシチュエーションを現実にするI-Dがあるらしい。

Datagram Congestion Control Protocol (DCCP) Encapsulation for NAT Traversal (DCCP-NAT)

DCCPという、UDPに輻輳制御をつけたようなトランスポート層のプロトコルがあるのですが、こいつがNATを通過できるように、UDPパケットなどの中にcapsulationしようというお話。

UDPはそれ自体がIP+ポート番号程度のプロトコルなので、こういうやり方で新しいトランスポート層プロトコルを活用するというやり方は、ここ10年くらいは主流になり得る考え方なのかもしれません。

UDP and TCP as the New Waist of the Internet Hourglass

Rosenberg御大が面白そうなInternet-Draftを書かれていたので、休憩がてら読んでみた。

「NAT(という名のNAPT)が幅広く使われるようになったせいで、TCP, UDPとIPが切り離せなくなってしまって、SCTPやIPSecが普及しないじゃないかよ。だからさっさとIPv6を普及させようぜ。」という主張。

ネットワークで色々と新しい物事を考えようとする時に、「でもNATがあるからそれダメじゃん」となってしまう事が多いので、セキュリティ絡み以外でのNATはさっさとこの世から消えて欲しいという思いはある。現在のIPv4ネットワークは、NATのおかげで延命させる事が出来そうな見込みはあるけれども、将来の成長を妨げる要因になっているのは否めない。

基幹部や欲しい人だけがIPv6環境にして、既存ネットワークは6to4, 4to6 NATを使ってIPv4のまま運用し続けるというアイデアは良さそうに思える。しかしIPv6への移行を推進するには、何かキラーアプリケーションが無いとダメだよねえ。

近年のEeePCとかMacBook Airを見ていると、小型化・静穏化したPCが着実に進化しているので、将来的に固定電話のような感覚で自家用サーバが普及しないかな…。今だってHDDレコーダなんて完全に家庭用サーバとして機能しているんじゃないかと思うんだけど。そうすれば家庭に置いたHDDレコーダの中身をネットワーク経由で再生する為に、固定IP環境とかNA(P)T-freeなネットワーク環境は便利なんじゃないかなあ。「それIPv4+DDNSで出来るよ」と言われてしまえば(概ね)それまでなんだけど。

Extensible Markup Language (XML) 1.0 (Fifth Edition)

XML 1.0の5th EditionがCandidate Recommendationという事で、何が変わるのかと思ってXML 1.0 Fourth Edition Specification Errataを見てみた。なんか互換性を損ないそうな拡張が割と入っていそうな気がするのは気のせいか…。

ObsoluteになったRFCの番号を付け替えるとかいうのは良いとしても、Unicode 3.0を廃して5.0に鞍替えするというのはどうなんだろうか。概ね下位互換性はあったと思うけど、Unicode 3.0までしかサポートしていないアプリケーションへの影響が出たりしないんだろうか。

XML 1.xの文書を、XML 1.0の機能だけを使って読み込むよう努力するべきというのも、それなりに弊害が起こりそうな気が。

Best Practice的な物はW3C Note程度にしておく方がいいんじゃないだろうか。とかいう感想。

後は概ね用語の厳密化と挙動の厳密化について。しかし挙動の厳密化については、影響の出てくるアプリケーションも出てくるんじゃないかと心配になる所。