要約

  • RFC 10020 は、受信のための CoAP 群組、資源を共有するアプリケーション群組、保護通信の安全群組を区別する。重なっていても、同じ集団や同じ権限にはならない。
  • 保護された群組要求はメッセージについて有用な事実を示すが、各対象が受信し、許可され、実行し、期待する効果を出したことまでは示さない。

CoAP 群組とは、IP マルチキャストアドレスと UDP ポートに向けられた要求を受け取るよう設定されたエンドポイントの集合である。アプリケーション群組は共通の CoAP 資源を共有するサーバ群であり、安全群組は保護された群組通信に参加するための材料と関係を表す。RFC 10020 はこれらの間に多対多の関係を認める。要求を送るクライアント自身が、受信側としての CoAP 群組の一員でないことさえある。

ここに重要な境界がある。「群組へ送った」は「業務上の対象全体が動いた」ではない。アドレスは送信先を表す。構成は誰が聞く予定だったかを表す。Group OSCORE は受信側がリプレイを検査し、主張された送信元を確認する助けになる。それでも各資源には固有の判断がある。正しい送信元を拒否できるし、受け入れた後でローカル依存のため実行できないこともある。

返信の少なさも全体成功の根拠にはならない。RFC 10020 は制約網で応答嵐を避けるため、応答抑制と待機を扱う。沈黙は意図された抑制、損失、休眠、フィルタ、古い参加表、資源不一致、あるいはローカル拒否を意味し得る。戻った応答は、その時刻と意味づけの範囲でのみ証拠になる。

保護は証拠を強くするが、証拠の種類を変えない。共有鍵と保護された要求は協調を可能にする。しかし、それだけで資源ごとの承認、装置側の実行記録、外部効果の観測を代行しない。Heng Lu の最小の共通仕様という考え方は、まさにこの分離を保つ。共有できる開始点を与え、決定が実際に起こる場所を奪わない。