[要約] RFC 8075は、HTTPを制約のあるアプリケーションプロトコル（CoAP）にマッピングするためのガイドラインです。このRFCの目的は、HTTPとCoAPの相互運用性を向上させるための実装のマッピング方法を提供することです。
Internet Engineering Task Force (IETF) A. Castellani
Request for Comments: 8075 University of Padova
Category: Standards Track S. Loreto
ISSN: 2070-1721 Ericsson
A. Rahman
InterDigital Communications, LLC
T. Fossati
Nokia
E. Dijk
Philips Lighting
February 2017
Guidelines for Mapping Implementations: HTTP to the Constrained Application Protocol (CoAP)
実装のマッピングに関するガイドライン：HTTPから制約付きアプリケーションプロトコル（CoAP）へ
Abstract
概要
This document provides reference information for implementing a cross-protocol network proxy that performs translation from the HTTP protocol to the Constrained Application Protocol (CoAP). This will enable an HTTP client to access resources on a CoAP server through the proxy. This document describes how an HTTP request is mapped to a CoAP request and how a CoAP response is mapped back to an HTTP response. This includes guidelines for status code, URI, and media type mappings, as well as additional interworking advice.
このドキュメントでは、HTTPプロトコルからConstrained Application Protocol（CoAP）への変換を実行するクロスプロトコルネットワークプロキシを実装するためのリファレンス情報を提供します。これにより、HTTPクライアントがプロキシ経由でCoAPサーバー上のリソースにアクセスできるようになります。このドキュメントでは、HTTP要求がCoAP要求にマップされる方法と、CoAP応答がHTTP応答にマップされる方法について説明します。これには、ステータスコード、URI、メディアタイプマッピングのガイドライン、および追加のインターワーキングアドバイスが含まれます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8075.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8075で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. HTTP-to-CoAP Proxy . . . . . . . . . . . . . . . . . . . . . 6
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. URI Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. URI Terminology . . . . . . . . . . . . . . . . . . . . . 8
5.2. Null Mapping . . . . . . . . . . . . . . . . . . . . . . 9
5.3. Default Mapping . . . . . . . . . . . . . . . . . . . . . 9
5.3.1. Optional Scheme Omission . . . . . . . . . . . . . . 9
5.3.2. Encoding Caveats . . . . . . . . . . . . . . . . . . 10
5.4. URI Mapping Template . . . . . . . . . . . . . . . . . . 10
5.4.1. Simple Form . . . . . . . . . . . . . . . . . . . . . 10
5.4.2. Enhanced Form . . . . . . . . . . . . . . . . . . . . 12
5.5. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 13
5.5.1. Examples . . . . . . . . . . . . . . . . . . . . . . 14
6. Media Type Mapping . . . . . . . . . . . . . . . . . . . . . 15
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 15
6.2. 'application/coap-payload' Media Type . . . . . . . . . . 16
6.3. Loose Media Type Mapping . . . . . . . . . . . . . . . . 17
6.4. Media Type to Content-Format Mapping Algorithm . . . . . 18
6.5. Content Transcoding . . . . . . . . . . . . . . . . . . . 19
6.5.1. General . . . . . . . . . . . . . . . . . . . . . . . 19
6.5.2. CoRE Link Format . . . . . . . . . . . . . . . . . . 20
6.6. Diagnostic Payloads . . . . . . . . . . . . . . . . . . . 20
7. Response Code Mapping . . . . . . . . . . . . . . . . . . . . 21
8. Additional Mapping Guidelines . . . . . . . . . . . . . . . . 23
8.1. Caching and Congestion Control . . . . . . . . . . . . . 23
8.2. Cache Refresh via Observe . . . . . . . . . . . . . . . . 24
8.3. Use of CoAP Block-Wise Transfer . . . . . . . . . . . . . 24
8.4. CoAP Multicast . . . . . . . . . . . . . . . . . . . . . 25
8.5. Timeouts . . . . . . . . . . . . . . . . . . . . . . . . 26
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
9.1. New 'core.hc' Resource Type . . . . . . . . . . . . . . . 26
9.2. New 'coap-payload' Internet Media Type . . . . . . . . . 26
10. Security Considerations . . . . . . . . . . . . . . . . . . . 28
10.1. Multicast . . . . . . . . . . . . . . . . . . . . . . . 29
10.2. Traffic Overflow . . . . . . . . . . . . . . . . . . . . 29
10.3. Handling Secured Exchanges . . . . . . . . . . . . . . . 30
10.4. URI Mapping . . . . . . . . . . . . . . . . . . . . . . 30
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
11.1. Normative References . . . . . . . . . . . . . . . . . . 31
11.2. Informative References . . . . . . . . . . . . . . . . . 32
Appendix A. Media Type Mapping Source Code . . . . . . . . . . . 35
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
The Constrained Application Protocol (CoAP) [RFC7252] has been designed with a twofold aim: it's an application protocol specialized for constrained environments and it's easily used in architectures based on Representational State Transfer (REST) [Fielding], such as the web. The latter goal has led to defining CoAP to easily interoperate with HTTP [RFC7230] through an intermediary proxy that performs cross-protocol conversion.
Constrained Application Protocol（CoAP）[RFC7252]は、2つの目的で設計されています。これは、制約された環境に特化したアプリケーションプロトコルであり、Representational State Transfer（REST）[Fielding]に基づくアーキテクチャ（Webなど）で簡単に使用できます。後者の目標は、プロトコル間変換を実行する中間プロキシを介してHTTP [RFC7230]と簡単に相互運用するようにCoAPを定義することにつながりました。
Section 10 of [RFC7252] describes the fundamentals of the CoAP-to-HTTP and the HTTP-to-CoAP cross-protocol mapping process. However, [RFC7252] focuses on the basic mapping of request methods and simple response code mapping between HTTP and CoAP, while leaving many details of the cross-protocol proxy for future definition. Therefore, a primary goal of this document is to define a consistent set of guidelines that an HTTP-to-CoAP proxy implementation should adhere to. The key benefit to adhering to such guidelines is to reduce variation between proxy implementations, thereby increasing interoperability between an HTTP client and a CoAP server independent of the proxy that implements the cross-protocol mapping. (For example, a proxy conforming to these guidelines made by vendor A can be easily replaced by a proxy from vendor B that also conforms to the guidelines without breaking API semantics.)
[RFC7252]のセクション10では、CoAP-to-HTTPおよびHTTP-to-CoAPクロスプロトコルマッピングプロセスの基本について説明しています。ただし、[RFC7252]は、要求メソッドの基本的なマッピングとHTTPとCoAPの間の単純な応答コードマッピングに焦点を当て、クロスプロトコルプロキシの多くの詳細は将来の定義に残しています。したがって、このドキュメントの主な目的は、HTTP-to-CoAPプロキシ実装が従うべき一貫したガイドラインのセットを定義することです。このようなガイドラインに従うことの主な利点は、プロキシ実装間のばらつきを減らし、クロスプロトコルマッピングを実装するプロキシから独立したHTTPクライアントとCoAPサーバー間の相互運用性を向上させることです。 （たとえば、ベンダーAによって作成されたこれらのガイドラインに準拠するプロキシは、APIセマンティクスを壊すことなくガイドラインにも準拠するベンダーBからのプロキシに簡単に置き換えることができます。）
This document describes HTTP mappings that apply to protocol elements defined in the base CoAP specification [RFC7252] and in the CoAP block-wise transfer specification [RFC7959]. It is up to CoAP protocol extensions (new methods, response codes, options, content-formats) to describe their own HTTP mappings, if applicable.
このドキュメントでは、ベースCoAP仕様[RFC7252]とCoAPブロック単位の転送仕様[RFC7959]で定義されているプロトコル要素に適用されるHTTPマッピングについて説明します。該当する場合、独自のHTTPマッピングを記述するのは、CoAPプロトコル拡張（新しいメソッド、応答コード、オプション、コンテンツ形式）です。
The rest of this document is organized as follows:
このドキュメントの残りの部分は、次のように構成されています。
o Section 2 defines proxy terminology;
o セクション2では、プロキシの用語を定義します。
o Section 3 introduces the HTTP-to-CoAP proxy;
o セクション3では、HTTP-to-CoAPプロキシを紹介しています。
o Section 4 lists use cases in which HTTP clients need to contact CoAP servers;
o セクション4は、HTTPクライアントがCoAPサーバーに接続する必要があるユースケースを示しています。
o Section 5 introduces a null, default, and advanced HTTP-to-CoAP URI mapping syntax;
o セクション5では、null、デフォルト、および高度なHTTP-to-CoAP URIマッピング構文を紹介しています。
o Section 6 describes how to map HTTP media types to CoAP content-formats, and vice versa;
o セクション6では、HTTPメディアタイプをCoAPコンテンツフォーマットに、またはその逆にマップする方法について説明します。
o Section 7 describes how to map CoAP responses to HTTP responses;
o セクション7では、CoAP応答をHTTP応答にマッピングする方法について説明します。
o Section 8 describes additional mapping guidelines related to caching, congestion, multicast, timeouts, etc.; and
o セクション8では、キャッシング、輻輳、マルチキャスト、タイムアウトなどに関連する追加のマッピングガイドラインについて説明します。そして
o Section 10 discusses the possible security impact of HTTP-to-CoAP protocol mapping.
o セクション10では、HTTPからCoAPプロトコルへのマッピングがセキュリティに与える影響について説明します。
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONAL」このドキュメントの[RFC2119]で説明されているように解釈されます。
This specification requires readers to be familiar with the vocabulary and concepts discussed in [RFC7228], in particular, the terms "constrained nodes" and "constrained networks". Readers must also be familiar with all of the terminology of the normative references listed in this document, in particular [RFC7252] (CoAP) and [RFC7230] (HTTP). In addition, this specification makes use of the following terms:
この仕様では、読者が[RFC7228]で説明されている語彙と概念、特に「制約付きノード」と「制約付きネットワーク」という用語に精通している必要があります。また、読者は、このドキュメントにリストされている規範的な参照のすべての用語、特に[RFC7252]（CoAP）および[RFC7230]（HTTP）に精通している必要があります。さらに、この仕様では次の用語を使用しています。
HC Proxy A proxy performing a cross-protocol mapping, in the context of this document an HTTP-to-CoAP (HC) mapping. Specifically, the HC Proxy acts as an HTTP server and a CoAP client. The HC Proxy can take on the role of a forward, reverse, or interception Proxy.
HCプロキシクロスプロトコルマッピングを実行するプロキシ。このドキュメントのコンテキストでは、HTTP-to-CoAP（HC）マッピングです。具体的には、HCプロキシはHTTPサーバーおよびCoAPクライアントとして機能します。 HCプロキシは、フォワード、リバース、またはインターセプトプロキシの役割を果たすことができます。
Application Level Gateway (ALG) An application-specific translation agent that allows an application on a host in one address realm to connect to its counterpart running on a host in a different realm transparently. See Section 2.9 of [RFC2663].
アプリケーションレベルゲートウェイ（ALG）1つのアドレスレルム内のホスト上のアプリケーションが、別のレルム内のホスト上で実行されている対応するアプリケーションに透過的に接続できるようにするアプリケーション固有の変換エージェント。 [RFC2663]のセクション2.9をご覧ください。
forward-proxy A message-forwarding agent that is selected by the HTTP client, usually via local configuration rules, to receive requests for some type(s) of absolute URI and to attempt to satisfy those requests via translation to the protocol indicated by the absolute URI. The user agent decides (is willing) to use the proxy as the forwarding/dereferencing agent for a predefined subset of the URI space. In [RFC7230], this is called a "proxy". [RFC7252] defines forward-proxy similarly.
forward-proxy通常、ローカル構成ルールを介してHTTPクライアントによって選択されるメッセージ転送エージェント。絶対URIの特定のタイプの要求を受信し、絶対によって示されるプロトコルへの変換を介してそれらの要求を満たそうとします。 URI。ユーザーエージェントは、URIスペースの事前定義されたサブセットの転送/逆参照エージェントとしてプロキシを使用することを決定します（意思があります）。 [RFC7230]では、これは「プロキシ」と呼ばれます。 [RFC7252]は同様にフォワードプロキシを定義します。
reverse-proxy As in [RFC7230], a receiving agent that acts as a layer above some other server(s) and translates the received requests to the underlying server's protocol. A reverse-proxy behaves as an origin (HTTP) server on its connection from the HTTP client. The HTTP client uses the "origin-form" (Section 5.3.1 of [RFC7230]) as a request-target URI. (Note that a reverse-proxy appears to an HTTP client as an origin server while a forward-proxy does not. So, when communicating with a reverse-proxy, a client may be unaware it is communicating with a proxy at all.)
reverse-proxy [RFC7230]と同様に、他のサーバーの上のレイヤーとして機能し、受信したリクエストを基盤となるサーバーのプロトコルに変換する受信エージェント。リバースプロキシは、HTTPクライアントからの接続ではオリジン（HTTP）サーバーとして動作します。 HTTPクライアントは、リクエストのターゲットURIとして「origin-form」（[RFC7230]のセクション5.3.1）を使用します。 （リバースプロキシはHTTPクライアントにはオリジンサーバーとして表示されますが、フォワードプロキシには表示されません。そのため、リバースプロキシと通信する場合、クライアントはプロキシと通信していることにまったく気付かない場合があります。）
interception proxy As in [RFC3040], a proxy that receives inbound HTTP traffic flows through the process of traffic redirection, transparent to the HTTP client.
インターセプトプロキシ[RFC3040]と同様に、インバウンドHTTPトラフィックを受信するプロキシは、トラフィックのリダイレクトプロセスを流れ、HTTPクライアントに対して透過的です。
An HC Proxy is accessed by an HTTP client that needs to fetch a resource on a CoAP server. The HC Proxy handles the HTTP request by mapping it to the equivalent CoAP request, which is then forwarded to the appropriate CoAP server. The received CoAP response is then mapped to an appropriate HTTP response and finally sent back to the originating HTTP client.
HCプロキシは、CoAPサーバー上のリソースをフェッチする必要があるHTTPクライアントによってアクセスされます。 HCプロキシは、HTTP要求を同等のCoAP要求にマッピングして処理し、適切なCoAPサーバーに転送します。受信したCoAP応答は、適切なHTTP応答にマップされ、最後に元のHTTPクライアントに送り返されます。
Section 10.2 of [RFC7252] defines basic normative requirements on HTTP-to-CoAP mapping. This document provides additional details and guidelines for the implementation of an HC Proxy.
[RFC7252]のセクション10.2は、HTTPからCoAPへのマッピングに関する基本的な規範的な要件を定義しています。このドキュメントでは、HCプロキシの実装に関する詳細とガイドラインを示します。
Constrained Network
.-------------------.
/ .------. \
/ | CoAP | \
/ |server| \
|| '------' ||
|| ||
.--------. HTTP Request .------------. CoAP Req .------. ||
| HTTP |---------------->|HTTP-to-CoAP|----------->| CoAP | ||
| Client |<----------------| Proxy |<-----------|server| ||
'--------' HTTP Response '------------' CoAP Resp '------' ||
|| ||
|| .------. ||
|| | CoAP | ||
\ |server| .------. /
\ '------' | CoAP | /
\ |server| /
\ '------' /
'-----------------'
Figure 1: HTTP-To-CoAP Proxy Deployment Scenario
図1：HTTP-To-CoAPプロキシ配備シナリオ
Figure 1 illustrates an example deployment scenario. There, an HC Proxy is located at the boundary of the constrained network domain and acts as an ALG that allows only a very specific type of traffic (i.e., authorized inbound HTTP requests and their associated outbound CoAP responses) to pass through. All other kinds of traffic are segregated within the respective network segments.
図1は、配置シナリオの例を示しています。そこでは、HCプロキシは制約されたネットワークドメインの境界に位置し、非常に特定のタイプのトラフィック（つまり、承認されたインバウンドHTTPリクエストとそれに関連するアウトバウンドCoAPレスポンス）のみが通過することを許可するALGとして機能します。他のすべての種類のトラフィックは、それぞれのネットワークセグメント内で分離されます。
To illustrate a few situations in which HTTP-to-CoAP protocol translation may be used, three use cases are described below.
HTTPからCoAPプロトコルへの変換が使用されるいくつかの状況を説明するために、3つの使用例を以下に説明します。
1. Legacy building control application without CoAP: A building control application that uses HTTP but not CoAP can check the status of CoAP sensors and/or control actuators via an HC Proxy.
1. CoAPを使用しないレガシービルディングコントロールアプリケーション：CoAPを使用せずにHTTPを使用するビルディングコントロールアプリケーションは、HCプロキシ経由でCoAPセンサーやコントロールアクチュエーターのステータスを確認できます。
2. Making sensor data available to third parties on the web: For demonstration or public interest purposes, an HC Proxy may be configured to expose the contents of a CoAP sensor to the world via the web (HTTP and/or HTTPS). Some sensors may only accept secure 'coaps' requests; therefore, the proxy is configured to translate requests to those devices accordingly. The HC Proxy is furthermore configured to only pass through GET requests in order to protect the constrained network.
2. センサーデータをWeb上のサードパーティが利用できるようにする：デモンストレーションまたは公共の利益のために、HCプロキシを構成して、CoAPセンサーのコンテンツをWeb（HTTPおよび/またはHTTPS）経由で世界に公開することができます。一部のセンサーは、安全な「coaps」リクエストのみを受け入れる場合があります。したがって、これらのデバイスへの要求を適宜変換するようにプロキシが構成されます。さらに、HCプロキシは、制約されたネットワークを保護するために、GETリクエストのみを通過させるように設定されています。
3. Smartphone and home sensor: A smartphone can access directly a CoAP home sensor using a mutually authenticated 'https' request, provided its home router runs an HC Proxy and is configured with the appropriate certificate. An HTML5 [W3C.REC-html5-20141028] application on the smartphone can provide a friendly UI using the standard (HTTP) networking functions of HTML5.
3. スマートフォンとホームセンサー：スマートフォンは、相互認証された「https」リクエストを使用してCoAPホームセンサーに直接アクセスできます。ただし、ホームルーターがHCプロキシを実行し、適切な証明書で構成されている必要があります。スマートフォン上のHTML5 [W3C.REC-html5-20141028]アプリケーションは、HTML5の標準（HTTP）ネットワーク機能を使用して、フレンドリーなUIを提供できます。
A key point in the above use cases is the expected nature of the URI to be used by the HTTP client initiating the HTTP request to the HC Proxy. Specifically, in use case #1, there will be no information related to 'coap' or 'coaps' embedded in the HTTP URI as it is a legacy HTTP client sending the request. Use case #2 is also expected to be similar. In contrast, in use case #3, it is likely that the HTTP client will specifically embed information related to 'coap' or 'coaps' in the HTTP URI of the HTTP request to the HC Proxy.
上記のユースケースの重要な点は、HCプロキシへのHTTPリクエストを開始するHTTPクライアントが使用するURIの予想される性質です。具体的には、ユースケース＃1では、リクエストを送信するレガシーHTTPクライアントであるため、HTTP URIに埋め込まれた「coap」または「coaps」に関連する情報はありません。ユースケース＃2も同様であると予想されます。対照的に、ユースケース＃3では、HTTPクライアントがHCプロキシへのHTTPリクエストのHTTP URIに「coap」または「coaps」に関連する情報を具体的に埋め込む可能性があります。
Though, in principle, a CoAP URI could be directly used by an HTTP client to dereference a CoAP resource through an HC Proxy; the reality is that all major web browsers, networking libraries, and command-line tools do not allow making HTTP requests using URIs with a scheme 'coap' or 'coaps'.
ただし、原則として、HTTPクライアントはCoAP URIを直接使用して、HCプロキシを介してCoAPリソースを逆参照することができます。現実には、すべての主要なWebブラウザー、ネットワークライブラリ、およびコマンドラインツールで、スキームが「coap」または「coaps」のURIを使用してHTTPリクエストを行うことが許可されていません。
Thus, there is a need for web applications to embed or "pack" a CoAP URI into an HTTP URI so that it can be (non-destructively) transported from the HTTP client to the HC Proxy. The HC Proxy can then "unpack" the CoAP URI and finally dereference it via a CoAP request to the target server.
したがって、WebアプリケーションがCoAP URIをHTTP URIに埋め込むか「パック」して、HTTPクライアントからHCプロキシに（非破壊的に）転送できるようにする必要があります。次に、HCプロキシはCoAP URIを「アンパック」し、最終的にCoAPリクエストを介してターゲットサーバーへの参照を解除できます。
URI mapping is the term used in this document to describe the process through which the URI of a CoAP resource is transformed into an HTTP URI so that:
URIマッピングは、このドキュメントでCoAPリソースのURIがHTTP URIに変換されるプロセスを説明するために使用される用語です。
o The requesting HTTP client can handle it; and
o 要求元のHTTPクライアントはそれを処理できます。そして
o The receiving HC Proxy can extract the intended CoAP URI unambiguously.
o 受信側のHCプロキシは、意図したCoAP URIを明確に抽出できます。
To this end, the remainder of this section will identify:
この目的を達成するために、このセクションの残りの部分では以下を識別します。
o The default mechanism to map a CoAP URI into an HTTP URI;
o CoAP URIをHTTP URIにマップするデフォルトのメカニズム。
o The URI Template format to express a class of CoAP-HTTP URI mapping functions; and
o CoAP-HTTP URIマッピング関数のクラスを表すためのURIテンプレート形式。そして
o The discovery mechanism based on "Constrained RESTful Environments (CoRE) Link Format" [RFC6690] through which clients of an HC Proxy can dynamically learn about the supported URI mapping template(s), as well as the URI where the HC Proxy function is anchored.
o 「制約付きRESTful環境（CoRE）リンクフォーマット」[RFC6690]に基づく検出メカニズム。HCプロキシのクライアントは、サポートされているURIマッピングテンプレートと、HCプロキシ機能がアンカーされているURIについて動的に学習できます。 。
In the remainder of this section, the following terms will be used with a distinctive meaning:
このセクションの残りの部分では、次の用語が独特の意味で使用されます。
HC Proxy URI: URI that refers to the HC Proxy function. It conforms to syntax defined in Section 2.7 of [RFC7230].
HCプロキシURI：HCプロキシ機能を参照するURI。 [RFC7230]のセクション2.7で定義されている構文に準拠しています。
Target CoAP URI: URI that refers to the (final) CoAP resource that has to be dereferenced. It conforms to syntax defined in Section 6 of [RFC7252]. Specifically, its scheme is either 'coap' or 'coaps'.
ターゲットCoAP URI：逆参照する必要がある（最終的な）CoAPリソースを参照するURI。 [RFC7252]のセクション6で定義されている構文に準拠しています。具体的には、そのスキームは「coap」または「coaps」です。
Hosting HTTP URI: URI that conforms to syntax in Section 2.7 of [RFC7230]. Its authority component refers to an HC Proxy, whereas a path and/or query component(s) embed the information used by an HC Proxy to extract the Target CoAP URI.
ホスティングHTTP URI：[RFC7230]のセクション2.7の構文に準拠するURI。その権限コンポーネントはHCプロキシを参照しますが、パスおよび/またはクエリコンポーネントは、HCプロキシがターゲットCoAP URIを抽出するために使用する情報を埋め込みます。
The null mapping is the case where there is no Target CoAP URI appended to the HC Proxy URI. In other words, it is a "pure" HTTP URI that is sent to the HC Proxy. This would typically occur in situations like use case #1 described in Section 4, and the proxy would typically be a reverse-proxy. In this scenario, the HC Proxy will determine through its own private algorithms what the Target CoAP URI should be.
nullマッピングは、HCプロキシURIに追加されたターゲットCoAP URIがない場合です。つまり、HCプロキシに送信されるのは「純粋な」HTTP URIです。これは通常、セクション4で説明したユースケース＃1のような状況で発生し、プロキシは通常リバースプロキシになります。このシナリオでは、HCプロキシは、独自のプライベートアルゴリズムを通じて、ターゲットCoAP URIを決定します。
The default mapping is for the Target CoAP URI to be appended as is (with the only caveat discussed in Section 5.3.2) to the HC Proxy URI, to form the Hosting HTTP URI. This is the effective request URI (see Section 5.5 of [RFC7230]) that will then be sent by the HTTP client in the HTTP request to the HC Proxy.
デフォルトのマッピングでは、ターゲットCoAP URIがそのまま（セクション5.3.2で説明されている唯一の注意事項を伴って）HCプロキシURIに追加され、ホスティングHTTP URIが形成されます。これは有効なリクエストURI（[RFC7230]のセクション5.5を参照）であり、HTTPリクエストでHTTPクライアントからHCプロキシに送信されます。
For example: given an HC Proxy URI https://p.example.com/hc/ and a Target CoAP URI coap://s.example.com/light, the resulting Hosting HTTP URI would be https://p.example.com/hc/coap://s.example.com/ light.
例：HCプロキシURI https://p.example.com/hc/およびターゲットCoAP URI coap：//s.example.com/lightを指定すると、結果のホスティングHTTP URIはhttps：// pになります。 example.com/hc/coap://s.example.com/ light。
Provided a correct Target CoAP URI, the Hosting HTTP URI resulting from the default mapping will be a syntactically valid HTTP URI. Furthermore, the Target CoAP URI can always be extracted unambiguously from the Hosting HTTP URI.
正しいターゲットCoAP URIを提供すると、デフォルトのマッピングから生成されるホスティングHTTP URIは構文的に有効なHTTP URIになります。さらに、ターゲットCoAP URIは、常にホスティングHTTP URIから明確に抽出できます。
There is no default for the HC Proxy URI. Therefore, it is either known in advance, e.g., as a configuration preset, or dynamically discovered using the mechanism described in Section 5.5.
HCプロキシURIのデフォルトはありません。したがって、それは事前に、たとえば構成プリセットとして知られているか、またはセクション5.5で説明されているメカニズムを使用して動的に発見されます。
The default URI mapping function SHOULD be implemented and SHOULD be activated by default in an HC Proxy, unless there are valid reasons (e.g., application specific) to use a different mapping function.
別のマッピング関数を使用する正当な理由（アプリケーション固有など）がない限り、デフォルトのURIマッピング関数を実装し、HCプロキシでデフォルトでアクティブにする必要があります（SHOULD）。
When constructing a Hosting HTTP URI by embedding a Target CoAP URI, the scheme (i.e., 'coap' or 'coaps'), the scheme component delimiter (":"), and the double slash ("//") preceding the authority MAY be omitted if a local default -- not defined by this document -- applies. If no prior mutual agreement exists between the client and the HC Proxy, then a Target CoAP URI without the scheme component is syntactically incorrect, and therefore:
ターゲットCoAP URI、スキーム（「coap」または「coaps」）、スキームコンポーネント区切り文字（ "："）、および権限の前の二重スラッシュ（ "//"）を埋め込んでホスティングHTTP URIを構築する場合このドキュメントで定義されていないローカルデフォルトが適用される場合は省略できます。クライアントとHCプロキシの間に事前の相互合意がない場合、スキームコンポーネントのないターゲットCoAP URIは構文的に正しくないため、次のようになります。
o It MUST NOT be emitted by clients; and o It MUST elicit a suitable client error status (i.e., 4xx) by the HC Proxy.
oクライアントによって発行されてはなりません。およびo HCプロキシによって適切なクライアントエラーステータス（4xxなど）を引き出す必要があります。
When the authority of the Target CoAP URI is given as an IPv6address, then the surrounding square brackets must be percent-encoded in the Hosting HTTP URI, in order to comply with the syntax defined in Section 3.3. of [RFC3986] for a URI path segment. For example: coap://[2001:db8::1]/light?on becomes https://p.example.com/hc/coap://%5B2001:db8::1%5D/light?on. (Note that the percent-encoded square brackets shall be reverted to their non-percent-encoded form when the HC Proxy unpacks the Target CoAP URI.)
ターゲットCoAP URIの権限がIPv6アドレスとして指定されている場合、セクション3.3で定義されている構文に準拠するために、括弧で囲まれた角かっこがホスティングHTTP URIでパーセントエンコードされている必要があります。 [RFC3986]のURIパスセグメント。例：coap：// [2001：db8 :: 1] / light？onはhttps://p.example.com/hc/coap://%5B2001:db8::1%5D/light?onになります。 （パーセントエンコードされた角かっこは、HCプロキシがターゲットCoAP URIをアンパックすると、パーセントエンコードされていない形式に戻されることに注意してください。）
Everything else can be safely copied verbatim from the Target CoAP URI to the Hosting HTTP URI.
それ以外はすべて、ターゲットCoAP URIからホスティングHTTP URIにそのまま安全にコピーできます。
This section defines a format for the URI Template [RFC6570] used by an HC Proxy to inform its clients about the expected syntax for the Hosting HTTP URI. This can then be used by the HTTP client to construct the effective request URI to be sent in the HTTP request to the HC Proxy.
このセクションでは、HCプロキシがホスティングHTTP URIの予想される構文についてクライアントに通知するために使用するURIテンプレート[RFC6570]の形式を定義します。次に、これをHTTPクライアントが使用して、HCプロキシへのHTTP要求で送信される有効な要求URIを構築できます。
When instantiated, a URI mapping template is always concatenated to an HC Proxy URI provided by the HC Proxy via discovery (see Section 5.5), or by other means.
インスタンス化されると、URIマッピングテンプレートは、ディスカバリ（セクション5.5を参照）またはその他の手段によってHCプロキシによって提供されるHCプロキシURIに常に連結されます。
A simple form (Section 5.4.1) and an enhanced form (Section 5.4.2) are provided to fit different users' requirements.
シンプルなフォーム（セクション5.4.1）と拡張されたフォーム（セクション5.4.2）は、さまざまなユーザーの要件に合わせて提供されます。
Both forms are expressed as Level 2 URI Templates [RFC6570] to take care of the expansion of values that are allowed to include reserved URI characters. The syntax of all URI formats is specified in this section in Augmented Backus-Naur Form (ABNF) [RFC5234].
どちらの形式も、予約されたURI文字を含めることができる値の拡張に対応するために、レベル2 URIテンプレート[RFC6570]として表現されます。すべてのURI形式の構文は、このセクションのAugmented Backus-Naur Form（ABNF）[RFC5234]で指定されています。
The simple form MUST be used for mappings where the Target CoAP URI is going to be copied (using rules of Section 5.3.2) at some fixed position into the Hosting HTTP URI.
シンプルなフォームは、（セクション5.3.2のルールを使用して）ターゲットCoAP URIが固定位置でホスティングHTTP URIにコピーされるマッピングに使用する必要があります。
The "tu" template variable is defined below using the ABNF rules from [RFC3986], Sections 3.2.2, 3.2.3, 3.3, and 3.4. It is intended to be used in a template definition to represent a Target CoAP URI:
「tu」テンプレート変数は、[RFC3986]のセクション3.2.2、3.2.3、3.3、および3.4のABNFルールを使用して以下で定義されています。これは、テンプレート定義でターゲットCoAP URIを表すために使用することを目的としています。
tu = [ ( "coap:" / "coaps:" ) "//" ] host [ ":" port ] path-abempty
[ "?" query ]
Note that the same considerations as in Section 5.3.1 apply, in that the CoAP scheme may be omitted from the Hosting HTTP URI.
ホスティングHTTP URIからCoAPスキームを省略できるという点で、セクション5.3.1と同じ考慮事項が適用されることに注意してください。
All the following examples (given as a specific URI mapping template, a Target CoAP URI, and the produced Hosting HTTP URI) use https://p.example.com/hc/ as the HC Proxy URI. Note that these examples all define mapping templates that deviate from the default template of Section 5.3 in order to illustrate the use of the above template variables.
以下のすべての例（特定のURIマッピングテンプレート、ターゲットCoAP URI、および生成されたホスティングHTTP URIとして提供）では、HCプロキシURIとしてhttps://p.example.com/hc/を使用します。これらの例はすべて、上記のテンプレート変数の使用法を説明するために、セクション5.3のデフォルトテンプレートから逸脱したマッピングテンプレートを定義しています。
1. Target CoAP URI is a query argument of the Hosting HTTP URI:
1. ターゲットCoAP URIは、ホスティングHTTP URIのクエリ引数です。
?target_uri={+tu}
coap://s.example.com/light
=> https://p.example.com/hc/?target_uri=coap://s.example.com/light
whereas
一方
coaps://s.example.com/light
=> https://p.example.com/hc/?target_uri=coaps://s.example.com/light
2. Target CoAP URI in the path component of the Hosting HTTP URI:
2. ホスティングHTTP URIのパスコンポーネントにあるターゲットCoAP URI：
forward/{+tu}
coap://s.example.com/light
=> https://p.example.com/hc/forward/coap://s.example.com/light
whereas
一方
coaps://s.example.com/light
=> https://p.example.com/hc/forward/coaps://s.example.com/light 3. Target CoAP URI is a query argument of the Hosting HTTP URI; client decides to omit the scheme because a default is agreed beforehand between client and proxy:
=> https://p.example.com/hc/forward/coaps://s.example.com/light 3.ターゲットCoAP URIは、ホスティングHTTP URIのクエリ引数です。クライアントとプロキシの間でデフォルトが事前に合意されているため、クライアントはスキームを省略することにしました。
?coap_uri={+tu}
coap://s.example.com/light
=> https://p.example.com/hc/?coap_uri=s.example.com/light
The enhanced form can be used to express more sophisticated mappings of the Target CoAP URI into the Hosting HTTP URI, i.e., mappings that do not fit into the simple form.
拡張フォームを使用して、ターゲットCoAP URIからホスティングHTTP URIへのより高度なマッピング、つまり、単純なフォームに適合しないマッピングを表現できます。
There MUST be at most one instance of each of the following template variables in a URI mapping template definition:
URIマッピングテンプレート定義には、次の各テンプレート変数のインスタンスが1つだけ存在する必要があります。
s = "coap" / "coaps" ; from [RFC7252], Sections 6.1 and 6.2
hp = host [":" port] ; from [RFC3986], Sections 3.2.2 and 3.2.3
p = path-abempty ; from [RFC3986], Section 3.3
q = query ; from [RFC3986], Section 3.4
qq = [ "?" query ] ; qq is empty if and only if 'query' is empty
The qq form is used when the path and the (optional) query components are to be copied verbatim from the Target CoAP URI into the Hosting HTTP URI, i.e., as "{+p}{+qq}". Instead, the q form is used when the query and path are mapped as separate entities, e.g., as in "coap_path={+p}&coap_query={+q}". So q and qq MUST be used in mutual exclusion in a template definition.
qqフォームは、パスと（オプションの）クエリコンポーネントがターゲットCoAP URIからホスティングHTTP URIにそのままコピーされる場合に使用されます。つまり、「{+ p} {+ qq}」のようになります。代わりに、「coap_path = {+ p}＆coap_query = {+ q}」のように、クエリとパスが個別のエンティティとしてマップされる場合は、q形式が使用されます。したがって、qとqqは、テンプレート定義で相互に除外して使用する必要があります。
All the following examples (given as a specific URI mapping template, a Target CoAP URI, and the produced Hosting HTTP URI) use https://p.example.com/hc/ as the HC Proxy URI.
以下のすべての例（特定のURIマッピングテンプレート、ターゲットCoAP URI、および生成されたホスティングHTTP URIとして提供）では、HCプロキシURIとしてhttps://p.example.com/hc/を使用します。
1. Target CoAP URI components in path segments and optional query in query component:
1. パスセグメントのターゲットCoAP URIコンポーネントとクエリコンポーネントのオプションのクエリ：
{+s}/{+hp}{+p}{+qq}
coap://s.example.com/light
=> https://p.example.com/hc/coap/s.example.com/light
whereas
coap://s.example.com/light?on
=> https://p.example.com/hc/coap/s.example.com/light?on
2. Target CoAP URI components split in individual query arguments:
2. 個別のクエリ引数に分割されたターゲットCoAP URIコンポーネント：
?s={+s}&hp={+hp}&p={+p}&q={+q}
coap://s.example.com/light
=> https://p.example.com/hc/?s=coap&hp=s.example.com&p=/light&q=
whereas
一方
coaps://s.example.com/light?on
=> https://p.example.com/hc/?s=coaps&hp=s.example.com&p=/light&q=on
In order to accommodate site-specific needs while allowing third parties to discover the proxy function, the HC Proxy SHOULD publish information related to the location and syntax of the HC Proxy function using the CoRE Link Format [RFC6690] interface.
サードパーティがプロキシ機能を発見できるようにしながらサイト固有のニーズに対応するために、HCプロキシは、CoREリンク形式[RFC6690]インターフェイスを使用して、HCプロキシ機能の場所と構文に関連する情報を公開する必要があります。
To this aim, a new Resource Type, "core.hc", is defined in this document. It can be used as the value for the "rt" attribute in a query to the "/.well-known/core" resource in order to locate the URI where the HC Proxy function is anchored, i.e., the HC Proxy URI.
この目的のために、このドキュメントでは新しいリソースタイプ「core.hc」を定義しています。これは、「/。well-known / core」リソースへのクエリの「rt」属性の値として使用して、HCプロキシ機能がアンカーされているURI、つまりHCプロキシURIを見つけることができます。
Along with it, the new target attribute "hct" is defined in this document. This attribute MAY be returned in a "core.hc" link to provide the URI mapping template associated with the mapping resource. The default template given in Section 5.3, i.e., {+tu}, MUST be assumed if no "hct" attribute is found in a returned link. If a "hct" attribute is present in a returned link, the client MUST use it to create a Hosting HTTP URI.
それに加えて、新しいターゲット属性「hct」がこのドキュメントで定義されています。この属性は、「core.hc」リンクで返され、マッピングリソースに関連付けられたURIマッピングテンプレートを提供する場合があります。返されたリンクに「hct」属性が見つからない場合は、セクション5.3で指定されているデフォルトのテンプレート、つまり{+ tu}を想定する必要があります。返されたリンクに「hct」属性が存在する場合、クライアントはそれを使用してホスティングHTTP URIを作成する必要があります。
The URI mapping SHOULD be discoverable (as specified in [RFC6690]) on both the HTTP and the CoAP side of the HC Proxy, with one important difference: on the CoAP side, the link associated with the "core.hc" resource always needs an explicit anchor parameter referring to the HTTP origin [RFC6454], while on the HTTP interface, the context URI of the link may be equal to the HTTP origin of the discovery request: in that case, the anchor parameter is not needed.
URIマッピングは、HCプロキシのHTTP側とCoAP側の両方で（[RFC6690]で指定されているように）検出可能である必要があります。ただし、CoAP側では、「core.hc」リソースに関連付けられたリンクには常にHTTP起点[RFC6454]を参照する明示的なアンカーパラメータ。HTTPインターフェイスでは、リンクのコンテキストURIはディスカバリ要求のHTTP起点と等しい場合があります。その場合、アンカーパラメータは必要ありません。
o The first example exercises the CoAP interface and assumes that the default template, {+tu}, is used. For example, a smartphone may discover the public HC Proxy before leaving the home network. Then, when outside the home network, the smartphone will be able to query the appropriate home sensor.
o 最初の例はCoAPインターフェイスを実行し、デフォルトのテンプレート{+ tu}が使用されていることを前提としています。たとえば、スマートフォンがホームネットワークを離れる前にパブリックHCプロキシを検出する場合があります。その後、ホームネットワークの外にいるとき、スマートフォンは適切なホームセンサーにクエリを実行できます。
Req: GET coap://[ff02::fd]/.well-known/core?rt=core.hc
Res: 2.05 Content
</hc/>;anchor="https://p.example.com";rt="core.hc"
o The second example -- also on the CoAP side of the HC Proxy -- uses a custom template, i.e., one where the CoAP URI is carried inside the query component, thus the returned link carries the URI Template to be used in an explicit "hct" attribute:
o 2番目の例（HCプロキシのCoAP側でも）は、カスタムテンプレートを使用します。つまり、CoAP URIがクエリコンポーネント内で実行されるため、返されたリンクは、明示的な「 hct "属性：
Req: GET coap://[ff02::fd]/.well-known/core?rt=core.hc
Res: 2.05 Content
</hc/>;anchor="https://p.example.com";
rt="core.hc";hct="?uri={+tu}"
On the HTTP side, link information can be serialized in more than one way:
HTTP側では、リンク情報を複数の方法でシリアル化できます。
o using the 'application/link-format' content type:
o 'application / link-format'コンテンツタイプを使用：
Req: GET /.well-known/core?rt=core.hc HTTP/1.1
Host: p.example.com
Res: HTTP/1.1 200 OK
Content-Type: application/link-format
Content-Length: 19
</hc/>;rt="core.hc"
o using the 'application/link-format+json' content type as defined in [CoRE-JSON-CBOR]:
o [CoRE-JSON-CBOR]で定義されている「application / link-format + json」コンテンツタイプを使用：
Req: GET /.well-known/core?rt=core.hc HTTP/1.1
Host: p.example.com
Res: HTTP/1.1 200 OK
Content-Type: application/link-format+json
Content-Length: 32
[{"href":"/hc/","rt":"core.hc"}]
An HC Proxy needs to translate HTTP media types (Section 3.1.1.1 of [RFC7231]) and content codings (Section 3.1.2.2 of [RFC7231]) into CoAP content-formats (Section 12.3 of [RFC7252]), and vice versa.
HCプロキシは、HTTPメディアタイプ（[RFC7231]のセクション3.1.1.1）とコンテンツコーディング（[RFC7231]のセクション3.1.2.2）をCoAPコンテンツ形式（[RFC7252]のセクション12.3））に、またはその逆に変換する必要があります。
Media type translation can happen in GET, PUT, or POST requests going from HTTP to CoAP, in 2.xx (i.e., successful) responses going from CoAP to HTTP, and in 4.xx/5.xx error responses with a diagnostic payload. Specifically, PUT and POST need to map both the Content-Type and Content-Encoding HTTP headers into a single CoAP Content-Format option, whereas GET needs to map Accept and Accept-Encoding HTTP headers into a single CoAP Accept option. To generate the HTTP response, the CoAP Content-Format option is mapped back to a suitable HTTP Content-Type and Content-Encoding combination.
メディアタイプの変換は、HTTPからCoAPへのGET、PUT、またはPOSTリクエスト、CoAPからHTTPへの2.xx（つまり成功）応答、および診断ペイロードを含む4.xx / 5.xxエラー応答で発生する。具体的には、PUTおよびPOSTは、Content-TypeヘッダーとContent-Encoding HTTPヘッダーの両方を単一のCoAP Content-Formatオプションにマッピングする必要がありますが、GETは、AcceptおよびAccept-Encoding HTTPヘッダーを単一のCoAP Acceptオプションにマッピングする必要があります。 HTTP応答を生成するために、CoAP Content-Formatオプションは、適切なHTTP Content-TypeとContent-Encodingの組み合わせにマップされます。
An HTTP request carrying a Content-Type and Content-Encoding combination that the HC Proxy is unable to map to an equivalent CoAP Content-Format SHALL elicit a 415 (Unsupported Media Type) response by the HC Proxy.
Content-TypeとContent-Encodingの組み合わせを運ぶHTTPリクエストは、HCプロキシが同等のCoAP Content-Formatにマップできないため、HCプロキシによって415（サポートされていないメディアタイプ）応答を引き出す必要があります。
On the content negotiation side, failure to map Accept and Accept-*
headers SHOULD be silently ignored: the HC Proxy SHOULD therefore
forward as a CoAP request with no Accept option. The HC Proxy thus
disregards the Accept/Accept-* header fields by treating the response
as if it is not subject to content negotiation, as mentioned in
Section 5.3 of [RFC7231]. However, an HC Proxy implementation is
free to attempt mapping a single Accept header in a GET request to
multiple CoAP GET requests, each with a single Accept option, which
are then tried in sequence until one succeeds. Note that an HTTP
Accept */* MUST be mapped to a CoAP request without an Accept option.
While the CoAP-to-HTTP direction always has a well-defined mapping (with the exception examined in Section 6.2), the HTTP-to-CoAP
CoAPからHTTPへの方向には、明確に定義されたマッピングが常にありますが（6.2節で説明した例外を除く）、HTTPからCoAPへ
direction is more problematic because the source set, i.e., potentially 1000+ IANA-registered media types, is much bigger than the destination set, i.e., the mere six values initially defined in Section 12.3 of [RFC7252].
ソースセット、つまり1000以上のIANAに登録されたメディアタイプは宛先セット、つまり[RFC7252]のセクション12.3で最初に定義された単なる6つの値よりもはるかに大きいため、方向はさらに問題になります。
Depending on the tight/loose coupling with the application(s) for which it proxies, the HC Proxy could implement different media type mappings.
プロキシするアプリケーションとの密結合/疎結合に応じて、HCプロキシは異なるメディアタイプマッピングを実装できます。
When tightly coupled, the HC Proxy knows exactly which content-formats are supported by the applications and can be strict when enforcing its forwarding policies in general, and the media type mapping in particular.
HCプロキシは、密結合すると、アプリケーションがサポートするコンテンツ形式を正確に認識し、一般に転送ポリシー、特にメディアタイプマッピングを適用するときに厳密になる可能性があります。
On the other hand, when the HC Proxy is a general purpose ALG, being too strict could significantly reduce the amount of traffic that it would be able to successfully forward. In this case, the "loose" media type mapping detailed in Section 6.3 MAY be implemented.
一方、HCプロキシが汎用のALGである場合、厳しすぎると、正常に転送できるトラフィックの量が大幅に減少する可能性があります。この場合、セクション6.3で詳述されている「ルーズ」メディアタイプマッピングが実装される場合があります。
The latter grants more evolution of the surrounding ecosystem, at the cost of allowing more attack surface. In fact, as a result of such strategy, payloads would be forwarded more liberally across the unconstrained/constrained network boundary of the communication path.
後者は、より多くの攻撃対象領域を許可することを犠牲にして、周囲のエコシステムのさらなる進化をもたらします。実際、そのような戦略の結果として、ペイロードは、通信パスの制約されていない/制約されたネットワーク境界を越えてより自由に転送されます。
If the HC Proxy receives a CoAP response with a Content-Format that it does not recognize (e.g., because the value has been registered after the proxy has been deployed, or the CoAP server uses an experimental value that is not registered), then the HC Proxy SHALL return a generic "application/coap-payload" media type with numeric parameter "cf" as defined in Section 9.2.
HCプロキシが、認識できないContent-Formatを含むCoAP応答を受信した場合（たとえば、プロキシのデプロイ後に値が登録されている、またはCoAPサーバーが登録されていない実験値を使用しているため）、 HCプロキシは、セクション9.2で定義されている数値パラメータ「cf」を使用して、一般的な「application / coap-payload」メディアタイプを返す必要があります（SHALL）。
For example, the CoAP content-format '60' ("application/cbor") would be represented by "application/coap-payload;cf=60", if the HC Proxy doesn't recognize the content-format '60'.
たとえば、HCプロキシがコンテンツ形式「60」を認識しない場合、CoAPコンテンツ形式「60」（「application / cbor」）は「application / coap-payload; cf = 60」で表されます。
An HTTP client may use the media type "application/coap-payload" as a means to send a specific content-format to a CoAP server via an HC Proxy if the client has determined that the HC Proxy does not directly support the type mapping it needs. This case may happen when dealing, for example, with newly registered, yet to be registered, or experimental CoAP content-formats. However, unless explicitly configured to allow pass-through of unknown content-formats, the HC Proxy SHOULD NOT forward requests carrying a Content-Type or Accept header with an "application/coap-payload", and return an appropriate client error instead.
HCプロキシがタイプマッピングを直接サポートしていないとクライアントが判断した場合、HTTPクライアントは、メディアタイプ「application / coap-payload」を使用して、HCプロキシを介して特定のコンテンツ形式をCoAPサーバーに送信できます。ニーズ。このケースは、たとえば、新しく登録されたがまだ登録されていない、または実験的なCoAPコンテンツ形式を扱うときに発生する可能性があります。ただし、不明なコンテンツ形式のパススルーを許可するように明示的に構成されていない限り、HCプロキシは、「application / coap-payload」でContent-TypeまたはAcceptヘッダーを含むリクエストを転送してはならず、代わりに適切なクライアントエラーを返します。
By structuring the type information in a super-class (e.g., "text") followed by a finer-grained sub-class (e.g., "html"), and optional parameters (e.g., "charset=utf-8"), Internet media types provide a rich and scalable framework for encoding the type of any given entity.
スーパークラス（たとえば、「テキスト」）の後に型情報を構造化し、その後にきめの細かいサブクラス（たとえば、「html」）、オプションのパラメーター（たとえば、「charset = utf-8」）を続けます。インターネットメディアタイプは、特定のエンティティのタイプをエンコードするための豊富でスケーラブルなフレームワークを提供します。
This approach is not applicable to CoAP, where content-formats conflate an Internet media type (potentially with specific parameters) and a content coding into one small integer value.
このアプローチはCoAPには適用できません。CoAPでは、コンテンツ形式がインターネットメディアタイプ（特定のパラメーターを持つ可能性があります）とコンテンツコーディングを1つの小さな整数値に統合します。
To remedy this loss of flexibility, we introduce the concept of a "loose" media type mapping, where media types that are specializations of a more generic media type can be aliased to their super-class and then mapped (if possible) to one of the CoAP content-formats. For example, "application/soap+xml" can be aliased to "application/xml", which has a known conversion to CoAP. In the context of this "loose" media type mapping, "application/ octet-stream" can be used as a fallback when no better alias is found for a specific media type.
この柔軟性の損失を改善するために、「緩い」メディアタイプマッピングの概念を導入します。ここでは、より一般的なメディアタイプの特殊化であるメディアタイプをスーパークラスにエイリアスし、（可能な場合）次のいずれかにマッピングできます。 CoAPコンテンツ形式。たとえば、「application / soap + xml」は、CoAPへの変換が既知の「application / xml」にエイリアス化できます。この「緩い」メディアタイプマッピングのコンテキストでは、特定のメディアタイプに適したエイリアスが見つからない場合のフォールバックとして、「application / octet-stream」を使用できます。
Table 1 defines the default lookup table for the "loose" media type mapping. It is expected that an implementation can refine it because either application-specific knowledge is given or new Content-Formats are defined. Given an input media type, the table returns its best generalized media type using the most specific match, i.e., the table entries are compared to the input in top to bottom order until an entry matches.
表1は、「ルーズ」メディアタイプマッピングのデフォルトのルックアップテーブルを定義しています。アプリケーション固有の知識が提供されるか、新しいContent-Formatsが定義されるため、実装によってそれを改善できることが期待されます。入力メディアタイプが指定されると、テーブルは最も具体的な一致を使用してその最も一般化されたメディアタイプを返します。つまり、テーブルエントリは、エントリが一致するまで、上から下の順序で入力と比較されます。
+-----------------------------+--------------------------+
| Internet media type pattern | Generalized media type |
+-----------------------------+--------------------------+
| application/*+xml | application/xml |
| application/*+json | application/json |
| application/*+cbor | application/cbor |
| text/xml | application/xml |
| text/* | text/plain |
| */* | application/octet-stream |
+-----------------------------+--------------------------+
Table 1: Media Type Generalization Lookup Table
表1：メディアタイプの汎化ルックアップテーブル
The "loose" media type mapping is an OPTIONAL feature. Implementations supporting this kind of mapping should provide a flexible way to define the set of media type generalizations allowed.
「ルーズ」メディアタイプマッピングはオプション機能です。この種類のマッピングをサポートする実装は、許可されるメディアタイプの一般化のセットを定義する柔軟な方法を提供する必要があります。
This section defines the algorithm used to map an HTTP Internet media type to its correspondent CoAP content-format; it can be used as a building block for translating HTTP Content-Type and Accept headers into CoAP Content-Format and Accept Options.
このセクションでは、HTTPインターネットメディアタイプを対応するCoAPコンテンツ形式にマップするために使用されるアルゴリズムを定義します。これは、HTTP Content-TypeおよびAcceptヘッダーをCoAP Content-FormatおよびAcceptオプションに変換するためのビルディングブロックとして使用できます。
The algorithm uses an IANA-maintained table, "CoAP Content-Formats", as established by Section 12.3 of [RFC7252] plus, possibly, any locally defined extension of it. Optionally, the table and lookup mechanism described in Section 6.3 can be used if the implementation chooses so.
このアルゴリズムは、[RFC7252]のセクション12.3で確立されたIANAが管理するテーブル「CoAP Content-Formats」に加えて、ローカルで定義された拡張機能を使用します。オプションで、セクション6.3で説明されているテーブルと検索メカニズムを、実装で選択した場合に使用できます。
Note that the algorithm assumes an "identity" Content-Encoding and expects the resource body has been already successfully content decoded or transcoded to the desired format.
アルゴリズムは「アイデンティティ」のContent-Encodingを想定しており、リソースの本文は、目的の形式にコンテンツが既にデコードまたはトランスコードされていることを前提としています。
In the following (Figure 2):
以下（図2）：
o media_type is the media type to translate;
o media_typeは、変換するメディアタイプです。
o coap_cf_registry is a lookup table matching the "CoAP Content-Formats" registry; and
o coap_cf_registryは、「CoAP Content-Formats」レジストリと一致するルックアップテーブルです。そして
o loose_mapper is an optional lookup table describing the loose media type mappings (e.g., the one defined in Table 1).
o loose_mapperは、ルーズなメディアタイプのマッピングを説明するオプションのルックアップテーブルです（たとえば、表1で定義されているもの）。
The full source code is provided in Appendix A.
完全なソースコードは付録Aにあります。
def mt2cf(media_type, encoding=None, coap_cf_registry=CoAPContentFormatRegistry(), loose_mapper=None): """Return a CoAP Content-Format given an Internet media type and its optional encoding. The current (as of 2016/10/24) "CoAP Content-Formats" registry is supplied by default. An optional 'loose-mapping' implementation can be supplied by the caller.""" assert media_type is not None assert coap_cf_registry is not None
def mt2cf（media_type、encoding = None、coap_cf_registry = CoAPContentFormatRegistry()、loose_mapper = None）： "" "インターネットメディアタイプとそのオプションのエンコーディングを指定してCoAPコンテンツ形式を返します。現在（2016/10/24現在） 「CoAP Content-Formats」レジストリがデフォルトで提供されています。オプションの「ルーズマッピング」実装を呼び出し元から提供できます。 "" "assert media_type is not None assert coap_cf_registry is not None
# Lookup the "CoAP Content-Formats" registry content_format = coap_cf_registry.lookup(media_type, encoding)
＃「CoAP Content-Formats」レジストリを検索content_format = coap_cf_registry.lookup（media_type、encoding）
# If an exact match is not found and a loose mapper has been # supplied, try to use it to get a media type with which to # retry the "CoAP Content-Formats" registry lookup. if content_format is None and loose_mapper is not None: content_format = coap_cf_registry.lookup( loose_mapper.lookup(media_type), encoding)
＃完全一致が見つからず、ルーズマッパーが＃提供されている場合は、それを使用して＃ "CoAP Content-Formats"レジストリルックアップを再試行するメディアタイプを取得してください。 content_formatがNoneで、loose_mapperがNoneでない場合：content_format = coap_cf_registry.lookup（loose_mapper.lookup（media_type）、encoding）
return content_format
content_formatを返す
Figure 2
図2
Payload content transcoding is an OPTIONAL feature. Implementations supporting this feature should provide a flexible way to define the set of transcodings allowed.
ペイロードコンテンツのトランスコーディングはオプションの機能です。この機能をサポートする実装は、許可されるトランスコーディングのセットを定義する柔軟な方法を提供する必要があります。
The HC Proxy might decide to transcode the received representation to a different (compatible) format when an optimized version of a specific format exists. For example, an XML-encoded resource could be transcoded to Efficient XML Interchange (EXI) format, or a JSON-encoded resource into Concise Binary Object Representation (CBOR) [RFC7049], effectively achieving compression without losing any information.
HCプロキシは、特定のフォーマットの最適化されたバージョンが存在する場合、受信した表現を別の（互換性のある）フォーマットにトランスコードすることを決定する場合があります。たとえば、XMLエンコードされたリソースを効率的なXML交換（EXI）形式にトランスコードしたり、JSONエンコードされたリソースをコンサイスバイナリオブジェクト表現（CBOR）[RFC7049]にトランスコードしたりして、情報を失うことなく効果的に圧縮を実現できます。
However, there are a few important factors to keep in mind when enabling a transcoding function:
ただし、トランスコーディング機能を有効にする場合は、いくつかの重要な要素に注意してください。
1. Maliciously crafted inputs coming from the HTTP side might inflate in size (see, for example, Section 4.2 of [RFC7049]), therefore creating a security threat for both the HC Proxy and the target resource.
1. HTTP側からの悪意を持って作成された入力はサイズが大きくなる可能性があり（たとえば、[RFC7049]のセクション4.2を参照）、HCプロキシとターゲットリソースの両方にセキュリティ上の脅威をもたらします。
2. Transcoding can lose information in non-obvious ways. For example, encoding an XML document using schema-informed EXI encoding leads to a loss of information when the destination does not know the exact schema version used by the encoder. That means that whenever the HC Proxy transcodes "application/xml" to "application/exi", in-band metadata could be lost.
2. トランスコーディングは、明白でない方法で情報を失う可能性があります。たとえば、スキーマに基づいたEXIエンコーディングを使用してXMLドキュメントをエンコードすると、宛先がエンコーダで使用されているスキーマの正確なバージョンを知らない場合、情報が失われます。つまり、HCプロキシが「application / xml」を「application / exi」にトランスコードすると、インバンドメタデータが失われる可能性があります。
3. When the Content-Type is mapped, there is a risk that the content with the destination type would have malware not active in the source type.
3. Content-Typeがマップされると、宛先タイプのコンテンツがソースタイプでアクティブでないマルウェアを含む可能性があるというリスクがあります。
It is crucial that these risks are well understood and carefully weighed against the actual benefits before deploying the transcoding function.
トランスコーディング機能を導入する前に、これらのリスクを十分に理解し、実際のメリットと慎重に比較検討することが重要です。
The CoRE Link Format [RFC6690] is a set of links (i.e., URIs and their formal relationships) that is carried as content payload in a CoAP response. These links usually include CoAP URIs that might be translated by the HC Proxy to the correspondent HTTP URIs using the implemented URI mapping function (see Section 5). Such a translation process would inspect the forwarded traffic and attempt to rewrite the body of resources with an application/link-format media type, mapping the embedded CoAP URIs to their HTTP counterparts. Some potential issues with this approach are:
CoREリンクフォーマット[RFC6690]は、CoAP応答でコンテンツペイロードとして伝送される一連のリンク（URIとその正式な関係）です。これらのリンクには通常、実装されたURIマッピング機能を使用して、HCプロキシによって対応するHTTP URIに変換される可能性のあるCoAP URIが含まれます（セクション5を参照）。このような変換プロセスは、転送されたトラフィックを検査し、リソースの本体をアプリケーション/リンク形式のメディアタイプで書き換えて、埋め込まれたCoAP URIを対応するHTTPにマッピングします。このアプローチの潜在的な問題は次のとおりです。
1. The client may be interested in retrieving original (unaltered) CoAP payloads through the HC Proxy, not modified versions.
1. クライアントは、変更されたバージョンではなく、HCプロキシを介して元の（変更されていない）CoAPペイロードを取得することに関心がある場合があります。
2. Tampering with payloads is incompatible with resources that are integrity protected (although this is a problem with transcoding in general).
2. ペイロードの改ざんは、整合性が保護されているリソースと互換性がありません（ただし、これは一般にトランスコーディングの問題です）。
3. The HC Proxy needs to fully understand syntax and semantics defined in [RFC6690], otherwise there is an inherent risk to corrupt the payloads.
3. HCプロキシは、[RFC6690]で定義されている構文とセマンティクスを完全に理解する必要があります。そうしないと、ペイロードを破壊する固有のリスクがあります。
Therefore, CoRE Link Format payload should only be transcoded at the risk and discretion of the proxy implementer.
したがって、CoRE Link Formatペイロードは、プロキシの実装者のリスクと裁量でのみトランスコードする必要があります。
CoAP responses may, in certain error cases, contain a diagnostic message in the payload explaining the error situation, as described in Section 5.5.2 of [RFC7252]. If present, the CoAP diagnostic payload SHOULD be copied into the HTTP response body with the media type of the response set to "text/plain;charset=utf-8". The CoAP diagnostic payload MUST NOT be copied into the HTTP reason-phrase, since it potentially contains CR-LF characters that are incompatible with HTTP reason-phrase syntax.
[RFC7252]のセクション5.5.2で説明されているように、CoAP応答では、特定のエラーの場合、エラー状況を説明する診断メッセージがペイロードに含まれる場合があります。存在する場合、CoAP診断ペイロードは、応答のメディアタイプを「text / plain; charset = utf-8」に設定して、HTTP応答本文にコピーする必要があります（SHOULD）。 CoAP診断ペイロードには、HTTP理由フレーズ構文と互換性のないCR-LF文字が含まれている可能性があるため、HTTP理由フレーズにコピーしないでください。
Table 2 defines the HTTP response status codes to which each CoAP response code SHOULD be mapped. Multiple HTTP status codes in the second column for a given CoAP response code indicates that multiple HTTP responses are possible for the same CoAP response code, depending on the conditions cited in the Notes (see the third column and text below the table).
表2は、各CoAP応答コードがマップされる必要があるHTTP応答ステータスコードを定義しています。特定のCoAP応答コードの2番目の列にある複数のHTTPステータスコードは、注に記載されている条件に応じて、同じCoAP応答コードに対して複数のHTTP応答が可能であることを示します（3番目の列と表の下のテキストを参照）。
+-------------------------------+----------------------------+------+
| CoAP Response Code | HTTP Status Code | Note |
+-------------------------------+----------------------------+------+
| 2.01 Created | 201 Created | 1 |
| 2.02 Deleted | 200 OK | 2 |
| | 204 No Content | 2 |
| 2.03 Valid | 304 Not Modified | 3 |
| | 200 OK | 4 |
| 2.04 Changed | 200 OK | 2 |
| | 204 No Content | 2 |
| 2.05 Content | 200 OK | |
| 2.31 Continue | N/A | 10 |
| 4.00 Bad Request | 400 Bad Request | |
| 4.01 Unauthorized | 403 Forbidden | 5 |
| 4.02 Bad Option | 400 Bad Request | 6 |
| | 500 Internal Server Error | 6 |
| 4.03 Forbidden | 403 Forbidden | |
| 4.04 Not Found | 404 Not Found | |
| 4.05 Method Not Allowed | 400 Bad Request | 7 |
| | 405 Method Not Allowed | 7 |
| 4.06 Not Acceptable | 406 Not Acceptable | |
| 4.08 Request Entity Incomplt. | N/A | 10 |
| 4.12 Precondition Failed | 412 Precondition Failed | |
| 4.13 Request Ent. Too Large | 413 Payload Too Large | 11 |
| 4.15 Unsupported Content-Fmt. | 415 Unsupported Media Type | |
| 5.00 Internal Server Error | 500 Internal Server Error | |
| 5.01 Not Implemented | 501 Not Implemented | |
| 5.02 Bad Gateway | 502 Bad Gateway | |
| 5.03 Service Unavailable | 503 Service Unavailable | 8 |
| 5.04 Gateway Timeout | 504 Gateway Timeout | |
| 5.05 Proxying Not Supported | 502 Bad Gateway | 9 |
+-------------------------------+----------------------------+------+
Table 2: CoAP-HTTP Response Code Mappings
表2：CoAP-HTTP応答コードのマッピング
Notes:
ノート：
1. A CoAP server may return an arbitrary format payload along with this response. If present, this payload MUST be returned as an entity in the HTTP 201 response. Section 6.3.2 of [RFC7231] does not put any requirement on the format of the entity. (In the past, [RFC2616] did. Note that [RFC2616] has been obsoleted by [RFC7230].)
1. CoAPサーバーは、この応答とともに任意の形式のペイロードを返す場合があります。存在する場合、このペイロードはHTTP 201応答のエンティティとして返される必要があります。 [RFC7231]のセクション6.3.2には、エンティティの形式に関する要件はありません。 （以前は[RFC2616]がそうでした。[RFC2616]は[RFC7230]によって廃止されていることに注意してください。）
2. The HTTP code is 200 or 204, respectively, for the case where a CoAP server returns a payload or not. [RFC7231], Section 6.3 requires code 200 in case a representation of the action result is returned for DELETE/POST/PUT, and code 204 if not. Hence, a proxy MUST transfer any CoAP payload contained in a CoAP 2.02 response to the HTTP client using a 200 OK response.
2. CoAPサーバーがペイロードを返す場合と返さない場合のHTTPコードは、それぞれ200または204です。 [RFC7231]、セクション6.3では、DELETE / POST / PUTに対してアクション結果の表現が返される場合はコード200が必要であり、そうでない場合はコード204が必要です。したがって、プロキシは、200 OK応答を使用して、CoAP 2.02応答に含まれるCoAPペイロードをHTTPクライアントに転送する必要があります。
3. HTTP code 304 (Not Modified) is sent if the HTTP client performed a conditional HTTP request and the CoAP server responded with 2.03 (Valid) to the corresponding CoAP validation request. Note that Section 4.1 of [RFC7232] puts some requirements on header fields that must be present in the HTTP 304 response.
3. HTTPクライアントが条件付きHTTP要求を実行し、CoAPサーバーが対応するCoAP検証要求に2.03（有効）で応答した場合、HTTPコード304（変更なし）が送信されます。 [RFC7232]のセクション4.1では、HTTP 304応答に存在する必要があるヘッダーフィールドにいくつかの要件が課されていることに注意してください。
4. A 200 response to a CoAP 2.03 occurs only when the HC Proxy, for efficiency reasons, is running a local cache. An unconditional HTTP GET that produces a cache-hit could trigger a revalidation (i.e., a conditional GET) on the CoAP side. The proxy receiving 2.03 updates the freshness of its cached representation and returns it to the HTTP client.
4. CoAP 2.03への200応答は、HCプロキシが効率上の理由でローカルキャッシュを実行している場合にのみ発生します。キャッシュヒットを生成する無条件のHTTP GETは、CoAP側で再検証（つまり、条件付きGET）をトリガーする可能性があります。 2.03を受信するプロキシは、キャッシュされた表現の鮮度を更新し、HTTPクライアントに返します。
5. An HTTP 401 Unauthorized (Section 3.1 of [RFC7235]) response is not applicable because there is no equivalent of WWW-Authenticate in CoAP, which is mandatory in an HTTP 401 response.
5. HTTP 401 Unauthorized（[RFC7235]のセクション3.1）応答は、HTTP 401応答で必須であるCoAPのWWW-Authenticateに相当するものがないため、適用されません。
6. If the proxy has a way to determine that the Bad Option is due to the straightforward mapping of a client request header into a CoAP option, then returning HTTP 400 (Bad Request) is appropriate. In all other cases, the proxy MUST return HTTP 500 (Internal Server Error) stating its inability to provide a suitable translation to the client's request.
6. プロキシに、不良オプションがCoAPオプションへのクライアントリクエストヘッダーの単純なマッピングによるものであると判断する方法がある場合、HTTP 400（不良リクエスト）を返すことが適切です。他のすべての場合、プロキシは、クライアントのリクエストに適切な変換を提供できないことを示すHTTP 500（内部サーバーエラー）を返さなければなりません（MUST）。
7. A CoAP 4.05 (Method Not Allowed) response SHOULD normally be mapped to an HTTP 400 (Bad Request) code, because the HTTP 405 response would require specifying the supported methods -- which are generally unknown. In this case, the HC Proxy SHOULD also return an HTTP reason-phrase in the HTTP status line that starts with the string "CoAP server returned 4.05" in order to facilitate troubleshooting. However, if the HC Proxy has more granular information about the supported methods for the requested resource (e.g., via a Resource Directory ([CoRE-RD])), then it MAY send back an HTTP 405 (Method Not Allowed) with a properly filled in "Allow" response-header field (Section 7.4.1 of [RFC7231]).
7. CoAP 4.05（メソッドは許可されていません）応答は通常、HTTP 400（不正な要求）コードにマップする必要があります。これは、HTTP 405応答では、サポートされているメソッド（通常は不明）を指定する必要があるためです。この場合、HCプロキシは、トラブルシューティングを容易にするために、文字列「CoAP server returned 4.05」で始まるHTTPステータス行でHTTP理由フレーズも返す必要があります（SHOULD）。ただし、HCプロキシに、リクエストされたリソースでサポートされているメソッドに関するより詳細な情報がある場合（たとえば、リソースディレクトリ（[CoRE-RD]）を介して）、適切にHTTP 405（メソッドは許可されていません）を返すことができます。 「許可」レスポンスヘッダーフィールドに入力する（[RFC7231]のセクション7.4.1）。
8. The value of the HTTP "Retry-After" response-header field is taken from the value of the CoAP Max-Age Option, if present.
8. HTTPの「Retry-After」応答ヘッダーフィールドの値は、CoAP Max-Age Optionの値（存在する場合）から取得されます。
9. This CoAP response can only happen if the proxy itself is configured to use a CoAP forward-proxy (Section 5.7 of [RFC7252]) to execute some, or all, of its CoAP requests.
9. このCoAP応答は、プロキシ自体がCoAPフォワードプロキシ（[RFC7252]のセクション5.7）を使用してCoAPリクエストの一部またはすべてを実行するように構成されている場合にのみ発生します。
10. Only used in CoAP block-wise transfer [RFC7959] between HC Proxy and CoAP server; never translated into an HTTP response.
10. HCプロキシとCoAPサーバー間のCoAPブロック単位転送[RFC7959]でのみ使用されます。 HTTP応答に変換されることはありません。
11. Only returned to the HTTP client if the HC Proxy was unable to successfully complete the request by retrying it with CoAP block-wise transfer; see Section 8.3.
11. HCプロキシがCoAPブロック単位の転送で要求を再試行して要求を正常に完了できなかった場合にのみ、HTTPクライアントに返されます。セクション8.3を参照してください。
An HC Proxy should cache CoAP responses and reply whenever applicable with a cached representation of the requested resource.
HCプロキシは、CoAP応答をキャッシュし、要求されたリソースのキャッシュされた表現を適用できる場合は常に応答する必要があります。
If the HTTP client drops the connection after the HTTP request was made, an HC Proxy should wait for the associated CoAP response and cache it if possible. Subsequent requests to the HC Proxy for the same resource can use the result present in cache, or, if a response has still to come, the HTTP requests will wait on the open CoAP request.
HTTP要求が行われた後でHTTPクライアントが接続をドロップした場合、HCプロキシは関連するCoAP応答を待機し、可能であればそれをキャッシュする必要があります。同じリソースに対するHCプロキシへの後続の要求は、キャッシュに存在する結果を使用できます。または、応答がまだ送信されていない場合、HTTP要求はオープンCoAP要求を待機します。
According to [RFC7252], a proxy must limit the number of outstanding requests to a given CoAP server to NSTART. To limit the amount of aggregate traffic to a constrained network, the HC Proxy should also put a limit on the number of concurrent CoAP requests pending on the same constrained network; further incoming requests may either be queued or be dropped (returning 503 Service Unavailable). This limit and the proxy queueing/dropping behavior should be configurable.
[RFC7252]によれば、プロキシは特定のCoAPサーバーへの未処理のリクエストの数をNSTARTに制限する必要があります。制約されたネットワークへの集約トラフィックの量を制限するために、HCプロキシは同じ制約されたネットワークで保留中の同時CoAP要求の数にも制限を設定する必要があります。それ以上の着信要求は、キューに入れられるか、またはドロップされます（503 Service Unavailableが返されます）。この制限とプロキシのキューイング/ドロップ動作は構成可能である必要があります。
Highly volatile resources that are being frequently requested may be observed [RFC7641] by the HC Proxy to keep their cached representation fresh while minimizing the amount of CoAP traffic in the constrained network (see Section 8.2).
HCプロキシは、頻繁に要求される揮発性の高いリソースを監視して[RFC7641]、キャッシュされた表現を最新の状態に保ちながら、制約付きネットワークでのCoAPトラフィックの量を最小限に抑えることができます（セクション8.2を参照）。
There are cases where using the CoAP observe protocol [RFC7641] to handle proxy cache refresh is preferable to the validation mechanism based on the entity-tag (ETag) as defined in [RFC7252]. Such scenarios include sleepy CoAP nodes -- with possibly high variance in requests' distribution -- which would greatly benefit from a server-driven cache update mechanism. Ideal candidates for CoAP observe are also crowded or very low throughput networks, where reduction of the total number of exchanged messages is an important requirement.
CoAP監視プロトコル[RFC7641]を使用してプロキシキャッシュリフレッシュを処理する方が、[RFC7252]で定義されているエンティティタグ（ETag）に基づく検証メカニズムよりも望ましい場合があります。このようなシナリオには、スリープ状態のCoAPノードが含まれます-要求の分散に大きなばらつきがある可能性があります-これは、サーバー主導のキャッシュ更新メカニズムから大きなメリットを得ます。 CoAP監視の理想的な候補は、混雑したネットワークまたは非常に低スループットのネットワークでもあり、交換メッセージの総数の削減が重要な要件です。
This subsection aims at providing a practical evaluation method to decide whether refreshing a cached resource R is more efficiently handled via ETag validation or by establishing an observation on R. The idea being that the HC Proxy proactively installs an observation on a "popular enough" resource and actively monitors:
このサブセクションは、キャッシュされたリソースRの更新がETag検証を介してより効率的に処理されるか、Rの観測を確立することによって決定する実用的な評価方法を提供することを目的としています。HCプロキシは「人気のある」リソースに観測をインストールするそして積極的に監視します：
a. Its update pattern on the CoAP side
a. CoAP側の更新パターン
b. The request pattern on the HTTP side
b. HTTP側のリクエストパターン
and uses the formula below to determine whether the observation should be kept alive or shut down.
また、以下の式を使用して、観測を維持するかシャットダウンするかを決定します。
Let T_R be the mean time between two client requests to resource R, let T_C be the mean time between two representation changes of R, and let M_R be the mean number of CoAP messages per second exchanged to and from resource R. If we assume that the initial cost for establishing the observation is negligible, an observation on R reduces M_R if and only if T_R < 2*T_C with respect to using ETag validation, that is, if and only if the mean arrival rate of requests for resource R is greater than half the change rate of R.
リソースRへの2つのクライアント要求間の平均時間をT_Rとし、Rの2つの表現変更間の平均時間をT_Cとし、リソースRとの間で交換される1秒あたりのCoAPメッセージの平均数をM_Rとします。観測を確立するための初期コストはごくわずかです。ETag検証の使用に関してT_R <2 * T_Cの場合、つまりリソースRのリクエストの平均到着率がより大きい場合に限り、Rでの観測によりM_Rが減少します。 Rの変化率の半分よりも
When observing the resource R, M_R is always upper bounded by 2/T_C.
リソースRを監視する場合、M_Rの上限は常に2 / T_Cです。
An HC Proxy SHOULD support CoAP block-wise transfers [RFC7959] to allow transport of large CoAP payloads while avoiding excessive link-layer fragmentation in constrained networks and to cope with small datagram buffers in CoAP endpoints as described in [RFC7252], Section 4.6.
HCプロキシは、CoAPブロックワイズ転送[RFC7959]をサポートする必要があります[RFC7959]。これにより、[RFC7252]のセクション4.6で説明されているように、制約のあるネットワークでのリンク層の過度の断片化を回避し、CoAPエンドポイントの小さなデータグラムバッファーに対処できます。
An HC Proxy SHOULD attempt to retry a payload-carrying CoAP PUT or POST request with block-wise transfer if the destination CoAP server responded with 4.13 (Request Entity Too Large) to the original request. An HC Proxy SHOULD attempt to use block-wise transfer when sending a CoAP PUT or POST request message that is larger than BLOCKWISE_THRESHOLD bytes. The value of BLOCKWISE_THRESHOLD is implementation specific; for example, it can be:
HCプロキシは、宛先CoAPサーバーが元の要求に4.13（要求エンティティが大きすぎる）で応答した場合、ブロック単位の転送でペイロードを運ぶCoAP PUTまたはPOST要求を再試行する必要があります（SHOULD）。 HCプロキシは、BLOCKWISE_THRESHOLDバイトより大きいCoAP PUTまたはPOSTリクエストメッセージを送信するときに、ブロック単位の転送を使用する必要があります（SHOULD）。 BLOCKWISE_THRESHOLDの値は実装固有です。たとえば、次のようになります。
o Calculated based on a known or typical UDP datagram buffer size for CoAP endpoints, or
o CoAPエンドポイントの既知または一般的なUDPデータグラムバッファーサイズに基づいて計算されます。
o Set to N times the known size of a link-layer frame in a constrained network where, e.g., N=5, or
o N = 5などの制約されたネットワークで、リンク層フレームの既知のサイズのN倍に設定します。
o Preset to a known IP MTU value, or
o 既知のIP MTU値にプリセット、または
o Set to a known Path MTU value.
o 既知のパスMTU値に設定します。
The value BLOCKWISE_THRESHOLD, or the parameters from which it is calculated, should be configurable in a proxy implementation. The maximum block size the proxy will attempt to use in CoAP requests should also be configurable.
値BLOCKWISE_THRESHOLD、またはそれが計算されるパラメーターは、プロキシー実装で構成可能でなければなりません。プロキシがCoAP要求で使用しようとする最大ブロックサイズも設定可能である必要があります。
The HC Proxy SHOULD detect CoAP endpoints not supporting block-wise transfers. This can be done by checking for a 4.02 (Bad Option) response returned by an endpoint in response to a CoAP request with a Block* Option, and subsequent absence of the 4.02 in response to the same request without Block* Options. This allows the HC Proxy to be more efficient, not attempting repeated block-wise transfers to CoAP servers that do not support it.
HCプロキシは、ブロック単位の転送をサポートしていないCoAPエンドポイントを検出する必要があります（SHOULD）。これは、Block *オプションを使用したCoAP要求に応答してエンドポイントから返された4.02（不良オプション）応答をチェックし、その後、Block *オプションを使用しない同じ要求に応答して4.02が存在しないことを確認することで実行できます。これにより、HCプロキシがより効率的になり、それをサポートしないCoAPサーバーへのブロック単位の転送が繰り返されなくなります。
An HC Proxy MAY support CoAP multicast. If it does, the HC Proxy sends out a multicast CoAP request if the Target CoAP URI's authority is a multicast IP literal or resolves to a multicast IP address. If the HC Proxy does not support CoAP multicast, it SHOULD respond 403 (Forbidden) to any valid HTTP request that maps to a CoAP multicast request.
HCプロキシはCoAPマルチキャストをサポートしてもよい（MAY）。一致する場合、ターゲットCoAP URIの権限がマルチキャストIPリテラルであるか、マルチキャストIPアドレスに解決される場合、HCプロキシはマルチキャストCoAP要求を送信します。 HCプロキシがCoAPマルチキャストをサポートしていない場合は、CoAPマルチキャスト要求にマップする有効なHTTP要求に403（禁止）で応答する必要があります（SHOULD）。
Details related to supporting CoAP multicast are currently out of scope of this document since in a proxy scenario, an HTTP client typically expects to receive a single response, not multiple. However, an HC Proxy that implements CoAP multicast may include application-specific functions to aggregate multiple CoAP responses into a single HTTP response. We suggest using the "application/http" Internet media type (Section 8.3.2 of [RFC7230]) to enclose a set of one or more HTTP response messages, each representing the mapping of one CoAP response.
プロキシシナリオでは、HTTPクライアントは通常、複数ではなく単一の応答を受信することを期待しているため、CoAPマルチキャストのサポートに関する詳細は、現在このドキュメントの範囲外です。ただし、CoAPマルチキャストを実装するHCプロキシには、複数のCoAP応答を単一のHTTP応答に集約するアプリケーション固有の機能が含まれている場合があります。 「application / http」インターネットメディアタイプ（[RFC7230]のセクション8.3.2）を使用して、それぞれが1つのCoAP応答のマッピングを表す1つ以上のHTTP応答メッセージのセットを囲むことをお勧めします
For further considerations related to the handling of multicast requests, see Section 10.1.
マルチキャスト要求の処理に関するその他の考慮事項については、10.1項を参照してください。
If the CoAP server takes a long time in responding, the HTTP client or any other proxy in between may timeout. Further discussion of timeouts in HTTP is available in Section 6.5 of [RFC7230].
CoAPサーバーの応答に時間がかかる場合、HTTPクライアントまたはその間の他のプロキシがタイムアウトする可能性があります。 HTTPのタイムアウトの詳細については、[RFC7230]のセクション6.5をご覧ください。
An HC Proxy MUST define an internal timeout for each pending CoAP request, because the CoAP server may silently die before completing the request. Assuming the proxy uses confirmable CoAP requests, such timeout value T SHOULD be
CoAPサーバーは要求を完了する前に黙って停止する可能性があるため、HCプロキシは保留中のCoAP要求ごとに内部タイムアウトを定義する必要があります。プロキシが確認可能なCoAP要求を使用すると仮定すると、そのようなタイムアウト値Tは
T = MAX_RTT + MAX_SERVER_RESPONSE_DELAY
T = MAX_RTT + MAX_SERVER_RESPONSE_DELAY
where MAX_RTT is defined in [RFC7252] and MAX_SERVER_RESPONSE_DELAY is defined as the worst-case expected response delay of the CoAP server. If unknown, a default value of 250 seconds can be used for MAX_SERVER_RESPONSE_DELAY as in Section 2.5 of [RFC7390].
ここで、MAX_RTTは[RFC7252]で定義されており、MAX_SERVER_RESPONSE_DELAYはCoAPサーバーの予想される最悪の応答遅延として定義されています。不明な場合、[RFC7390]のセクション2.5のように、MAX_SERVER_RESPONSE_DELAYにデフォルト値の250秒を使用できます。
This document registers a new Resource Type (rt=) Link Target Attribute, 'core.hc', in the "Resource Type (rt=) Link Target Attribute Values" subregistry under the "Constrained RESTful Environments (CoRE) Parameters" registry.
このドキュメントでは、「制約付きRESTful環境（CoRE）パラメータ」レジストリの「リソースタイプ（rt =）リンクターゲット属性値」サブレジストリに、新しいリソースタイプ（rt =）リンクターゲット属性 'core.hc'を登録します。
Attribute Value: core.hc
属性値：core.hc
Description: HTTP-to-CoAP mapping base resource.
説明：HTTP-to-CoAPマッピングベースリソース。
Reference: See Section 5.5 of RFC 8075.
参照：RFC 8075のセクション5.5を参照してください。
This document defines the "application/coap-payload" media type with a single parameter "cf". This media type represents any payload that a CoAP message can carry, having a content-format that can be identified by an integer in range 0-65535 corresponding to a CoAP Content-Format parameter ([RFC7252], Section 12.3). The parameter "cf" is the integer defining the CoAP content-format.
このドキュメントは、単一のパラメーター「cf」で「application / coap-payload」メディアタイプを定義します。このメディアタイプは、CoAPメッセージが伝送できる任意のペイロードを表し、CoAP Content-Formatパラメータ（[RFC7252]、セクション12.3）に対応する0〜65535の範囲の整数で識別できるコンテンツ形式を持っています。パラメータ「cf」は、CoAPコンテンツ形式を定義する整数です。
Type name: application
タイプ名：アプリケーション
Subtype name: coap-payload
サブタイプ名：coap-payload
Required parameters: "cf" (CoAP Content-Format integer in range 0-65535 denoting the content-format of the CoAP payload carried, as defined by the "CoAP Content-Formats" subregistry that is part of the "Constrained RESTful Environments (CoRE) Parameters" registry).
必須パラメーター：「cf」（CoAP Content-Formatsサブレジストリー「Costrained RESTful Environments（CoRE ）パラメータ」レジストリ）。
Optional parameters: None
オプションのパラメーター：なし
Encoding considerations: Common use is BINARY. The specific CoAP content-format encoding considerations for the selected Content-Format ("cf" parameter) apply. The encoding can vary based on the value of the "cf" parameter.
エンコードに関する考慮事項：一般的な使用法はBINARYです。選択したコンテンツ形式（「cf」パラメーター）に固有のCoAPコンテンツ形式エンコーディングの考慮事項が適用されます。エンコーディングは、「cf」パラメータの値に基づいて変化します。
Security considerations: The specific CoAP content-format security considerations for the selected Content-Format ("cf" parameter) apply.
セキュリティに関する考慮事項：選択したコンテンツ形式（「cf」パラメーター）に固有のCoAPコンテンツ形式のセキュリティに関する考慮事項が適用されます。
Interoperability considerations: This media type can never be used directly in CoAP messages because there are no means available to encode the mandatory "cf" parameter in CoAP.
相互運用性の考慮事項：CoAPで必須の「cf」パラメーターをエンコードする手段がないため、このメディアタイプをCoAPメッセージで直接使用することはできません。
Published specification: RFC 8075
公開された仕様：RFC 8075
Applications that use this media type: HTTP-to-CoAP proxies.
このメディアタイプを使用するアプリケーション：HTTP-to-CoAPプロキシ。
Fragment identifier considerations: CoAP does not support URI fragments; therefore, a CoAP payload fragment cannot be identified. Fragments are not applicable for this media type.
フラグメント識別子の考慮事項：CoAPはURIフラグメントをサポートしていません。したがって、CoAPペイロードフラグメントは識別できません。フラグメントは、このメディアタイプには適用されません。
Additional information:
追加情報：
Deprecated alias names for this type: N/A
このタイプの非推奨のエイリアス名：N / A
Magic number(s): N/A
File extension(s): N/A
Macintosh file type code(s): N/A
Person and email address to contact for further information:
詳細について連絡する人とメールアドレス：
Esko Dijk ("esko@ieee.org")
Esko Dijk（「esko@ieee.org」）
Intended usage: COMMON
使用目的：COMMON
Restrictions on usage:
使用上の制限：
An application (or user) can only use this media type if it has to represent a CoAP payload of which the specified CoAP Content-Format is an unrecognized number, such that a proper translation directly to the equivalent HTTP media type is not possible.
アプリケーション（またはユーザー）は、指定されたCoAP Content-Formatが認識されない番号であるCoAPペイロードを表す必要がある場合にのみ、このメディアタイプを使用できます。これにより、同等のHTTPメディアタイプに直接適切に変換できません。
Author: CoRE WG
作成者：CoRE WG
Change controller: IETF
コントローラの変更：IETF
Provisional registration: No
仮登録：いいえ
The security considerations in Section 9.2 of [RFC7230] apply in full to the HC Proxy. This section discusses security aspects and requirements that are specific to the deployment and operation of an HC Proxy.
[RFC7230]のセクション9.2のセキュリティに関する考慮事項は、HCプロキシに完全に適用されます。このセクションでは、HCプロキシの展開と操作に固有のセキュリティの側面と要件について説明します。
An HC Proxy located at the boundary of a constrained network is an easy single point of failure for reducing availability. As such, special care should be taken in designing, developing, and operating it, keeping in mind that, in most cases, it has fewer limitations than the constrained devices it is serving. In particular, its quality of implementation and operation -- i.e., use of current software development practices, careful selection of third-party libraries, sane configuration defaults, and an expedited way to upgrade a running instance -- are all essential attributes of the HC Proxy.
制約のあるネットワークの境界にあるHCプロキシは、可用性を低下させるための簡単な単一障害点です。そのため、設計、開発、操作には特別な注意を払う必要があります。ほとんどの場合、提供する制約付きデバイスよりも制限が少ないことに注意してください。特に、その実装と操作の品質（つまり、現在のソフトウェア開発手法の使用、サードパーティライブラリの慎重な選択、適切な構成のデフォルト、実行中のインスタンスを迅速にアップグレードする方法）はすべて、HCの重要な属性です。プロキシ。
The correctness of request parsing in general (including any content transcoding), and of URI translation in particular, is essential to the security of the HC Proxy function. This is especially true when the constrained network hosts devices with genuinely limited capabilities. For this purpose, see also Sections 9.3, 9.4, 9.5 and 9.6 of [RFC7230] for well-known issues related to HTTP request parsing and Section 11.1 of [RFC7252] for an overview of CoAP-specific concerns related to URI processing -- in particular, the potential impact on access control mechanisms that are based on URIs.
HCプロキシ機能のセキュリティには、リクエストの解析全般（コンテンツのトランスコーディングを含む）、特にURI変換の正確さが不可欠です。これは、制約されたネットワークが、機能が本当に制限されたデバイスをホストする場合に特に当てはまります。この目的のために、HTTPリクエストの解析に関連する既知の問題については[RFC7230]のセクション9.3、9.4、9.5および9.6を、URI処理に関連するCoAP固有の問題の概要については[RFC7252]のセクション11.1も参照してください。特に、URIに基づくアクセス制御メカニズムへの潜在的な影響。
An HC Proxy MUST implement Transport Layer Security (TLS) with a Pre-Shared Key (PSK) [RFC4279] and SHOULD implement TLS [RFC5246] with support for client authentication using X.509 certificates. A prerequisite of the latter is the availability of a Certification Authority (CA) to issue suitable certificates. Although this can be a challenging requirement in certain application scenarios, it is worth noting that there exist open-source tools (e.g., [OpenSSL]) that can be used to set up and operate an application-specific CA.
HCプロキシは、事前共有キー（PSK）[RFC4279]でトランスポート層セキュリティ（TLS）を実装する必要があり、X.509証明書を使用したクライアント認証をサポートするTLS [RFC5246]を実装する必要があります。後者の前提条件は、適切な証明書を発行するための認証局（CA）の可用性です。これは特定のアプリケーションシナリオでは困難な要件になる可能性がありますが、アプリケーション固有のCAのセットアップと操作に使用できるオープンソースツール（[OpenSSL]など）が存在することは注目に値します。
By default, the HC Proxy MUST authenticate all incoming requests prior to forwarding them to the CoAP server. This default behavior MAY be explicitly disabled by an administrator.
デフォルトでは、HCプロキシはすべての着信リクエストをCoAPサーバーに転送する前に認証する必要があります。このデフォルトの動作は、管理者によって明示的に無効にされる場合があります。
The following subparagraphs categorize and discuss a set of specific security issues related to the translation, caching, and forwarding functionality exposed by an HC Proxy.
次のサブパラグラフは、HCプロキシによって公開される変換、キャッシング、および転送機能に関連する一連の特定のセキュリティ問題を分類して説明します。
Multicast requests impose a non-trivial cost on the constrained network and endpoints and might be exploited as a DoS attack vector (see also Section 10.2). From a privacy perspective, they can be used to gather detailed information about the resources hosted in the constrained network. For example, an outsider that is able to successfully query the "/.well-known/core" resource could obtain a comprehensive list of the target's home appliances and devices. From a security perspective, they can be used to carry out a network reconnaissance attack to gather information about possible vulnerabilities that could be exploited at a later point in time. For these reasons, it is RECOMMENDED that requests to multicast resources are access controlled with a default-deny policy. It is RECOMMENDED that the requestor of a multicast resource be strongly authenticated. If privacy and/or security are first class requirements, for example, whenever the HTTP request transits through the public Internet, the request SHOULD be transported over a mutually authenticated and encrypted TLS connection.
マルチキャスト要求は、制約されたネットワークとエンドポイントに重要なコストを課し、DoS攻撃ベクトルとして利用される可能性があります（セクション10.2も参照）。プライバシーの観点からは、これらを使用して、制約されたネットワークでホストされているリソースに関する詳細情報を収集できます。たとえば、「/。well-known / core」リソースを正常に照会できる部外者は、ターゲットの家電製品とデバイスの包括的なリストを取得できます。セキュリティの観点から、これらはネットワーク偵察攻撃を実行して、後で悪用される可能性のある脆弱性に関する情報を収集するために使用できます。これらの理由により、マルチキャストリソースへのリクエストは、デフォルトの拒否ポリシーでアクセス制御することをお勧めします。マルチキャストリソースのリクエスタは、強力に認証されることをお勧めします。プライバシーやセキュリティがファーストクラスの要件である場合、たとえば、HTTPリクエストがパブリックインターネットを通過するときは常に、相互認証および暗号化されたTLS接続を介してリクエストを転送する必要があります（SHOULD）。
Due to the typically constrained nature of CoAP nodes, particular attention should be given to the implementation of traffic reduction mechanisms (see Section 8.1), because an inefficient proxy implementation can be targeted by unconstrained Internet attackers. Bandwidth or complexity involved in such attacks is very low.
非効率的なプロキシ実装は制約のないインターネット攻撃者の標的となる可能性があるため、CoAPノードの一般的な制約の性質により、トラフィック削減メカニズムの実装（セクション8.1を参照）に特に注意を払う必要があります。このような攻撃に伴う帯域幅または複雑さは非常に低いです。
An amplification attack to the constrained network may be triggered by a multicast request generated by a single HTTP request that is mapped to a CoAP multicast resource, as discussed in Section 11.3 of [RFC7252].
[RFC7252]のセクション11.3で説明されているように、制約付きネットワークに対する増幅攻撃は、CoAPマルチキャストリソースにマッピングされた単一のHTTPリクエストによって生成されたマルチキャストリクエストによってトリガーされる可能性があります。
The risk likelihood of this amplification technique is higher than an amplification attack carried out by a malicious constrained device (e.g., ICMPv6 flooding, like Packet Too Big, or Parameter Problem on a multicast destination [RFC4732]) since it does not require direct access to the constrained network.
への直接アクセスを必要としないため、この増幅手法のリスクの可能性は、悪意のある制約のあるデバイスによって実行される増幅攻撃（たとえば、Packet Too BigなどのICMPv6フラッディング、またはマルチキャスト宛先[RFC4732]のパラメーター問題）よりも高くなります。制約されたネットワーク。
The feasibility of this attack, which disrupts availability of the targeted CoAP server, can be limited by access controlling the exposed multicast resources, so that only known/authorized users can access such URIs.
標的のCoAPサーバーの可用性を混乱させるこの攻撃の実現可能性は、公開されたマルチキャストリソースをアクセス制御することによって制限でき、既知の/許可されたユーザーのみがそのようなURIにアクセスできるようにします。
An HTTP request can be sent to the HC Proxy over a secured connection. However, there may not always exist a secure connection mapping to CoAP. For example, a secure distribution method for multicast traffic is complex and may not be implemented (see [RFC7390]).
保護された接続を介して、HTTP要求をHCプロキシに送信できます。ただし、CoAPへの安全な接続マッピングが常に存在するとは限りません。たとえば、マルチキャストトラフィックの安全な配布方法は複雑で、実装されない場合があります（[RFC7390]を参照）。
An HC Proxy should implement rules for security context translations. For example, all 'https' unicast requests are translated to 'coaps' requests, or 'https' requests are translated to unsecured 'coap' requests. Another rule could specify the security policy and parameters used for Datagram Transport Layer Security (DTLS) sessions [RFC7925]. Such rules will largely depend on the application and network context in which the HC Proxy operates. These rules should be configurable.
HCプロキシは、セキュリティコンテキスト変換のルールを実装する必要があります。たとえば、すべての「https」ユニキャストリクエストは「coaps」リクエストに変換されるか、「https」リクエストは保護されていない「coap」リクエストに変換されます。別のルールでは、データグラムトランスポート層セキュリティ（DTLS）セッション[RFC7925]に使用されるセキュリティポリシーとパラメータを指定できます。このようなルールは、HCプロキシが動作するアプリケーションとネットワークコンテキストに大きく依存します。これらのルールは構成可能である必要があります。
It is RECOMMENDED that, by default, accessing a 'coaps' URI is only allowed from a corresponding 'https' URI.
デフォルトでは、 'coaps' URIへのアクセスは、対応する 'https' URIからのみ許可されることをお勧めします。
By default, an HC Proxy SHOULD reject any secured CoAP client request (i.e., one with a 'coaps' scheme) if there is no configured security policy mapping. This recommendation may be relaxed in case the destination network is believed to be secured by other means. Assuming that CoAP nodes are isolated behind a firewall as in the HC Proxy deployment shown in Figure 1, the HC Proxy may be configured to translate the incoming HTTPS request using plain CoAP (NoSec mode).
デフォルトで、HCプロキシは、セキュリティポリシーマッピングが構成されていない場合、セキュリティ保護されたCoAPクライアント要求（「coaps」スキームを使用した要求）を拒否する必要があります（SHOULD）。宛先ネットワークが他の手段で保護されていると考えられる場合、この推奨は緩和される場合があります。図1に示すHCプロキシの配置のように、CoAPノードがファイアウォールの背後に隔離されていると仮定すると、HCプロキシは、プレーンCoAP（NoSecモード）を使用して着信HTTPS要求を変換するように構成できます。
The following risks related to the URI mapping described in Section 5 and its use by an HC Proxy have been identified:
セクション5で説明されているURIマッピングとHCプロキシによるその使用に関連する次のリスクが確認されています。
DoS attack on the constrained/CoAP network. Mitigation: by default, deny any Target CoAP URI whose authority is (or maps to) a multicast address. Then explicitly whitelist multicast resources/authorities that are allowed to be dereferenced. See also Section 8.4.
制約のある/ CoAPネットワークに対するDoS攻撃。軽減策：既定では、権限がマルチキャストアドレスである（またはマルチキャストアドレスにマップされている）ターゲットCoAP URIをすべて拒否します。次に、逆参照が許可されているマルチキャストリソース/権限を明示的にホワイトリストに登録します。セクション8.4も参照してください。
Leaking information on the constrained/CoAP network resources and topology. Mitigation: by default, deny any Target CoAP URI (especially "/.well-known/core" is a resource to be protected), and then explicitly whitelist resources that are allowed to be seen by clients outside the constrained network.
制約のある/ CoAPネットワークリソースとトポロジに関する情報の漏洩。軽減策：デフォルトでは、すべてのターゲットCoAP URI（特に「/.well-known/core」は保護されるリソースです）を拒否し、制約されたネットワークの外部のクライアントによる参照を許可されているリソースを明示的にホワイトリストに登録します。
The CoAP target resource is totally transparent from outside the constrained network. Mitigation: implement an HTTPS-only interface, which makes the Target CoAP URI totally opaque to a passive attacker outside the constrained network.
CoAPターゲットリソースは、制約されたネットワークの外部から完全に透過的です。軽減策：HTTPSのみのインターフェイスを実装します。これにより、ターゲットCoAP URIは、制約されたネットワーク外の受動的な攻撃者に対して完全に不透明になります。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、DOI 10.17487 / RFC3986、2005年1月、<http：/ /www.rfc-editor.org/info/rfc3986>。
[RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, DOI 10.17487/RFC4279, December 2005, <http://www.rfc-editor.org/info/rfc4279>.
[RFC4279] Eronen、P.、Ed。およびH. Tschofenig編、「トランスポート層セキュリティ（TLS）の事前共有鍵暗号」、RFC 4279、DOI 10.17487 / RFC4279、2005年12月、<http://www.rfc-editor.org/info/rfc4279 >。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234]クロッカー、D。、エド。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<http://www.rfc-editor.org/info/rfc5234>。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、DOI 10.17487 / RFC5246、2008年8月、<http://www.rfc-editor.org/info / rfc5246>。
[RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, "URI Template", RFC 6570, DOI 10.17487/RFC6570, March 2012, <http://www.rfc-editor.org/info/rfc6570>.
[RFC6570]グレゴリオ、J。、フィールディング、R。、ハドリー、M。、ノッティンガム、M。、およびD.オーチャード、「URIテンプレート」、RFC 6570、DOI 10.17487 / RFC6570、2012年3月、<http：// www .rfc-editor.org / info / rfc6570>。
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, <http://www.rfc-editor.org/info/rfc6690>.
[RFC6690] Shelby、Z。、「Constrained RESTful Environments（CoRE）Link Format」、RFC 6690、DOI 10.17487 / RFC6690、2012年8月、<http://www.rfc-editor.org/info/rfc6690>。
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.
[RFC7230]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Message Syntax and Routing」、RFC 7230、DOI 10.17487 / RFC7230、2014年6月、<http://www.rfc-editor.org/info/ rfc7230>。
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <http://www.rfc-editor.org/info/rfc7231>.
[RFC7231]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Semantics and Content」、RFC 7231、DOI 10.17487 / RFC7231、2014年6月、<http://www.rfc-editor.org/info/rfc7231 >。
[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", RFC 7232, DOI 10.17487/RFC7232, June 2014, <http://www.rfc-editor.org/info/rfc7232>.
[RFC7232]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Conditional Requests」、RFC 7232、DOI 10.17487 / RFC7232、2014年6月、<http://www.rfc-editor.org/info/rfc7232> 。
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, DOI 10.17487/RFC7235, June 2014, <http://www.rfc-editor.org/info/rfc7235>.
[RFC7235]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Authentication」、RFC 7235、DOI 10.17487 / RFC7235、2014年6月、<http://www.rfc-editor.org/info/rfc7235>。
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <http://www.rfc-editor.org/info/rfc7252>.
[RFC7252] Shelby、Z.、Hartke、K。、およびC. Bormann、「The Constrained Application Protocol（CoAP）」、RFC 7252、DOI 10.17487 / RFC7252、2014年6月、<http：//www.rfc-editor。 org / info / rfc7252>。
[RFC7641] Hartke, K., "Observing Resources in the Constrained Application Protocol (CoAP)", RFC 7641, DOI 10.17487/RFC7641, September 2015, <http://www.rfc-editor.org/info/rfc7641>.
[RFC7641] Hartke、K。、「Observing Resources in the Constrained Application Protocol（CoAP）」、RFC 7641、DOI 10.17487 / RFC7641、2015年9月、<http://www.rfc-editor.org/info/rfc7641>。
[RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in the Constrained Application Protocol (CoAP)", RFC 7959, DOI 10.17487/RFC7959, August 2016, <http://www.rfc-editor.org/info/rfc7959>.
[RFC7959] Bormann、C.およびZ. Shelby、Ed。、「Block-Wise Transfers in the Constrained Application Protocol（CoAP）」、RFC 7959、DOI 10.17487 / RFC7959、2016年8月、<http：//www.rfc- editor.org/info/rfc7959>。
[CoRE-JSON-CBOR] Li, K., Rahman, A., and C. Bormann, "Representing CoRE Formats in JSON and CBOR", Work in Progress, draft-ietf-core-links-json-06, July 2016.
[CoRE-JSON-CBOR] Li、K.、Rahman、A.、C。Bormann、「Representing CoRE Formats in JSON and CBOR」、Work in Progress、draft-ietf-core-links-json-06、July 2016 。
[CoRE-RD] Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE Resource Directory", Work in Progress, draft-ietf-core-resource-directory-09, October 2016.
[CoRE-RD]シェルビー、Z。、コスター、M。、ボルマン、C。、およびP.ストク、「CoRE Resource Directory」、Work in Progress、draft-ietf-core-resource-directory-09、2016年10月。
[Fielding] Fielding, R., "Architectural Styles and the Design of Network-based Software Architectures", PhD Dissertation, University of California, Irvine, ISBN 0-599-87118-0, 2000.
[Fielding] Fielding、R。、「Architectural Styles and the Design of Network-based Software Architectures」、PhD Dissertation、University of California、Irvine、ISBN 0-599-87118-0、2000。
[OpenSSL] The OpenSSL Project, , "ca - sample minimal CA application", 2000-2016, <https://www.openssl.org/docs/manmaster/man1/ca.html>.
[OpenSSL] OpenSSLプロジェクト、「ca-サンプル最小CAアプリケーション」、2000-2016、<https://www.openssl.org/docs/manmaster/man1/ca.html>。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, DOI 10.17487/RFC2616, June 1999, <http://www.rfc-editor.org/info/rfc2616>.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「Hypertext Transfer Protocol-HTTP / 1.1」 、RFC 2616、DOI 10.17487 / RFC2616、1999年6月、<http://www.rfc-editor.org/info/rfc2616>。
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, DOI 10.17487/RFC2663, August 1999, <http://www.rfc-editor.org/info/rfc2663>.
[RFC2663] Srisuresh、P。およびM. Holdrege、「IPネットワークアドレス変換（NAT）の用語と考慮事項」、RFC 2663、DOI 10.17487 / RFC2663、1999年8月、<http://www.rfc-editor.org/info / rfc2663>。
[RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web Replication and Caching Taxonomy", RFC 3040, DOI 10.17487/RFC3040, January 2001, <http://www.rfc-editor.org/info/rfc3040>.
[RFC3040] Cooper、I.、Melve、I。、およびG. Tomlinson、「インターネットWebレプリケーションおよびキャッシング分類法」、RFC 3040、DOI 10.17487 / RFC3040、2001年1月、<http://www.rfc-editor.org / info / rfc3040>。
[RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, DOI 10.17487/RFC4732, December 2006, <http://www.rfc-editor.org/info/rfc4732>.
[RFC4732] Handley、M.、Ed。、Rescorla、E.、Ed。、およびIAB、「インターネットサービス拒否の考慮事項」、RFC 4732、DOI 10.17487 / RFC4732、2006年12月、<http：// www。 rfc-editor.org/info/rfc4732>。
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, DOI 10.17487/RFC6454, December 2011, <http://www.rfc-editor.org/info/rfc6454>.
[RFC6454] Barth、A。、「The Web Origin Concept」、RFC 6454、DOI 10.17487 / RFC6454、2011年12月、<http://www.rfc-editor.org/info/rfc6454>。
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013, <http://www.rfc-editor.org/info/rfc7049>.
[RFC7049] Bormann、C。およびP. Hoffman、「簡潔なバイナリオブジェクト表現（CBOR）」、RFC 7049、DOI 10.17487 / RFC7049、2013年10月、<http://www.rfc-editor.org/info/rfc7049> 。
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, <http://www.rfc-editor.org/info/rfc7228>.
[RFC7228] Bormann、C.、Ersue、M.、and A. Keranen、 "Terminology for Constrained-Node Networks"、RFC 7228、DOI 10.17487 / RFC7228、May 2014、<http://www.rfc-editor.org / info / rfc7228>。
[RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for the Constrained Application Protocol (CoAP)", RFC 7390, DOI 10.17487/RFC7390, October 2014, <http://www.rfc-editor.org/info/rfc7390>.
[RFC7390]ラーマン、A。、エド。 E. Dijk編、「制約付きアプリケーションプロトコル（CoAP）のグループ通信」、RFC 7390、DOI 10.17487 / RFC7390、2014年10月、<http://www.rfc-editor.org/info/rfc7390>。
[RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) Profiles for the Internet of Things", RFC 7925, DOI 10.17487/RFC7925, July 2016, <http://www.rfc-editor.org/info/rfc7925>.
[RFC7925] Tschofenig、H.、Ed。 T. Fossati、「モノのインターネットのためのトランスポート層セキュリティ（TLS）/データグラムトランスポート層セキュリティ（DTLS）プロファイル」、RFC 7925、DOI 10.17487 / RFC7925、2016年7月、<http：//www.rfc-editor。 org / info / rfc7925>。
[W3C.REC-html5-20141028] Hickson, I., Berjon, R., Faulkner, S., Leithead, T., Navara, E., O'Connor, E., and S. Pfeiffer, "HTML5", World Wide Web Consortium Recommendation REC-html5-20141028, October 2014, <http://www.w3.org/TR/2014/REC-html5-20141028>.
[W3C.REC-html5-20141028] Hickson、I.、Berjon、R.、Faulkner、S.、Leithead、T.、Navara、E.、O'Connor、E.、and S. Pfeiffer、 "HTML5"、 World Wide Web Consortium Recommendation REC-html5-20141028、2014年10月、<http://www.w3.org/TR/2014/REC-html5-20141028>。
#!/usr/bin/env python
import unittest import re
ユニットテストのインポート再インポート
class CoAPContentFormatRegistry(object): """Map an Internet media type (and optional inherent encoding) to a CoAP Content-Format. """ TEXT_PLAIN = 0 LINK_FORMAT = 40 XML = 41 OCTET_STREAM = 42 EXI = 47 JSON = 50 CBOR = 60 GROUP_JSON = 256
CoAPContentFormatRegistry（object）： "" "インターネットメディアタイプ（およびオプションの固有のエンコーディング）をCoAP Content-Formatにマップします。" "" TEXT_PLAIN = 0 LINK_FORMAT = 40 XML = 41 OCTET_STREAM = 42 EXI = 47 JSON = 50 CBOR = 60 GROUP_JSON = 256
# http://www.iana.org/assignments/core-parameters
# as of 2016/10/24.
LOOKUP_TABLE = {
("text/plain;charset=utf-8", None): TEXT_PLAIN,
("application/link-format", None): LINK_FORMAT,
("application/xml", None): XML,
("application/octet-stream", None): OCTET_STREAM,
("application/exi", None): EXI,
("application/json", None): JSON,
("application/cbor", None): CBOR,
("application/coap-group+json", "utf-8"): GROUP_JSON,
}
def lookup(self, media_type, encoding): """Return the CoAP Content-Format matching the supplied media type (and optional encoding), or None if no match can be found.""" return CoAPContentFormatRegistry.LOOKUP_TABLE.get( (media_type, encoding), None)
def lookup（self、media_type、encoding）： "" "指定されたメディアタイプ（およびオプションのエンコーディング）に一致するCoAPコンテンツ形式を返すか、一致が見つからない場合はNone。" "" return CoAPContentFormatRegistry.LOOKUP_TABLE.get（（ media_type、encoding）、None）
class LooseMediaTypeMapper(object):
# Order matters in this table: more specific types have higher rank
# compared to less specific types.
# This code only performs a shallow validation of acceptable
# characters and assumes overall validation of the media type and
# subtype has been done beforehand.
LOOKUP_TABLE = [
(re.compile("application/.+\+xml$"), "application/xml"),
(re.compile("application/.+\+json$"), "application/json"),
(re.compile("application/.+\+cbor$"), "application/cbor"),
(re.compile("text/xml$"), "application/xml"),
(re.compile("text/[a-z\.\-\+]+$"), "text/plain;charset=utf-8"),
(re.compile("[a-z]+/[a-z\.\-\+]+$"), "application/octet-stream")
]
def lookup(self, media_type): """Return the best loose media type match available using the contents of LOOKUP_TABLE.""" for entry in LooseMediaTypeMapper.LOOKUP_TABLE: if entry[0].match(media_type) is not None: return entry[1] return None
def lookup（self、media_type）： "" "LooseMediaTypeMapper.LOOKUP_TABLEのエントリのLOOKUP_TABLE。" ""のコンテンツを使用して、利用可能な最良のメディアタイプの一致を返します：entry [0] .match（media_type）がNoneでない場合：return entry [1] return None
def mt2cf(media_type, encoding=None, coap_cf_registry=CoAPContentFormatRegistry(), loose_mapper=None): """Return a CoAP Content-Format given an Internet media type and its optional encoding. The current (as of 2016/10/24) "CoAP Content-Formats" registry is supplied by default. An optional 'loose-mapping' implementation can be supplied by the caller.""" assert media_type is not None assert coap_cf_registry is not None
def mt2cf（media_type、encoding = None、coap_cf_registry = CoAPContentFormatRegistry()、loose_mapper = None）： "" "インターネットメディアタイプとそのオプションのエンコーディングを指定してCoAPコンテンツ形式を返します。現在（2016/10/24現在） 「CoAP Content-Formats」レジストリがデフォルトで提供されています。オプションの「ルーズマッピング」実装を呼び出し元から提供できます。 "" "assert media_type is not None assert coap_cf_registry is not None
# Lookup the "CoAP Content-Formats" registry content_format = coap_cf_registry.lookup(media_type, encoding)
＃「CoAP Content-Formats」レジストリを検索content_format = coap_cf_registry.lookup（media_type、encoding）
# If an exact match is not found and a loose mapper has been # supplied, try to use it to get a media type with which to # retry the "CoAP Content-Formats" registry lookup. if content_format is None and loose_mapper is not None: content_format = coap_cf_registry.lookup( loose_mapper.lookup(media_type), encoding)
＃完全一致が見つからず、ルーズマッパーが＃提供されている場合は、それを使用して＃ "CoAP Content-Formats"レジストリルックアップを再試行するメディアタイプを取得してください。 content_formatがNoneで、loose_mapperがNoneでない場合：content_format = coap_cf_registry.lookup（loose_mapper.lookup（media_type）、encoding）
return content_format
content_formatを返す
class TestMT2CF(unittest.TestCase):
クラスTestMT2CF（unittest.TestCase）：
def testMissingContentType(self):
with self.assertRaises(AssertionError):
mt2cf(None)
def testMissingContentFormatRegistry(self):
with self.assertRaises(AssertionError):
mt2cf(None, coap_cf_registry=None)
def testTextPlain(self):
self.assertEqual(mt2cf("text/plain;charset=utf-8"),
CoAPContentFormatRegistry.TEXT_PLAIN)
def testLinkFormat(self):
self.assertEqual(mt2cf("application/link-format"),
CoAPContentFormatRegistry.LINK_FORMAT)
def testXML(self):
self.assertEqual(mt2cf("application/xml"),
CoAPContentFormatRegistry.XML)
def testOctetStream(self):
self.assertEqual(mt2cf("application/octet-stream"),
CoAPContentFormatRegistry.OCTET_STREAM)
def testEXI(self):
self.assertEqual(mt2cf("application/exi"),
CoAPContentFormatRegistry.EXI)
def testJSON(self):
self.assertEqual(mt2cf("application/json"),
CoAPContentFormatRegistry.JSON)
def testCBOR(self):
self.assertEqual(mt2cf("application/cbor"),
CoAPContentFormatRegistry.CBOR)
def testCoAPGroupJSON(self):
self.assertEqual(mt2cf("application/coap-group+json",
"utf-8"),
CoAPContentFormatRegistry.GROUP_JSON)
def testUnknownMediaType(self):
self.assertFalse(mt2cf("unknown/media-type"))
def testLooseXML1(self):
self.assertEqual(
mt2cf(
"application/somesubtype+xml",
loose_mapper=LooseMediaTypeMapper()),
CoAPContentFormatRegistry.XML)
def testLooseXML2(self): self.assertEqual( mt2cf( "text/xml", loose_mapper=LooseMediaTypeMapper()), CoAPContentFormatRegistry.XML)
def testLooseXML2（self）：self.assertEqual（mt2cf（ "text / xml"、loose_mapper = LooseMediaTypeMapper()）、CoAPContentFormatRegistry.XML）
def testLooseJSON(self):
self.assertEqual(
mt2cf(
"application/somesubtype+json",
loose_mapper=LooseMediaTypeMapper()),
CoAPContentFormatRegistry.JSON)
def testLooseCBOR(self):
self.assertEqual(
mt2cf(
"application/somesubtype+cbor",
loose_mapper=LooseMediaTypeMapper()),
CoAPContentFormatRegistry.CBOR)
def testLooseText(self): self.assertEqual( mt2cf( "text/somesubtype", loose_mapper=LooseMediaTypeMapper()), CoAPContentFormatRegistry.TEXT_PLAIN)
def testLooseText（self）：self.assertEqual（mt2cf（ "text / somesubtype"、loose_mapper = LooseMediaTypeMapper()）、CoAPContentFormatRegistry.TEXT_PLAIN）
def testLooseUnknown(self):
self.assertEqual(
mt2cf(
"application/somesubtype-of-some-sort+format",
loose_mapper=LooseMediaTypeMapper()),
CoAPContentFormatRegistry.OCTET_STREAM)
def testLooseInvalidStartsWithNonAlpha(self):
self.assertFalse(
mt2cf(
" application/somesubtype",
loose_mapper=LooseMediaTypeMapper()))
def testLooseInvalidEndsWithUnexpectedChar(self):
self.assertFalse(
mt2cf(
"application/somesubtype ",
loose_mapper=LooseMediaTypeMapper()))
def testLooseInvalidUnexpectedCharInTheMiddle(self):
self.assertFalse(
mt2cf(
"application /somesubtype",
loose_mapper=LooseMediaTypeMapper()))
def testLooseInvalidNoSubType1(self): self.assertFalse( mt2cf( "application", loose_mapper=LooseMediaTypeMapper()))
def testLooseInvalidNoSubType1（self）：self.assertFalse（mt2cf（ "application"、loose_mapper = LooseMediaTypeMapper()））
def testLooseInvalidNoSubType2(self):
self.assertFalse(
mt2cf(
"application/",
loose_mapper=LooseMediaTypeMapper()))
if __name__ == "__main__":
unittest.main(verbosity=2)
Acknowledgments
謝辞
An initial version of Table 2 in Section 7 has been provided in revision -05 of the CoRE CoAP I-D. Special thanks to Peter van der Stok for countless comments and discussions on this document that contributed to its current structure and text.
セクション7の表2の初期バージョンは、CoRE CoAP I-Dのリビジョン-05で提供されています。現在の構造とテキストに貢献したこのドキュメントに関する無数のコメントと議論をしてくれたPeter van der Stokに特に感謝します。
Thanks to Abhijan Bhattacharyya, Alexey Melnikov, Brian Frank, Carsten Bormann, Christian Amsuess, Christian Groves, Cullen Jennings, Dorothy Gellert, Francesco Corazza, Francis Dupont, Hannes Tschofenig, Jaime Jimenez, Kathleen Moriarty, Kepeng Li, Kerry Lynn, Klaus Hartke, Larry Masinter, Linyi Tian, Michele Rossi, Michele Zorzi, Nicola Bui, Peter Saint-Andre, Sean Leonard, Spencer Dawkins, Stephen Farrell, Suresh Krishnan, and Zach Shelby for helpful comments and discussions that have shaped the document.
アビジャン・バタチャリヤ、アレクセイ・メルニコフ、ブライアン・フランク、カルステン・ボルマン、クリスチャン・アムスース、クリスチャン・グローブス、カレン・ジェニングス、ドロシー・ゲラート、フランチェスコ・コラッツァ、フランシス・デュポン、ハンネス・ツコフェニグ、ハイメ・ジメネス、キャスリーン・モリアーティ、ケペン・リー、ケリー・リー、ケリー・リー、ケリー・リードキュメントを形成した有益なコメントと議論については、ラリーマシンター、リンイーティアン、ミケーレロッシ、ミケーレゾルジ、ニコラブイ、ピーターサンタンドレ、ショーンレナード、スペンサードーキンス、スティーブンファレル、スレッシュクリシュナン、ザックシェルビー。
The research leading to these results has received funding from the European Community's Seventh Framework Programme [FP7/2007-2013] under grant agreement n.251557.
これらの結果につながる研究は、助成金契約n.251557に基づいて、欧州共同体の第7次フレームワークプログラム[FP7 / 2007-2013]から資金を受け取りました。
Authors' Addresses
著者のアドレス
Angelo P. Castellani University of Padova Via Gradenigo 6/B Padova 35131 Italy
アンジェロP.カステラーニパドヴァ大学Via Gradenigo 6 / B Padua 35131イタリア
Email: angelo@castellani.net
Salvatore Loreto Ericsson Hirsalantie 11 Jorvas 02420 Finland
Salvatore Loreto Ericsson Hirsalantie 11 Jorvas 02420フィンランド
Email: salvatore.loreto@ericsson.com
Akbar Rahman InterDigital Communications, LLC 1000 Sherbrooke Street West Montreal H3A 3G4 Canada
Akbar Rahman InterDigital Communications、LLC 1000 Sherbrooke Street West Montreal H3A 3G4 Canada
Phone: +1 514 585 0761
Email: Akbar.Rahman@InterDigital.com
Thomas Fossati Nokia 3 Ely Road Milton, Cambridge CB24 6DD United Kingdom
Thomas Fossati Nokia 3 Ely Roadミルトン、ケンブリッジCB24 6DDイギリス
Email: thomas.fossati@nokia.com
Esko Dijk Philips Lighting High Tech Campus 7 Eindhoven 5656 AE The Netherlands
Esko Dijkフィリップスライティングハイテクキャンパス7アイントホーフェン5656 AEオランダ
Email: esko.dijk@philips.com