メインコンテンツまでスキップ

1. Introduction (はじめに)

インターネット上でのウェブサービス (ウェブAPI) の使用は、ほとんどのアプリケーションで普遍的なものとなり、ウェブの基本的な Representational State Transfer [REST] アーキテクチャに依存しています。

Constrained RESTful Environments (CoRE) の作業は、最も制約されたノード (例えば、限られたRAMとROMを持つ8ビットマイクロコントローラ) とネットワーク (例えば、6LoWPAN, [RFC4944]) に適した形でRESTアーキテクチャを実現することを目指しています。6LoWPANのような制約されたネットワークは、IPv6パケットを小さなリンク層フレームに断片化することをサポートしていますが、これによりパケット配信確率が大幅に低下します。CoAPの設計目標の1つは、メッセージのオーバーヘッドを小さく保ち、断片化の必要性を制限することでした。

CoAPの主な目標の1つは、この制約された環境の特別な要件、特にエネルギー、ビルディングオートメーション、およびその他のマシン・ツー・マシン (M2M) アプリケーションを考慮した汎用ウェブプロトコルを設計することです。CoAPの目標は、HTTP [RFC2616] を盲目的に圧縮することではなく、HTTPと共通するRESTのサブセットを実現しつつ、M2Mアプリケーション向けに最適化することです。CoAPは、シンプルなHTTPインターフェースをよりコンパクトなプロトコルに作り直すために使用できますが、さらに重要なことに、組み込みディスカバリ、マルチキャストサポート、非同期メッセージ交換など、M2M向けの機能も提供します。

この文書は、Constrained Application Protocol (CoAP) を規定しており、既存のウェブとの統合のためにHTTPに簡単に変換でき、マルチキャストサポート、非常に低いオーバーヘッド、制約された環境とM2Mアプリケーションのためのシンプルさなどの特殊な要件を満たします。

1.1. Features (機能)​

CoAPには以下の主な機能があります:

  • 制約された環境でM2M要件を満たすウェブプロトコル

  • ユニキャストとマルチキャストリクエストをサポートする、オプションの信頼性を持つUDP [RFC0768] バインディング

  • 非同期メッセージ交換

  • 低いヘッダーオーバーヘッドと解析の複雑さ

  • URIとコンテンツタイプのサポート

  • シンプルなプロキシとキャッシング機能

  • ステートレスHTTPマッピング。これにより、HTTPを介してCoAPリソースへのアクセスを統一された方法で提供するプロキシを構築したり、HTTPのシンプルなインターフェースをCoAP上で代替的に実現したりすることができます

  • Datagram Transport Layer Security (DTLS) [RFC6347] へのセキュリティバインディング

1.2. Terminology (用語)​

この文書におけるキーワード "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"NOT RECOMMENDED"、"MAY"、および "OPTIONAL" は、すべて大文字で表記される場合、[RFC2119] に記載されているとおりに解釈されます。これらの単語は、規範的な意味を持たない小文字でこの文書に現れることもあります。

本仕様では、読者が [RFC2616] で議論されているすべての用語と概念、特に "resource" (リソース)、"representation" (表現)、"cache" (キャッシュ)、"fresh" (新鮮) に精通していることを要求します。(この仕様は、更新されたHTTP RFCセット (RFC 7230からRFC 7235) が利用可能になる前に完成したため、特に前身バージョンであるRFC 2616を参照しています。) さらに、本仕様では以下の用語を定義します:

Endpoint (エンドポイント) : CoAPプロトコルに参加するエンティティ。通俗的には、エンドポイントは "Node" (ノード) 上に存在しますが、"Host" (ホスト) の方がインターネット標準の使用法とより一貫性があり、UDPポート番号とセキュリティアソシエーションを含むことができるトランスポート層多重化情報によってさらに識別されます (Section 4.1)。

Sender (送信者) : メッセージの発信元エンドポイント。特定の送信者の識別の側面が焦点となる場合、"source endpoint" (送信元エンドポイント) とも呼ばれます。

Recipient (受信者) : メッセージの宛先エンドポイント。特定の受信者の識別の側面が焦点となる場合、"destination endpoint" (宛先エンドポイント) とも呼ばれます。

Client (クライアント) : リクエストの発信元エンドポイント; レスポンスの宛先エンドポイント。

Server (サーバー) : リクエストの宛先エンドポイント; レスポンスの発信元エンドポイント。

Origin Server (オリジンサーバー) : 特定のリソースが存在する、または作成される予定のサーバー。

Intermediary (中継者) : オリジンサーバーに向かって (おそらくさらなる中継者を経由して) サーバーとクライアントの両方として機能するCoAPエンドポイント。中継者の一般的な形態はプロキシです; この仕様では、そのようなプロキシのいくつかのクラスについて説明します。

Proxy (プロキシ) : 主にリクエストの転送とレスポンスの中継に関心を持つ中継者であり、その過程でキャッシング、ネームスペース変換、またはプロトコル変換を実行する可能性があります。一般的な意味での中継者とは対照的に、プロキシは一般的に特定のアプリケーションセマンティクスを実装しません。リクエスト転送の全体構造における位置に基づいて、プロキシには2つの一般的な形態があります: forward-proxy (フォワードプロキシ) と reverse-proxy (リバースプロキシ)。場合によっては、単一のエンドポイントが、各リクエストの性質に基づいて動作を切り替えて、オリジンサーバー、フォワードプロキシ、またはリバースプロキシとして機能することがあります。

Forward-Proxy (フォワードプロキシ) : クライアントによって選択されたエンドポイント (通常はローカル設定ルールを介して) であり、クライアントに代わってリクエストを実行し、必要な変換を行います。変換には、"coap" URIのプロキシリクエストのような最小限のものから、まったく異なるアプリケーション層プロトコルとの間の変換を必要とするものまであります。

Reverse-Proxy (リバースプロキシ) : 1つまたは複数の他のサーバーの代理として機能し、それらに代わってリクエストを満たし、必要な変換を行うエンドポイント。フォワードプロキシとは異なり、クライアントはリバースプロキシと通信していることに気づかない可能性があります; リバースプロキシは、ターゲットリソースのオリジンサーバーであるかのようにリクエストを受信します。

CoAP-to-CoAP Proxy (CoAP間プロキシ) : CoAPリクエストからCoAPリクエストへマッピングするプロキシ、すなわち、サーバー側とクライアント側の両方でCoAPプロトコルを使用します。cross-proxy (クロスプロキシ) と対比されます。

Cross-Proxy (クロスプロキシ) : クロスプロトコルプロキシ、または略して "cross-proxy" は、CoAP-HTTPプロキシやHTTP-CoAPプロキシなど、異なるプロトコル間で変換を行うプロキシです。この仕様はCoAP-CoAPプロキシに対して非常に具体的な要求を行いますが、クロスプロキシにはより多くのバリエーションが可能です。

Confirmable Message (確認可能メッセージ) : 確認応答を必要とするメッセージ。これらのメッセージは "Confirmable" (確認可能) と呼ばれます。パケットが失われていない場合、各確認可能メッセージは、Acknowledgement (確認応答) タイプまたはReset (リセット) タイプの正確に1つの返信メッセージを引き出します。

Non-confirmable Message (確認不要メッセージ) : 確認応答を必要としない他のメッセージ。これは、センサーからの繰り返し読み取りなど、アプリケーション要件のために定期的に繰り返されるメッセージに特に当てはまります。

Acknowledgement Message (確認応答メッセージ) : 確認応答メッセージは、特定の確認可能メッセージが到着したことを確認します。確認応答メッセージ自体は、確認可能メッセージにカプセル化されたリクエストの成功または失敗を示しませんが、確認応答メッセージはPiggybacked Response (ピギーバックレスポンス) を運ぶこともできます (下記参照)。

Reset Message (リセットメッセージ) : リセットメッセージは、特定のメッセージ (確認可能または確認不要) が受信されたが、それを適切に処理するためのコンテキストが欠けていることを示します。この状態は通常、受信ノードが再起動し、メッセージを解釈するために必要ないくつかの状態を忘れた場合に発生します。リセットメッセージを引き起こすこと (例えば、空の確認可能メッセージを送信することによって) は、エンドポイントの生存性の低コストチェック ("CoAP ping") としても有用です。

Piggybacked Response (ピギーバックレスポンス) : ピギーバックレスポンスは、このレスポンスのリクエストの受信を確認するために送信されるCoAP Acknowledgement (ACK) メッセージに直接含まれます (Section 5.2.1)。

Separate Response (セパレートレスポンス) : リクエストを運ぶ確認可能メッセージが空メッセージで確認された場合 (例えば、サーバーがすぐに答えを持っていないため)、セパレートレスポンスは別のメッセージ交換で送信されます (Section 5.2.2)。

Empty Message (空メッセージ) : コードが0.00のメッセージ; リクエストでもレスポンスでもありません。空メッセージには4バイトのヘッダーのみが含まれます。

Critical Option (クリティカルオプション) : メッセージを適切に処理するために、メッセージを最終的に受信するエンドポイントによって理解される必要があるオプション (Section 5.4.1)。"Option" (オプション) という名前が示すように、クリティカルオプションの実装は一般的にオプショナルです: サポートされていないクリティカルオプションは、エラーレスポンスまたはメッセージの要約拒否につながります。

Elective Option (エレクティブオプション) : それを理解しないエンドポイントによって無視されることを意図したオプション。オプションを理解しなくてもメッセージを処理することは許容されます (Section 5.4.1)。

Unsafe Option (アンセーフオプション) : メッセージを安全に転送するために、メッセージを受信するプロキシによって理解される必要があるオプション (Section 5.4.2)。すべてのクリティカルオプションがアンセーフオプションであるわけではありません。

Safe-to-Forward Option (安全転送オプション) : それを理解しないプロキシによる転送に対して安全であることを意図したオプション。オプションを理解しなくてもメッセージを転送することは許容されます (Section 5.4.2)。

Resource Discovery (リソースディスカバリ) : CoAPクライアントがホストされているリソースのリスト (すなわち、Section 7で定義されているリンク) をサーバーに問い合わせるプロセス。

Content-Format (コンテンツフォーマット) : インターネットメディアタイプ (特定のパラメータが与えられる可能性がある) とコンテンツコーディング (多くの場合、アイデンティティコンテンツコーディング) の組み合わせであり、"CoAP Content-Formats" レジストリによって定義される数値識別子によって識別されます。数値識別子よりもリソース表現のこれらの特性の組み合わせに焦点が置かれる場合、これは "representation format" (表現形式) とも呼ばれます。

制約されたノードと制約されたノードネットワークに関する追加の用語は、[RFC7228] に記載されています。

本仕様では、"byte" (バイト) という用語は、"octet" (オクテット) の同義語として、現在の慣習的な意味で使用されます。

このプロトコルのすべてのマルチバイト整数は、ネットワークバイトオーダーで解釈されます。

に最終更新