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

3. Message Format (メッセージフォーマット)

CoAPは、デフォルトでUDP上で転送される (すなわち、各CoAPメッセージは1つのUDPデータグラムのデータセクションを占める) コンパクトなメッセージの交換に基づいています。CoAPは、Datagram Transport Layer Security (DTLS) を介して使用することもできます (Section 9.1を参照)。また、SMS、TCP、またはSCTPなどの他のトランスポートを介して使用することもできますが、その仕様はこの文書の範囲外です。(CoAPはUDP-lite [RFC3828] とUDPゼロチェックサム [RFC6936] をサポートしていません。)

CoAPメッセージはシンプルなバイナリ形式でエンコードされます。メッセージフォーマットは、固定サイズの4バイトヘッダーで始まります。その後に、0から8バイトの長さの可変長Tokenの値が続きます。

Tokenの値の後には、Type-Length-Value (TLV) 形式の0個以上のCoAP Optionのシーケンスが続き、オプションでデータグラムの残りを占めるペイロードが続きます。

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver| T |  TKL  |      Code     |          Message ID           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Token (if any, TKL bytes) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Options (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1|    Payload (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     図 7: メッセージフォーマット

ヘッダー内のフィールドは以下のように定義されます:

Version (Ver, バージョン): 2ビット符号なし整数。CoAPバージョン番号を示します。本仕様の実装は、このフィールドを1 (バイナリ01) に設定しなければなりません。その他の値は将来のバージョンのために予約されています。未知のバージョン番号を持つメッセージは黙って無視されなければなりません。

Type (T, タイプ): 2ビット符号なし整数。このメッセージがConfirmable (0)、Non-confirmable (1)、Acknowledgement (2)、またはReset (3) タイプであるかを示します。これらのメッセージタイプのセマンティクスはSection 4で定義されています。

Token Length (TKL, Token長): 4ビット符号なし整数。可変長Tokenフィールドの長さ (0-8バイト) を示します。長さ9-15は予約されており、送信してはならず、メッセージフォーマットエラーとして処理されなければなりません。

Code (コード): 8ビット符号なし整数で、3ビットのクラス (最上位ビット) と5ビットの詳細 (最下位ビット) に分割され、"c.dd" として文書化されます。ここで "c" は3ビットサブフィールドの0から7の数字であり、"dd" は5ビットサブフィールドの00から31の2桁の数字です。クラスは、リクエスト (0)、成功レスポンス (2)、クライアントエラーレスポンス (4)、またはサーバーエラーレスポンス (5) を示すことができます。(他のすべてのクラス値は予約されています。) 特別なケースとして、Code 0.00は空メッセージを示します。リクエストの場合、Codeフィールドはリクエストメソッドを示します; レスポンスの場合、レスポンスコードを示します。可能な値はCoAP Code Registries (Section 12.1) で管理されています。リクエストとレスポンスのセマンティクスはSection 5で定義されています。

Message ID (メッセージID): ネットワークバイトオーダーの16ビット符号なし整数。メッセージの重複を検出し、Acknowledgement/ResetタイプのメッセージをConfirmable/Non-confirmableタイプのメッセージにマッチングするために使用されます。Message IDの生成とメッセージのマッチングのルールはSection 4で定義されています。

ヘッダーの後には、Token Lengthフィールドで指定される0から8バイトのToken値が続きます。Token値はリクエストとレスポンスを関連付けるために使用されます。Tokenの生成とリクエストおよびレスポンスの関連付けのルールはSection 5.3.1で定義されています。

ヘッダーとTokenの後には、0個以上のOption (Section 3.1) が続きます。Optionの後には、メッセージの終わり、別のOption、またはPayload Markerとペイロードのいずれかが続くことができます。

ヘッダー、token、options (存在する場合) の後に、ペイロードが存在する可能性があります。存在し、長さがゼロでない場合、固定の1バイトのPayload Marker (0xFF) がプレフィックスとして付けられ、オプションの終わりとペイロードの開始を示します。ペイロードデータは、マーカーの後からUDPデータグラムの終わりまで延びます。つまり、Payload Lengthはデータグラムサイズから計算されます。Payload Markerの後にゼロ長のペイロードが続く場合、メッセージフォーマットエラーとして処理されなければなりません。

実装ノート: バイト値0xFFはオプションの長さまたは値内にも出現する可能性があるため、0xFFの単純なバイト単位のスキャンはペイロードマーカーを見つけるための実行可能な技術ではありません。バイト0xFFは、別のオプションの開始が発生する可能性がある場所でのみペイロードマーカーのセマンティクスを持ちます。

3.1. Option Format (オプションフォーマット)​

CoAPは、メッセージに含めることができる多数のオプションを定義しています。メッセージ内のオプションの各インスタンスは、定義されたCoAPオプションのOption Number、Option Valueの長さ、およびOption Value自体を指定します。

Option Numberを直接指定する代わりに、インスタンスはOption Numberの順序で出現しなければならず、それらの間でデルタエンコーディングが使用されます: 各インスタンスのOption Numberは、そのデルタとメッセージ内の前のインスタンスのOption Numberの合計として計算されます。メッセージ内の最初のインスタンスの場合、Option Numberがゼロの前のオプションインスタンスが仮定されます。同じオプションの複数のインスタンスは、ゼロのデルタを使用することによって含めることができます。

Option NumbersはCoAP Option Numbers" レジストリ (Section 12.2) で管理されています。この文書で定義されているオプションのセマンティクスについては、Section 5.4を参照してください。

  0   1   2   3   4   5   6   7
+---------------+---------------+
|               |               |
|  Option Delta | Option Length |   1 byte
|               |               |
+---------------+---------------+
\                               \
/         Option Delta          /   0-2 bytes
\          (extended)           \
+-------------------------------+
\                               \
/         Option Length         /   0-2 bytes
\          (extended)           \
+-------------------------------+
\                               \
/                               /
\                               \
/         Option Value          /   0 or more bytes
\                               \
/                               /
\                               \
+-------------------------------+

                      図 8: オプションフォーマット

Option内のフィールドは以下のように定義されます:

Option Delta (オプションデルタ): 4ビット符号なし整数。0から12の値はOption Deltaを示します。3つの値は特別な構造のために予約されています:

  • 13: 初期バイトの後に8ビット符号なし整数が続き、Option Deltaマイナス13を示します。

  • 14: 初期バイトの後にネットワークバイトオーダーの16ビット符号なし整数が続き、Option Deltaマイナス269を示します。

  • 15: Payload Markerのために予約されています。フィールドがこの値に設定されているが、バイト全体がペイロードマーカーでない場合、これはメッセージフォーマットエラーとして処理されなければなりません。

結果として得られるOption Deltaは、このオプションのOption Numberと前のオプション (最初のオプションの場合はゼロ) のOption Numberとの差として使用されます。言い換えれば、Option Numberは、このオプションとその前のすべてのオプションのOption Delta値を単純に合計することによって計算されます。

Option Length (オプション長): 4ビット符号なし整数。0から12の値は、Option Valueの長さをバイト単位で示します。3つの値は特別な構造のために予約されています:

  • 13: Option Valueの前に8ビット符号なし整数があり、Option Lengthマイナス13を示します。

  • 14: Option Valueの前にネットワークバイトオーダーの16ビット符号なし整数があり、Option Lengthマイナス269を示します。

  • 15: 将来の使用のために予約されています。フィールドがこの値に設定されている場合、メッセージフォーマットエラーとして処理されなければなりません。

Value (値): 正確にOption Length バイトのシーケンス。Option Valueの長さと形式は、それぞれのオプションに依存し、可変長の値を定義することができます。この文書で使用されている形式についてはSection 3.2を参照してください; 他の文書で定義されているオプションは、他のオプション値形式を利用することができます。

3.2. Option Value Formats (オプション値フォーマット)​

この文書で定義されているオプションは、以下のオプション値フォーマットを使用します。

empty (空): ゼロ長のバイトシーケンス。

opaque (不透明): 不透明なバイトシーケンス。

uint (符号なし整数): Option Lengthフィールドで指定されたバイト数を使用してネットワークバイトオーダーで表される非負整数。

オプション定義は、許可されるバイト数の範囲を指定することができます; 選択肢がある場合、送信者は可能な限り少ないバイト数で整数を表現すべきです。すなわち、先頭のゼロバイトなしで。例えば、数値0は空のオプション値 (ゼロ長のバイトシーケンス) で表され、数値1は数値1の単一バイト (最上位ビット優先表記法でのビット組み合わせ00000001) で表されます。受信者は、先頭のゼロバイトを持つ値を処理する準備ができていなければなりません。

実装ノート: 送信者に許可される例外的な動作は、テンプレート内で固定サイズのオプションを使用する、高度に制約された、テンプレート化された実装 (例えば、ハードウェア実装) を対象としています。

string (文字列): UTF-8 [RFC3629] をNet-Unicode形式 [RFC5198] でエンコードされたUnicode文字列。

ここで、およびCoAPプロトコルでUTF-8エンコーディングが使用される他のすべての場所で、エンコードされた文字列がCoAP実装によって不透明なバイト文字列として直接使用でき、等価性のために比較できることが意図されていることに注意してください。CoAP実装内で正規化を実行する期待も必要もありません (CoAPプロトコル外のソースから、正規化されていないUnicode文字列を供給することが知られているソースからUnicode文字列をインポートする場合を除く)。また、ASCII文字列 (特殊な制御文字を使用しない) は常に有効なUTF-8 Net-Unicode文字列であることに注意してください。

に最終更新