MessagePackというオープンソースプロジェクトの現状と IETF による標準化について、それが果たして正しいのか、と困惑せざるをえない事態が起きているので、それについて簡単に書く。何が起きているのか知らない人々に少しでも知ってもらえたら嬉しい。
なお、自分はMessagePackのユーザであって開発者ではない。MessagePackを使ったコードを書いて動かしているが、MessagePackそのもののデータフォーマットについて詳細まで知っているわけではないし、MessagePackの改善については特にいいアイデアを出せる気もしない。
現バージョンのMessagePackについてとりたてて不満はなかったが、最近文字列型を加えよう、あるいはもっと楽に文字列を扱えるようにしよう、という話が出てきた。JSON的に楽に扱えて更にバイナリデータを投入できるフォーマットの需要そのものは理解できると思う。自分がスマートフォン向けアプリケーションを書いていたら多分欲しいと思う。
MessagePackの開発者たち(オリジナルの開発者である @frsyuki を含む)はこの変更に前向きなようだ。ただしこの変更は現行のMessagePackでフォーマットされたデータの取り扱いにも影響するため、互換性に最大限に配慮する必要がある。自分もMessagePackライブラリのバージョン差異では悩みたくない。
とはいえ、そこについては特に心配していない。彼ら(@frsyukiを含めたMessagePack開発者たち)は既にいろいろなケースを知っているし、多くの助言者たちがいる。きっとうまくやるだろう。
ところで、この議論の中で唐突によくわからない話が出てきた。MessagePackを、正確にはBinaryPackというMessagePackのforkで(おそらくは)MessagePackと互換性のないもの、をIETF標準に提案しているという話だ。
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg08973.html
http://tools.ietf.org/html/draft-bormann-apparea-bpack-01
この話にはMessagePackユーザの自分の目から見て、いくつかの困惑せざるをえない点がある。
- なぜMessagePackそのものではなくそのforkが提案対象となっているのか？
- なぜこの時期に急いでIETF標準に提案する必要があるのか？
- このIETF標準の策定方法と言えるものはopenと言えるのか？
上述のBinaryPackドラフトにはMessagePackに関する言及がある。ではなぜMessagePackそのものをIETF標準への提案としなかったのか、理由がわからない。MessagePackは既に実装が存在し、実際に多くの場所で使われ、仕様も(これまでは、事実上)固定されていた。UTF-8文字列型が欲しかったのだとして、ならばMessagePackをIETF標準として、更にその上で変更を加えるようにすればいい。"rough cosensus" と言うが、そもそもの出発点をどこに置くかについて何のコンセンサスもとれていないように見える。
IETF標準への提案、という事態がそもそも突発的すぎて、何故そうなっているのかがわからない。MessagePack開発コミュニティへの事前の提案などが一切行われておらず、ドラフトを提出したあとで github のissue 121に宣言する形になっている。この時期に、MessagePack開発者への事前の連絡もなく、唐突にIETF標準への提案という作業が行われ、かつ次の機会を待つわけでもなく強行されているのはなぜなのだろう。またUTF-8文字列型をMessagePack自体がサポートするという流れになっているにもかかわらず、そのforkによる提案を継続し仕切り直すようにも見えないのはなぜなのだろう。
IETF標準の策定に関するプロセスは、GitHubやTwitterで世界中の開発者が意見を交換して進行するスタイルに較べて果たしてopenなものだと言えるのだろうか。例えば上述のメールには以下のような1文がある。
I think his overall thinking is fine, but it is much more dominated by a requirement for backwards compatibility than an IETF process would be.So, the larger question on whether the msgpack community is ready to take part (or just endure) in an IETF-style consensus process (including handing over change control) still looms.
That doesn't diminish from the requirement for a msgpack-like format, and I think we should use Hallway Time in Orlando to discuss potential ways forward.
(tagomoris訳)
彼(frsyuki)の考えは全体的にすばらしいが、後方互換性を重視するあまり、IETFのやりかたよりもかなり独裁的に進めているように私は思う。そして、より大きな疑問は、MessagePackコミュニティが、IETFにおける議論に参加するつもりがあるのかどうかがよくわからない、ということだ。MessagePackというフォーマットの主導権をIETF WGに渡すという選択肢もあるが、そうするつもりがあるかどうかもわからない。
こういう状況だが、MessagePack的なフォーマット自体の需要がなくなるわけではない。なので私は Orlando におけるIETFの会合で顔をあわせるときに、この話を進めるための議論をすべきだと思っている。
"we should use Hallway Time in Orlando to discuss ..." がオープンな議論か？ そこでどのような意見がありどのような合意がとられるかはどこに公開されるのだ？ 我々はその内容をどうやって入手し、どのようにその議論に参加すればいいのだ？ 全員オーランドまで来いと？
MessagePackの開発者は日本人で、また多くの言語バインディングの実装も日本人が行っている(日本人以外が行っているものもある)。彼らが日本語で、主にTwitterにおいて、議論を行っているのは他の言語を主にする人々からは Closed だと思えることがあるのかもしれない。 しかし彼らの議論は、少なくとも世界中の誰からも見える場所で行われている。誰でも参加できる。単に日本語なだけだ。だいいち英語で話しかければ英語で返ってくるだろう。
そして重要なこと。彼らの議論は、何かを決定するためのものではない。彼らはあくまで改善案をまとめるために議論しているのであって、その結果は「提案」としてgithubのissueに投稿される。そこに、誰でも、どのような意見でも加えることができる。
MLで英語で議論しているのと、言語以外に何か違いがあるのか？ 特定のオフラインミーティングに出掛けない限り議論にも参加できないのと較べて、どちらがよりオープンだと言えるのか？
さて、IETF標準は強制力のあるものではない、筋の悪いforkなど単に無視すればいい、という意見があると思う。それは正しいと自分も思うのだが、しかしRFCというものについてもう少し考えてみよう。
「HTTPでこういうリクエスト送っていいんだっけ？」「RFC見ろ」
「メールアドレスのフォーマットの制約ってどうだったっけ？」「RFC見ろ」
...
「MessagePackなデータを処理するライブラリ書こうと思うんだけど、フォーマットの仕様はどこかな？」「RFCにあったよね確か、ほらググったら見付かった、これ見ればいいんじゃないかな」
わお！
(この記事の英語版 http://tagomoris.tumblr.com/post/44270601071/confusion-about-ietf-draft-for-a-fork-of-messagepack )
