要約

  • RFC 6690はRFC 5988のWeb Linkingを小型サーバー向けのapplication/link-formatという資源表現にした。RFC 5785の枠組みで/.well-known/coreを登録し、発見の入口をそろえた。
  • リンクには資源種別rt、インターフェースif、内容形式ct、最大サイズの見積もりszを添えられる。条件付きの検索は可能だが、フィルターへの対応はサーバーの任意である。
  • リンク一覧は次の問い合わせ先を示す。読み値や処理の結果は、その資源への別の要求で確かめる。2014年のCoAPは、制約のある機器の転送モデルに資源発見を組み込んだ。

誰もクリックしてくれない機械

人間はページのリンクを見て、目的の情報まで進める。建物の制御器には画面も案内係もない。温度計や照度センサーの資源を探すには、ネットワークの中で入口を見つけなければならない。RFC 6690が念頭に置いたのは、8ビットのマイクロコントローラーや低電力の通信網だ。記憶領域も通信量も限られる。センサーのパスを制御器に固定しておけば、交換や配置変更のたびに古い住所が残る。

標準が選んだ入口は/.well-known/coreだった。この仕様を実装するサーバーは、該当するプロトコルの標準ポートでその資源を提供する。GETへの返答はCoRE Link Formatのリンク一覧で、掲載するリンクがなければ本文は空にもなる。仕様の例には</sensors/temp>;rt="temperature-c";if="sensor"という短い記述がある。資源のパス、温度という種類、センサーとしてのインターフェースが並ぶ。照度のリンクが見つかれば、制御器はその対象に次のGETを送れる。

最初のGETと次のGETは役割が違う。一方は案内図を受け取り、もう一方は対象へ到着する。案内図に照度センサーが載っていても、今の値を得たことにはならない。センサーが眠っているかもしれず、対象へのアクセスに別の条件があるかもしれない。共通の入口は「どこを訪ねるか」を安くし、実際の資源はそれぞれの場所で応答する。

ヘッダーのリンクが本文になった

RFC 5988は、文脈となる資源と対象を型付きの関係で結ぶWeb Linkingを定めた。RFC 6690はHTTPのLinkヘッダーに似た表記を借り、独立した資源表現として返すようにした。媒体型はapplication/link-format。対象URIを山括弧で囲み、後ろに属性を続け、複数のリンクをカンマで区切る。小さな機器がXMLの大きな木を組み立てずに、まず行き先を選べる形だ。

属性は一つの「機器情報」に混ぜられない。rtはアプリケーションが定めた資源の種類で、何を表すかに近い。ifは資源とどうやり取りするかを表すインターフェースで、異なる種類の資源が同じものを使える。ctは内容形式、szはGETで得る表現の最大サイズの見積もりだ。後者は小さな受信側が転送の大きさを考える手掛かりになる。rtは人が読む名前を目的とせず、その用途にはtitleがある。

関係を表すrelを省いた場合も、意味は空白ではない。既定値のhostsは、リンクの文脈となるサーバーが対象をホストすることを示す。明示した関係やanchorを使えば別の文脈も記述でき、対象がほかのサーバーにある場合もある。URIだけを抜き取って関係を捨てると、外部の説明を同じサーバーの資源と読み違える。節約した文字列の中に、管理主体の区別が残されている。

一覧は短くていい

/.well-known/coreに全センサーを平たく並べる義務はない。どのリンクを載せ、どう整理するかはアプリケーションが決める。たとえば/sensorsという集合への入口だけを置き、その先の資源に温度と照度のリンクを持たせられる。小さなサーバーは、案内を求めるすべてのクライアントに建物全体の一覧を毎回渡さずに済む。

クライアント側もGET /.well-known/core?rt=light-luxのように資源種別を指定できる。ただしRFC 6690が定めたフィルターの実装は任意だ。空の返答を受けたとき、サーバーが条件を処理したのか、どのリンクを公開しているのかを確認する必要がある。資源種別やインターフェースの値はアプリケーションの語彙であり、全世界の製品型番表ではない。

眠る機器や細い回線が増えると、毎回すべての端末に尋ねる方法は高くつく。RFC 6690は、ほかのサーバーのリンクを保持する資源ディレクトリにも触れる。能力のある節点が集めて案内できるが、詳しいディレクトリの動作はこの仕様の外に置かれた。元の機器が記述を出し、ディレクトリが複写を保管し、クライアントが候補を選び、最後に対象が答える。案内の更新時刻と対象の現在は別々に確認する。

案内図にも持ち主がいる

この仕組みは一つの巨大な名簿から生まれたわけではない。RFC 5785が決まった場所への入口を与え、RFC 5988がリンク関係を与え、RFC 6690が小型サーバー向けの本文にした。RFC 7252は後からCoAPの資源発見にその考えを組み込んだ。サーバーごとに尋ね始める場所が分かるので、制御器は全機器のパスを出荷時から抱え込まずに済む。

一覧に何を載せるかはサーバー側の選択だ。認証された相手に応じて表示を変えることもできる。一方、リンクを隠すだけでは、URIを知っている相手による対象への要求を防げない。アクセスの可否は対象で判断する。信頼できる案内が必要なら、案内を出した相手の認証も必要になる。案内、転送、対象の応答は異なる管理点を通る。

公式文書が示すのは、2012年に定められた構文と入口、そして二段階の発見手順だ。特定の建物での採用を確かめるには、機器の当時のファームウェア、/.well-known/coreの応答と、続くセンサーへの要求が要る。冒頭の制御器は案内口で住所を得る。照度の値を渡すのは、その住所の先にあるセンサーだ。