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

6. CoAP URIs

CoAPは、CoAPリソースを識別し、リソースを特定する手段を提供するために、"coap"および"coaps" URIスキームを使用します。リソースは階層的に編成され、特定のUDPポートでCoAPリクエスト ("coap") またはDTLS保護されたCoAPリクエスト ("coaps") をリッスンする潜在的なCoAPオリジンサーバーによって管理されます。CoAPサーバーは、ホストコンポーネントとオプションのUDPポート番号を含む一般的な構文の権限コンポーネントによって識別されます。URIの残りの部分は、CoAPプロトコルによって定義されたメソッドによって操作できるリソースを識別します。したがって、"coap"および"coaps" URIスキームは、それぞれ"http"および"https" URIスキームと比較できます。

"coap"および"coaps" URIスキームの構文は、このセクションで拡張バッカスナウア記法 (ABNF) [RFC5234] で指定されています。"host"、"port"、"path-abempty"、"query"、"segment"、"IP-literal"、"IPv4address"、および"reg-name"の定義は [RFC3986] から採用されています。

実装ノート: 残念ながら、時間の経過とともに、URIフォーマットはかなり複雑になりました。実装者は [RFC3986] を注意深く読むことをお勧めします。たとえば、IPv6アドレスのABNFは予想よりも複雑です。また、実装者は、URIからそのデコードされたコンポーネントへ、またはその逆のプロセスで、正確に1回のパーセントデコードまたはパーセントエンコードパスを実行するように注意する必要があります。パーセントエンコーディングはデータの透明性にとって最も重要ですが、パスコンポーネントのスラッシュ文字など、異常な結果をもたらす可能性があります。

6.1. coap URI Scheme (coap URIスキーム)​

coap-URI = "coap:" "//" host [ ":" port ] path-abempty [ "?" query ]

ホストコンポーネントがIP-literalまたはIPv4addressとして提供されている場合、そのIPアドレスでCoAPサーバーに到達できます。ホストが登録名の場合、その名前は間接識別子と見なされ、エンドポイントはDNSなどの名前解決サービスを使用して、そのホストのアドレスを検索する場合があります。ホストは空であってはなりません; 権限が欠落しているか、ホストが空のURIを受信した場合、それは無効と見なされなければなりません。ポートサブコンポーネントは、CoAPサーバーが配置されているUDPポートを示します。空であるか、指定されていない場合、デフォルトポート5683が想定されます。

パスは、ホストとポートの範囲内のリソースを識別します。スラッシュ文字 (U+002F SOLIDUS "/") で区切られたパスセグメントのシーケンスで構成されます。

クエリは、リソースをさらにパラメータ化するために使用されます。アンパサンド文字 (U+0026 AMPERSAND "&") で区切られたパラメータのシーケンスで構成されます。パラメータは通常、"key=value"ペアの形式です。

"coap" URIスキームは、ホストの名前空間における"既知の場所"のために [RFC5785] によって定義されたパスプレフィックス"/.well-known/"をサポートします。これにより、ホスト ("サイト全体のメタデータ") に関するポリシーまたはその他の情報、たとえばホストされているリソース (Section 7を参照) の発見が可能になります。

アプリケーション設計者は、短いが説明的なURIを使用することをお勧めします。CoAPが使用される環境は通常、帯域幅とエネルギーの点で制約されているため、これらの2つの品質間のトレードオフは、説明性を無視せずに簡潔さに傾くべきです。

6.2. coaps URI Scheme (coaps URIスキーム)​

coaps-URI = "coaps:" "//" host [ ":" port ] path-abempty [ "?" query ]

"coap"スキームに対して上記にリストされているすべての要件は、"coaps"スキームの要件でもあります。ただし、ポートサブコンポーネントが空であるか、指定されていない場合、デフォルトのUDPポート5684が想定され、UDPデータグラムはSection 9.1で説明されているようにDTLSを使用して保護されなければなりません。

"coaps"で識別されたリクエストへの応答のキャッシュに関する考慮事項は、Section 11.2で説明されています。

"coaps"スキームを介して利用可能にされたリソースは、リソース識別子が同じ権限 (同じUDPポートをリッスンしている同じホスト) を示している場合でも、"coap"スキームと共有IDを持ちません。これらは異なる名前空間であり、異なるオリジンサーバーと見なされます。

6.3. Normalization and Comparison Rules (正規化と比較ルール)​

"coap"および"coaps" URIスキームはURI一般構文に準拠しているため、そのようなURIは、各スキームに対して上記で説明したデフォルトを使用して、[RFC3986] のSection 6で定義されたアルゴリズムに従って正規化および比較されます。

ポートがスキームのデフォルトポートに等しい場合、通常の形式はポートサブコンポーネントを省略することです。同様に、空のパスコンポーネントは絶対パス"/"と同等であるため、通常の形式は"/"のパスを提供することです。スキームとホストは大文字と小文字を区別せず、通常は小文字で提供されます; IP-literalは推奨形式 [RFC5952] です; 他のすべてのコンポーネントは大文字と小文字を区別して比較されます。"reserved"セット以外の文字は、パーセントエンコードされたバイトと同等です ([RFC3986]、Section 2.1を参照): 通常の形式はそれらをエンコードしないことです。

たとえば、次の3つのURIは同等であり、CoAPメッセージに同じオプションとオプション値が表示されます:

coap://example.com:5683/~sensors/temp.xml
coap://EXAMPLE.com/%7Esensors/temp.xml
coap://EXAMPLE.com:/%7esensors/temp.xml

6.4. Decomposing URIs into Options (URIをオプションに分解)​

文字列 |url| からリクエストのオプションを解析する手順は次のとおりです。これらの手順により、リクエストに0個以上のUri-Host、Uri-Port、Uri-Path、およびUri-Queryオプションが含まれるか、失敗します。

  1. |url| 文字列が絶対URI ([RFC3986]) でない場合、このアルゴリズムは失敗します。

  2. [RFC3986] によって定義された参照解決プロセスを使用して |url| 文字列を解決します。この段階では、URLはASCIIエンコーディング [RFC0020] であり、ステップ5、8、および9の後にデコードされたコンポーネントはUTF-8 [RFC3629] で解釈されます。

    注: この時点で何に対して相対的に解決されるかは重要ではありません。すでに絶対URLであることがわかっているためです。

  3. |url| にASCII小文字に変換後の値が"coap"または"coaps"ではない <scheme> コンポーネントがない場合、このアルゴリズムは失敗します。

  4. |url| に <fragment> コンポーネントがある場合、このアルゴリズムは失敗します。

  5. |url| の <host> コンポーネントがリクエストの宛先IPアドレスをIP-literalまたはIPv4addressとして表していない場合、Uri-Hostオプションを含め、そのオプションの値を |url| の <host> コンポーネントの値とし、ASCII小文字に変換してから、すべてのパーセントエンコーディング ("%" に続く2つの16進数字) を対応する文字に変換します。

    注: リクエストの宛先IPアドレスがホスト部分から派生する通常の場合、これにより、Uri-Hostオプションが <host> コンポーネントのreg-name形式に対して選択的であることが保証されます。

  6. |url| に <port> コンポーネントがある場合、|port| をそのコンポーネントの値を10進整数として解釈したものとします; それ以外の場合、|port| をスキームのデフォルトポートとします。

  7. |port| がリクエストの宛先UDPポートと等しくない場合、Uri-Portオプションを含め、そのオプションの値を |port| とします。

  8. |url| の <path> コンポーネントの値が空であるか、単一のスラッシュ文字 (U+002F SOLIDUS "/") で構成されている場合、次のステップに移動します。

    それ以外の場合、<path> コンポーネントの各セグメントについて、Uri-Pathオプションを含め、そのオプションの値を、各パーセントエンコーディング ("%" に続く2つの16進数字) を対応するバイトに変換した後のセグメント (区切りスラッシュ文字を含まない) とします。

  9. |url| に <query> コンポーネントがある場合、<query> コンポーネントの各パラメータについて、Uri-Queryオプションを含め、そのオプションの値を、各パーセントエンコーディングを対応するバイトに変換した後のパラメータ (疑問符と区切りアンパサンド文字を含まない) とします。

これらのルールは、すべてのパーセントエンコーディングを完全に解決することに注意してください。

6.5. Composing URIs from Options (オプションからURIを構成)​

リクエストのオプションからURIを構築する手順は次のとおりです。これらの手順により、URIが生成されるか、失敗します。これらの手順では、文字をパーセントエンコードすることは、その各 (UTF-8エンコードされた) バイトを、バイトを表す2つの16進数字が続く"%"文字で置き換えることを意味します。ここで、数字A-Fは大文字です ([RFC3986]、Section 2.1で定義されています; 変動性を減らすために、CoAP URIのパーセントエンコーディングの16進表記は大文字を使用しなければなりません)。"unreserved"および"sub-delims"の定義は [RFC3986] から採用されています。

  1. リクエストがDTLSを使用して保護されている場合、|url| を文字列"coaps://"とします。それ以外の場合、|url| を文字列"coap://"とします。

  2. リクエストにUri-Hostオプションが含まれている場合、|host| をそのオプションの値とし、非ASCII文字は対応するパーセントエンコーディングに置き換えます。|host| が有効なreg-nameまたはIP-literalまたはIPv4addressでない場合、アルゴリズムは失敗します。リクエストにUri-Hostオプションが含まれていない場合、|host| をリクエストの宛先IPアドレスを表すIP-literal ([RFC5952] の規則を利用) またはIPv4addressとします。

  3. |host| を |url| に追加します。

  4. リクエストにUri-Portオプションが含まれている場合、|port| をそのオプションの値とします。それ以外の場合、|port| をリクエストの宛先UDPポートとします。

  5. |port| がスキームのデフォルトポートでない場合、単一の文字U+003A COLON (":") に続いて |port| の10進表現を |url| に追加します。

  6. |resource name| を空の文字列とします。リクエストの各Uri-Pathオプションについて、単一の文字U+002F SOLIDUS ("/") に続いてオプションの値を |resource name| に追加します。"unreserved"セットにない、または"sub-delims"セットにない、またはU+003A COLON (":") 文字でない、またはU+0040 COMMERCIAL AT ("@") 文字でない任意の文字をパーセントエンコード形式に変換した後。

  7. |resource name| が空の文字列の場合、それを単一の文字U+002F SOLIDUS ("/") に設定します。

  8. リクエストの各Uri-Queryオプションについて、単一の文字U+003F QUESTION MARK ("?") (最初のオプションの場合) またはU+0026 AMPERSAND ("&") (後続のオプションの場合) に続いてオプションの値を |resource name| に追加します。"unreserved"セットにない、または"sub-delims"セット (U+0026 AMPERSAND ("&") を除く) にない、またはU+003A COLON (":") でない、またはU+0040 COMMERCIAL AT ("@") でない、またはU+002F SOLIDUS ("/") でない、またはU+003F QUESTION MARK ("?") 文字でない任意の文字をパーセントエンコード形式に変換した後。

  9. |resource name| を |url| に追加します。

  10. |url| を返します。

これらの手順は、通常の形式のURIにつながるように設計されていることに注意してください (Section 6.3を参照)。

に最終更新