1. はじめに
インターネット上のWebサービス（Web API）の使用は、ほとんどのアプリケーションで遍在するようになり、Webの基本的なRepresentational State Transfer [REST]アーキテクチャに依存しています。
Constrained RESTful Environments (CoRE) に関する作業は、最も制約のあるノード（例：RAMとROMが限られた8ビットマイクロコントローラー）およびネットワーク（例：6LoWPAN、[RFC4944]）に適した形式でRESTアーキテクチャを実現することを目的としています。6LoWPANなどの制約のあるネットワークは、IPv6パケットの小さなリンク層フレームへの断片化をサポートしますが、これによりパケット配信確率が大幅に低下します。CoAPの設計目標の1つは、メッセージのオーバーヘッドを小さく保ち、断片化の必要性を制限することです。
CoAPの主な目標の1つは、エネルギー、ビルオートメーション、およびその他のマシンツーマシン（M2M）アプリケーションを特に考慮して、この制約のある環境の特別な要件に合わせて汎用Webプロトコルを設計することです。CoAPの目標は、HTTP [RFC2616]を盲目的に圧縮することではなく、HTTPと共通のRESTのサブセットを実現し、M2Mアプリケーション向けに最適化することです。CoAPは、単純なHTTPインターフェイスをよりコンパクトなプロトコルに作り直すために使用できますが、さらに重要なことに、組み込みの検出、マルチキャストサポート、非同期メッセージ交換などのM2M向けの機能も提供します。
このドキュメントでは、Constrained Application Protocol (CoAP) を規定しています。これは、既存のWebとの統合のためにHTTPに簡単に変換できる一方で、マルチキャストサポート、非常に低いオーバーヘッド、制約のある環境およびM2Mアプリケーション向けのシンプルさなどの特別な要件を満たしています。
1.1. 特徴
CoAPには、次の主な特徴があります。
o 制約のある環境でのM2M要件を満たすWebプロトコル
o ユニキャストおよびマルチキャスト要求をサポートするオプションの信頼性を備えたUDP [RFC0768] バインディング。
o 非同期メッセージ交換。
o 低いヘッダーオーバーヘッドと解析の複雑さ。
o URIおよびContent-typeのサポート。
o シンプルなプロキシおよびキャッシュ機能。
o ステートレスHTTPマッピング。これにより、CoAPリソースへのアクセスをHTTP経由で統一された方法で提供するプロキシを構築したり、HTTPのシンプルなインターフェイスをCoAP上で代替的に実現したりできます。
o Datagram Transport Layer Security (DTLS) [RFC6347] へのセキュリティバインディング。
1.2. 用語
このドキュメントのキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", および "OPTIONAL" は、すべて大文字で表示される場合、[RFC2119] で説明されているように解釈されます。これらの単語は、このドキュメントでは小文字で表示されることもありますが、その場合は規範的な意味を持ちません。
この仕様では、読者が [RFC2616] で説明されているすべての用語と概念（「リソース」、「表現」、「キャッシュ」、「フレッシュ」など）に精通していることを前提としています。（更新されたHTTP RFCのセットであるRFC 7230からRFC 7235が利用可能になる前に完了したため、この仕様は具体的には前身のバージョンであるRFC 2616を参照しています。）さらに、この仕様では次の用語を定義しています。
Endpoint (エンドポイント) CoAPプロトコルに参加しているエンティティ。口語的には、エンドポイントは「ノード」上に存在しますが、「ホスト」の方がインターネット標準の用法と一致しており、UDPポート番号やセキュリティアソシエーション（セクション4.1）を含むトランスポート層多重化情報によってさらに識別されます。
Sender (送信者) メッセージの送信元エンドポイント。特定の送信者の識別の側面に焦点を当てる場合、「ソースエンドポイント」とも呼ばれます。
Recipient (受信者) メッセージの宛先エンドポイント。特定の受信者の識別の側面に焦点を当てる場合、「宛先エンドポイント」とも呼ばれます。
Client (クライアント) リクエストの送信元エンドポイント。レスポンスの宛先エンドポイント。
Server (サーバー) リクエストの宛先エンドポイント。レスポンスの送信元エンドポイント。
Origin Server (オリジンサーバー) 特定のリソースが存在する、または作成されるサーバー。
Intermediary (仲介者) オリジンサーバーに対して（場合によってはさらなる仲介者を介して）サーバーとクライアントの両方として機能するCoAPエンドポイント。仲介者の一般的な形式はプロキシです。この仕様では、いくつかのクラスのプロキシについて説明します。
Proxy (プロキシ) 主にリクエストの転送とレスポンスの中継に関係し、その過程でキャッシュ、名前空間変換、またはプロトコル変換を実行する可能性のある仲介者。一般的な意味での仲介者とは対照的に、プロキシは通常、特定のアプリケーションセマンティクスを実装しません。リクエスト転送の全体的な構造における位置に基づいて、フォワードプロキシとリバースプロキシの2つの一般的な形式があります。場合によっては、単一のエンドポイントがオリジンサーバー、フォワードプロキシ、またはリバースプロキシとして機能し、各リクエストの性質に基づいて動作を切り替えることがあります。
Forward-Proxy (フォワードプロキシ) クライアントによって（通常はローカル構成ルールを介して）選択され、クライアントに代わってリクエストを実行し、必要な変換を行うエンドポイント。一部の変換は、「coap」URIのプロキシリクエストの場合のように最小限ですが、他のリクエストでは、まったく異なるアプリケーション層プロトコルとの間の変換が必要になる場合があります。
Reverse-Proxy (リバースプロキシ) 1つ以上の他のサーバーの代わりになり、それらに代わってリクエストを満たし、必要な変換を行うエンドポイント。フォワードプロキシとは異なり、クライアントはリバースプロキシと通信していることに気付かない場合があります。リバースプロキシは、ターゲットリソースのオリジンサーバーであるかのようにリクエストを受信します。
CoAP-to-CoAP Proxy (CoAP対CoAPプロキシ) CoAPリクエストからCoAPリクエストにマッピングするプロキシ。つまり、サーバー側とクライアント側の両方でCoAPプロトコルを使用します。クロスプロキシとは対照的です。
Cross-Proxy (クロスプロキシ) クロスプロトコルプロキシ、略して「クロスプロキシ」は、CoAP対HTTPプロキシやHTTP対CoAPプロキシなど、異なるプロトコル間で変換を行うプロキシです。この仕様では、CoAP対CoAPプロキシに対して非常に具体的な要求を行っていますが、クロスプロキシではさらに多くのバリエーションが可能です。
Confirmable Message (確認可能メッセージ) 一部のメッセージには確認が必要です。これらのメッセージは「Confirmable（確認可能）」と呼ばれます。パケットが失われない場合、各Confirmableメッセージは、Acknowledgement（確認応答）またはReset（リセット）タイプの戻りメッセージを正確に1つ引き出します。
Non-confirmable Message (確認不要メッセージ) 他の一部のメッセージは確認を必要としません。これは、センサーからの読み取り値の繰り返しなど、アプリケーションの要件のために定期的に繰り返されるメッセージに特に当てはまります。
Acknowledgement Message (確認応答メッセージ) 確認応答メッセージは、特定のConfirmableメッセージが到着したことを確認します。それ自体では、確認応答メッセージは、Confirmableメッセージにカプセル化されたリクエストの成功または失敗を示すものではありませんが、確認応答メッセージにはPiggybacked Response（ピギーバック応答）が含まれる場合もあります（下記参照）。
Reset Message (リセットメッセージ) リセットメッセージは、特定のメッセージ（ConfirmableまたはNon-confirmable）が受信されたが、それを適切に処理するためのコンテキストが不足していることを示します。この状態は通常、受信ノードが再起動し、メッセージを解釈するために必要な状態を忘れてしまった場合に発生します。リセットメッセージを誘発すること（たとえば、空のConfirmableメッセージを送信することによる）は、エンドポイントの生存を確認するための安価なチェック（「CoAP ping」）としても役立ちます。
Piggybacked Response (ピギーバック応答) ピギーバック応答は、この応答のリクエストの受信を確認するために送信されるCoAP確認応答（ACK）メッセージに直接含まれます（セクション5.2.1）。
Separate Response (分離応答) リクエストを運ぶConfirmableメッセージが空のメッセージで確認された場合（たとえば、サーバーにすぐに答えがないため）、分離応答が別のメッセージ交換で送信されます（セクション5.2.2）。
Empty Message (空メッセージ) コードが0.00のメッセージ。リクエストでもレスポンスでもありません。空メッセージには、4バイトのヘッダーのみが含まれます。
Critical Option (クリティカルオプション) メッセージを適切に処理するために、最終的にメッセージを受信するエンドポイントが理解する必要があるオプション（セクション5.4.1）。「オプション」という名前が示すように、クリティカルオプションの実装は一般にオプションであることに注意してください。サポートされていないクリティカルオプションは、エラー応答またはメッセージの即時拒否につながります。
Elective Option (エレクティブオプション) それを理解しないエンドポイントによって無視されることを意図したオプション。オプションを理解していなくてもメッセージを処理することは許容されます（セクション5.4.1）。
Unsafe Option (アンセーフオプション) メッセージを安全に転送するために、メッセージを受信するプロキシが理解する必要があるオプション（セクション5.4.2）。すべてのクリティカルオプションがアンセーフオプションであるとは限りません。
Safe-to-Forward Option (転送安全オプション) それを理解しないプロキシによる転送が安全であることを意図したオプション。オプションを理解していなくてもメッセージを転送することは許容されます（セクション5.4.2）。
Resource Discovery (リソース検出) CoAPクライアントがサーバーに対して、ホストされているリソース（つまり、セクション7で定義されているリンク）のリストをクエリするプロセス。
Content-Format (コンテンツ形式) インターネットメディアタイプ（特定のパラメータが指定されている可能性があります）とコンテンツコーディング（多くの場合、IDコンテンツコーディング）の組み合わせ。「CoAP Content-Formats」レジストリによって定義された数値識別子によって識別されます。数値識別子よりも、リソース表現のこれらの特性の組み合わせに焦点が当てられている場合、これは「表現形式」とも呼ばれます。
制約のあるノードおよび制約のあるノードネットワークに関する追加の用語は、[RFC7228] に記載されています。
この仕様では、「byte」という用語は、現在慣習的な意味で「octet」の同義語として使用されています。
このプロトコルのすべてのマルチバイト整数は、ネットワークバイトオーダーで解釈されます。
算術が使用される場合、この仕様ではプログラミング言語Cでおなじみの表記法を使用しますが、演算子 "**" はべき乗を表します。