　ざっくりIDFで紹介されたセッションを説明するとこんな具合だが、もう少しだけ解説を加えたい。Photo05の図は、あまりにアバウトというか、エンジニアが描いた図版とは思えない（か、このレベルの図しか描けないほど中身の検討が進んでないかどちらか）。プロファイルが大ざっぱすぎのもさることながら、Framework APIとその下にあるFrameworkが相当重くなる事が予測されるためだ。

Photo05

　単純に考えても、Transport層は接続方法も機能も転送性能もかなり異なるものが並んでいる。従ってこれらの差異は全部Framework層で吸収することになり、これがまず結構なオーバーヘッドになると予測される。また、既存のプロトコルは必ずしもIoTやウェアラブルに最適とはいえないものも少なくない。実のところThread Groupが新規のTransport Protocolを提供するのは、特にIoTの中でも一番ローエンドにあたるエンドデバイスには、既存のプロトコルではオーバーヘッドが大きすぎるという見極めをつけたからでもある。このあたりはZigBeeで長年苦闘してきたメーカーが集まっているだけの事はあり、見極めも早い。

　また、Photo02で言うところの「IoT Device/Wearable Device」と「Smart Device」が、Photo05で見る限り同一のAPIになっているのもかなり疑問がある。実際はコアとなるAPIとオプション扱いのAPIに分けられ、ライブラリなどの追加でオプションは使えるようにすることで、IoTデバイスからスマートデバイスまで対応するという実装になるかと思うが、現実問題としてそんなコアAPIがうまく定まるのか、という疑問もある。このあたりは、ARMのmbed OSとmbed Device Serverが異なるAPIセットを持つのと好対照を成している。

Photo02

　ただ、こうした事はOICのメンバーは恐らく百も承知で、にもかかわらずこの位広い範囲をカバーしないとOICという規格そのものが成立しない、と踏んだのだろう。つまりThread Groupとは異なり、「IoTを特定の接続方法に絞りこむのは無理」と判断したのだと筆者は考える。2015年2月に出てくるOICの仕様がどんなものになるのか、ちょっと楽しみである。