[要約] RFC 7252は、制約のあるアプリケーションプロトコル（CoAP）に関する仕様であり、IoTデバイス間の通信を効率的に行うために設計されています。CoAPは、低帯域幅や制約されたリソースで動作するデバイスに適しており、軽量な通信プロトコルとして使用されます。
Internet Engineering Task Force (IETF) Z. Shelby
Request for Comments: 7252 ARM
Category: Standards Track K. Hartke
ISSN: 2070-1721 C. Bormann
Universitaet Bremen TZI
June 2014
The Constrained Application Protocol (CoAP)
制約付きアプリケーションプロトコル（CoAP）
Abstract
概要
The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine-to-machine (M2M) applications such as smart energy and building automation.
制約付きアプリケーションプロトコル（CoAP）は、制約付きノードおよび制約付き（低電力、損失の多い）ネットワークで使用するための専用のWeb転送プロトコルです。ノードには多くの場合、少量のROMとRAMを備えた8ビットマイクロコントローラーが搭載されていますが、IPv6 over Low-Power Wireless Personal Area Networks（6LoWPANs）などの制約のあるネットワークでは、多くの場合、パケットエラー率が高く、標準的なスループットは数十kbit / sです。プロトコルは、スマートエネルギーやビルディングオートメーションなどのマシンツーマシン（M2M）アプリケーション用に設計されています。
CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments.
CoAPは、アプリケーションエンドポイント間の要求/応答対話モデルを提供し、サービスとリソースの組み込み検出をサポートし、URIやインターネットメディアタイプなどのWebの主要な概念を含みます。 CoAPは、マルチキャストサポート、非常に低いオーバーヘッド、制約された環境でのシンプルさなどの特殊な要件を満たしながら、Webと統合するためにHTTPと簡単にインターフェイスするように設計されています。
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 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション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/rfc7252.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7252で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Features . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
2. Constrained Application Protocol . . . . . . . . . . . . . . 10
2.1. Messaging Model . . . . . . . . . . . . . . . . . . . . . 11
2.2. Request/Response Model . . . . . . . . . . . . . . . . . 12
2.3. Intermediaries and Caching . . . . . . . . . . . . . . . 15
2.4. Resource Discovery . . . . . . . . . . . . . . . . . . . 15
3. Message Format . . . . . . . . . . . . . . . . . . . . . . . 15
3.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 17
3.2. Option Value Formats . . . . . . . . . . . . . . . . . . 19
4. Message Transmission . . . . . . . . . . . . . . . . . . . . 20
4.1. Messages and Endpoints . . . . . . . . . . . . . . . . . 20
4.2. Messages Transmitted Reliably . . . . . . . . . . . . . . 21
4.3. Messages Transmitted without Reliability . . . . . . . . 23
4.4. Message Correlation . . . . . . . . . . . . . . . . . . . 24
4.5. Message Deduplication . . . . . . . . . . . . . . . . . . 24
4.6. Message Size . . . . . . . . . . . . . . . . . . . . . . 25
4.7. Congestion Control . . . . . . . . . . . . . . . . . . . 26
4.8. Transmission Parameters . . . . . . . . . . . . . . . . . 27
4.8.1. Changing the Parameters . . . . . . . . . . . . . . . 27
4.8.2. Time Values Derived from Transmission Parameters . . 28
5. Request/Response Semantics . . . . . . . . . . . . . . . . . 31
5.1. Requests . . . . . . . . . . . . . . . . . . . . . . . . 31
5.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 31
5.2.1. Piggybacked . . . . . . . . . . . . . . . . . . . . . 33
5.2.2. Separate . . . . . . . . . . . . . . . . . . . . . . 33
5.2.3. Non-confirmable . . . . . . . . . . . . . . . . . . . 34
5.3. Request/Response Matching . . . . . . . . . . . . . . . . 34
5.3.1. Token . . . . . . . . . . . . . . . . . . . . . . . . 34
5.3.2. Request/Response Matching Rules . . . . . . . . . . . 35
5.4. Options . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.4.1. Critical/Elective . . . . . . . . . . . . . . . . . . 37
5.4.2. Proxy Unsafe or Safe-to-Forward and NoCacheKey . . . 38
5.4.3. Length . . . . . . . . . . . . . . . . . . . . . . . 38
5.4.4. Default Values . . . . . . . . . . . . . . . . . . . 38
5.4.5. Repeatable Options . . . . . . . . . . . . . . . . . 39
5.4.6. Option Numbers . . . . . . . . . . . . . . . . . . . 39
5.5. Payloads and Representations . . . . . . . . . . . . . . 40
5.5.1. Representation . . . . . . . . . . . . . . . . . . . 40
5.5.2. Diagnostic Payload . . . . . . . . . . . . . . . . . 41
5.5.3. Selected Representation . . . . . . . . . . . . . . . 41
5.5.4. Content Negotiation . . . . . . . . . . . . . . . . . 41
5.6. Caching . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.6.1. Freshness Model . . . . . . . . . . . . . . . . . . . 43
5.6.2. Validation Model . . . . . . . . . . . . . . . . . . 43
5.7. Proxying . . . . . . . . . . . . . . . . . . . . . . . . 44
5.7.1. Proxy Operation . . . . . . . . . . . . . . . . . . . 44
5.7.2. Forward-Proxies . . . . . . . . . . . . . . . . . . . 46
5.7.3. Reverse-Proxies . . . . . . . . . . . . . . . . . . . 46
5.8. Method Definitions . . . . . . . . . . . . . . . . . . . 47
5.8.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.8.2. POST . . . . . . . . . . . . . . . . . . . . . . . . 47
5.8.3. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.8.4. DELETE . . . . . . . . . . . . . . . . . . . . . . . 48
5.9. Response Code Definitions . . . . . . . . . . . . . . . . 48
5.9.1. Success 2.xx . . . . . . . . . . . . . . . . . . . . 48
5.9.2. Client Error 4.xx . . . . . . . . . . . . . . . . . . 50
5.9.3. Server Error 5.xx . . . . . . . . . . . . . . . . . . 51
5.10. Option Definitions . . . . . . . . . . . . . . . . . . . 52
5.10.1. Uri-Host, Uri-Port, Uri-Path, and Uri-Query . . . . 53
5.10.2. Proxy-Uri and Proxy-Scheme . . . . . . . . . . . . . 54
5.10.3. Content-Format . . . . . . . . . . . . . . . . . . . 55
5.10.4. Accept . . . . . . . . . . . . . . . . . . . . . . . 55
5.10.5. Max-Age . . . . . . . . . . . . . . . . . . . . . . 55
5.10.6. ETag . . . . . . . . . . . . . . . . . . . . . . . . 56
5.10.7. Location-Path and Location-Query . . . . . . . . . . 57
5.10.8. Conditional Request Options . . . . . . . . . . . . 57
5.10.9. Size1 Option . . . . . . . . . . . . . . . . . . . . 59
6. CoAP URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.1. coap URI Scheme . . . . . . . . . . . . . . . . . . . . . 59
6.2. coaps URI Scheme . . . . . . . . . . . . . . . . . . . . 60
6.3. Normalization and Comparison Rules . . . . . . . . . . . 61
6.4. Decomposing URIs into Options . . . . . . . . . . . . . . 61
6.5. Composing URIs from Options . . . . . . . . . . . . . . . 62
7. Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 64
7.1. Service Discovery . . . . . . . . . . . . . . . . . . . . 64
7.2. Resource Discovery . . . . . . . . . . . . . . . . . . . 64
7.2.1. 'ct' Attribute . . . . . . . . . . . . . . . . . . . 64
8. Multicast CoAP . . . . . . . . . . . . . . . . . . . . . . . 65
8.1. Messaging Layer . . . . . . . . . . . . . . . . . . . . . 65
8.2. Request/Response Layer . . . . . . . . . . . . . . . . . 66
8.2.1. Caching . . . . . . . . . . . . . . . . . . . . . . . 67
8.2.2. Proxying . . . . . . . . . . . . . . . . . . . . . . 67
9. Securing CoAP . . . . . . . . . . . . . . . . . . . . . . . . 68
9.1. DTLS-Secured CoAP . . . . . . . . . . . . . . . . . . . . 69
9.1.1. Messaging Layer . . . . . . . . . . . . . . . . . . . 70
9.1.2. Request/Response Layer . . . . . . . . . . . . . . . 71
9.1.3. Endpoint Identity . . . . . . . . . . . . . . . . . . 71
10. Cross-Protocol Proxying between CoAP and HTTP . . . . . . . . 74
10.1. CoAP-HTTP Proxying . . . . . . . . . . . . . . . . . . . 75
10.1.1. GET . . . . . . . . . . . . . . . . . . . . . . . . 76
10.1.2. PUT . . . . . . . . . . . . . . . . . . . . . . . . 77
10.1.3. DELETE . . . . . . . . . . . . . . . . . . . . . . . 77
10.1.4. POST . . . . . . . . . . . . . . . . . . . . . . . . 77
10.2. HTTP-CoAP Proxying . . . . . . . . . . . . . . . . . . . 77
10.2.1. OPTIONS and TRACE . . . . . . . . . . . . . . . . . 78
10.2.2. GET . . . . . . . . . . . . . . . . . . . . . . . . 78
10.2.3. HEAD . . . . . . . . . . . . . . . . . . . . . . . . 79
10.2.4. POST . . . . . . . . . . . . . . . . . . . . . . . . 79
10.2.5. PUT . . . . . . . . . . . . . . . . . . . . . . . . 79
10.2.6. DELETE . . . . . . . . . . . . . . . . . . . . . . . 80
10.2.7. CONNECT . . . . . . . . . . . . . . . . . . . . . . 80
11. Security Considerations . . . . . . . . . . . . . . . . . . . 80
11.1. Parsing the Protocol and Processing URIs . . . . . . . . 80
11.2. Proxying and Caching . . . . . . . . . . . . . . . . . . 81
11.3. Risk of Amplification . . . . . . . . . . . . . . . . . 81
11.4. IP Address Spoofing Attacks . . . . . . . . . . . . . . 83
11.5. Cross-Protocol Attacks . . . . . . . . . . . . . . . . . 84
11.6. Constrained-Node Considerations . . . . . . . . . . . . 86
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 86
12.1. CoAP Code Registries . . . . . . . . . . . . . . . . . . 86
12.1.1. Method Codes . . . . . . . . . . . . . . . . . . . . 87
12.1.2. Response Codes . . . . . . . . . . . . . . . . . . . 88
12.2. CoAP Option Numbers Registry . . . . . . . . . . . . . . 89
12.3. CoAP Content-Formats Registry . . . . . . . . . . . . . 91
12.4. URI Scheme Registration . . . . . . . . . . . . . . . . 93
12.5. Secure URI Scheme Registration . . . . . . . . . . . . . 94
12.6. Service Name and Port Number Registration . . . . . . . 95
12.7. Secure Service Name and Port Number Registration . . . . 96
12.8. Multicast Address Registration . . . . . . . . . . . . . 97
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 97
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 98
14.1. Normative References . . . . . . . . . . . . . . . . . . 98
14.2. Informative References . . . . . . . . . . . . . . . . . 100
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 104
Appendix B. URI Examples . . . . . . . . . . . . . . . . . . . . 110
The use of web services (web APIs) on the Internet has become ubiquitous in most applications and depends on the fundamental Representational State Transfer [REST] architecture of the Web.
インターネットでのWebサービス（Web API）の使用は、ほとんどのアプリケーションでユビキタスになり、Webの基本的な表現状態転送[REST]アーキテクチャに依存しています。
The work on Constrained RESTful Environments (CoRE) aims at realizing the REST architecture in a suitable form for the most constrained nodes (e.g., 8-bit microcontrollers with limited RAM and ROM) and networks (e.g., 6LoWPAN, [RFC4944]). Constrained networks such as 6LoWPAN support the fragmentation of IPv6 packets into small link-layer frames; however, this causes significant reduction in packet delivery probability. One design goal of CoAP has been to keep message overhead small, thus limiting the need for fragmentation.
制約付きRESTful環境（CoRE）に関する作業は、最も制約のあるノード（たとえば、RAMとROMが制限された8ビットマイクロコントローラー）とネットワーク（たとえば、6LoWPAN、[RFC4944]）に適した形式でRESTアーキテクチャを実現することを目的としています。 6LoWPANなどの制約のあるネットワークは、IPv6パケットの小さなリンク層フレームへの断片化をサポートします。ただし、これによりパケット配信の確率が大幅に低下します。 CoAPの設計目標の1つは、メッセージのオーバーヘッドを小さく保つことで、フラグメンテーションの必要性を制限することでした。
One of the main goals of CoAP is to design a generic web protocol for the special requirements of this constrained environment, especially considering energy, building automation, and other machine-to-machine (M2M) applications. The goal of CoAP is not to blindly compress HTTP [RFC2616], but rather to realize a subset of REST common with HTTP but optimized for M2M applications. Although CoAP could be used for refashioning simple HTTP interfaces into a more compact protocol, more importantly it also offers features for M2M such as built-in discovery, multicast support, and asynchronous message exchanges.
CoAPの主な目標の1つは、特にエネルギー、ビルディングオートメーション、およびその他のマシンツーマシン（M2M）アプリケーションを考慮して、この制約された環境の特別な要件に対応する汎用Webプロトコルを設計することです。 CoAPの目標は、HTTP [RFC2616]を盲目的に圧縮することではなく、HTTPと共通であるがM2Mアプリケーション用に最適化されたRESTのサブセットを実現することです。 CoAPは、単純なHTTPインターフェイスをよりコンパクトなプロトコルに作り直すために使用できますが、さらに重要なことに、組み込みの検出、マルチキャストサポート、非同期メッセージ交換などのM2Mの機能も提供します。
This document specifies the Constrained Application Protocol (CoAP), which easily translates to HTTP for integration with the existing Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments and M2M applications.
このドキュメントでは、制約付きアプリケーションプロトコル（CoAP）を指定します。これは、マルチキャストサポート、非常に低いオーバーヘッド、制約された環境やM2Mアプリケーションの簡素化などの特殊な要件を満たしながら、既存のWebと統合するために簡単にHTTPに変換します。
CoAP has the following main features:
CoAPには次の主な機能があります。
o Web protocol fulfilling M2M requirements in constrained environments
o 制約のある環境でM2M要件を満たすWebプロトコル
o UDP [RFC0768] binding with optional reliability supporting unicast and multicast requests.
o UDP [RFC0768]バインディング。オプションで、ユニキャストおよびマルチキャスト要求をサポートする信頼性を備えています。
o Asynchronous message exchanges.
o 非同期メッセージ交換。
o Low header overhead and parsing complexity.
o 低いヘッダーオーバーヘッドと解析の複雑さ。
o URI and Content-type support.
o URIおよびコンテンツタイプのサポート。
o Simple proxy and caching capabilities.
o シンプルなプロキシとキャッシング機能。
o A stateless HTTP mapping, allowing proxies to be built providing access to CoAP resources via HTTP in a uniform way or for HTTP simple interfaces to be realized alternatively over CoAP.
o ステートレスHTTPマッピング。プロキシを構築して、HTTP経由でCoAPリソースへのアクセスを統一的に提供したり、HTTPシンプルインターフェイスを代替としてCoAPで実現したりできます。
o Security binding to Datagram Transport Layer Security (DTLS) [RFC6347].
o データグラムトランスポート層セキュリティ（DTLS）[RFC6347]へのセキュリティバインディング。
The key words "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] when they appear in ALL CAPS. These words may also appear in this document in lowercase, absent their normative meanings.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONAL "このドキュメントの[RFC2119]で説明されているように、すべて大文字で表記されていると解釈されます。これらの単語は、規範的な意味がなければ、このドキュメントでは小文字で表示される場合もあります。
This specification requires readers to be familiar with all the terms and concepts that are discussed in [RFC2616], including "resource", "representation", "cache", and "fresh". (Having been completed before the updated set of HTTP RFCs, RFC 7230 to RFC 7235, became available, this specification specifically references the predecessor version -- RFC 2616.) In addition, this specification defines the following terminology:
この仕様では、[RFC2616]で説明されている「リソース」、「表現」、「キャッシュ」、「フレッシュ」などのすべての用語と概念に精通している必要があります。 （更新されたHTTP RFCのセットであるRFC 7230からRFC 7235が利用可能になる前に完了しているため、この仕様は特に先行バージョンであるRFC 2616を参照しています。さらに、この仕様は次の用語を定義しています。
Endpoint An entity participating in the CoAP protocol. Colloquially, an endpoint lives on a "Node", although "Host" would be more consistent with Internet standards usage, and is further identified by transport-layer multiplexing information that can include a UDP port number and a security association (Section 4.1).
エンドポイントCoAPプロトコルに参加しているエンティティ。口語的には、エンドポイントは「ノード」上に存在しますが、「ホスト」はインターネット標準の使用法とより整合性が高く、UDPポート番号とセキュリティアソシエーションを含むトランスポート層多重化情報によってさらに識別されます（セクション4.1）。
Sender The originating endpoint of a message. When the aspect of identification of the specific sender is in focus, also "source endpoint".
送信者メッセージの発信エンドポイント。特定の送信者の識別の側面に焦点が当てられている場合は、「ソースエンドポイント」も。
Recipient The destination endpoint of a message. When the aspect of identification of the specific recipient is in focus, also "destination endpoint".
受信者メッセージの宛先エンドポイント。特定の受信者の識別の側面に焦点が当てられている場合は、「宛先エンドポイント」も。
Client The originating endpoint of a request; the destination endpoint of a response.
クライアント要求の発信元エンドポイント。応答の宛先エンドポイント。
Server The destination endpoint of a request; the originating endpoint of a response.
サーバーリクエストの宛先エンドポイント。応答の元のエンドポイント。
Origin Server The server on which a given resource resides or is to be created.
起点サーバー特定のリソースが存在するサーバー、または作成されるサーバー。
Intermediary A CoAP endpoint that acts both as a server and as a client towards an origin server (possibly via further intermediaries). A common form of an intermediary is a proxy; several classes of such proxies are discussed in this specification.
中間サーバー（場合によっては追加の中間サーバーを介して）として、サーバーとクライアントの両方としてオリジンサーバーに対するCoAPエンドポイント。仲介者の一般的な形式はプロキシです。この仕様では、このようなプロキシのいくつかのクラスについて説明します。
Proxy An intermediary that mainly is concerned with forwarding requests and relaying back responses, possibly performing caching, namespace translation, or protocol translation in the process. As opposed to intermediaries in the general sense, proxies generally do not implement specific application semantics. Based on the position in the overall structure of the request forwarding, there are two common forms of proxy: forward-proxy and reverse-proxy. In some cases, a single endpoint might act as an origin server, forward-proxy, or reverse-proxy, switching behavior based on the nature of each request.
プロキシ主に要求の転送と応答の中継に関係する仲介者であり、プロセスでキャッシング、名前空間変換、またはプロトコル変換を実行する可能性があります。一般的な意味での仲介者とは対照的に、プロキシは通常、特定のアプリケーションセマンティクスを実装しません。リクエスト転送の全体的な構造における位置に基づいて、プロキシには2つの一般的な形式があります。フォワードプロキシとリバースプロキシです。場合によっては、1つのエンドポイントがオリジンサーバー、フォワードプロキシ、またはリバースプロキシとして機能し、各リクエストの性質に基づいて動作を切り替えることがあります。
Forward-Proxy An endpoint selected by a client, usually via local configuration rules, to perform requests on behalf of the client, doing any necessary translations. Some translations are minimal, such as for proxy requests for "coap" URIs, whereas other requests might require translation to and from entirely different application-layer protocols.
Forward-Proxyクライアントに代わって要求を実行し、必要な変換を行うために、通常はローカル構成ルールを介してクライアントによって選択されたエンドポイント。 「coap」URIのプロキシリクエストなど、一部の変換は最小限ですが、他のリクエストでは、完全に異なるアプリケーション層プロトコルとの間の変換が必要になる場合があります。
Reverse-Proxy An endpoint that stands in for one or more other server(s) and satisfies requests on behalf of these, doing any necessary translations. Unlike a forward-proxy, the client may not be aware that it is communicating with a reverse-proxy; a reverse-proxy receives requests as if it were the origin server for the target resource.
リバースプロキシ1つまたは複数の他のサーバーの代わりになり、これらに代わって要求を満たし、必要な変換を行うエンドポイント。フォワードプロキシとは異なり、クライアントはリバースプロキシと通信していることに気付かない場合があります。リバースプロキシは、ターゲットリソースのオリジンサーバーであるかのように要求を受信します。
CoAP-to-CoAP Proxy A proxy that maps from a CoAP request to a CoAP request, i.e., uses the CoAP protocol both on the server and the client side. Contrast to cross-proxy.
CoAP-to-CoAPプロキシCoAP要求からCoAP要求にマップするプロキシ。つまり、サーバー側とクライアント側の両方でCoAPプロトコルを使用します。クロスプロキシと対比。
Cross-Proxy A cross-protocol proxy, or "cross-proxy" for short, is a proxy that translates between different protocols, such as a CoAP-to-HTTP proxy or an HTTP-to-CoAP proxy. While this specification makes very specific demands of CoAP-to-CoAP proxies, there is more variation possible in cross-proxies.
クロスプロキシクロスプロトコルプロキシ、または略して「クロスプロキシ」は、CoAP-to-HTTPプロキシやHTTP-to-CoAPプロキシなど、異なるプロトコル間で変換するプロキシです。この仕様はCoAP-to-CoAPプロキシの非常に特定の要求を行いますが、クロスプロキシではより多くのバリエーションが可能です。
Confirmable Message Some messages require an acknowledgement. These messages are called "Confirmable". When no packets are lost, each Confirmable message elicits exactly one return message of type Acknowledgement or type Reset.
確認可能なメッセージ一部のメッセージには確認が必要です。これらのメッセージは「確認可能」と呼ばれます。パケットが失われない場合、各確認可能なメッセージは、タイプが確認またはタイプがリセットの戻りメッセージを1つだけ引き出します。
Non-confirmable Message Some other messages do not require an acknowledgement. This is particularly true for messages that are repeated regularly for application requirements, such as repeated readings from a sensor.
確認できないメッセージ他のいくつかのメッセージは確認を必要としません。これは、センサーからの繰り返し読み取りなど、アプリケーション要件のために定期的に繰り返されるメッセージに特に当てはまります。
Acknowledgement Message An Acknowledgement message acknowledges that a specific Confirmable message arrived. By itself, an Acknowledgement message does not indicate success or failure of any request encapsulated in the Confirmable message, but the Acknowledgement message may also carry a Piggybacked Response (see below).
確認メッセージ確認メッセージは、特定の確認可能なメッセージが到着したことを確認します。単独では、確認応答メッセージは確認可能メッセージにカプセル化された要求の成功または失敗を示しませんが、確認応答メッセージはPiggybacked応答を運ぶこともあります（下記参照）。
Reset Message A Reset message indicates that a specific message (Confirmable or Non-confirmable) was received, but some context is missing to properly process it. This condition is usually caused when the receiving node has rebooted and has forgotten some state that would be required to interpret the message. Provoking a Reset message (e.g., by sending an Empty Confirmable message) is also useful as an inexpensive check of the liveness of an endpoint ("CoAP ping").
リセットメッセージリセットメッセージは、特定のメッセージ（確認可能または確認不可能）を受信したが、適切に処理するために一部のコンテキストが欠落していることを示します。この状態は通常、受信ノードが再起動し、メッセージの解釈に必要ないくつかの状態を忘れたときに発生します。 （たとえば、Empty Confirmableメッセージを送信することによって）リセットメッセージを誘発することは、エンドポイントの活性の安価なチェック（「CoAP ping」）としても役立ちます。
Piggybacked Response A piggybacked Response is included right in a CoAP Acknowledgement (ACK) message that is sent to acknowledge receipt of the Request for this Response (Section 5.2.1).
ピギーバック応答ピギーバック応答は、この応答の要求の受信を確認するために送信されるCoAP肯定応答（ACK）メッセージに直接含まれています（セクション5.2.1）。
Separate Response When a Confirmable message carrying a request is acknowledged with an Empty message (e.g., because the server doesn't have the answer right away), a Separate Response is sent in a separate message exchange (Section 5.2.2).
個別の応答リクエストを含む確認可能なメッセージが空のメッセージで確認応答されると（たとえば、サーバーにすぐに応答がないため）、個別のメッセージ交換で個別の応答が送信されます（セクション5.2.2）。
Empty Message A message with a Code of 0.00; neither a request nor a response. An Empty message only contains the 4-byte header.
空のメッセージコード0.00のメッセージ。リクエストもレスポンスもありません。空のメッセージには4バイトのヘッダーのみが含まれます。
Critical Option An option that would need to be understood by the endpoint ultimately receiving the message in order to properly process the message (Section 5.4.1). Note that the implementation of critical options is, as the name "Option" implies, generally optional: unsupported critical options lead to an error response or summary rejection of the message.
重要なオプションメッセージを適切に処理するために最終的にメッセージを受信するエンドポイントが理解する必要があるオプション（セクション5.4.1）。重要なオプションの実装は、「オプション」という名前が示すように、通常はオプションです。サポートされていない重要なオプションは、エラー応答またはメッセージの要約拒否につながります。
Elective Option An option that is intended to be ignored by an endpoint that does not understand it. Processing the message even without understanding the option is acceptable (Section 5.4.1).
選択オプション理解できないエンドポイントによって無視されることを意図したオプション。オプションを理解していなくてもメッセージを処理することは許容されます（セクション5.4.1）。
Unsafe Option An option that would need to be understood by a proxy receiving the message in order to safely forward the message (Section 5.4.2). Not every critical option is an unsafe option.
安全でないオプションメッセージを安全に転送するために、メッセージを受信するプロキシが理解する必要があるオプション（セクション5.4.2）。すべての重要なオプションが安全でないオプションであるとは限りません。
Safe-to-Forward Option An option that is intended to be safe for forwarding by a proxy that does not understand it. Forwarding the message even without understanding the option is acceptable (Section 5.4.2).
Safe-to-Forwardオプション理解できないプロキシによる転送を安全にするためのオプション。オプションを理解していなくてもメッセージを転送することは許容されます（セクション5.4.2）。
Resource Discovery The process where a CoAP client queries a server for its list of hosted resources (i.e., links as defined in Section 7).
リソースディスカバリCoAPクライアントがホストされているリソース（セクション7で定義されているリンク）のリストをサーバーに照会するプロセス。
Content-Format The combination of an Internet media type, potentially with specific parameters given, and a content-coding (which is often the identity content-coding), identified by a numeric identifier defined by the "CoAP Content-Formats" registry. When the focus is less on the numeric identifier than on the combination of these characteristics of a resource representation, this is also called "representation format".
Content-Format特定のパラメーターが指定されている可能性のあるインターネットメディアタイプと、「CoAP Content-Formats」レジストリで定義された数値識別子によって識別されるコンテンツコーディング（多くの場合、アイデンティティコンテンツコーディング）の組み合わせ。リソース表現のこれらの特性の組み合わせよりも数値識別子に重点が置かれていない場合、これは「表現形式」とも呼ばれます。
Additional terminology for constrained nodes and constrained-node networks can be found in [RFC7228].
制約付きノードおよび制約付きノードネットワークの追加の用語は、[RFC7228]にあります。
In this specification, the term "byte" is used in its now customary sense as a synonym for "octet".
この仕様では、「バイト」という用語は「オクテット」の同義語として現在慣習的な意味で使用されています。
All multi-byte integers in this protocol are interpreted in network byte order.
このプロトコルのすべてのマルチバイト整数は、ネットワークバイトオーダーで解釈されます。
Where arithmetic is used, this specification uses the notation familiar from the programming language C, except that the operator "**" stands for exponentiation.
算術が使用される場合、この仕様では、演算子「**」が指数を表すことを除いて、プログラミング言語Cでよく知られている表記法を使用します。
The interaction model of CoAP is similar to the client/server model of HTTP. However, machine-to-machine interactions typically result in a CoAP implementation acting in both client and server roles. A CoAP request is equivalent to that of HTTP and is sent by a client to request an action (using a Method Code) on a resource (identified by a URI) on a server. The server then sends a response with a Response Code; this response may include a resource representation.
CoAPの相互作用モデルは、HTTPのクライアント/サーバーモデルに似ています。ただし、マシン間の相互作用により、通常、クライアントとサーバーの両方の役割で動作するCoAP実装が発生します。 CoAPリクエストはHTTPのリクエストと同等であり、サーバー上のリソース（URIで識別される）に対するアクション（メソッドコードを使用）をリクエストするためにクライアントから送信されます。次に、サーバーは応答コードを含む応答を送信します。この応答には、リソース表現が含まれる場合があります。
Unlike HTTP, CoAP deals with these interchanges asynchronously over a datagram-oriented transport such as UDP. This is done logically using a layer of messages that supports optional reliability (with exponential back-off). CoAP defines four types of messages: Confirmable, Non-confirmable, Acknowledgement, Reset. Method Codes and Response Codes included in some of these messages make them carry requests or responses. The basic exchanges of the four types of messages are somewhat orthogonal to the request/response interactions; requests can be carried in Confirmable and Non-confirmable messages, and responses can be carried in these as well as piggybacked in Acknowledgement messages.
HTTPとは異なり、CoAPはこれらの交換をUDPなどのデータグラム指向のトランスポートを介して非同期で処理します。これは、オプションの信頼性をサポートするメッセージのレイヤーを使用して論理的に行われます（指数バックオフあり）。 CoAPは、確認可能、確認不可能、確認応答、リセットの4種類のメッセージを定義します。これらのメッセージのいくつかに含まれているメソッドコードと応答コードは、要求または応答を運ぶようにします。 4種類のメッセージの基本的な交換は、要求/応答の相互作用に対してある程度直交しています。リクエストは確認可能なメッセージと確認できないメッセージで運ぶことができ、レスポンスはこれらのメッセージで運ぶことができ、承認メッセージで便乗することができます。
One could think of CoAP logically as using a two-layer approach, a CoAP messaging layer used to deal with UDP and the asynchronous nature of the interactions, and the request/response interactions using Method and Response Codes (see Figure 1). CoAP is however a single protocol, with messaging and request/response as just features of the CoAP header.
CoAPは、2層アプローチ、UDPと対話の非同期の性質を処理するために使用されるCoAPメッセージング層、およびメソッドと応答コードを使用した要求/応答の対話（図1を参照）を使用すると論理的に考えることができます。ただし、CoAPは単一のプロトコルであり、メッセージングと要求/応答はCoAPヘッダーの機能にすぎません。
+----------------------+
| Application |
+----------------------+
+----------------------+ \
| Requests/Responses | |
|----------------------| | CoAP
| Messages | |
+----------------------+ /
+----------------------+
| UDP |
+----------------------+
Figure 1: Abstract Layering of CoAP
図1：CoAPの抽象的なレイヤリング
The CoAP messaging model is based on the exchange of messages over UDP between endpoints.
CoAPメッセージングモデルは、エンドポイント間のUDPを介したメッセージの交換に基づいています。
CoAP uses a short fixed-length binary header (4 bytes) that may be followed by compact binary options and a payload. This message format is shared by requests and responses. The CoAP message format is specified in Section 3. Each message contains a Message ID used to detect duplicates and for optional reliability. (The Message ID is compact; its 16-bit size enables up to about 250 messages per second from one endpoint to another with default protocol parameters.)
CoAPは短い固定長バイナリヘッダー（4バイト）を使用し、その後にコンパクトバイナリオプションとペイロードが続く場合があります。このメッセージ形式は、要求と応答で共有されます。 CoAPメッセージフォーマットはセクション3で指定されています。各メッセージには、重複の検出とオプションの信頼性のために使用されるメッセージIDが含まれています。 （メッセージIDはコンパクトです。その16ビットサイズにより、デフォルトのプロトコルパラメータを使用して、1つのエンドポイントから別のエンドポイントに毎秒最大約250メッセージを送信できます。
Reliability is provided by marking a message as Confirmable (CON). A Confirmable message is retransmitted using a default timeout and exponential back-off between retransmissions, until the recipient sends an Acknowledgement message (ACK) with the same Message ID (in this example, 0x7d34) from the corresponding endpoint; see Figure 2. When a recipient is not at all able to process a Confirmable message (i.e., not even able to provide a suitable error response), it replies with a Reset message (RST) instead of an Acknowledgement (ACK).
信頼性は、メッセージを確認可能（CON）としてマークすることで提供されます。確認可能なメッセージは、受信者が対応するエンドポイントから同じメッセージID（この例では0x7d34）の確認応答メッセージ（ACK）を送信するまで、デフォルトのタイムアウトと再送信間の指数バックオフを使用して再送信されます。図2を参照してください。受信者が確認可能なメッセージをまったく処理できない（つまり、適切なエラー応答を提供することさえできない）場合、受信者は確認応答（ACK）ではなくリセットメッセージ（RST）で応答します。
Client Server
| |
| CON [0x7d34] |
+----------------->|
| |
| ACK [0x7d34] |
|<-----------------+
| |
Figure 2: Reliable Message Transmission
図2：信頼性の高いメッセージ送信
A message that does not require reliable transmission (for example, each single measurement out of a stream of sensor data) can be sent as a Non-confirmable message (NON). These are not acknowledged, but still have a Message ID for duplicate detection (in this example, 0x01a0); see Figure 3. When a recipient is not able to process a Non-confirmable message, it may reply with a Reset message (RST).
信頼性の高い送信を必要としないメッセージ（たとえば、センサーデータのストリームからの各単一測定）は、確認不可能なメッセージ（NON）として送信できます。これらは確認されませんが、重複検出用のメッセージID（この例では0x01a0）がまだあります。図3を参照してください。受信者が確認できないメッセージを処理できない場合、受信者はリセットメッセージ（RST）で応答することがあります。
Client Server
| |
| NON [0x01a0] |
+----------------->|
| |
Figure 3: Unreliable Message Transmission
図3：信頼できないメッセージ送信
See Section 4 for details of CoAP messages.
CoAPメッセージの詳細については、セクション4を参照してください。
As CoAP runs over UDP, it also supports the use of multicast IP destination addresses, enabling multicast CoAP requests. Section 8 discusses the proper use of CoAP messages with multicast addresses and precautions for avoiding response congestion.
CoAPはUDP上で実行されるため、マルチキャストIP宛先アドレスの使用もサポートし、マルチキャストCoAP要求を有効にします。セクション8では、マルチキャストアドレスを含むCoAPメッセージの適切な使用と、応答の輻輳を回避するための注意事項について説明します。
Several security modes are defined for CoAP in Section 9 ranging from no security to certificate-based security. This document specifies a binding to DTLS for securing the protocol; the use of IPsec with CoAP is discussed in [IPsec-CoAP].
セクション9では、セキュリティなしから証明書ベースのセキュリティまで、いくつかのセキュリティモードがCoAPに対して定義されています。このドキュメントは、プロトコルを保護するためのDTLSへのバインディングを指定します。 CoAPでのIPsecの使用については、[IPsec-CoAP]で説明しています。
CoAP request and response semantics are carried in CoAP messages, which include either a Method Code or Response Code, respectively. Optional (or default) request and response information, such as the URI and payload media type are carried as CoAP options. A Token is used to match responses to requests independently from the underlying messages (Section 5.3). (Note that the Token is a concept separate from the Message ID.)
CoAP要求および応答のセマンティクスは、それぞれメソッドコードまたは応答コードを含むCoAPメッセージで伝達されます。 URIやペイロードメディアタイプなどのオプション（またはデフォルト）の要求および応答情報は、CoAPオプションとして伝達されます。トークンは、基になるメッセージとは独立してリクエストへの応答を照合するために使用されます（セクション5.3）。 （トークンはメッセージIDとは別の概念であることに注意してください。）
A request is carried in a Confirmable (CON) or Non-confirmable (NON) message, and, if immediately available, the response to a request carried in a Confirmable message is carried in the resulting Acknowledgement (ACK) message. This is called a piggybacked response, detailed in Section 5.2.1. (There is no need for separately acknowledging a piggybacked response, as the client will retransmit the request if the Acknowledgement message carrying the piggybacked response is lost.) Two examples for a basic GET request with piggybacked response are shown in Figure 4, one successful, one resulting in a 4.04 (Not Found) response.
要求は確認可能（CON）または非確認可能（NON）メッセージで送信され、すぐに使用可能な場合、確認可能メッセージで送信された要求への応答は、結果の確認応答（ACK）メッセージで送信されます。これは、ピギーバック応答と呼ばれ、セクション5.2.1で詳しく説明されています。 （ピギーバック応答を運ぶ確認応答メッセージが失われた場合、クライアントは要求を再送信するため、ピギーバック応答を個別に確認する必要はありません。）ピギーバック応答を使用した基本的なGET要求の2つの例を図4に示します。 1つは4.04（Not Found）応答になります。
Client Server Client Server
| | | |
| CON [0xbc90] | | CON [0xbc91] |
| GET /temperature | | GET /temperature |
| (Token 0x71) | | (Token 0x72) |
+----------------->| +----------------->|
| | | |
| ACK [0xbc90] | | ACK [0xbc91] |
| 2.05 Content | | 4.04 Not Found |
| (Token 0x71) | | (Token 0x72) |
| "22.5 C" | | "Not found" |
|<-----------------+ |<-----------------+
| | | |
Figure 4: Two GET Requests with Piggybacked Responses
図4：ピギーバック応答を伴う2つのGET要求
If the server is not able to respond immediately to a request carried in a Confirmable message, it simply responds with an Empty Acknowledgement message so that the client can stop retransmitting the request. When the response is ready, the server sends it in a new Confirmable message (which then in turn needs to be acknowledged by the client). This is called a "separate response", as illustrated in Figure 5 and described in more detail in Section 5.2.2.
サーバーが確認可能なメッセージで送信された要求にすぐに応答できない場合、サーバーは空の確認メッセージで応答するだけなので、クライアントは要求の再送信を停止できます。応答の準備ができると、サーバーはそれを新しいConfirmableメッセージで送信します（次に、クライアントによって確認される必要があります）。これは、「個別の応答」と呼ばれ、図5に示され、セクション5.2.2で詳細に説明されています。
Client Server
| |
| CON [0x7a10] |
| GET /temperature |
| (Token 0x73) |
+----------------->|
| |
| ACK [0x7a10] |
|<-----------------+
| |
... Time Passes ...
| |
| CON [0x23bb] |
| 2.05 Content |
| (Token 0x73) |
| "22.5 C" |
|<-----------------+
| |
| ACK [0x23bb] |
+----------------->|
| |
Figure 5: A GET Request with a Separate Response
図5：個別の応答を伴うGET要求
If a request is sent in a Non-confirmable message, then the response is sent using a new Non-confirmable message, although the server may instead send a Confirmable message. This type of exchange is illustrated in Figure 6.
確認不可能なメッセージでリクエストが送信された場合、サーバーは代わりに確認可能なメッセージを送信できますが、新しい確認不可能なメッセージを使用して応答が送信されます。このタイプの交換を図6に示します。
Client Server
| |
| NON [0x7a11] |
| GET /temperature |
| (Token 0x74) |
+----------------->|
| |
| NON [0x23bc] |
| 2.05 Content |
| (Token 0x74) |
| "22.5 C" |
|<-----------------+
| |
Figure 6: A Request and a Response Carried in Non-confirmable Messages
図6：確認不可能なメッセージで実行される要求と応答
CoAP makes use of GET, PUT, POST, and DELETE methods in a similar manner to HTTP, with the semantics specified in Section 5.8. (Note that the detailed semantics of CoAP methods are "almost, but not entirely unlike" [HHGTTG] those of HTTP methods: intuition taken from HTTP experience generally does apply well, but there are enough differences that make it worthwhile to actually read the present specification.)
CoAPは、HTTPと同様の方法でGET、PUT、POST、およびDELETEメソッドを使用します。セマンティクスはセクション5.8で指定されています。 （CoAPメソッドの詳細なセマンティクスは「ほぼ、完全に異なるわけではない」[HHGTTG]であることに注意してください] HTTPメソッドのセマンティクス：通常、HTTPの経験から得られた直感は適切に適用されますが、実際に現在を読む価値のある十分な違いがあります仕様。）
Methods beyond the basic four can be added to CoAP in separate specifications. New methods do not necessarily have to use requests and responses in pairs. Even for existing methods, a single request may yield multiple responses, e.g., for a multicast request (Section 8) or with the Observe option [OBSERVE].
基本的な4つを超えるメソッドは、個別の仕様でCoAPに追加できます。新しいメソッドでは、要求と応答をペアで使用する必要はありません。既存のメソッドの場合でも、単一の要求で複数の応答が生成されることがあります。たとえば、マルチキャスト要求（セクション8）の場合や、監視オプション[監視]を使用した場合などです。
URI support in a server is simplified as the client already parses the URI and splits it into host, port, path, and query components, making use of default values for efficiency. Response Codes relate to a small subset of HTTP status codes with a few CoAP-specific codes added, as defined in Section 5.9.
サーバーでのURIサポートは、クライアントが既にURIを解析し、それをホスト、ポート、パス、およびクエリコンポーネントに分割しているため、効率化のためにデフォルト値を利用しているため、簡素化されています。応答コードは、セクション5.9で定義されているように、いくつかのCoAP固有のコードが追加されたHTTPステータスコードの小さなサブセットに関連しています。
The protocol supports the caching of responses in order to efficiently fulfill requests. Simple caching is enabled using freshness and validity information carried with CoAP responses. A cache could be located in an endpoint or an intermediary. Caching functionality is specified in Section 5.6.
このプロトコルは、要求を効率的に満たすために、応答のキャッシュをサポートしています。シンプルキャッシングは、CoAP応答で伝達される鮮度と有効性の情報を使用して有効になります。キャッシュはエンドポイントまたは中間に配置できます。キャッシング機能はセクション5.6で指定されています。
Proxying is useful in constrained networks for several reasons, including to limit network traffic, to improve performance, to access resources of sleeping devices, and for security reasons. The proxying of requests on behalf of another CoAP endpoint is supported in the protocol. When using a proxy, the URI of the resource to request is included in the request, while the destination IP address is set to the address of the proxy. See Section 5.7 for more information on proxy functionality.
プロキシは、ネットワークトラフィックの制限、パフォーマンスの向上、スリープ状態のデバイスのリソースへのアクセス、セキュリティ上の理由など、いくつかの理由で制約のあるネットワークで役立ちます。プロトコルでは、別のCoAPエンドポイントに代わる要求のプロキシがサポートされています。プロキシを使用する場合、リクエストするリソースのURIはリクエストに含まれますが、宛先IPアドレスはプロキシのアドレスに設定されます。プロキシ機能の詳細については、セクション5.7を参照してください。
As CoAP was designed according to the REST architecture [REST], and thus exhibits functionality similar to that of the HTTP protocol, it is quite straightforward to map from CoAP to HTTP and from HTTP to CoAP. Such a mapping may be used to realize an HTTP REST interface using CoAP or to convert between HTTP and CoAP. This conversion can be carried out by a cross-protocol proxy ("cross-proxy"), which converts the Method or Response Code, media type, and options to the corresponding HTTP feature. Section 10 provides more detail about HTTP mapping.
CoAPはRESTアーキテクチャ[REST]に従って設計されているため、HTTPプロトコルと同様の機能を発揮するため、CoAPからHTTPへ、およびHTTPからCoAPへのマッピングは非常に簡単です。このようなマッピングは、CoAPを使用してHTTP RESTインターフェースを実現するため、またはHTTPとCoAPの間で変換するために使用できます。この変換は、メソッドまたは応答コード、メディアタイプ、オプションを対応するHTTP機能に変換するクロスプロトコルプロキシ（「クロスプロキシ」）で実行できます。セクション10では、HTTPマッピングについて詳しく説明します。
Resource discovery is important for machine-to-machine interactions and is supported using the CoRE Link Format [RFC6690] as discussed in Section 7.
リソース検出は、マシン間の相互作用にとって重要であり、セクション7で説明されているように、CoREリンクフォーマット[RFC6690]を使用してサポートされます。
CoAP is based on the exchange of compact messages that, by default, are transported over UDP (i.e., each CoAP message occupies the data section of one UDP datagram). CoAP may also be used over Datagram Transport Layer Security (DTLS) (see Section 9.1). It could also be used over other transports such as SMS, TCP, or SCTP, the specification of which is out of this document's scope. (UDP-lite [RFC3828] and UDP zero checksum [RFC6936] are not supported by CoAP.)
CoAPは、デフォルトでUDPを介して転送されるコンパクトメッセージの交換に基づいています（つまり、各CoAPメッセージは1つのUDPデータグラムのデータセクションを占有します）。 CoAPは、データグラムトランスポート層セキュリティ（DTLS）でも使用できます（セクション9.1を参照）。 SMS、TCP、SCTPなどの他のトランスポートでも使用できますが、その仕様はこのドキュメントの範囲外です。 （UDP-lite [RFC3828]およびUDPゼロチェックサム[RFC6936]はCoAPでサポートされていません。）
CoAP messages are encoded in a simple binary format. The message format starts with a fixed-size 4-byte header. This is followed by a variable-length Token value, which can be between 0 and 8 bytes long.
CoAPメッセージは単純なバイナリ形式でエンコードされます。メッセージフォーマットは、固定サイズの4バイトヘッダーで始まります。この後には、可変長のトークン値が続きます。これは、0から8バイトまでの長さにすることができます。
Following the Token value comes a sequence of zero or more CoAP Options in Type-Length-Value (TLV) format, optionally followed by a payload that takes up the rest of the datagram.
トークン値の後には、Type-Length-Value（TLV）形式のゼロ以上のCoAPオプションのシーケンスが続き、オプションで、データグラムの残りを占めるペイロードが続きます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver| T | TKL | Code | Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token (if any, TKL bytes) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1| Payload (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Message Format
図7：メッセージ形式
The fields in the header are defined as follows:
ヘッダーのフィールドは次のように定義されています。
Version (Ver): 2-bit unsigned integer. Indicates the CoAP version number. Implementations of this specification MUST set this field to 1 (01 binary). Other values are reserved for future versions. Messages with unknown version numbers MUST be silently ignored.
バージョン（Ver）：2ビットの符号なし整数。 CoAPバージョン番号を示します。この仕様の実装は、このフィールドを1（01バイナリ）に設定する必要があります。その他の値は、将来のバージョン用に予約されています。バージョン番号が不明なメッセージは、黙って無視しなければなりません（MUST）。
Type (T): 2-bit unsigned integer. Indicates if this message is of type Confirmable (0), Non-confirmable (1), Acknowledgement (2), or Reset (3). The semantics of these message types are defined in Section 4.
タイプ（T）：2ビットの符号なし整数。このメッセージのタイプが確認可能（0）、確認不可能（1）、確認（2）、またはリセット（3）のいずれであるかを示します。これらのメッセージタイプのセマンティクスは、セクション4で定義されています。
Token Length (TKL): 4-bit unsigned integer. Indicates the length of the variable-length Token field (0-8 bytes). Lengths 9-15 are reserved, MUST NOT be sent, and MUST be processed as a message format error.
トークン長（TKL）：4ビットの符号なし整数。可変長トークンフィールドの長さを示します（0-8バイト）。長さ9〜15は予約されており、送信してはならず、メッセージフォーマットエラーとして処理する必要があります。
Code: 8-bit unsigned integer, split into a 3-bit class (most significant bits) and a 5-bit detail (least significant bits), documented as "c.dd" where "c" is a digit from 0 to 7 for the 3-bit subfield and "dd" are two digits from 00 to 31 for the 5-bit subfield. The class can indicate a request (0), a success response (2), a client error response (4), or a server error response (5). (All other class values are reserved.) As a special case, Code 0.00 indicates an Empty message. In case of a request, the Code field indicates the Request Method; in case of a response, a Response Code. Possible values are maintained in the CoAP Code Registries (Section 12.1). The semantics of requests and responses are defined in Section 5.
コード：8ビットの符号なし整数。3ビットのクラス（最上位ビット）と5ビットの詳細（最下位ビット）に分割され、「c.dd」として文書化されています。「c」は0〜7の数字です。 3ビットサブフィールドの場合、 "dd"は5ビットサブフィールドの場合、00から31までの2桁です。クラスは、要求（0）、成功応答（2）、クライアントエラー応答（4）、またはサーバーエラー応答（5）を示すことができます。 （他のすべてのクラス値は予約されています。）特別な場合として、コード0.00は空のメッセージを示します。リクエストの場合、コードフィールドはリクエストメソッドを示します。応答の場合は、応答コード。可能な値はCoAPコードレジストリ（セクション12.1）で維持されます。リクエストとレスポンスのセマンティクスはセクション5で定義されています。
Message ID: 16-bit unsigned integer in network byte order. Used to detect message duplication and to match messages of type Acknowledgement/Reset to messages of type Confirmable/Non-confirmable. The rules for generating a Message ID and matching messages are defined in Section 4.
メッセージID：ネットワークバイトオーダーの16ビット符号なし整数。メッセージの重複を検出し、タイプAcknowledgement / ResetのメッセージをタイプConfirmable / Non-confirmableのメッセージと照合するために使用されます。メッセージIDと一致するメッセージを生成するためのルールは、セクション4で定義されています。
The header is followed by the Token value, which may be 0 to 8 bytes, as given by the Token Length field. The Token value is used to correlate requests and responses. The rules for generating a Token and correlating requests and responses are defined in Section 5.3.1.
ヘッダーの後にトークン値が続きます。これは、トークン長フィールドで指定されるように、0〜8バイトの場合があります。トークン値は、要求と応答を関連付けるために使用されます。トークンを生成し、リクエストとレスポンスを関連付けるためのルールは、セクション5.3.1で定義されています。
Header and Token are followed by zero or more Options (Section 3.1). An Option can be followed by the end of the message, by another Option, or by the Payload Marker and the payload.
ヘッダーとトークンの後には0個以上のオプションが続きます（セクション3.1）。オプションの後には、メッセージの最後、別のオプション、またはペイロードマーカーとペイロードを続けることができます。
Following the header, token, and options, if any, comes the optional payload. If present and of non-zero length, it is prefixed by a fixed, one-byte Payload Marker (0xFF), which indicates the end of options and the start of the payload. The payload data extends from after the marker to the end of the UDP datagram, i.e., the Payload Length is calculated from the datagram size. The absence of the Payload Marker denotes a zero-length payload. The presence of a marker followed by a zero-length payload MUST be processed as a message format error.
ヘッダー、トークン、オプション（ある場合）に続いて、オプションのペイロードが続きます。存在し、長さがゼロでない場合は、オプションの終わりとペイロードの始まりを示す、固定の1バイトのペイロードマーカー（0xFF）が前に付きます。ペイロードデータは、マーカーの後からUDPデータグラムの最後まで続きます。つまり、ペイロード長はデータグラムサイズから計算されます。ペイロードマーカーがない場合は、長さがゼロのペイロードを示します。長さゼロのペイロードが後に続くマーカーの存在は、メッセージフォーマットエラーとして処理される必要があります。
Implementation Note: The byte value 0xFF may also occur within an option length or value, so simple byte-wise scanning for 0xFF is not a viable technique for finding the payload marker. The byte 0xFF has the meaning of a payload marker only where the beginning of another option could occur.
実装上の注意：バイト値0xFFもオプションの長さまたは値内で発生する可能性があるため、0xFFの単純なバイト単位のスキャンは、ペイロードマーカーを見つけるための実行可能な手法ではありません。バイト0xFFは、別のオプションの始まりが発生する可能性がある場合にのみ、ペイロードマーカーの意味を持ちます。
CoAP defines a number of options that can be included in a message. Each option instance in a message specifies the Option Number of the defined CoAP option, the length of the Option Value, and the Option Value itself.
CoAPは、メッセージに含めることができるいくつかのオプションを定義します。メッセージ内の各オプションインスタンスは、定義されたCoAPオプションのオプション番号、オプション値の長さ、およびオプション値自体を指定します。
Instead of specifying the Option Number directly, the instances MUST appear in order of their Option Numbers and a delta encoding is used between them: the Option Number for each instance is calculated as the sum of its delta and the Option Number of the preceding instance in the message. For the first instance in a message, a preceding option instance with Option Number zero is assumed. Multiple instances of the same option can be included by using a delta of zero.
オプション番号を直接指定する代わりに、インスタンスはオプション番号の順に表示されなければならず、それらの間でデルタエンコーディングが使用されます。各インスタンスのオプション番号は、そのデルタと前のインスタンスのオプション番号の合計として計算されます。メッセージ。メッセージの最初のインスタンスでは、オプション番号がゼロの先行オプションインスタンスが想定されます。ゼロのデルタを使用して、同じオプションの複数のインスタンスを含めることができます。
Option Numbers are maintained in the "CoAP Option Numbers" registry (Section 12.2). See Section 5.4 for the semantics of the options defined in this document.
オプション番号は、「CoAPオプション番号」レジストリ（セクション12.2）で維持されます。このドキュメントで定義されているオプションのセマンティクスについては、セクション5.4を参照してください。
0 1 2 3 4 5 6 7
+---------------+---------------+
| | |
| Option Delta | Option Length | 1 byte
| | |
+---------------+---------------+
\ \
/ Option Delta / 0-2 bytes
\ (extended) \
+-------------------------------+
\ \
/ Option Length / 0-2 bytes
\ (extended) \
+-------------------------------+
\ \
/ /
\ \
/ Option Value / 0 or more bytes
\ \
/ /
\ \
+-------------------------------+
Figure 8: Option Format
図8：オプションの形式
The fields in an option are defined as follows:
オプションのフィールドは次のように定義されます。
Option Delta: 4-bit unsigned integer. A value between 0 and 12 indicates the Option Delta. Three values are reserved for special constructs:
オプションDelta：4ビットの符号なし整数。 0から12までの値は、オプションデルタを示します。 3つの値は、特別な構成のために予約されています。
13: An 8-bit unsigned integer follows the initial byte and indicates the Option Delta minus 13.
13：最初のバイトの後に8ビットの符号なし整数が続き、オプションデルタ-13を示します。
14: A 16-bit unsigned integer in network byte order follows the initial byte and indicates the Option Delta minus 269.
14：ネットワークバイトオーダーの16ビット符号なし整数は、最初のバイトに続き、オプションデルタから269を引いたものを示します。
15: Reserved for the Payload Marker. If the field is set to this value but the entire byte is not the payload marker, this MUST be processed as a message format error.
15：ペイロードマーカー用に予約されています。フィールドがこの値に設定されているが、バイト全体がペイロードマーカーではない場合、これはメッセージフォーマットエラーとして処理される必要があります。
The resulting Option Delta is used as the difference between the Option Number of this option and that of the previous option (or zero for the first option). In other words, the Option Number is calculated by simply summing the Option Delta values of this and all previous options before it.
結果のオプションデルタは、このオプションのオプション番号と前のオプションのオプション番号の差（または最初のオプションの場合はゼロ）として使用されます。つまり、オプション番号は、これとその前のすべての以前のオプションのオプションデルタ値を単に合計することによって計算されます。
Option Length: 4-bit unsigned integer. A value between 0 and 12 indicates the length of the Option Value, in bytes. Three values are reserved for special constructs:
オプションの長さ：4ビットの符号なし整数。 0から12までの値は、オプション値の長さをバイトで示します。 3つの値は、特別な構成のために予約されています。
13: An 8-bit unsigned integer precedes the Option Value and indicates the Option Length minus 13.
13：8ビットの符号なし整数はオプション値の前にあり、オプション長から13を引いた値を示します。
14: A 16-bit unsigned integer in network byte order precedes the Option Value and indicates the Option Length minus 269.
14：ネットワークバイトオーダーの16ビット符号なし整数は、オプション値の前にあり、オプション長から269を引いたものを示します。
15: Reserved for future use. If the field is set to this value, it MUST be processed as a message format error.
15：将来の使用のために予約されています。フィールドがこの値に設定されている場合、メッセージフォーマットエラーとして処理される必要があります。
Value: A sequence of exactly Option Length bytes. The length and format of the Option Value depend on the respective option, which MAY define variable-length values. See Section 3.2 for the formats used in this document; options defined in other documents MAY make use of other option value formats.
値：正確にOption Lengthバイトのシーケンス。オプション値の長さと形式は、それぞれのオプションによって異なります。オプションは可変長の値を定義する場合があります。このドキュメントで使用されているフォーマットについては、セクション3.2を参照してください。他のドキュメントで定義されているオプションは、他のオプション値のフォーマットを使用する場合があります。
The options defined in this document make use of the following option value formats.
このドキュメントで定義されているオプションは、次のオプション値の形式を使用しています。
empty: A zero-length sequence of bytes.
empty：長さ0のバイトのシーケンス。
opaque: An opaque sequence of bytes.
opaque：不透明なバイトシーケンス。
uint: A non-negative integer that is represented in network byte order using the number of bytes given by the Option Length field.
uint：[オプションの長さ]フィールドで指定されたバイト数を使用してネットワークバイトオーダーで表される負でない整数。
An option definition may specify a range of permissible numbers of bytes; if it has a choice, a sender SHOULD represent the integer with as few bytes as possible, i.e., without leading zero bytes. For example, the number 0 is represented with an empty option value (a zero-length sequence of bytes) and the number 1 by a single byte with the numerical value of 1 (bit combination 00000001 in most significant bit first notation). A recipient MUST be prepared to process values with leading zero bytes.
オプション定義では、許容されるバイト数の範囲を指定できます。選択肢がある場合、送信者は整数を可能な限り少ないバイト数で、つまり先行ゼロバイトなしで表現する必要があります（SHOULD）。たとえば、数値0は空のオプション値（長さがゼロのバイトシーケンス）で表され、数値1は1バイトの数値1（最上位ビットの最初の表記での00000001のビットの組み合わせ）で表されます。受信者は、先頭の0バイトの値を処理する準備ができていなければなりません。
Implementation Note: The exceptional behavior permitted for the sender is intended for highly constrained, templated implementations (e.g., hardware implementations) that use fixed-size options in the templates.
実装メモ：送信者に許可されている例外的な動作は、テンプレートで固定サイズのオプションを使用する、高度に制約されたテンプレート実装（ハードウェア実装など）を対象としています。
string: A Unicode string that is encoded using UTF-8 [RFC3629] in Net-Unicode form [RFC5198].
string：UTF-8 [RFC3629]を使用してNet-Unicode形式[RFC5198]でエンコードされたUnicode文字列。
Note that here, and in all other places where UTF-8 encoding is used in the CoAP protocol, the intention is that the encoded strings can be directly used and compared as opaque byte strings by CoAP protocol implementations. There is no expectation and no need to perform normalization within a CoAP implementation (except where Unicode strings that are not known to be normalized are imported from sources outside the CoAP protocol). Note also that ASCII strings (that do not make use of special control characters) are always valid UTF-8 Net-Unicode strings.
ここおよびCoAPプロトコルでUTF-8エンコーディングが使用されている他のすべての場所では、エンコードされた文字列を直接使用して、CoAPプロトコルの実装で不透明なバイト文字列として比較できることに注意してください。期待はなく、CoAP実装内で正規化を実行する必要はありません（正規化されていないことがわかっているUnicode文字列がCoAPプロトコルの外部のソースからインポートされる場合を除く）。また、ASCII文字列（特殊な制御文字を使用しない）は常に有効なUTF-8 Net-Unicode文字列であることに注意してください。
CoAP messages are exchanged asynchronously between CoAP endpoints. They are used to transport CoAP requests and responses, the semantics of which are defined in Section 5.
CoAPメッセージは、CoAPエンドポイント間で非同期的に交換されます。これらは、CoAP要求と応答を転送するために使用され、そのセマンティクスはセクション5で定義されています。
As CoAP is bound to unreliable transports such as UDP, CoAP messages may arrive out of order, appear duplicated, or go missing without notice. For this reason, CoAP implements a lightweight reliability mechanism, without trying to re-create the full feature set of a transport like TCP. It has the following features:
CoAPはUDPなどの信頼性の低いトランスポートにバインドされているため、CoAPメッセージが順不同で到着したり、重複して表示されたり、通知なしに失われたりする場合があります。このため、CoAPは、TCPなどのトランスポートの完全な機能セットを再作成することなく、軽量の信頼性メカニズムを実装しています。次の機能があります。
o Simple stop-and-wait retransmission reliability with exponential back-off for Confirmable messages.
o 確認可能なメッセージの指数バックオフを備えた単純なストップアンドウェイト再送信の信頼性。
o Duplicate detection for both Confirmable and Non-confirmable messages.
o 確認可能なメッセージと確認できないメッセージの両方の重複検出。
A CoAP endpoint is the source or destination of a CoAP message. The specific definition of an endpoint depends on the transport being used for CoAP. For the transports defined in this specification, the endpoint is identified depending on the security mode used (see Section 9): With no security, the endpoint is solely identified by an IP address and a UDP port number. With other security modes, the endpoint is identified as defined by the security mode.
CoAPエンドポイントは、CoAPメッセージの送信元または宛先です。エンドポイントの具体的な定義は、CoAPに使用されるトランスポートによって異なります。この仕様で定義されているトランスポートの場合、エンドポイントは、使用されるセキュリティモードに応じて識別されます（セクション9を参照）。セキュリティがない場合、エンドポイントはIPアドレスとUDPポート番号によってのみ識別されます。他のセキュリティモードでは、エンドポイントはセキュリティモードで定義されているように識別されます。
There are different types of messages. The type of a message is specified by the Type field of the CoAP Header.
メッセージにはさまざまなタイプがあります。メッセージのタイプは、CoAPヘッダーのTypeフィールドで指定されます。
Separate from the message type, a message may carry a request, a response, or be Empty. This is signaled by the Request/Response Code field in the CoAP Header and is relevant to the request/response model. Possible values for the field are maintained in the CoAP Code Registries (Section 12.1).
メッセージの種類とは別に、メッセージは要求、応答、または空の場合があります。これは、CoAPヘッダーの要求/応答コードフィールドによって通知され、要求/応答モデルに関連しています。フィールドの可能な値は、CoAPコードレジストリ（セクション12.1）で維持されます。
An Empty message has the Code field set to 0.00. The Token Length field MUST be set to 0 and bytes of data MUST NOT be present after the Message ID field. If there are any bytes, they MUST be processed as a message format error.
空のメッセージでは、コードフィールドが0.00に設定されています。トークン長フィールドは0に設定する必要があり、データのバイトはメッセージIDフィールドの後に存在してはなりません。バイトがある場合、それらはメッセージフォーマットエラーとして処理される必要があります。
The reliable transmission of a message is initiated by marking the message as Confirmable in the CoAP header. A Confirmable message always carries either a request or response, unless it is used only to elicit a Reset message, in which case it is Empty. A recipient MUST either (a) acknowledge a Confirmable message with an Acknowledgement message or (b) reject the message if the recipient lacks context to process the message properly, including situations where the message is Empty, uses a code with a reserved class (1, 6, or 7), or has a message format error. Rejecting a Confirmable message is effected by sending a matching Reset message and otherwise ignoring it. The Acknowledgement message MUST echo the Message ID of the Confirmable message and MUST carry a response or be Empty (see Sections 5.2.1 and 5.2.2). The Reset message MUST echo the Message ID of the Confirmable message and MUST be Empty. Rejecting an Acknowledgement or Reset message (including the case where the Acknowledgement carries a request or a code with a reserved class, or the Reset message is not Empty) is effected by silently ignoring it. More generally, recipients of Acknowledgement and Reset messages MUST NOT respond with either Acknowledgement or Reset messages.
メッセージの信頼できる送信は、CoAPヘッダーでメッセージを確認可能としてマークすることによって開始されます。確認可能メッセージは、リセットメッセージを引き出すためだけに使用される場合を除いて、常に要求または応答のいずれかを伝達します。この場合、メッセージは空です。受信者は、（a）確認メッセージで確認メッセージを確認するか、（b）メッセージが空である状況を含め、受信者がメッセージを適切に処理するためのコンテキストを欠いている場合にメッセージを拒否する必要があります（予約済みクラス（1 、6、7）、またはメッセージ形式エラーがあります。確認可能なメッセージを拒否するには、対応するリセットメッセージを送信し、それ以外の場合は無視します。確認メッセージは、確認可能メッセージのメッセージIDをエコーする必要があり、応答を送信するか、空である必要があります（セクション5.2.1および5.2.2を参照）。リセットメッセージは、確認可能メッセージのメッセージIDをエコーする必要があり、空でなければなりません。確認またはリセットメッセージの拒否（確認が予約済みクラスの要求またはコードを含む場合、またはリセットメッセージが空でない場合を含む）は、黙って無視することによって行われます。より一般的には、確認およびリセットメッセージの受信者は、確認またはリセットメッセージで応答してはなりません（MUST NOT）。
The sender retransmits the Confirmable message at exponentially increasing intervals, until it receives an acknowledgement (or Reset message) or runs out of attempts.
送信者は、確認応答（またはリセットメッセージ）を受信するか、試行がなくなるまで、指数関数的に増加する間隔で確認可能メッセージを再送信します。
Retransmission is controlled by two things that a CoAP endpoint MUST keep track of for each Confirmable message it sends while waiting for an acknowledgement (or reset): a timeout and a retransmission counter. For a new Confirmable message, the initial timeout is set to a random duration (often not an integral number of seconds) between ACK_TIMEOUT and (ACK_TIMEOUT * ACK_RANDOM_FACTOR) (see Section 4.8), and the retransmission counter is set to 0. When the timeout is triggered and the retransmission counter is less than MAX_RETRANSMIT, the message is retransmitted, the retransmission counter is incremented, and the timeout is doubled. If the retransmission counter reaches MAX_RETRANSMIT on a timeout, or if the endpoint receives a Reset message, then the attempt to transmit the message is canceled and the application process informed of failure. On the other hand, if the endpoint receives an acknowledgement in time, transmission is considered successful.
再送信は、CoAPエンドポイントが確認（またはリセット）を待機している間に送信する確認可能なメッセージごとに追跡する必要がある2つの要素、つまりタイムアウトと再送信カウンターによって制御されます。新しいConfirmableメッセージの場合、初期タイムアウトはACK_TIMEOUTと（ACK_TIMEOUT * ACK_RANDOM_FACTOR）の間のランダムな期間（多くの場合、整数秒ではない）に設定され（セクション4.8を参照）、再送信カウンターは0に設定されます。がトリガーされ、再送信カウンターがMAX_RETRANSMIT未満の場合、メッセージが再送信され、再送信カウンターが増分され、タイムアウトが2倍になります。タイムアウト時に再送信カウンターがMAX_RETRANSMITに達した場合、またはエンドポイントがリセットメッセージを受信した場合、メッセージの送信の試行はキャンセルされ、アプリケーションプロセスは失敗を通知されます。一方、エンドポイントが時間内に確認応答を受信した場合、送信は成功したと見なされます。
This specification makes no strong requirements on the accuracy of the clocks used to implement the above binary exponential back-off algorithm. In particular, an endpoint may be late for a specific retransmission due to its sleep schedule and may catch up on the next one. However, the minimum spacing before another retransmission is ACK_TIMEOUT, and the entire sequence of (re-)transmissions MUST stay in the envelope of MAX_TRANSMIT_SPAN (see Section 4.8.2), even if that means a sender may miss an opportunity to transmit.
この仕様では、上記のバイナリ指数バックオフアルゴリズムを実装するために使用されるクロックの精度に強い要件はありません。特に、エンドポイントは、スリープスケジュールが原因で特定の再送信が遅れ、次の再送信に追いつく場合があります。ただし、別の再送信までの最小間隔はACK_TIMEOUTであり、送信者が送信する機会を逃す可能性がある場合でも、（再）送信のシーケンス全体はMAX_TRANSMIT_SPANのエンベロープに留まらなければなりません（セクション4.8.2を参照）。
A CoAP endpoint that sent a Confirmable message MAY give up in attempting to obtain an ACK even before the MAX_RETRANSMIT counter value is reached. For example, the application has canceled the request as it no longer needs a response, or there is some other indication that the CON message did arrive. In particular, a CoAP request message may have elicited a separate response, in which case it is clear to the requester that only the ACK was lost and a retransmission of the request would serve no purpose. However, a responder MUST NOT in turn rely on this cross-layer behavior from a requester, i.e., it MUST retain the state to create the ACK for the request, if needed, even if a Confirmable response was already acknowledged by the requester.
確認可能メッセージを送信したCoAPエンドポイントは、MAX_RETRANSMITカウンター値に達する前であっても、ACKを取得しようとしてあきらめる場合があります。たとえば、応答が不要になったためにアプリケーションが要求をキャンセルしたか、CONメッセージが到着したことを示す他の兆候があります。特に、CoAP要求メッセージは別の応答を引き出した可能性があります。その場合、要求側にはACKのみが失われ、要求の再送信は何の役にも立たないことは明らかです。ただし、レスポンダーは、リクエスターからのこのクロスレイヤー動作に依存してはなりません（MUST）。つまり、確認可能な応答がリクエスターによってすでに確認されている場合でも、必要に応じて、リクエストのACKを作成するための状態を保持する必要があります。
Another reason for giving up retransmission MAY be the receipt of ICMP errors. If it is desired to take account of ICMP errors, to mitigate potential spoofing attacks, implementations SHOULD take care to check the information about the original datagram in the ICMP message, including port numbers and CoAP header information such as message type and code, Message ID, and Token; if this is not possible due to limitations of the UDP service API, ICMP errors SHOULD be ignored. Packet Too Big errors [RFC4443] ("fragmentation needed and DF set" for IPv4 [RFC0792]) cannot properly occur and SHOULD be ignored if the implementation note in Section 4.6 is followed; otherwise, they SHOULD feed into a path MTU discovery algorithm [RFC4821]. Source Quench and Time Exceeded ICMP messages SHOULD be ignored. Host, network, port, or protocol unreachable errors or parameter problem errors MAY, after appropriate vetting, be used to inform the application of a failure in sending.
再送信を中止するもう1つの理由は、ICMPエラーの受信である可能性があります。 ICMPエラーを考慮する必要がある場合は、なりすまし攻撃の可能性を軽減するために、実装でICMPメッセージの元のデータグラムに関する情報（ポート番号、メッセージタイプやコード、メッセージIDなどのCoAPヘッダー情報を含む）を確認する必要があります、およびトークン。 UDPサービスAPIの制限のためにこれが不可能な場合、ICMPエラーは無視してください。パケットが大きすぎるエラー[RFC4443]（IPv4の場合は「断片化が必要で、DFが設定されている」[RFC0792]）は正しく発生せず、セクション4.6の実装に関する注意事項に従っている場合は無視する必要があります。それ以外の場合は、パスMTU発見アルゴリズム[RFC4821]にフィードする必要があります（SHOULD）。 Source QuenchおよびTime Exceeded ICMPメッセージは無視してください。ホスト、ネットワーク、ポート、またはプロトコル到達不能エラーまたはパラメーター問題エラーは、適切な検査の後、送信の失敗をアプリケーションに通知するために使用される場合があります。
Some messages do not require an acknowledgement. This is particularly true for messages that are repeated regularly for application requirements, such as repeated readings from a sensor where eventual success is sufficient.
一部のメッセージは確認を必要としません。これは、最終的な成功で十分なセンサーからの繰り返し読み取りなど、アプリケーション要件のために定期的に繰り返されるメッセージに特に当てはまります。
As a more lightweight alternative, a message can be transmitted less reliably by marking the message as Non-confirmable. A Non-confirmable message always carries either a request or response and MUST NOT be Empty. A Non-confirmable message MUST NOT be acknowledged by the recipient. A recipient MUST reject the message if it lacks context to process the message properly, including the case where the message is Empty, uses a code with a reserved class (1, 6, or 7), or has a message format error. Rejecting a Non-confirmable message MAY involve sending a matching Reset message, and apart from the Reset message the rejected message MUST be silently ignored.
より軽量な代替手段として、メッセージに確認不能のマークを付けると、メッセージの信頼性が低下します。確認不可能なメッセージは常に要求または応答のいずれかを伝達し、空であってはなりません。確認できないメッセージは、受信者によって確認されてはなりません。メッセージが空である場合、予約済みクラス（1、6、または7）のコードを使用している場合、またはメッセージ形式エラーがある場合など、メッセージを適切に処理するコンテキストがない場合、受信者はメッセージを拒否する必要があります。確認不可能なメッセージを拒否することは、一致するリセットメッセージを送信することを伴う場合があり、リセットメッセージは別として、拒否されたメッセージは黙って無視されなければなりません（MUST）。
At the CoAP level, there is no way for the sender to detect if a Non-confirmable message was received or not. A sender MAY choose to transmit multiple copies of a Non-confirmable message within MAX_TRANSMIT_SPAN (limited by the provisions of Section 4.7, in particular, by PROBING_RATE if no response is received), or the network may duplicate the message in transit. To enable the receiver to act only once on the message, Non-confirmable messages specify a Message ID as well. (This Message ID is drawn from the same number space as the Message IDs for Confirmable messages.)
CoAPレベルでは、確認できないメッセージが受信されたかどうかを送信者が検出する方法はありません。送信者は、MAX_TRANSMIT_SPAN内で確認不可能なメッセージの複数のコピーを送信することを選択してもよい（MAY）（セクション4.7の規定によって制限され、特に応答が受信されない場合はPROBING_RATEによって制限されます）。または、ネットワークが送信中のメッセージを複製する場合があります。受信者がメッセージに対して1回だけ動作できるようにするために、確認不可能なメッセージでもメッセージIDを指定します。 （このメッセージIDは、確認可能なメッセージのメッセージIDと同じ番号スペースから取得されます。）
Summarizing Sections 4.2 and 4.3, the four message types can be used as in Table 1. "*" means that the combination is not used in normal operation but only to elicit a Reset message ("CoAP ping").
セクション4.2と4.3を要約すると、表1のように4つのメッセージタイプを使用できます。「*」は、その組み合わせが通常の操作では使用されず、リセットメッセージ（「CoAP ping」）を引き出すためだけに使用されることを意味します。
+----------+-----+-----+-----+-----+
| | CON | NON | ACK | RST |
+----------+-----+-----+-----+-----+
| Request | X | X | - | - |
| Response | X | X | X | - |
| Empty | * | - | X | X |
+----------+-----+-----+-----+-----+
Table 1: Usage of Message Types
表1：メッセージタイプの使用法
An Acknowledgement or Reset message is related to a Confirmable message or Non-confirmable message by means of a Message ID along with additional address information of the corresponding endpoint. The Message ID is a 16-bit unsigned integer that is generated by the sender of a Confirmable or Non-confirmable message and included in the CoAP header. The Message ID MUST be echoed in the Acknowledgement or Reset message by the recipient.
確認メッセージまたはリセットメッセージは、対応するエンドポイントの追加のアドレス情報とともにメッセージIDを使用して、確認可能なメッセージまたは確認できないメッセージに関連付けられます。メッセージIDは、確認可能または確認不可能なメッセージの送信者によって生成され、CoAPヘッダーに含まれる16ビットの符号なし整数です。メッセージIDは、受信者による確認またはリセットメッセージでエコーする必要があります。
The same Message ID MUST NOT be reused (in communicating with the same endpoint) within the EXCHANGE_LIFETIME (Section 4.8.2).
EXCHANGE_LIFETIME内で同じメッセージIDを（同じエンドポイントとの通信で）再利用してはなりません（セクション4.8.2）。
Implementation Note: Several implementation strategies can be employed for generating Message IDs. In the simplest case, a CoAP endpoint generates Message IDs by keeping a single Message ID variable, which is changed each time a new Confirmable or Non-confirmable message is sent, regardless of the destination address or port. Endpoints dealing with large numbers of transactions could keep multiple Message ID variables, for example, per prefix or destination address. (Note that some receiving endpoints may not be able to distinguish unicast and multicast packets addressed to it, so endpoints generating Message IDs need to make sure these do not overlap.) It is strongly recommended that the initial value of the variable (e.g., on startup) be randomized, in order to make successful off-path attacks on the protocol less likely.
実装に関する注記：メッセージIDの生成には、いくつかの実装戦略を採用できます。最も単純なケースでは、CoAPエンドポイントは単一のメッセージID変数を保持することでメッセージIDを生成します。この変数は、宛先アドレスやポートに関係なく、新しい確認可能または確認不可能なメッセージが送信されるたびに変更されます。多数のトランザクションを処理するエンドポイントは、たとえば、プレフィックスまたは宛先アドレスごとに複数のメッセージID変数を保持できます。 （一部の受信エンドポイントは、自分宛てのユニキャストパケットとマルチキャストパケットを区別できない場合があるため、メッセージIDを生成するエンドポイントは、これらが重複しないようにする必要があります。）変数の初期値（たとえば、スタートアップ）をランダム化し、プロトコルへのオフパス攻撃を成功させないようにします。
For an Acknowledgement or Reset message to match a Confirmable or Non-confirmable message, the Message ID and source endpoint of the Acknowledgement or Reset message MUST match the Message ID and destination endpoint of the Confirmable or Non-confirmable message.
確認またはリセットメッセージが確認可能または確認不可能なメッセージと一致するためには、メッセージIDおよび確認またはリセットメッセージの送信元エンドポイントが、確認可能または確認不可能なメッセージのメッセージIDおよび宛先エンドポイントと一致する必要があります。
A recipient might receive the same Confirmable message (as indicated by the Message ID and source endpoint) multiple times within the EXCHANGE_LIFETIME (Section 4.8.2), for example, when its Acknowledgement went missing or didn't reach the original sender before the first timeout. The recipient SHOULD acknowledge each duplicate copy of a Confirmable message using the same Acknowledgement or Reset message but SHOULD process any request or response in the message only once. This rule MAY be relaxed in case the Confirmable message transports a request that is idempotent (see Section 5.1) or can be handled in an idempotent fashion. Examples for relaxed message deduplication: o A server might relax the requirement to answer all retransmissions of an idempotent request with the same response (Section 4.2), so that it does not have to maintain state for Message IDs. For example, an implementation might want to process duplicate transmissions of a GET, PUT, or DELETE request as separate requests if the effort incurred by duplicate processing is less expensive than keeping track of previous responses would be.
受信者は、EXCHANGE_LIFETIME（セクション4.8.2）内に同じ確認可能メッセージ（メッセージIDとソースエンドポイントで示される）を複数回受信する可能性があります。たとえば、最初の前に確認が失われたり、元の送信者に到達しなかった場合タイムアウト。受信者は、確認応答またはリセットメッセージを使用して確認可能なメッセージの重複コピーをそれぞれ確認する必要がありますが、メッセージ内の要求または応答は1回だけ処理する必要があります（SHOULD）。このルールは、確認可能メッセージがべき等（5.1節を参照）またはべき等の方法で処理できる要求を転送する場合に緩和される場合があります。緩和されたメッセージ重複排除の例：oサーバーは、同じ応答（セクション4.2）でべき等要求のすべての再送信に応答する要件を緩和し、メッセージIDの状態を維持する必要がないようにします。たとえば、以前の応答を追跡するよりも重複処理の負担が少ない場合、実装では、GET、PUT、またはDELETE要求の重複送信を個別の要求として処理することができます。
o A constrained server might even want to relax this requirement for certain non-idempotent requests if the application semantics make this trade-off favorable. For example, if the result of a POST request is just the creation of some short-lived state at the server, it may be less expensive to incur this effort multiple times for a request than keeping track of whether a previous transmission of the same request already was processed.
o 制約されたサーバーは、アプリケーションのセマンティクスによってこのトレードオフが有利になる場合、特定のべき等でない要求に対するこの要件を緩和することさえできます。たとえば、POSTリクエストの結果がサーバーでの短命な状態の作成である場合、同じリクエストの以前の送信かどうかを追跡するよりも、リクエストに対してこの作業を複数回発生させる方が費用がかからない場合があります。すでに処理されました。
A recipient might receive the same Non-confirmable message (as indicated by the Message ID and source endpoint) multiple times within NON_LIFETIME (Section 4.8.2). As a general rule that MAY be relaxed based on the specific semantics of a message, the recipient SHOULD silently ignore any duplicated Non-confirmable message and SHOULD process any request or response in the message only once.
受信者は、NON_LIFETIME内で（メッセージIDとソースエンドポイントによって示される）同じ確認不可能なメッセージを複数回受信する可能性があります（セクション4.8.2）。メッセージの特定のセマンティクスに基づいて緩和される可能性があるという一般的なルールとして、受信者は重複する確認不可能なメッセージを黙って無視し、メッセージ内の要求または応答を一度だけ処理する必要があります（SHOULD）。
While specific link layers make it beneficial to keep CoAP messages small enough to fit into their link-layer packets (see Section 1), this is a matter of implementation quality. The CoAP specification itself provides only an upper bound to the message size. Messages larger than an IP packet result in undesirable packet fragmentation. A CoAP message, appropriately encapsulated, SHOULD fit within a single IP packet (i.e., avoid IP fragmentation) and (by fitting into one UDP payload) obviously needs to fit within a single IP datagram. If the Path MTU is not known for a destination, an IP MTU of 1280 bytes SHOULD be assumed; if nothing is known about the size of the headers, good upper bounds are 1152 bytes for the message size and 1024 bytes for the payload size.
特定のリンクレイヤーでは、CoAPメッセージをリンクレイヤーパケット（セクション1を参照）に収まるほど小さく保つことが有益ですが、これは実装品質の問題です。 CoAP仕様自体は、メッセージサイズの上限のみを提供します。 IPパケットより大きいメッセージは、望ましくないパケットの断片化を引き起こします。適切にカプセル化されたCoAPメッセージは、単一のIPパケット内に収まる（SHOULD）（つまり、IPフラグメンテーションを回避する）必要があり、（1つのUDPペイロードに収まることによって）単一のIPデータグラムに収まる必要があることは明らかです。宛先のパスMTUが不明の場合、1280バイトのIP MTUを想定する必要があります（SHOULD）。ヘッダーのサイズがわからない場合、適切な上限は、メッセージサイズが1152バイト、ペイロードサイズが1024バイトです。
Implementation Note: CoAP's choice of message size parameters works well with IPv6 and with most of today's IPv4 paths. (However, with IPv4, it is harder to absolutely ensure that there is no IP fragmentation. If IPv4 support on unusual networks is a consideration, implementations may want to limit themselves to more conservative IPv4 datagram sizes such as 576 bytes; per [RFC0791], the absolute minimum value of the IP MTU for IPv4 is as low as 68 bytes, which would leave only 40 bytes minus security overhead for a UDP payload. Implementations extremely focused on this problem set might also set the IPv4 DF bit and perform some form of path MTU discovery [RFC4821]; this should generally be unnecessary in realistic use cases for CoAP, however.) A more important kind of fragmentation in many constrained networks is that on the adaptation layer (e.g., 6LoWPAN L2 packets are limited to 127 bytes including various overheads); this may motivate implementations to be frugal in their packet sizes and to move to block-wise transfers [BLOCK] when approaching three-digit message sizes.
実装上の注意：CoAPによるメッセージサイズパラメータの選択は、IPv6および今日のほとんどのIPv4パスで適切に機能します。 （ただし、IPv4では、IPの断片化がないことを完全に保証することは困難です。通常とは異なるネットワークでのIPv4サポートを検討する場合、実装は、[RFC0791]に従って、576バイトなどのより保守的なIPv4データグラムサイズに制限する必要があります。 、IPv4のIP MTUの絶対最小値は68バイトと低く、これにより、40バイトからUDPペイロードのセキュリティオーバーヘッドを差し引いたものになります。この問題セットに非常に重点を置いた実装では、IPv4 DFビットも設定され、何らかの形式で実行される場合があります。 of path MTU discovery [RFC4821];これは一般にCoAPの実際の使用例では不要であるはずです。）多くの制約されたネットワークでのより重要な種類の断片化は、アダプテーション層（たとえば、6LoWPAN L2パケットは127バイトに制限される）です。さまざまなオーバーヘッドを含む）;これにより、実装のパケットサイズが質素になり、3桁のメッセージサイズに近づいたときにブロック単位の転送[BLOCK]に移行する動機になる場合があります。
Message sizes are also of considerable importance to implementations on constrained nodes. Many implementations will need to allocate a buffer for incoming messages. If an implementation is too constrained to allow for allocating the above-mentioned upper bound, it could apply the following implementation strategy for messages not using DTLS security: Implementations receiving a datagram into a buffer that is too small are usually able to determine if the trailing portion of a datagram was discarded and to retrieve the initial portion. So, at least the CoAP header and options, if not all of the payload, are likely to fit within the buffer. A server can thus fully interpret a request and return a 4.13 (Request Entity Too Large; see Section 5.9.2.9) Response Code if the payload was truncated. A client sending an idempotent request and receiving a response larger than would fit in the buffer can repeat the request with a suitable value for the Block Option [BLOCK].
メッセージサイズは、制約されたノードでの実装にとっても非常に重要です。多くの実装では、着信メッセージ用のバッファを割り当てる必要があります。実装が制約されすぎて上記の上限を割り当てることができない場合、DTLSセキュリティを使用していないメッセージに次の実装戦略を適用できます。小さすぎるバッファにデータグラムを受信する実装は、通常、末尾にあるかどうかを判断できますデータグラムの一部が破棄され、最初の部分を取得しました。したがって、すべてのペイロードではないにしても、少なくともCoAPヘッダーとオプションは、バッファー内に収まる可能性があります。したがって、ペイロードが切り捨てられた場合、サーバーは要求を完全に解釈して4.13（要求エンティティが大きすぎます。セクション5.9.2.9を参照）応答コードを返すことができます。べき等の要求を送信し、バッファに収まるよりも大きな応答を受信するクライアントは、ブロックオプション[BLOCK]に適切な値を使用して要求を繰り返すことができます。
Basic congestion control for CoAP is provided by the exponential back-off mechanism in Section 4.2.
CoAPの基本的な輻輳制御は、セクション4.2の指数バックオフメカニズムによって提供されます。
In order not to cause congestion, clients (including proxies) MUST strictly limit the number of simultaneous outstanding interactions that they maintain to a given server (including proxies) to NSTART. An outstanding interaction is either a CON for which an ACK has not yet been received but is still expected (message layer) or a request for which neither a response nor an Acknowledgment message has yet been received but is still expected (which may both occur at the same time, counting as one outstanding interaction). The default value of NSTART for this specification is 1.
輻輳を引き起こさないために、クライアント（プロキシを含む）は、特定のサーバー（プロキシを含む）に対して維持する同時の未解決の対話の数をNSTARTに厳密に制限する必要があります。未処理の対話は、ACKがまだ受信されていないがまだ予期されているCON（メッセージレイヤー）、または応答も確認応答メッセージもまだ受信されていないがまだ予期されている要求（両方で発生する可能性があります）のいずれかです。同時に、1つの未処理のインタラクションとしてカウントされます）。この仕様のNSTARTのデフォルト値は1です。
Further congestion control optimizations and considerations are expected in the future, may for example provide automatic initialization of the CoAP transmission parameters defined in Section 4.8, and thus may allow a value for NSTART greater than one.
今後さらに輻輳制御の最適化と考慮事項が予想され、たとえば、セクション4.8で定義されたCoAP送信パラメーターの自動初期化が提供されるため、NSTARTの値が1より大きい可能性があります。
After EXCHANGE_LIFETIME, a client stops expecting a response to a Confirmable request for which no acknowledgment message was received.
EXCHANGE_LIFETIMEの後、クライアントは確認メッセージが受信されなかった確認可能な要求への応答を予期しなくなります。
The specific algorithm by which a client stops to "expect" a response to a Confirmable request that was acknowledged, or to a Non-confirmable request, is not defined. Unless this is modified by additional congestion control optimizations, it MUST be chosen in such a way that an endpoint does not exceed an average data rate of PROBING_RATE in sending to another endpoint that does not respond.
クライアントが確認応答された確認可能な要求または確認不可能な要求への応答を「期待する」ために停止する特定のアルゴリズムは定義されていません。これが追加の輻輳制御最適化によって変更されない限り、応答しない別のエンドポイントに送信するときにエンドポイントがPROBING_RATEの平均データレートを超えないように選択する必要があります。
Note: CoAP places the onus of congestion control mostly on the clients. However, clients may malfunction or actually be attackers, e.g., to perform amplification attacks (Section 11.3). To limit the damage (to the network and to its own energy resources), a server SHOULD implement some rate limiting for its response transmission based on reasonable assumptions about application requirements. This is most helpful if the rate limit can be made effective for the misbehaving endpoints, only.
注：CoAPは、輻輳制御の負担を主にクライアントに課します。ただし、クライアントは誤動作したり、実際に攻撃者になったりする可能性があります（増幅攻撃を実行するなど）（セクション11.3）。 （ネットワークと自身のエネルギーリソースへの）損傷を制限するために、サーバーは、アプリケーション要件に関する合理的な仮定に基づいて、応答送信にいくつかのレート制限を実装する必要があります（SHOULD）。これは、動作が正しくないエンドポイントに対してのみレート制限を有効にできる場合にのみ役立ちます。
Message transmission is controlled by the following parameters:
メッセージの送信は、次のパラメータによって制御されます。
+-------------------+---------------+
| name | default value |
+-------------------+---------------+
| ACK_TIMEOUT | 2 seconds |
| ACK_RANDOM_FACTOR | 1.5 |
| MAX_RETRANSMIT | 4 |
| NSTART | 1 |
| DEFAULT_LEISURE | 5 seconds |
| PROBING_RATE | 1 byte/second |
+-------------------+---------------+
Table 2: CoAP Protocol Parameters
表2：CoAPプロトコルパラメータ
The values for ACK_TIMEOUT, ACK_RANDOM_FACTOR, MAX_RETRANSMIT, NSTART, DEFAULT_LEISURE (Section 8.2), and PROBING_RATE may be configured to values specific to the application environment (including dynamically adjusted values); however, the configuration method is out of scope of this document. It is RECOMMENDED that an application environment use consistent values for these parameters; the specific effects of operating with inconsistent values in an application environment are outside the scope of the present specification.
ACK_TIMEOUT、ACK_RANDOM_FACTOR、MAX_RETRANSMIT、NSTART、DEFAULT_LEISURE（セクション8.2）、およびPROBING_RATEの値は、アプリケーション環境に固有の値（動的に調整された値を含む）に設定できます。ただし、設定方法はこのドキュメントの範囲外です。アプリケーション環境では、これらのパラメーターに一貫した値を使用することをお勧めします。アプリケーション環境で一貫性のない値で動作する特定の影響は、本明細書の範囲外です。
The transmission parameters have been chosen to achieve a behavior in the presence of congestion that is safe in the Internet. If a configuration desires to use different values, the onus is on the configuration to ensure these congestion control properties are not violated. In particular, a decrease of ACK_TIMEOUT below 1 second would violate the guidelines of [RFC5405]. ([RTO-CONSIDER] provides some additional background.) CoAP was designed to enable implementations that do not maintain round-trip-time (RTT) measurements. However, where it is desired to decrease the ACK_TIMEOUT significantly or increase NSTART, this can only be done safely when maintaining such measurements. Configurations MUST NOT decrease ACK_TIMEOUT or increase NSTART without using mechanisms that ensure congestion control safety, either defined in the configuration or in future standards documents.
送信パラメータは、インターネットで安全な輻輳が発生した場合の動作を実現するように選択されています。構成が異なる値を使用したい場合、これらの輻輳制御プロパティに違反しないようにする責任は構成にあります。特に、1秒未満のACK_TIMEOUTの減少は、[RFC5405]のガイドラインに違反します。 （[RTO-CONSIDER]は追加の背景情報を提供します。）CoAPは、往復時間（RTT）測定を維持しない実装を可能にするように設計されました。ただし、ACK_TIMEOUTを大幅に減らすか、NSTARTを増やすことが望ましい場合は、そのような測定を維持する場合にのみ安全に行うことができます。構成は、構成または将来の標準ドキュメントで定義されている、輻輳制御の安全性を保証するメカニズムを使用せずに、ACK_TIMEOUTを減らしたり、NSTARTを増やしたりしてはなりません。
ACK_RANDOM_FACTOR MUST NOT be decreased below 1.0, and it SHOULD have a value that is sufficiently different from 1.0 to provide some protection from synchronization effects.
ACK_RANDOM_FACTORを1.0未満にしてはならず、同期効果からの保護を提供するために、1.0とは十分に異なる値にする必要があります。
MAX_RETRANSMIT can be freely adjusted, but a value that is too small will reduce the probability that a Confirmable message is actually received, while a larger value than given here will require further adjustments in the time values (see Section 4.8.2).
MAX_RETRANSMITは自由に調整できますが、値が小さすぎると、Confirmableメッセージが実際に受信される可能性が低くなります。ここで指定した値よりも大きい値では、時間値をさらに調整する必要があります（4.8.2項を参照）。
If the choice of transmission parameters leads to an increase of derived time values (see Section 4.8.2), the configuration mechanism MUST ensure the adjusted value is also available to all the endpoints with which these adjusted values are to be used to communicate.
送信パラメーターの選択が派生時間値の増加につながる場合（セクション4.8.2を参照）、構成メカニズムは、調整された値が通信に使用されるすべてのエンドポイントでも使用できることを確認する必要があります。
The combination of ACK_TIMEOUT, ACK_RANDOM_FACTOR, and MAX_RETRANSMIT influences the timing of retransmissions, which in turn influences how long certain information items need to be kept by an implementation. To be able to unambiguously reference these derived time values, we give them names as follows:
ACK_TIMEOUT、ACK_RANDOM_FACTOR、およびMAX_RETRANSMITの組み合わせは、再送信のタイミングに影響します。これは、特定の情報アイテムが実装によって保持される必要がある期間に影響します。これらの派生時間値を明確に参照できるように、次のように名前を付けます。
o MAX_TRANSMIT_SPAN is the maximum time from the first transmission of a Confirmable message to its last retransmission. For the default transmission parameters, the value is (2+4+8+16)*1.5 = 45 seconds, or more generally:
o MAX_TRANSMIT_SPANは、確認可能なメッセージの最初の送信から最後の再送信までの最大時間です。デフォルトの送信パラメータの場合、値は（2 + 4 + 8 + 16）* 1.5 = 45秒、またはより一般的には次のとおりです。
ACK_TIMEOUT * ((2 ** MAX_RETRANSMIT) - 1) * ACK_RANDOM_FACTOR
o MAX_TRANSMIT_WAIT is the maximum time from the first transmission of a Confirmable message to the time when the sender gives up on receiving an acknowledgement or reset. For the default transmission parameters, the value is (2+4+8+16+32)*1.5 = 93 seconds, or more generally:
o MAX_TRANSMIT_WAITは、確認可能なメッセージの最初の送信から、送信者が確認またはリセットの受信を中止するまでの最大時間です。デフォルトの送信パラメータの場合、値は（2 + 4 + 8 + 16 + 32）* 1.5 = 93秒、またはより一般的には次のとおりです。
ACK_TIMEOUT * ((2 ** (MAX_RETRANSMIT + 1)) - 1) *
ACK_RANDOM_FACTOR
In addition, some assumptions need to be made on the characteristics of the network and the nodes.
さらに、ネットワークとノードの特性について、いくつかの仮定を行う必要があります。
o MAX_LATENCY is the maximum time a datagram is expected to take from the start of its transmission to the completion of its reception. This constant is related to the MSL (Maximum Segment Lifetime) of [RFC0793], which is "arbitrarily defined to be 2 minutes" ([RFC0793] glossary, page 81). Note that this is not necessarily smaller than MAX_TRANSMIT_WAIT, as MAX_LATENCY is not intended to describe a situation when the protocol works well, but the worst-case situation against which the protocol has to guard. We, also arbitrarily, define MAX_LATENCY to be 100 seconds. Apart from being reasonably realistic for the bulk of configurations as well as close to the historic choice for TCP, this value also allows Message ID lifetime timers to be represented in 8 bits (when measured in seconds). In these calculations, there is no assumption that the direction of the transmission is irrelevant (i.e., that the network is symmetric); there is just the assumption that the same value can reasonably be used as a maximum value for both directions. If that is not the case, the following calculations become only slightly more complex.
o MAX_LATENCYは、データグラムが送信の開始から受信の完了までにかかると予想される最大時間です。この定数は[RFC0793]のMSL（Maximum Segment Lifetime）に関連しており、「2分間であると任意に定義される」（[RFC0793]用語集、81ページ）。 MAX_LATENCYはプロトコルが適切に機能する状況を説明することを目的としていないため、これは必ずしもMAX_TRANSMIT_WAITよりも小さいわけではありませんが、プロトコルが保護しなければならない最悪の状況です。また、任意で、MAX_LATENCYを100秒に定義します。 TCPの歴史的な選択に近いだけでなく、大部分の構成に対して合理的に現実的であることに加えて、この値により、メッセージIDライフタイムタイマーを8ビットで表すことができます（秒単位で測定した場合）。これらの計算では、伝送の方向が無関係である（つまり、ネットワークが対称である）との仮定はありません。同じ値を両方向の最大値として合理的に使用できるという仮定があります。そうでない場合、以下の計算は少しだけ複雑になります。
o PROCESSING_DELAY is the time a node takes to turn around a Confirmable message into an acknowledgement. We assume the node will attempt to send an ACK before having the sender time out, so as a conservative assumption we set it equal to ACK_TIMEOUT.
o PROCESSING_DELAYは、ノードが確認可能メッセージを確認応答に変えるのにかかる時間です。ノードは送信者がタイムアウトする前にACKを送信しようとするため、控えめな仮定として、ACK_TIMEOUTに設定します。
o MAX_RTT is the maximum round-trip time, or:
o MAX_RTTは最大往復時間、または：
(2 * MAX_LATENCY) + PROCESSING_DELAY
（2 * MAX_LATENCY）+ PROCESSING_DELAY
From these values, we can derive the following values relevant to the protocol operation:
これらの値から、プロトコル操作に関連する次の値を導出できます。
o EXCHANGE_LIFETIME is the time from starting to send a Confirmable message to the time when an acknowledgement is no longer expected, i.e., message-layer information about the message exchange can be purged. EXCHANGE_LIFETIME includes a MAX_TRANSMIT_SPAN, a MAX_LATENCY forward, PROCESSING_DELAY, and a MAX_LATENCY for the way back. Note that there is no need to consider MAX_TRANSMIT_WAIT if the configuration is chosen such that the last waiting period (ACK_TIMEOUT * (2 ** MAX_RETRANSMIT) or the difference between MAX_TRANSMIT_SPAN and MAX_TRANSMIT_WAIT) is less than MAX_LATENCY -- which is a likely choice, as MAX_LATENCY is a worst-case value unlikely to be met in the real world. In this case, EXCHANGE_LIFETIME simplifies to:
o EXCHANGE_LIFETIMEは、確認可能メッセージの送信を開始してから、確認応答が不要になるまでの時間です。つまり、メッセージ交換に関するメッセージレイヤー情報をパージできます。 EXCHANGE_LIFETIMEには、MAX_TRANSMIT_SPAN、MAX_LATENCYフォワード、PROCESSING_DELAY、MAX_LATENCYが含まれています。最後の待機期間（ACK_TIMEOUT *（2 ** MAX_RETRANSMIT）またはMAX_TRANSMIT_SPANとMAX_TRANSMIT_WAITの差）がMAX_LATENCY未満になるように構成が選択されている場合、MAX_TRANSMIT_WAITを考慮する必要がないことに注意してください。 MAX_LATENCYは、現実の世界ではありそうもない最悪の値です。この場合、EXCHANGE_LIFETIMEは次のように単純化されます。
MAX_TRANSMIT_SPAN + (2 * MAX_LATENCY) + PROCESSING_DELAY
or 247 seconds with the default transmission parameters.
またはデフォルトの送信パラメータで247秒。
o NON_LIFETIME is the time from sending a Non-confirmable message to the time its Message ID can be safely reused. If multiple transmission of a NON message is not used, its value is MAX_LATENCY, or 100 seconds. However, a CoAP sender might send a NON message multiple times, in particular for multicast applications. While the period of reuse is not bounded by the specification, an expectation of reliable detection of duplication at the receiver is on the timescales of MAX_TRANSMIT_SPAN. Therefore, for this purpose, it is safer to use the value:
o NON_LIFETIMEは、確認不可能なメッセージを送信してから、そのメッセージIDを安全に再利用できるようになるまでの時間です。 NONメッセージの複数送信を使用しない場合、その値はMAX_LATENCY、つまり100秒です。ただし、CoAP送信者は、特にマルチキャストアプリケーションの場合、NONメッセージを複数回送信する可能性があります。再利用の期間は仕様によって制限されませんが、レシーバーでの重複の信頼できる検出は、MAX_TRANSMIT_SPANのタイムスケールで期待されます。したがって、この目的のためには、値を使用する方が安全です。
MAX_TRANSMIT_SPAN + MAX_LATENCY
MAX_TRANSMIT_SPAN + MAX_LATENCY
or 145 seconds with the default transmission parameters; however, an implementation that just wants to use a single timeout value for retiring Message IDs can safely use the larger value for EXCHANGE_LIFETIME.
またはデフォルトの送信パラメータで145秒。ただし、メッセージIDの廃止に単一のタイムアウト値を使用するだけの実装では、EXCHANGE_LIFETIMEの値を大きくしても安全です。
Table 3 lists the derived parameters introduced in this subsection with their default values.
表3に、このサブセクションで紹介する派生パラメーターとそのデフォルト値を示します。
+-------------------+---------------+
| name | default value |
+-------------------+---------------+
| MAX_TRANSMIT_SPAN | 45 s |
| MAX_TRANSMIT_WAIT | 93 s |
| MAX_LATENCY | 100 s |
| PROCESSING_DELAY | 2 s |
| MAX_RTT | 202 s |
| EXCHANGE_LIFETIME | 247 s |
| NON_LIFETIME | 145 s |
+-------------------+---------------+
Table 3: Derived Protocol Parameters
表3：派生プロトコルのパラメーター
CoAP operates under a similar request/response model as HTTP: a CoAP endpoint in the role of a "client" sends one or more CoAP requests to a "server", which services the requests by sending CoAP responses. Unlike HTTP, requests and responses are not sent over a previously established connection but are exchanged asynchronously over CoAP messages.
CoAPはHTTPと同様の要求/応答モデルの下で動作します。「クライアント」の役割のCoAPエンドポイントは、1つ以上のCoAP要求を「サーバー」に送信し、「サーバー」はCoAP応答を送信して要求を処理します。 HTTPとは異なり、要求と応答は以前に確立された接続を介して送信されるのではなく、CoAPメッセージを介して非同期的に交換されます。
A CoAP request consists of the method to be applied to the resource, the identifier of the resource, a payload and Internet media type (if any), and optional metadata about the request.
CoAP要求は、リソースに適用されるメソッド、リソースの識別子、ペイロードとインターネットメディアタイプ（存在する場合）、および要求に関するオプションのメタデータで構成されます。
CoAP supports the basic methods of GET, POST, PUT, and DELETE, which are easily mapped to HTTP. They have the same properties of safe (only retrieval) and idempotent (you can invoke it multiple times with the same effects) as HTTP (see Section 9.1 of [RFC2616]). The GET method is safe; therefore, it MUST NOT take any other action on a resource other than retrieval. The GET, PUT, and DELETE methods MUST be performed in such a way that they are idempotent. POST is not idempotent, because its effect is determined by the origin server and dependent on the target resource; it usually results in a new resource being created or the target resource being updated.
CoAPは、GET、POST、PUT、およびDELETEの基本的なメソッドをサポートしており、これらはHTTPに簡単にマップされます。それらには、HTTPと同じプロパティ（安全な取得のみ）およびべき等（同じ効果で複数回呼び出すことができます）がHTTPと同じです（[RFC2616]のセクション9.1を参照）。 GETメソッドは安全です。したがって、リソースに対して取得以外のアクションを実行してはなりません（MUST NOT）。 GET、PUT、DELETEメソッドは、べき等になるように実行する必要があります。 POSTは、元のサーバーによって決定され、ターゲットリソースに依存するため、べき等ではありません。通常、新しいリソースが作成されるか、ターゲットリソースが更新されます。
A request is initiated by setting the Code field in the CoAP header of a Confirmable or a Non-confirmable message to a Method Code and including request information.
確認メッセージまたは確認不能メッセージのCoAPヘッダーのコードフィールドをメソッドコードに設定し、リクエスト情報を含めることで、リクエストが開始されます。
The methods used in requests are described in detail in Section 5.8.
リクエストで使用されるメソッドについては、セクション5.8で詳しく説明しています。
After receiving and interpreting a request, a server responds with a CoAP response that is matched to the request by means of a client-generated token (Section 5.3); note that this is different from the Message ID that matches a Confirmable message to its Acknowledgement.
要求を受信して解釈した後、サーバーは、クライアントが生成したトークンを使用して、要求に一致するCoAP応答で応答します（セクション5.3）。これは、確認可能メッセージとその確認を照合するメッセージIDとは異なります。
A response is identified by the Code field in the CoAP header being set to a Response Code. Similar to the HTTP Status Code, the CoAP Response Code indicates the result of the attempt to understand and satisfy the request. These codes are fully defined in Section 5.9. The Response Code numbers to be set in the Code field of the CoAP header are maintained in the CoAP Response Code Registry (Section 12.1.2).
応答は、CoAPヘッダーのコードフィールドが応答コードに設定されることで識別されます。 HTTPステータスコードと同様に、CoAP応答コードは、要求を理解して満足する試みの結果を示します。これらのコードはセクション5.9で完全に定義されています。 CoAPヘッダーのコードフィールドに設定される応答コード番号は、CoAP応答コードレジストリ（セクション12.1.2）に保持されます。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|class| detail |
+-+-+-+-+-+-+-+-+
Figure 9: Structure of a Response Code
図9：応答コードの構造
The upper three bits of the 8-bit Response Code number define the class of response. The lower five bits do not have any categorization role; they give additional detail to the overall class (Figure 9).
8ビットの応答コード番号の上位3ビットは、応答のクラスを定義します。下位5ビットには分類の役割はありません。クラス全体の詳細を示します（図9）。
As a human-readable notation for specifications and protocol diagnostics, CoAP code numbers including the Response Code are documented in the format "c.dd", where "c" is the class in decimal, and "dd" is the detail as a two-digit decimal. For example, "Forbidden" is written as 4.03 -- indicating an 8-bit code value of hexadecimal 0x83 (4*0x20+3) or decimal 131 (4*32+3).
仕様とプロトコル診断の人間が読める表記として、応答コードを含むCoAPコード番号は「c.dd」の形式で文書化されています。「c」は10進数のクラス、「dd」は2つの詳細です10進数。たとえば、「Forbidden」は4.03と記述され、8ビットのコード値が16進数の0x83（4 * 0x20 + 3）または10進数の131（4 * 32 + 3）であることを示します。
There are 3 classes of Response Codes:
応答コードには3つのクラスがあります。
2 - Success: The request was successfully received, understood, and accepted.
2-成功：リクエストは正常に受信され、理解され、受け入れられました。
4 - Client Error: The request contains bad syntax or cannot be fulfilled.
4-クライアントエラー：リクエストに不正な構文が含まれているか、実行できません。
5 - Server Error: The server failed to fulfill an apparently valid request.
5-サーバーエラー：サーバーは明らかに有効な要求を実行できませんでした。
The Response Codes are designed to be extensible: Response Codes in the Client Error or Server Error class that are unrecognized by an endpoint are treated as being equivalent to the generic Response Code of that class (4.00 and 5.00, respectively). However, there is no generic Response Code indicating success, so a Response Code in the Success class that is unrecognized by an endpoint can only be used to determine that the request was successful without any further details.
応答コードは拡張できるように設計されています。エンドポイントによって認識されないクライアントエラーまたはサーバーエラークラスの応答コードは、そのクラスの一般的な応答コード（それぞれ4.00および5.00）と同等として扱われます。ただし、成功を示す一般的な応答コードはないため、エンドポイントで認識されないSuccessクラスの応答コードは、詳細がなくても要求が成功したかどうかを判断するためにのみ使用できます。
The possible Response Codes are described in detail in Section 5.9.
可能な応答コードについては、セクション5.9で詳しく説明しています。
Responses can be sent in multiple ways, which are defined in the following subsections.
応答は、以下のサブセクションで定義されている複数の方法で送信できます。
In the most basic case, the response is carried directly in the Acknowledgement message that acknowledges the request (which requires that the request was carried in a Confirmable message). This is called a "Piggybacked Response".
最も基本的なケースでは、応答は、要求を確認する確認メッセージで直接伝えられます（要求が確認可能なメッセージで伝えられたことを必要とします）。これは「ピギーバック応答」と呼ばれます。
The response is returned in the Acknowledgement message, independent of whether the response indicates success or failure. In effect, the response is piggybacked on the Acknowledgement message, and no separate message is required to return the response.
応答が成功か失敗かを問わず、応答は確認応答メッセージで返されます。実際には、応答は確認応答メッセージに便乗され、応答を返すために別のメッセージは必要ありません。
Implementation Note: The protocol leaves the decision whether to piggyback a response or not (i.e., send a separate response) to the server. The client MUST be prepared to receive either. On the quality-of-implementation level, there is a strong expectation that servers will implement code to piggyback whenever possible -- saving resources in the network and both at the client and at the server.
実装上の注意：プロトコルは、応答をピギーバックするかどうか（つまり、個別の応答を送信するかどうか）をサーバーに残します。クライアントはどちらかを受信する準備をしなければなりません。実装の品質レベルでは、サーバーは可能な限り便乗するコードを実装し、ネットワークとクライアントおよびサーバーの両方でリソースを節約することが強く期待されています。
It may not be possible to return a piggybacked response in all cases. For example, a server might need longer to obtain the representation of the resource requested than it can wait to send back the Acknowledgement message, without risking the client repeatedly retransmitting the request message (see also the discussion of PROCESSING_DELAY in Section 4.8.2). The response to a request carried in a Non-confirmable message is always sent separately (as there is no Acknowledgement message).
すべてのケースで便乗した応答を返すことができない場合があります。たとえば、サーバーがリクエストされたリソースの表現を取得するのに、クライアントがリクエストメッセージを繰り返し再送信する危険を冒さずに、確認メッセージの返信を待つよりも長い時間が必要な場合があります（セクション4.8.2のPROCESSING_DELAYの説明も参照）。確認不可能なメッセージで送信された要求への応答は、常に個別に送信されます（確認応答メッセージがないため）。
One way to implement this in a server is to initiate the attempt to obtain the resource representation and, while that is in progress, time out an acknowledgement timer. A server may also immediately send an acknowledgement if it knows in advance that there will be no piggybacked response. In both cases, the acknowledgement effectively is a promise that the request will be acted upon later.
これをサーバーに実装する1つの方法は、リソース表現を取得する試みを開始し、それが進行中の間に確認タイマーをタイムアウトにすることです。サーバーは、ピギーバックされた応答がないことを事前に知っている場合、すぐに確認応答を送信することもできます。どちらの場合も、確認応答は事実上、要求が後で実行されるという約束です。
When the server finally has obtained the resource representation, it sends the response. When it is desired that this message is not lost, it is sent as a Confirmable message from the server to the client and answered by the client with an Acknowledgement, echoing the new Message ID chosen by the server. (It may also be sent as a Non-confirmable message; see Section 5.2.3.)
サーバーが最終的にリソース表現を取得すると、応答を送信します。このメッセージが失われないようにする必要がある場合は、サーバーからクライアントに確認可能なメッセージとして送信され、サーバーが選択した新しいメッセージIDをエコーして、クライアントが確認応答します。 （確認できないメッセージとして送信される場合もあります。セクション5.2.3を参照してください。）
When the server chooses to use a separate response, it sends the Acknowledgement to the Confirmable request as an Empty message. Once the server sends back an Empty Acknowledgement, it MUST NOT send back the response in another Acknowledgement, even if the client retransmits another identical request. If a retransmitted request is received (perhaps because the original Acknowledgement was delayed), another Empty Acknowledgement is sent, and any response MUST be sent as a separate response.
サーバーが別の応答を使用することを選択すると、確認応答を空のメッセージとして確認可能要求に送信します。サーバーがEmpty Acknowledgementを送信すると、クライアントが別の同一の要求を再送信した場合でも、サーバーは別のAcknowledgementで応答を送信してはなりません（MUST NOT）。再送信された要求が受信された場合（おそらく元の確認応答が遅延したため）、別の空の確認応答が送信され、応答は別の応答として送信する必要があります（MUST）。
If the server then sends a Confirmable response, the client's Acknowledgement to that response MUST also be an Empty message (one that carries neither a request nor a response). The server MUST stop retransmitting its response on any matching Acknowledgement (silently ignoring any Response Code or payload) or Reset message.
サーバーが確認可能な応答を送信する場合、その応答に対するクライアントの確認応答も空のメッセージ（要求も応答も送信しないメッセージ）である必要があります。サーバーは、一致する確認応答（応答コードまたはペイロードを黙って無視）またはリセットメッセージで応答の再送信を停止する必要があります。
Implementation Notes: Note that, as the underlying datagram transport may not be sequence-preserving, the Confirmable message carrying the response may actually arrive before or after the Acknowledgement message for the request; for the purposes of terminating the retransmission sequence, this also serves as an acknowledgement. Note also that, while the CoAP protocol itself does not make any specific demands here, there is an expectation that the response will come within a time frame that is reasonable from an application point of view. As there is no underlying transport protocol that could be instructed to run a keep-alive mechanism, the requester may want to set up a timeout that is unrelated to CoAP's retransmission timers in case the server is destroyed or otherwise unable to send the response.
実装上の注意：基礎となるデータグラムトランスポートはシーケンスを保持しない可能性があるため、応答を含む確認可能なメッセージは、要求の確認応答メッセージの前または後に実際に到着する場合があります。再送信シーケンスを終了するために、これは確認応答としても機能します。また、ここではCoAPプロトコル自体は特定の要求を行いませんが、アプリケーションの観点からは妥当な時間枠内に応答が来ることが期待されていることにも注意してください。キープアライブメカニズムを実行するように指示できる基になるトランスポートプロトコルがないため、リクエスタは、サーバーが破壊された場合や応答を送信できない場合に備えて、CoAPの再送信タイマーとは関係のないタイムアウトを設定できます。
If the request message is Non-confirmable, then the response SHOULD be returned in a Non-confirmable message as well. However, an endpoint MUST be prepared to receive a Non-confirmable response (preceded or followed by an Empty Acknowledgement message) in reply to a Confirmable request, or a Confirmable response in reply to a Non-confirmable request.
要求メッセージが確認できない場合、応答は確認できないメッセージでも返される必要があります（SHOULD）。ただし、エンドポイントは、確認可能な要求に応答して確認不可能な応答（空の確認メッセージが前または後に続く）、または確認不可能な要求に応答して確認可能な応答を受信できるように準備する必要があります。
Regardless of how a response is sent, it is matched to the request by means of a token that is included by the client in the request, along with additional address information of the corresponding endpoint.
応答の送信方法に関係なく、対応するエンドポイントの追加のアドレス情報とともに、クライアントが要求に含めるトークンによって、応答と要求が照合されます。
The Token is used to match a response with a request. The token value is a sequence of 0 to 8 bytes. (Note that every message carries a token, even if it is of zero length.) Every request carries a client-generated token that the server MUST echo (without modification) in any resulting response.
トークンは、応答と要求を照合するために使用されます。トークン値は、0から8バイトのシーケンスです。 （長さがゼロであっても、すべてのメッセージがトークンを運ぶことに注意してください。）すべての要求は、サーバーが結果の応答で（変更なしで）エコーするクライアント生成トークンを運ぶ。
A token is intended for use as a client-local identifier for differentiating between concurrent requests (see Section 5.3); it could have been called a "request ID".
トークンは、同時要求を区別するためのクライアントローカル識別子としての使用を目的としています（セクション5.3を参照）。 「リクエストID」と呼ぶこともできます。
The client SHOULD generate tokens in such a way that tokens currently in use for a given source/destination endpoint pair are unique. (Note that a client implementation can use the same token for any request if it uses a different endpoint each time, e.g., a different source port number.) An empty token value is appropriate e.g., when no other tokens are in use to a destination, or when requests are made serially per destination and receive piggybacked responses. There are, however, multiple possible implementation strategies to fulfill this.
クライアントは、特定の送信元/宛先エンドポイントのペアで現在使用されているトークンが一意になるように、トークンを生成する必要があります（SHOULD）。 （クライアントの実装は、毎回異なるエンドポイントを使用する場合、たとえば異なる送信元ポート番号を使用する場合、どの要求にも同じトークンを使用できることに注意してください。）空のトークン値は、宛先に他のトークンが使用されていない場合などに適切です。 、またはリクエストが宛先ごとに連続して行われ、ピギーバックされた応答を受け取る場合。ただし、これを実現するための実装戦略は複数あります。
A client sending a request without using Transport Layer Security (Section 9) SHOULD use a nontrivial, randomized token to guard against spoofing of responses (Section 11.4). This protective use of tokens is the reason they are allowed to be up to 8 bytes in size. The actual size of the random component to be used for the Token depends on the security requirements of the client and the level of threat posed by spoofing of responses. A client that is connected to the general Internet SHOULD use at least 32 bits of randomness, keeping in mind that not being directly connected to the Internet is not necessarily sufficient protection against spoofing. (Note that the Message ID adds little in protection as it is usually sequentially assigned, i.e., guessable, and can be circumvented by spoofing a separate response.) Clients that want to optimize the Token length may further want to detect the level of ongoing attacks (e.g., by tallying recent Token mismatches in incoming messages) and adjust the Token length upwards appropriately. [RFC4086] discusses randomness requirements for security.
トランスポート層セキュリティを使用せずにリクエストを送信するクライアント（セクション9）は、ランダムなトークンを使用して、応答のスプーフィングを防止する必要があります（セクション11.4）。この保護的なトークンの使用が、最大8バイトのサイズを許可されている理由です。トークンに使用されるランダムコンポーネントの実際のサイズは、クライアントのセキュリティ要件と、応答のなりすましによってもたらされる脅威のレベルによって異なります。一般的なインターネットに接続しているクライアントは、少なくとも32ビットのランダム性を使用する必要があります（SHOULD）。インターネットに直接接続していなくても、スプーフィングに対する十分な保護とは限らないことに注意してください。 （通常、メッセージIDは順次割り当てられるため、メッセージIDはほとんど保護されません。つまり、推測可能であり、個別の応答をスプーフィングすることで回避できます。）トークンの長さを最適化したいクライアントは、進行中の攻撃のレベルをさらに検出したい場合があります（たとえば、受信メッセージの最近のトークンの不一致を集計することにより）、トークンの長さを適切に上方に調整します。 [RFC4086]は、セキュリティのランダム性要件について説明しています。
An endpoint receiving a token it did not generate MUST treat the token as opaque and make no assumptions about its content or structure.
生成しなかったトークンを受信するエンドポイントは、トークンを不透明として扱い、その内容や構造について何も仮定してはなりません（MUST）。
The exact rules for matching a response to a request are as follows:
リクエストへの応答を照合するための正確なルールは次のとおりです。
1. The source endpoint of the response MUST be the same as the destination endpoint of the original request.
1. 応答のソースエンドポイントは、元の要求の宛先エンドポイントと同じである必要があります。
2. In a piggybacked response, the Message ID of the Confirmable request and the Acknowledgement MUST match, and the tokens of the response and original request MUST match. In a separate response, just the tokens of the response and original request MUST match.
2. ピギーバック応答では、確認可能要求のメッセージIDと確認応答が一致する必要があり、応答と元の要求のトークンが一致する必要があります。別の応答では、応答と元の要求のトークンのみが一致する必要があります。
In case a message carrying a response is unexpected (the client is not waiting for a response from the identified endpoint, at the endpoint addressed, and/or with the given token), the response is rejected (Sections 4.2 and 4.3).
応答を伴うメッセージが予期しないものである場合（クライアントは、識別されたエンドポイントからの応答、アドレス指定されたエンドポイント、および/または指定されたトークンを使用して待機していない）の場合、応答は拒否されます（セクション4.2および4.3）。
Implementation Note: A client that receives a response in a CON message may want to clean up the message state right after sending the ACK. If that ACK is lost and the server retransmits the CON, the client may no longer have any state to which to correlate this response, making the retransmission an unexpected message; the client will likely send a Reset message so it does not receive any more retransmissions. This behavior is normal and not an indication of an error. (Clients that are not aggressively optimized in their state memory usage will still have message state that will identify the second CON as a retransmission. Clients that actually expect more messages from the server [OBSERVE] will have to keep state in any case.)
実装上の注意：CONメッセージで応答を受信するクライアントは、ACKを送信した直後にメッセージの状態をクリーンアップしたい場合があります。そのACKが失われ、サーバーがCONを再送信すると、クライアントはこの応答を関連付ける状態を持たなくなり、再送信が予期しないメッセージになります。クライアントはリセットメッセージを送信する可能性が高いため、再送信を受信しません。この動作は正常であり、エラーを示すものではありません。 （状態のメモリ使用量が積極的に最適化されていないクライアントは、2番目のCONを再送信として識別するメッセージ状態を保持します。サーバーからのメッセージを実際に期待するクライアント[OBSERVE]は、どのような場合でも状態を維持する必要があります。）
Both requests and responses may include a list of one or more options. For example, the URI in a request is transported in several options, and metadata that would be carried in an HTTP header in HTTP is supplied as options as well.
要求と応答の両方に、1つ以上のオプションのリストが含まれる場合があります。たとえば、リクエスト内のURIはいくつかのオプションで転送され、HTTPのHTTPヘッダーに含まれるメタデータもオプションとして提供されます。
CoAP defines a single set of options that are used in both requests and responses:
CoAPは、要求と応答の両方で使用されるオプションの単一のセットを定義します。
o Content-Format
o コンテンツ形式
o ETag
o ETag
o Location-Path
o ロケーションパス
o Location-Query
o 場所クエリ
o Max-Age
o マックスエイジ
o Proxy-Uri
o Ｐろｘｙーうり
o Proxy-Scheme
o プロキシスキーム
o Uri-Host
o うりーほｓｔ
o Uri-Path
o 道路
o Uri-Port o Uri-Query
お うりーぽｒｔ お うりーくえｒｙ
o Accept
o 受け入れる
o If-Match
o イフマッチ
o If-None-Match
o If-None-Match
o Size1
o サイズ1
The semantics of these options along with their properties are defined in detail in Section 5.10.
これらのオプションのセマンティクスとそのプロパティは、セクション5.10で詳しく定義されています。
Not all options are defined for use with all methods and Response Codes. The possible options for methods and Response Codes are defined in Sections 5.8 and 5.9, respectively. In case an option is not defined for a Method or Response Code, it MUST NOT be included by a sender and MUST be treated like an unrecognized option by a recipient.
すべてのオプションがすべてのメソッドと応答コードで使用できるように定義されているわけではありません。メソッドおよび応答コードの可能なオプションは、それぞれセクション5.8および5.9で定義されています。オプションがメソッドまたは応答コードに対して定義されていない場合、送信者はそれを含めてはならず、受信者が認識できないオプションのように扱わなければなりません（MUST）。
Options fall into one of two classes: "critical" or "elective". The difference between these is how an option unrecognized by an endpoint is handled:
オプションは、「クリティカル」または「選択」の2つのクラスのいずれかに分類されます。これらの違いは、エンドポイントで認識されないオプションの処理方法です。
o Upon reception, unrecognized options of class "elective" MUST be silently ignored.
o 受信時に、「選択的」クラスの認識されないオプションは黙って無視されなければなりません。
o Unrecognized options of class "critical" that occur in a Confirmable request MUST cause the return of a 4.02 (Bad Option) response. This response SHOULD include a diagnostic payload describing the unrecognized option(s) (see Section 5.5.2).
o Confirmable要求で発生する「クリティカル」クラスの認識されないオプションは、4.02（不良オプション）応答を返さなければなりません（MUST）。この応答には、認識されないオプションを説明する診断ペイロードを含める必要があります（セクション5.5.2を参照）。
o Unrecognized options of class "critical" that occur in a Confirmable response, or piggybacked in an Acknowledgement, MUST cause the response to be rejected (Section 4.2).
o 確認可能な応答で発生する、または確認応答で便乗するクラス「クリティカル」の認識されないオプションは、応答を拒否する必要があります（セクション4.2）。
o Unrecognized options of class "critical" that occur in a Non-confirmable message MUST cause the message to be rejected (Section 4.3).
o 確認不可能なメッセージで発生する「クリティカル」クラスの認識されないオプションは、メッセージを拒否する必要があります（セクション4.3）。
Note that, whether critical or elective, an option is never "mandatory" (it is always optional): these rules are defined in order to enable implementations to stop processing options they do not understand or implement.
重要であるか選択的であるかに関係なく、オプションは決して「必須」ではないことに注意してください（常にオプションです）。これらのルールは、理解または実装していないオプションの処理を実装が停止できるようにするために定義されています。
Critical/elective rules apply to non-proxying endpoints. A proxy processes options based on Unsafe/Safe-to-Forward classes as defined in Section 5.7.
重要/選択ルールは、非プロキシエンドポイントに適用されます。プロキシは、セクション5.7で定義されているUnsafe / Safe-to-Forwardクラスに基づいてオプションを処理します。
In addition to an option being marked as critical or elective, options are also classified based on how a proxy is to deal with the option if it does not recognize it. For this purpose, an option can either be considered Unsafe to forward (UnSafe is set) or Safe-to-Forward (UnSafe is clear).
オプションがクリティカルまたは選択的としてマークされていることに加えて、オプションは、プロキシがオプションを認識しない場合のオプションの処理方法に基づいて分類されます。この目的のために、オプションは転送するのが安全ではない（UnSafeが設定されている）または転送するのが安全である（UnSafeが明確である）と見なすことができます。
In addition, for an option that is marked Safe-to-Forward, the option number indicates whether or not it is intended to be part of the Cache-Key (Section 5.6) in a request. If some of the NoCacheKey bits are 0, it is; if all NoCacheKey bits are 1, it is not (see Section 5.4.6).
さらに、Safe-to-Forwardとマークされているオプションの場合、オプション番号は、リクエスト内のキャッシュキー（セクション5.6）の一部となるかどうかを示します。 NoCacheKeyビットの一部が0の場合は0です。すべてのNoCacheKeyビットが1の場合は1ではありません（セクション5.4.6を参照）。
Note: The Cache-Key indication is relevant only for proxies that do not implement the given option as a request option and instead rely on the Unsafe/Safe-to-Forward indication only. For example, for ETag, actually using the request option as a part of the Cache-Key is grossly inefficient, but it is the best thing one can do if ETag is not implemented by a proxy, as the response is going to differ based on the presence of the request option. A more useful proxy that does implement the ETag request option is not using ETag as a part of the Cache-Key.
注：Cache-Key指示は、指定されたオプションを要求オプションとして実装せず、代わりにUnsafe / Safe-to-Forward指示のみに依存するプロキシにのみ関連します。たとえば、ETagの場合、実際にリクエストオプションをCache-Keyの一部として使用することは非常に非効率的ですが、ETagがプロキシによって実装されていない場合に実行できる最善の方法です。リクエストオプションの存在。 ETagリクエストオプションを実装するより便利なプロキシは、Cache-Keyの一部としてETagを使用していません。
NoCacheKey is indicated in three bits so that only one out of eight codepoints is qualified as NoCacheKey, leaving seven out of eight codepoints for what appears to be the more likely case.
NoCacheKeyは3ビットで示されるため、8つのコードポイントのうち1つだけがNoCacheKeyとして認定され、8つのコードポイントのうち7つがより可能性が高いと思われるものに残されます。
Proxy behavior with regard to these classes is defined in Section 5.7.
これらのクラスに関するプロキシの動作は、セクション5.7で定義されています。
Option values are defined to have a specific length, often in the form of an upper and lower bound. If the length of an option value in a request is outside the defined range, that option MUST be treated like an unrecognized option (see Section 5.4.1).
オプション値は特定の長さを持つように定義され、多くの場合、上限と下限の形式になります。リクエスト内のオプション値の長さが定義された範囲外である場合、そのオプションは認識されないオプションのように扱われなければなりません（セクション5.4.1を参照）。
Options may be defined to have a default value. If the value of an option is intended to be this default value, the option SHOULD NOT be included in the message. If the option is not present, the default value MUST be assumed.
オプションは、デフォルト値を持つように定義できます。オプションの値がこのデフォルト値であることが意図されている場合、オプションはメッセージに含まれるべきではありません（SHOULD NOT）。オプションが存在しない場合、デフォルト値を想定する必要があります。
Where a critical option has a default value, this is chosen in such a way that the absence of the option in a message can be processed properly both by implementations unaware of the critical option and by implementations that interpret this absence as the presence of the default value for the option.
重要なオプションにデフォルト値がある場合、これは、メッセージにオプションがないことを、重要なオプションを認識しない実装と、この不在をデフォルトの存在として解釈する実装の両方で適切に処理できるように選択されます。オプションの値。
The definition of some options specifies that those options are repeatable. An option that is repeatable MAY be included one or more times in a message. An option that is not repeatable MUST NOT be included more than once in a message.
一部のオプションの定義は、それらのオプションが反復可能であることを指定しています。繰り返し可能なオプションは、メッセージに1回以上含めることができます。反復できないオプションは、メッセージに2回以上含めることはできません。
If a message includes an option with more occurrences than the option is defined for, each supernumerary option occurrence that appears subsequently in the message MUST be treated like an unrecognized option (see Section 5.4.1).
オプションが定義されているよりも多くのオカレンスを持つオプションがメッセージに含まれている場合、その後メッセージに表示される各過剰オプションオカレンスは、認識されないオプションのように扱われなければなりません（セクション5.4.1を参照）。
An Option is identified by an option number, which also provides some additional semantics information, e.g., odd numbers indicate a critical option, while even numbers indicate an elective option. Note that this is not just a convention, it is a feature of the protocol: Whether an option is elective or critical is entirely determined by whether its option number is even or odd.
オプションはオプション番号によって識別されます。これは、いくつかの追加のセマンティクス情報も提供します。たとえば、奇数はクリティカルオプションを示し、偶数は選択オプションを示します。これは単なる規約ではなく、プロトコルの機能であることに注意してください。オプションが選択的か重要かは、オプション番号が偶数か奇数かによって完全に決まります。
More generally speaking, an Option number is constructed with a bit mask to indicate if an option is Critical or Elective, Unsafe or Safe-to-Forward, and, in the case of Safe-to-Forward, to provide a Cache-Key indication as shown by the following figure. In the following text, the bit mask is expressed as a single byte that is applied to the least significant byte of the option number in unsigned integer representation. When bit 7 (the least significant bit) is 1, an option is Critical (and likewise Elective when 0). When bit 6 is 1, an option is Unsafe (and likewise Safe-to-Forward when 0). When bit 6 is 0, i.e., the option is not Unsafe, it is not a Cache-Key (NoCacheKey) if and only if bits 3-5 are all set to 1; all other bit combinations mean that it indeed is a Cache-Key. These classes of options are explained in the next sections.
より一般的に言えば、オプション番号はビットマスクで構成され、オプションがクリティカルまたは選択的であるか、安全でないか、転送が安全かを示し、転送が安全な場合は、キャッシュキーを表示します。次の図に示すように。次のテキストでは、ビットマスクは、符号なし整数表現でオプション番号の最下位バイトに適用される1バイトとして表されます。ビット7（最下位ビット）が1の場合、オプションはCriticalです（0の場合も同様に選択可能）。ビット6が1の場合、オプションは安全ではありません（0の場合も同様に安全に転送できます）。ビット6が0の場合、つまりオプションがUnsafeではない場合、ビット3〜5がすべて1に設定されている場合にのみ、キャッシュキー（NoCacheKey）ではありません。他のすべてのビットの組み合わせは、それが実際にキャッシュキーであることを意味します。これらのオプションのクラスについては、次のセクションで説明します。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| | NoCacheKey| U | C |
+---+---+---+---+---+---+---+---+
Figure 10: Option Number Mask (Least Significant Byte)
図10：オプション番号マスク（最下位バイト）
An endpoint may use an equivalent of the C code in Figure 11 to derive the characteristics of an option number "onum".
エンドポイントは、図11のCコードと同等のものを使用して、オプション番号「onum」の特性を導出できます。
Critical = (onum & 1);
UnSafe = (onum & 2);
NoCacheKey = ((onum & 0x1e) == 0x1c);
Figure 11: Determining Characteristics from an Option Number
図11：オプション番号からの特性の決定
The option numbers for the options defined in this document are listed in the "CoAP Option Numbers" registry (Section 12.2).
このドキュメントで定義されているオプションのオプション番号は、「CoAPオプション番号」レジストリ（セクション12.2）に記載されています。
Both requests and responses may include a payload, depending on the Method or Response Code, respectively. If a Method or Response Code is not defined to have a payload, then a sender MUST NOT include one, and a recipient MUST ignore it.
要求と応答の両方に、それぞれメソッドまたは応答コードに応じて、ペイロードが含まれる場合があります。メソッドまたはレスポンスコードがペイロードを持つように定義されていない場合、送信者はペイロードを含めてはならず、受信者はそれを無視する必要があります。
The payload of requests or of responses indicating success is typically a representation of a resource ("resource representation") or the result of the requested action ("action result"). Its format is specified by the Internet media type and content coding given by the Content-Format Option. In the absence of this option, no default value is assumed, and the format will need to be inferred by the application (e.g., from the application context). Payload "sniffing" SHOULD only be attempted if no content type is given.
要求または成功を示す応答のペイロードは、通常、リソースの表現（「リソース表現」）または要求されたアクションの結果（「アクション結果」）です。その形式は、インターネットメディアタイプとContent-Formatオプションで指定されたコンテンツコーディングによって指定されます。このオプションがない場合、デフォルト値は想定されず、フォーマットはアプリケーションによって（たとえば、アプリケーションコンテキストから）推測される必要があります。ペイロードの「スニッフィング」は、コンテンツタイプが指定されていない場合にのみ試行してください。
Implementation Note: On a quality-of-implementation level, there is a strong expectation that a Content-Format indication will be provided with resource representations whenever possible. This is not a "SHOULD" level requirement solely because it is not a protocol requirement, and it also would be difficult to outline exactly in what cases this expectation can be violated.
実装に関する注記：実装の品質レベルでは、可能な場合は常にContent-Format指示にリソース表現が提供されることが強く期待されます。これはプロトコル要件ではないため、「SHOULD」レベルの要件ではありません。また、この期待に違反する可能性のあるケースを正確に概説することも困難です。
For responses indicating a client or server error, the payload is considered a representation of the result of the requested action only if a Content-Format Option is given. In the absence of this option, the payload is a Diagnostic Payload (Section 5.5.2).
クライアントまたはサーバーのエラーを示す応答の場合、ペイロードは、Content-Formatオプションが指定されている場合にのみ、要求されたアクションの結果の表現と見なされます。このオプションがない場合、ペイロードは診断ペイロードです（セクション5.5.2）。
If no Content-Format option is given, the payload of responses indicating a client or server error is a brief human-readable diagnostic message, explaining the error situation. This diagnostic message MUST be encoded using UTF-8 [RFC3629], more specifically using Net-Unicode form [RFC5198].
Content-Formatオプションを指定しない場合、クライアントまたはサーバーのエラーを示す応答のペイロードは、エラーの状況を説明する、人間が読める短い診断メッセージです。この診断メッセージは、UTF-8 [RFC3629]を使用して、より具体的にはNet-Unicode形式[RFC5198]を使用してエンコードする必要があります。
The message is similar to the Reason-Phrase on an HTTP status line. It is not intended for end users but for software engineers that during debugging need to interpret it in the context of the present, English-language specification; therefore, no mechanism for language tagging is needed or provided. In contrast to what is usual in HTTP, the payload SHOULD be empty if there is no additional information beyond the Response Code.
このメッセージは、HTTPステータスラインのReason-Phraseに似ています。これはエンドユーザー向けではなく、デバッグ中に現在の英語仕様のコンテキストで解釈する必要があるソフトウェアエンジニア向けです。したがって、言語のタグ付けのメカニズムは必要ありません。通常のHTTPとは対照的に、応答コード以外に追加情報がない場合、ペイロードは空にする必要があります（SHOULD）。
Not all responses carry a payload that provides a representation of the resource addressed by the request. It is, however, sometimes useful to be able to refer to such a representation in relation to a response, independent of whether it actually was enclosed.
すべての応答が、要求によってアドレス指定されたリソースの表現を提供するペイロードを運ぶわけではありません。ただし、実際に囲まれているかどうかに関係なく、応答に関連してそのような表現を参照できると便利な場合があります。
We use the term "selected representation" to refer to the current representation of a target resource that would have been selected in a successful response if the corresponding request had used the method GET and excluded any conditional request options (Section 5.10.8).
「選択された表現」という用語は、対応するリクエストがメソッドGETを使用し、条件付きリクエストオプションを除外した場合に、正常な応答で選択されたターゲットリソースの現在の表現を指すために使用します（5.10.8項）。
Certain response options provide metadata about the selected representation, which might differ from the representation included in the message for responses to some state-changing methods. Of the response options defined in this specification, only the ETag response option (Section 5.10.6) is defined as metadata about the selected representation.
特定の応答オプションは、選択された表現に関するメタデータを提供します。これは、一部の状態変更メソッドへの応答のメッセージに含まれる表現とは異なる場合があります。この仕様で定義されている応答オプションのうち、ETag応答オプション（セクション5.10.6）のみが、選択された表現に関するメタデータとして定義されています。
A server may be able to supply a representation for a resource in one of multiple representation formats. Without further information from the client, it will provide the representation in the format it prefers.
サーバーは、リソースの表現を複数の表現形式のいずれかで提供できる場合があります。クライアントからのさらなる情報なしで、それはそれが好むフォーマットで表現を提供します。
By using the Accept Option (Section 5.10.4) in a request, the client can indicate which content-format it prefers to receive.
リクエストでAcceptオプション（5.10.4節）を使用することにより、クライアントは受信するコンテンツ形式を指定できます。
CoAP endpoints MAY cache responses in order to reduce the response time and network bandwidth consumption on future, equivalent requests.
CoAPエンドポイントは、将来の同等の要求での応答時間とネットワーク帯域幅の消費を削減するために、応答をキャッシュする場合があります。
The goal of caching in CoAP is to reuse a prior response message to satisfy a current request. In some cases, a stored response can be reused without the need for a network request, reducing latency and network round-trips; a "freshness" mechanism is used for this purpose (see Section 5.6.1). Even when a new request is required, it is often possible to reuse the payload of a prior response to satisfy the request, thereby reducing network bandwidth usage; a "validation" mechanism is used for this purpose (see Section 5.6.2).
CoAPでのキャッシングの目的は、現在の要求を満たすために以前の応答メッセージを再利用することです。場合によっては、ネットワーク要求を必要とせずに格納された応答を再利用でき、待ち時間とネットワークの往復を削減できます。このために「鮮度」メカニズムが使用されます（5.6.1項を参照）。新しいリクエストが必要になった場合でも、以前のレスポンスのペイロードを再利用してリクエストを満たすことができるため、ネットワーク帯域幅の使用量を削減できます。この目的のために「検証」メカニズムが使用されます（5.6.2項を参照）。
Unlike HTTP, the cacheability of CoAP responses does not depend on the request method, but it depends on the Response Code. The cacheability of each Response Code is defined along the Response Code definitions in Section 5.9. Response Codes that indicate success and are unrecognized by an endpoint MUST NOT be cached.
HTTPとは異なり、CoAP応答のキャッシュ可能性は要求メソッドに依存しませんが、応答コードに依存します。各レスポンスコードのキャッシュ可能性は、セクション5.9のレスポンスコードの定義に従って定義されます。成功を示し、エンドポイントによって認識されない応答コードはキャッシュしてはなりません（MUST NOT）。
For a presented request, a CoAP endpoint MUST NOT use a stored response, unless:
提示された要求の場合、CoAPエンドポイントは、次の場合を除き、保存された応答を使用してはなりません（MUST NOT）。
o the presented request method and that used to obtain the stored response match,
o 提示された要求メソッドと、格納された応答の一致を取得するために使用される
o all options match between those in the presented request and those of the request used to obtain the stored response (which includes the request URI), except that there is no need for a match of any request options marked as NoCacheKey (Section 5.4) or recognized by the Cache and fully interpreted with respect to its specified cache behavior (such as the ETag request option described in Section 5.10.6; see also Section 5.4.2), and
o NoCacheKey（セクション5.4）としてマークされている、または認識されている要求オプションの一致が必要ない場合を除いて、すべてのオプションは、提示された要求のオプションと格納された応答（要求URIを含む）の取得に使用される要求のオプションの間で一致します。キャッシュにより、指定されたキャッシュ動作（5.10.6で説明されているETagリクエストオプションなど）に完全に解釈されます。5.4.2も参照してください。
o the stored response is either fresh or successfully validated as defined below.
o 保存された応答は、以下に定義されているように、新しいか、正常に検証されています。
The set of request options that is used for matching the cache entry is also collectively referred to as the "Cache-Key". For URI schemes other than coap and coaps, matching of those options that constitute the request URI may be performed under rules specific to the URI scheme.
キャッシュエントリの照合に使用される要求オプションのセットは、「キャッシュキー」とも総称されます。 coapおよびcoaps以外のURIスキームの場合、要求URIを構成するオプションのマッチングは、URIスキームに固有のルールの下で実行できます。
When a response is "fresh" in the cache, it can be used to satisfy subsequent requests without contacting the origin server, thereby improving efficiency.
応答がキャッシュ内で「新鮮」な場合、それを使用して、オリジンサーバーに接続せずに後続の要求を満たすことができるため、効率が向上します。
The mechanism for determining freshness is for an origin server to provide an explicit expiration time in the future, using the Max-Age Option (see Section 5.10.5). The Max-Age Option indicates that the response is to be considered not fresh after its age is greater than the specified number of seconds.
フレッシュネスを決定するメカニズムは、オリジンサーバーがMax-Ageオプションを使用して、将来の有効期限を明示的に提供することです（セクション5.10.5を参照）。 Max-Ageオプションは、指定された秒数よりも経過時間が経過すると、応答が新鮮ではないと見なされることを示します。
The Max-Age Option defaults to a value of 60. Thus, if it is not present in a cacheable response, then the response is considered not fresh after its age is greater than 60 seconds. If an origin server wishes to prevent caching, it MUST explicitly include a Max-Age Option with a value of zero seconds.
Max-Age Optionのデフォルト値は60です。したがって、キャッシュ可能な応答に存在しない場合、その応答は、経過時間が60秒を超えると新しいとは見なされません。オリジンサーバーがキャッシュを防止したい場合、ゼロ秒の値を持つMax-Ageオプションを明示的に含める必要があります。
If a client has a fresh stored response and makes a new request matching the request for that stored response, the new response invalidates the old response.
クライアントに新しい保存された応答があり、その保存された応答の要求と一致する新しい要求を行う場合、新しい応答は古い応答を無効にします。
When an endpoint has one or more stored responses for a GET request, but cannot use any of them (e.g., because they are not fresh), it can use the ETag Option (Section 5.10.6) in the GET request to give the origin server an opportunity both to select a stored response to be used, and to update its freshness. This process is known as "validating" or "revalidating" the stored response.
エンドポイントがGETリクエストに対して1つ以上の応答を格納しているが、それらのいずれも使用できない場合（たとえば、フレッシュでないため）、GETリクエストでETagオプション（5.10.6項）を使用してオリジンを指定できます。サーバーに、使用する保存済み応答を選択する機会と、その鮮度を更新する機会の両方を提供します。このプロセスは、保存された応答の「検証」または「再検証」と呼ばれます。
When sending such a request, the endpoint SHOULD add an ETag Option specifying the entity-tag of each stored response that is applicable.
そのようなリクエストを送信するとき、エンドポイントは、該当する格納された各応答のエンティティタグを指定するETagオプションを追加する必要があります（SHOULD）。
A 2.03 (Valid) response indicates the stored response identified by the entity-tag given in the response's ETag Option can be reused after updating it as described in Section 5.9.1.3.
2.03（有効）応答は、応答のETagオプションで指定されたエンティティタグによって識別される格納された応答が、セクション5.9.1.3で説明されているように、更新後に再利用できることを示します。
Any other Response Code indicates that none of the stored responses nominated in the request is suitable. Instead, the response SHOULD be used to satisfy the request and MAY replace the stored response.
その他の応答コードは、要求で指定された保存済み応答のいずれも適切でないことを示しています。代わりに、応答は要求を満たすために使用されるべきであり（SHOULD）、格納された応答を置き換えてもよい（MAY）。
A proxy is a CoAP endpoint that can be tasked by CoAP clients to perform requests on their behalf. This may be useful, for example, when the request could otherwise not be made, or to service the response from a cache in order to reduce response time and network bandwidth or energy consumption.
プロキシは、CoAPクライアントが自分に代わってリクエストを実行するようにタスクを設定できるCoAPエンドポイントです。これは、たとえば、要求が行われない場合、または応答時間とネットワーク帯域幅またはエネルギー消費を削減するためにキャッシュからの応答を処理する場合に役立ちます。
In an overall architecture for a Constrained RESTful Environment, proxies can serve quite different purposes. Proxies can be explicitly selected by clients, a role that we term "forward-proxy". Proxies can also be inserted to stand in for origin servers, a role that we term "reverse-proxy". Orthogonal to this distinction, a proxy can map from a CoAP request to a CoAP request (CoAP-to-CoAP proxy) or translate from or to a different protocol ("cross-proxy"). Full definitions of these terms are provided in Section 1.2.
制約付きRESTful環境の全体的なアーキテクチャでは、プロキシはまったく異なる目的に使用できます。プロキシはクライアントが明示的に選択できます。これは、「フォワードプロキシ」と呼ばれる役割です。プロキシを挿入して、オリジンサーバーの代わりにすることもできます。これは、「リバースプロキシ」と呼ばれる役割です。この区別と直交して、プロキシはCoAP要求からCoAP要求にマップする（CoAP-to-CoAPプロキシ）か、または別のプロトコルに変換する（「クロスプロキシ」）ことができます。これらの用語の完全な定義は、セクション1.2に記載されています。
Notes: The terminology in this specification has been selected to be culturally compatible with the terminology used in the wider web application environments, without necessarily matching it in every detail (which may not even be relevant to Constrained RESTful Environments). Not too much semantics should be ascribed to the components of the terms (such as "forward", "reverse", or "cross").
注：この仕様の用語は、より詳細なWebアプリケーション環境で使用される用語と文化的に互換性があるように選択されていますが、詳細に完全に一致している必要はありません（制約付きRESTful環境に関連しない場合もあります）。用語の構成要素（「フォワード」、「リバース」、「クロス」など）のせいにして、意味論をあまり多くすべきではありません。
HTTP proxies, besides acting as HTTP proxies, often offer a transport-protocol proxying function ("CONNECT") to enable end-to-end transport layer security through the proxy. No such function is defined for CoAP-to-CoAP proxies in this specification, as forwarding of UDP packets is unlikely to be of much value in Constrained RESTful Environments. See also Section 10.2.7 for the cross-proxy case.
HTTPプロキシは、HTTPプロキシとして機能するだけでなく、多くの場合、トランスポートプロトコルプロキシ機能（「CONNECT」）を提供して、プロキシを介したエンドツーエンドのトランスポート層セキュリティを有効にします。この仕様では、CoAP-to-CoAPプロキシに対してそのような機能は定義されていません。UDPパケットの転送は、制約付きRESTful環境ではあまり価値がないためです。クロスプロキシのケースについては、セクション10.2.7も参照してください。
When a client uses a proxy to make a request that will use a secure URI scheme (e.g., "coaps" or "https"), the request towards the proxy SHOULD be sent using DTLS except where equivalent lower-layer security is used for the leg between the client and the proxy.
クライアントがプロキシを使用して安全なURIスキーム（「coaps」や「https」など）を使用する要求を行う場合、同等の下位層セキュリティが使用される場合を除いて、プロキシへの要求はDTLSを使用して送信する必要があります（SHOULD）。クライアントとプロキシ間のレッグ。
A proxy generally needs a way to determine potential request parameters for a request it places to a destination, based on the request it received from its client. This way is fully specified for a forward-proxy but may depend on the specific configuration for a reverse-proxy. In particular, the client of a reverse-proxy generally does not indicate a locator for the destination, necessitating some form of namespace translation in the reverse-proxy. However, some aspects of the operation of proxies are common to all its forms.
プロキシは通常、クライアントから受信したリクエストに基づいて、宛先に送信するリクエストの潜在的なリクエストパラメータを決定する方法を必要とします。この方法は、フォワードプロキシに対して完全に指定されていますが、リバースプロキシの特定の構成によって異なる場合があります。特に、リバースプロキシのクライアントは通常、宛先のロケーターを示さないため、リバースプロキシでなんらかの形式の名前空間変換が必要になります。ただし、プロキシの操作のいくつかの側面は、そのすべての形式に共通です。
If a proxy does not employ a cache, then it simply forwards the translated request to the determined destination. Otherwise, if it does employ a cache but does not have a stored response that matches the translated request and is considered fresh, then it needs to refresh its cache according to Section 5.6. For options in the request that the proxy recognizes, it knows whether the option is intended to act as part of the key used in looking up the cached value or not. For example, since requests for different Uri-Path values address different resources, Uri-Path values are always part of the Cache-Key, while, e.g., Token values are never part of the Cache-Key. For options that the proxy does not recognize but that are marked Safe-to-Forward in the option number, the option also indicates whether it is to be included in the Cache-Key (NoCacheKey is not all set) or not (NoCacheKey is all set). (Options that are unrecognized and marked Unsafe lead to 4.02 Bad Option.)
プロキシーがキャッシュを使用しない場合は、変換された要求を決定された宛先に転送するだけです。それ以外の場合、キャッシュを使用しているが、変換されたリクエストと一致し、フレッシュと見なされる格納された応答がない場合は、セクション5.6に従ってキャッシュを更新する必要があります。プロキシが認識するリクエスト内のオプションについては、オプションがキャッシュされた値の検索に使用されるキーの一部として機能することを目的としているかどうかがわかります。たとえば、異なるUri-Path値に対するリクエストは異なるリソースをアドレス指定するため、Uri-Path値は常にキャッシュキーの一部ですが、たとえば、トークン値は決してキャッシュキーの一部ではありません。プロキシが認識しないが、オプション番号で「安全に転送」とマークされているオプションの場合、オプションは、それがキャッシュキーに含まれるか（NoCacheKeyがすべて設定されていない）か、含まれていないか（NoCacheKeyがすべて）も示します。セットする）。 （認識されず、Unsafeとマークされたオプションは、4.02 Bad Optionにつながります。）
If the request to the destination times out, then a 5.04 (Gateway Timeout) response MUST be returned. If the request to the destination returns a response that cannot be processed by the proxy (e.g, due to unrecognized critical options or message format errors), then a 5.02 (Bad Gateway) response MUST be returned. Otherwise, the proxy returns the response to the client.
宛先への要求がタイムアウトした場合、5.04（ゲートウェイタイムアウト）応答を返さなければなりません（MUST）。宛先へのリクエストがプロキシで処理できない応答を返す場合（たとえば、認識されない重要なオプションやメッセージフォーマットエラーが原因）、5.02（不正なゲートウェイ）応答を返す必要があります。それ以外の場合、プロキシはクライアントに応答を返します。
If a response is generated out of a cache, the generated (or implied) Max-Age Option MUST NOT extend the max-age originally set by the server, considering the time the resource representation spent in the cache. For example, the Max-Age Option could be adjusted by the proxy for each response using the formula:
キャッシュから応答が生成された場合、生成された（または暗黙の）Max-Ageオプションは、リソース表現がキャッシュで費やした時間を考慮して、サーバーによって最初に設定されたmax-ageを拡張してはなりません（MUST NOT）。たとえば、Max-Age Optionは、次の式を使用して、プロキシごとに応答ごとに調整できます。
proxy-max-age = original-max-age - cache-age
For example, if a request is made to a proxied resource that was refreshed 20 seconds ago and had an original Max-Age of 60 seconds, then that resource's proxied max-age is now 40 seconds. Considering potential network delays on the way from the origin server, a proxy should be conservative in the max-age values offered.
たとえば、20秒前に更新され、元のMax-Ageが60秒であったプロキシされたリソースに対してリクエストが行われた場合、そのリソースのプロキシされた最大エージは40秒になります。オリジンサーバーからの途中でネットワーク遅延が発生する可能性があることを考慮すると、プロキシは、提供される最大エージ値で控えめにする必要があります。
All options present in a proxy request MUST be processed at the proxy. Unsafe options in a request that are not recognized by the proxy MUST lead to a 4.02 (Bad Option) response being returned by the proxy. A CoAP-to-CoAP proxy MUST forward to the origin server all Safe-to-Forward options that it does not recognize. Similarly, Unsafe options in a response that are not recognized by the CoAP-to-CoAP proxy server MUST lead to a 5.02 (Bad Gateway) response. Again, Safe-to-Forward options that are not recognized MUST be forwarded.
プロキシ要求に存在するすべてのオプションは、プロキシで処理される必要があります。プロキシで認識されないリクエスト内の安全でないオプションは、プロキシから返される4.02（不良オプション）応答につながる必要があります。 CoAP-to-CoAPプロキシは、認識しないすべてのSafe-to-Forwardオプションをオリジンサーバーに転送する必要があります。同様に、CoAP-to-CoAPプロキシサーバーによって認識されない応答の安全でないオプションは、5.02（不正なゲートウェイ）応答につながる必要があります。この場合も、認識されないSafe-to-Forwardオプションは転送する必要があります。
Additional considerations for cross-protocol proxying between CoAP and HTTP are discussed in Section 10.
CoAPとHTTP間のクロスプロトコルプロキシに関するその他の考慮事項については、セクション10で説明します。
CoAP distinguishes between requests made (as if) to an origin server and requests made through a forward-proxy. CoAP requests to a forward-proxy are made as normal Confirmable or Non-confirmable requests to the forward-proxy endpoint, but they specify the request URI in a different way: The request URI in a proxy request is specified as a string in the Proxy-Uri Option (see Section 5.10.2), while the request URI in a request to an origin server is split into the Uri-Host, Uri-Port, Uri-Path, and Uri-Query Options (see Section 5.10.1). Alternatively, the URI in a proxy request can be assembled from a Proxy-Scheme option and the split options mentioned.
CoAPは、（あたかも）オリジンサーバーに対して行われた要求と、フォワードプロキシを介して行われた要求を区別します。フォワードプロキシへのCoAPリクエストは、フォワードプロキシエンドポイントへの通常の確認可能または確認不可能なリクエストとして行われますが、リクエストURIは別の方法で指定されます。プロキシリクエストのリクエストURIは、プロキシの文字列として指定されます。 -Uriオプション（セクション5.10.2を参照）、オリジンサーバーへのリクエストのリクエストURIは、Uri-Host、Uri-Port、Uri-Path、およびUri-Queryオプションに分割されます（セクション5.10.1を参照） 。または、プロキシリクエストのURIは、Proxy-Schemeオプションと前述の分割オプションから組み立てることもできます。
When a proxy request is made to an endpoint and the endpoint is unwilling or unable to act as proxy for the request URI, it MUST return a 5.05 (Proxying Not Supported) response. If the authority (host and port) is recognized as identifying the proxy endpoint itself (see Section 5.10.2), then the request MUST be treated as a local (non-proxied) request.
エンドポイントに対してプロキシ要求が行われ、エンドポイントが要求URIのプロキシとして機能することを望まないか、または機能できない場合、5.05（プロキシはサポートされていません）応答を返す必要があります。権限（ホストとポート）がプロキシエンドポイント自体を識別するものとして認識されている場合（セクション5.10.2を参照）、リクエストはローカル（プロキシされていない）リクエストとして扱われなければなりません（MUST）。
Unless a proxy is configured to forward the proxy request to another proxy, it MUST translate the request as follows: the scheme of the request URI defines the outgoing protocol and its details (e.g., CoAP is used over UDP for the "coap" scheme and over DTLS for the "coaps" scheme.) For a CoAP-to-CoAP proxy, the origin server's IP address and port are determined by the authority component of the request URI, and the request URI is decoded and split into the Uri-Host, Uri-Port, Uri-Path and Uri-Query Options. This consumes the Proxy-Uri or Proxy-Scheme option, which is therefore not forwarded to the origin server.
プロキシーがプロキシー要求を別のプロキシーに転送するように構成されていない限り、要求を次のように変換する必要があります。要求URIのスキームは、発信プロトコルとその詳細を定義します（たとえば、CoAPはUDPを介して「coap」スキームで使用されます。 Coap-to-CoAPプロキシの場合、DTLSを介して。）CoAP-to-CoAPプロキシの場合、元のサーバーのIPアドレスとポートは、リクエストURIの機関コンポーネントによって決定され、リクエストURIはデコードされ、Uri-Hostに分割されます。 、Uri-Port、Uri-Path、およびUri-Queryオプション。これにより、Proxy-UriまたはProxy-Schemeオプションが使用されるため、オリジンサーバーに転送されません。
Reverse-proxies do not make use of the Proxy-Uri or Proxy-Scheme options but need to determine the destination (next hop) of a request from information in the request and information in their configuration. For example, a reverse-proxy might offer various resources as if they were its own resources, after having learned of their existence through resource discovery. The reverse-proxy is free to build a namespace for the URIs that identify these resources. A reverse-proxy may also build a namespace that gives the client more control over where the request goes, e.g., by embedding host identifiers and port numbers into the URI path of the resources offered.
リバースプロキシは、Proxy-UriまたはProxy-Schemeオプションを使用しませんが、リクエストの情報とその構成の情報からリクエストの宛先（ネクストホップ）を決定する必要があります。たとえば、リバースプロキシは、リソースの発見を通じてそれらの存在を知った後、それらが独自のリソースであるかのようにさまざまなリソースを提供する場合があります。リバースプロキシは、これらのリソースを識別するURIの名前空間を自由に構築できます。リバースプロキシは、たとえば、提供されたリソースのURIパスにホスト識別子とポート番号を埋め込むことにより、クライアントがリクエストの送信先をより詳細に制御できる名前空間を構築することもできます。
In processing the response, a reverse-proxy has to be careful that ETag option values from different sources are not mixed up on one resource offered to its clients. In many cases, the ETag can be forwarded unchanged. If the mapping from a resource offered by the reverse-proxy to resources offered by its various origin servers is not unique, the reverse-proxy may need to generate a new ETag, making sure the semantics of this option are properly preserved.
応答の処理では、リバースプロキシは、クライアントに提供される1つのリソースで、さまざまなソースからのETagオプション値が混同されないように注意する必要があります。多くの場合、ETagは変更せずに転送できます。リバースプロキシによって提供されるリソースからさまざまなオリジンサーバーによって提供されるリソースへのマッピングが一意でない場合、リバースプロキシは新しいETagを生成し、このオプションのセマンティクスが適切に保持されるようにする必要がある場合があります。
In this section, each method is defined along with its behavior. A request with an unrecognized or unsupported Method Code MUST generate a 4.05 (Method Not Allowed) piggybacked response.
このセクションでは、各メソッドをその動作とともに定義します。認識されない、またはサポートされていないメソッドコードを含むリクエストは、4.05（メソッドが許可されていない）ピギーバック応答を生成する必要があります。
The GET method retrieves a representation for the information that currently corresponds to the resource identified by the request URI. If the request includes an Accept Option, that indicates the preferred content-format of a response. If the request includes an ETag Option, the GET method requests that ETag be validated and that the representation be transferred only if validation failed. Upon success, a 2.05 (Content) or 2.03 (Valid) Response Code SHOULD be present in the response.
GETメソッドは、要求URIによって識別されるリソースに現在対応している情報の表現を取得します。リクエストにAccept Optionが含まれている場合、それはレスポンスの優先コンテンツ形式を示します。リクエストにETagオプションが含まれている場合、GETメソッドはETagの検証と、検証が失敗した場合にのみ表現を転送することを要求します。成功すると、2.05（コンテンツ）または2.03（有効）応答コードが応答に存在する必要があります（SHOULD）。
The GET method is safe and idempotent.
GETメソッドは安全でべき等です。
The POST method requests that the representation enclosed in the request be processed. The actual function performed by the POST method is determined by the origin server and dependent on the target resource. It usually results in a new resource being created or the target resource being updated.
POSTメソッドは、リクエストに含まれる表現が処理されることをリクエストします。 POSTメソッドによって実行される実際の機能は、オリジンサーバーによって決定され、ターゲットリソースに依存します。通常、新しいリソースが作成されるか、ターゲットリソースが更新されます。
If a resource has been created on the server, the response returned by the server SHOULD have a 2.01 (Created) Response Code and SHOULD include the URI of the new resource in a sequence of one or more Location-Path and/or Location-Query Options (Section 5.10.7). If the POST succeeds but does not result in a new resource being created on the server, the response SHOULD have a 2.04 (Changed) Response Code. If the POST succeeds and results in the target resource being deleted, the response SHOULD have a 2.02 (Deleted) Response Code. POST is neither safe nor idempotent.
サーバー上でリソースが作成されている場合、サーバーから返される応答には2.01（作成済み）応答コードが含まれている必要があり、新しいリソースのURIを1つ以上のLocation-PathやLocation-Queryのシーケンスに含める必要があります（SHOULD）。オプション（5.10.7節）。 POSTは成功したが、サーバー上に新しいリソースが作成されなかった場合、応答には2.04（変更された）応答コードが必要です（SHOULD）。 POSTが成功し、結果としてターゲットリソースが削除される場合、応答には2.02（削除済み）応答コードが必要です（SHOULD）。 POSTは安全でもべき等でもありません。
The PUT method requests that the resource identified by the request URI be updated or created with the enclosed representation. The representation format is specified by the media type and content coding given in the Content-Format Option, if provided.
PUTメソッドは、リクエストURIで識別されるリソースを、囲まれた表現で更新または作成することを要求します。表現形式は、提供されている場合、Content-Formatオプションで指定されたメディアタイプとコンテンツコーディングによって指定されます。
If a resource exists at the request URI, the enclosed representation SHOULD be considered a modified version of that resource, and a 2.04 (Changed) Response Code SHOULD be returned. If no resource exists, then the server MAY create a new resource with that URI, resulting in a 2.01 (Created) Response Code. If the resource could not be created or modified, then an appropriate error Response Code SHOULD be sent.
リソースがリクエストURIに存在する場合、囲まれた表現はそのリソースの変更されたバージョンと見なされるべきであり、2.04（変更された）応答コードが返されるべきです（SHOULD）。リソースが存在しない場合、サーバーはそのURIで新しいリソースを作成することができ（MAY）、結果として2.01（作成済み）応答コードが返されます。リソースを作成または変更できなかった場合は、適切なエラー応答コードを送信する必要があります（SHOULD）。
Further restrictions to a PUT can be made by including the If-Match (see Section 5.10.8.1) or If-None-Match (see Section 5.10.8.2) options in the request.
リクエストにIf-Match（セクション5.10.8.1を参照）またはIf-None-Match（セクション5.10.8.2を参照）オプションを含めることで、PUTをさらに制限できます。
PUT is not safe but is idempotent.
PUTは安全ではありませんが、べき等です。
The DELETE method requests that the resource identified by the request URI be deleted. A 2.02 (Deleted) Response Code SHOULD be used on success or in case the resource did not exist before the request.
DELETEメソッドは、リクエストURIで識別されるリソースを削除するようリクエストします。 2.02（削除済み）応答コードは、成功した場合、または要求の前にリソースが存在しなかった場合に使用する必要があります（SHOULD）。
DELETE is not safe but is idempotent.
DELETEは安全ではありませんが、べき等です。
Each Response Code is described below, including any options required in the response. Where appropriate, some of the codes will be specified in regards to related Response Codes in HTTP [RFC2616]; this does not mean that any such relationship modifies the HTTP mapping specified in Section 10.
各応答コードは、応答に必要なオプションを含めて、以下で説明されています。適切な場合、HTTP [RFC2616]の関連する応答コードに関して、一部のコードが指定されます。これは、そのような関係がセクション10で指定されたHTTPマッピングを変更することを意味するものではありません。
This class of Response Code indicates that the clients request was successfully received, understood, and accepted.
このクラスの応答コードは、クライアント要求が正常に受信、理解、および受け入れられたことを示しています。
Like HTTP 201 "Created", but only used in response to POST and PUT requests. The payload returned with the response, if any, is a representation of the action result.
HTTP 201と同様に「作成」されますが、POSTおよびPUTリクエストへの応答としてのみ使用されます。応答とともに返されるペイロード（ある場合）は、アクション結果の表現です。
If the response includes one or more Location-Path and/or Location-Query Options, the values of these options specify the location at which the resource was created. Otherwise, the resource was created at the request URI. A cache receiving this response MUST mark any stored response for the created resource as not fresh.
応答に1つ以上のLocation-Pathおよび/またはLocation-Queryオプションが含まれている場合、これらのオプションの値は、リソースが作成された場所を指定します。それ以外の場合、リソースはリクエストURIで作成されました。この応答を受信するキャッシュは、作成されたリソースの格納された応答を新しいものとしてマークする必要があります。
This response is not cacheable.
この応答はキャッシュできません。
This Response Code is like HTTP 204 "No Content" but only used in response to requests that cause the resource to cease being available, such as DELETE and, in certain circumstances, POST. The payload returned with the response, if any, is a representation of the action result.
この応答コードはHTTP 204の「コンテンツなし」に似ていますが、DELETEや特定の状況ではPOSTなど、リソースの利用を停止させる要求に応答する場合にのみ使用されます。応答とともに返されるペイロード（ある場合）は、アクション結果の表現です。
This response is not cacheable. However, a cache MUST mark any stored response for the deleted resource as not fresh.
この応答はキャッシュできません。ただし、キャッシュは、削除されたリソースの保存された応答を新しいものとしてマークする必要があります。
This Response Code is related to HTTP 304 "Not Modified" but only used to indicate that the response identified by the entity-tag identified by the included ETag Option is valid. Accordingly, the response MUST include an ETag Option and MUST NOT include a payload.
この応答コードはHTTP 304 "Not Modified"に関連していますが、含まれているETagオプションによって識別されたエンティティタグによって識別された応答が有効であることを示すためにのみ使用されます。したがって、応答にはETagオプションを含める必要があり、ペイロードを含めることはできません。
When a cache that recognizes and processes the ETag response option receives a 2.03 (Valid) response, it MUST update the stored response with the value of the Max-Age Option included in the response (explicitly, or implicitly as a default value; see also Section 5.6.2). For each type of Safe-to-Forward option present in the response, the (possibly empty) set of options of this type that are present in the stored response MUST be replaced with the set of options of this type in the response received. (Unsafe options may trigger similar option-specific processing as defined by the option.)
ETag応答オプションを認識して処理するキャッシュが2.03（有効）応答を受信すると、応答に含まれているMax-Age Optionの値で（明示的または暗黙的にデフォルト値として）格納されている応答を更新する必要があります。セクション5.6.2）。応答に存在するSafe-to-Forwardオプションのタイプごとに、格納された応答に存在するこのタイプのオプションの（空の可能性がある）セットを、受信した応答のこのタイプのオプションのセットで置き換える必要があります。 （安全でないオプションは、オプションで定義されているのと同様のオプション固有の処理をトリガーする可能性があります。）
This Response Code is like HTTP 204 "No Content" but only used in response to POST and PUT requests. The payload returned with the response, if any, is a representation of the action result.
この応答コードはHTTP 204 "No Content"に似ていますが、POSTおよびPUTリクエストへの応答でのみ使用されます。応答とともに返されるペイロード（ある場合）は、アクション結果の表現です。
This response is not cacheable. However, a cache MUST mark any stored response for the changed resource as not fresh.
この応答はキャッシュできません。ただし、キャッシュは、変更されたリソースの格納された応答を最新のものとしてマークする必要があります。
This Response Code is like HTTP 200 "OK" but only used in response to GET requests.
この応答コードはHTTP 200 "OK"に似ていますが、GET要求への応答でのみ使用されます。
The payload returned with the response is a representation of the target resource.
応答とともに返されるペイロードは、ターゲットリソースの表現です。
This response is cacheable: Caches can use the Max-Age Option to determine freshness (see Section 5.6.1) and (if present) the ETag Option for validation (see Section 5.6.2).
この応答はキャッシュ可能です。キャッシュはMax-Ageオプションを使用して、鮮度（セクション5.6.1を参照）および（存在する場合）検証用のETagオプション（セクション5.6.2を参照）を決定できます。
This class of Response Code is intended for cases in which the client seems to have erred. These Response Codes are applicable to any request method.
このクラスの応答コードは、クライアントにエラーが発生したと思われる場合を対象としています。これらの応答コードは、すべての要求メソッドに適用できます。
The server SHOULD include a diagnostic payload under the conditions detailed in Section 5.5.2.
サーバーは、セクション5.5.2で詳述されている条件下で診断ペイロードを含める必要があります。
Responses of this class are cacheable: Caches can use the Max-Age Option to determine freshness (see Section 5.6.1). They cannot be validated.
このクラスの応答はキャッシュ可能です。キャッシュはMax-Age Optionを使用して鮮度を判断できます（5.6.1を参照）。検証できません。
This Response Code is Like HTTP 400 "Bad Request".
この応答コードは、HTTP 400 "Bad Request"のようなものです。
The client is not authorized to perform the requested action. The client SHOULD NOT repeat the request without first improving its authentication status to the server. Which specific mechanism can be used for this is outside this document's scope; see also Section 9.
クライアントには、要求されたアクションを実行する権限がありません。クライアントは、最初にサーバーへの認証ステータスを改善せずに要求を繰り返すべきではありません。これに使用できる特定のメカニズムは、このドキュメントの範囲外です。セクション9も参照してください。
The request could not be understood by the server due to one or more unrecognized or malformed options. The client SHOULD NOT repeat the request without modification.
1つ以上の認識されないオプションまたは不正なオプションが原因で、サーバーはリクエストを理解できませんでした。クライアントは変更せずにリクエストを繰り返すべきではありません。
This Response Code is like HTTP 403 "Forbidden".
この応答コードはHTTP 403 "Forbidden"のようなものです。
This Response Code is like HTTP 404 "Not Found".
この応答コードはHTTP 404「見つかりません」のようなものです。
This Response Code is like HTTP 405 "Method Not Allowed" but with no parallel to the "Allow" header field.
この応答コードはHTTP 405 "Method Not Allowed"に似ていますが、 "Allow"ヘッダーフィールドに対応していません。
This Response Code is like HTTP 406 "Not Acceptable", but with no response entity.
この応答コードはHTTP 406 "Not Acceptable"に似ていますが、応答エンティティはありません。
This Response Code is like HTTP 412 "Precondition Failed".
この応答コードは、HTTP 412 "Precondition Failed"のようなものです。
This Response Code is like HTTP 413 "Request Entity Too Large".
この応答コードはHTTP 413「リクエストエンティティが大きすぎます」に似ています。
The response SHOULD include a Size1 Option (Section 5.10.9) to indicate the maximum size of request entity the server is able and willing to handle, unless the server is not in a position to make this information available.
応答には、サーバーがこの情報を利用できる位置にない限り、サーバーが処理でき、処理できる要求エンティティの最大サイズを示すために、Size1オプション（5.10.9節）を含める必要があります（SHOULD）。
This Response Code is like HTTP 415 "Unsupported Media Type".
この応答コードは、HTTP 415「サポートされていないメディアタイプ」のようなものです。
This class of Response Code indicates cases in which the server is aware that it has erred or is incapable of performing the request. These Response Codes are applicable to any request method.
このクラスの応答コードは、エラーが発生したか、要求を実行できないことをサーバーが認識している場合を示します。これらの応答コードは、すべての要求メソッドに適用できます。
The server SHOULD include a diagnostic payload under the conditions detailed in Section 5.5.2.
サーバーは、セクション5.5.2で詳述されている条件下で診断ペイロードを含める必要があります。
Responses of this class are cacheable: Caches can use the Max-Age Option to determine freshness (see Section 5.6.1). They cannot be validated.
このクラスの応答はキャッシュ可能です。キャッシュはMax-Age Optionを使用して鮮度を判断できます（5.6.1を参照）。検証できません。
This Response Code is like HTTP 500 "Internal Server Error".
この応答コードは、HTTP 500「内部サーバーエラー」のようなものです。
This Response Code is like HTTP 501 "Not Implemented".
この応答コードは、HTTP 501 "Not Implemented"のようなものです。
This Response Code is like HTTP 502 "Bad Gateway".
この応答コードは、HTTP 502 "Bad Gateway"のようなものです。
This Response Code is like HTTP 503 "Service Unavailable" but uses the Max-Age Option in place of the "Retry-After" header field to indicate the number of seconds after which to retry.
この応答コードはHTTP 503 "Service Unavailable"に似ていますが、 "Retry-After"ヘッダーフィールドの代わりにMax-Ageオプションを使用して、再試行後の秒数を示します。
This Response Code is like HTTP 504 "Gateway Timeout".
この応答コードは、HTTP 504「ゲートウェイタイムアウト」のようなものです。
The server is unable or unwilling to act as a forward-proxy for the URI specified in the Proxy-Uri Option or using Proxy-Scheme (see Section 5.10.2).
サーバーは、Proxy-Uriオプションで指定されたURIのフォワードプロキシとして機能するか、またはプロキシスキーマを使用することができないか、または機能しません（セクション5.10.2を参照）。
The individual CoAP options are summarized in Table 4 and explained in the subsections of this section.
個別のCoAPオプションを表4にまとめ、このセクションのサブセクションで説明します。
In this table, the C, U, and N columns indicate the properties Critical, UnSafe, and NoCacheKey, respectively. Since NoCacheKey only has a meaning for options that are Safe-to-Forward (not marked Unsafe), the column is filled with a dash for UnSafe options.
この表のC列、U列、およびN列は、それぞれプロパティCritical、UnSafe、およびNoCacheKeyを示しています。 NoCacheKeyは、前方安全（Unsafeとマークされていない）のオプションに対してのみ意味があるため、UnSafeオプションの場合、列はダッシュで埋められます。
+-----+---+---+---+---+----------------+--------+--------+----------+
| No. | C | U | N | R | Name | Format | Length | Default |
+-----+---+---+---+---+----------------+--------+--------+----------+
| 1 | x | | | x | If-Match | opaque | 0-8 | (none) |
| 3 | x | x | - | | Uri-Host | string | 1-255 | (see |
| | | | | | | | | below) |
| 4 | | | | x | ETag | opaque | 1-8 | (none) |
| 5 | x | | | | If-None-Match | empty | 0 | (none) |
| 7 | x | x | - | | Uri-Port | uint | 0-2 | (see |
| | | | | | | | | below) |
| 8 | | | | x | Location-Path | string | 0-255 | (none) |
| 11 | x | x | - | x | Uri-Path | string | 0-255 | (none) |
| 12 | | | | | Content-Format | uint | 0-2 | (none) |
| 14 | | x | - | | Max-Age | uint | 0-4 | 60 |
| 15 | x | x | - | x | Uri-Query | string | 0-255 | (none) |
| 17 | x | | | | Accept | uint | 0-2 | (none) |
| 20 | | | | x | Location-Query | string | 0-255 | (none) |
| 35 | x | x | - | | Proxy-Uri | string | 1-1034 | (none) |
| 39 | x | x | - | | Proxy-Scheme | string | 1-255 | (none) |
| 60 | | | x | | Size1 | uint | 0-4 | (none) |
+-----+---+---+---+---+----------------+--------+--------+----------+
C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable
Table 4: Options
表4：オプション
The Uri-Host, Uri-Port, Uri-Path, and Uri-Query Options are used to specify the target resource of a request to a CoAP origin server. The options encode the different components of the request URI in a way that no percent-encoding is visible in the option values and that the full URI can be reconstructed at any involved endpoint. The syntax of CoAP URIs is defined in Section 6.
Uri-Host、Uri-Port、Uri-Path、およびUri-Queryオプションは、CoAPオリジンサーバへの要求のターゲットリソースを指定するために使用されます。オプションは、リクエストURIのさまざまなコンポーネントをエンコードして、オプションの値にパーセントエンコーディングが表示されないようにし、関係するエンドポイントで完全なURIを再構築できるようにします。 CoAP URIの構文は、セクション6で定義されています。
The steps for parsing URIs into options is defined in Section 6.4. These steps result in zero or more Uri-Host, Uri-Port, Uri-Path, and Uri-Query Options being included in a request, where each option holds the following values:
URIを解析してオプションにする手順は、セクション6.4で定義されています。これらの手順により、リクエストに含まれるUri-Host、Uri-Port、Uri-Path、およびUri-Queryオプションが0個以上になります。各オプションには次の値が含まれます。
o the Uri-Host Option specifies the Internet host of the resource being requested,
o Uri-Hostオプションは、要求されているリソースのインターネットホストを指定します。
o the Uri-Port Option specifies the transport-layer port number of the resource,
o Uri-Portオプションは、リソースのトランスポート層ポート番号を指定します。
o each Uri-Path Option specifies one segment of the absolute path to the resource, and
o 各Uri-Pathオプションは、リソースへの絶対パスの1つのセグメントを指定します。
o each Uri-Query Option specifies one argument parameterizing the resource.
o 各Uri-Queryオプションは、リソースをパラメーター化する1つの引数を指定します。
Note: Fragments ([RFC3986], Section 3.5) are not part of the request URI and thus will not be transmitted in a CoAP request.
注：フラグメント（[RFC3986]、セクション3.5）はリクエストURIの一部ではないため、CoAPリクエストでは送信されません。
The default value of the Uri-Host Option is the IP literal representing the destination IP address of the request message. Likewise, the default value of the Uri-Port Option is the destination UDP port. The default values for the Uri-Host and Uri-Port Options are sufficient for requests to most servers. Explicit Uri-Host and Uri-Port Options are typically used when an endpoint hosts multiple virtual servers.
Uri-Hostオプションのデフォルト値は、要求メッセージの宛先IPアドレスを表すIPリテラルです。同様に、Uri-Portオプションのデフォルト値は宛先UDPポートです。ほとんどのサーバーへの要求には、Uri-HostおよびUri-Portオプションのデフォルト値で十分です。明示的なUri-HostおよびUri-Portオプションは、エンドポイントが複数の仮想サーバーをホストする場合に通常使用されます。
The Uri-Path and Uri-Query Option can contain any character sequence. No percent-encoding is performed. The value of a Uri-Path Option MUST NOT be "." or ".." (as the request URI must be resolved before parsing it into options).
Uri-PathおよびUri-Queryオプションには、任意の文字シーケンスを含めることができます。パーセントエンコーディングは実行されません。 Uri-Pathオプションの値は「。」であってはなりません。または ".."（リクエストURIをオプションに解析する前に解決する必要があるため）。
The steps for constructing the request URI from the options are defined in Section 6.5. Note that an implementation does not necessarily have to construct the URI; it can simply look up the target resource by examining the individual options.
オプションからリクエストURIを構築する手順は、6.5節で定義されています。実装は必ずしもURIを構築する必要はないことに注意してください。個々のオプションを調べることで、ターゲットリソースを簡単に検索できます。
Examples can be found in Appendix B.
例は付録Bにあります。
The Proxy-Uri Option is used to make a request to a forward-proxy (see Section 5.7). The forward-proxy is requested to forward the request or service it from a valid cache and return the response.
Proxy-Uriオプションは、フォワードプロキシへのリクエストを行うために使用されます（セクション5.7を参照）。転送プロキシは、リクエストを転送するか、有効なキャッシュからリクエストを処理してレスポンスを返すようにリクエストされます。
The option value is an absolute-URI ([RFC3986], Section 4.3).
オプションの値は、絶対URIです（[RFC3986]、セクション4.3）。
Note that the forward-proxy MAY forward the request on to another proxy or directly to the server specified by the absolute-URI. In order to avoid request loops, a proxy MUST be able to recognize all of its server names, including any aliases, local variations, and the numeric IP addresses.
forward-proxyは、リクエストを別のプロキシに、または絶対URIで指定されたサーバーに直接転送してもよいことに注意してください。要求ループを回避するために、プロキシは、エイリアス、ローカルバリエーション、および数値IPアドレスを含む、そのサーバー名のすべてを認識できる必要があります。
An endpoint receiving a request with a Proxy-Uri Option that is unable or unwilling to act as a forward-proxy for the request MUST cause the return of a 5.05 (Proxying Not Supported) response.
リクエストのフォワードプロキシとして機能できない、または機能したくないProxy-Uriオプションを含むリクエストを受信するエンドポイントは、5.05（プロキシはサポートされていません）レスポンスを返さなければなりません（MUST）。
The Proxy-Uri Option MUST take precedence over any of the Uri-Host, Uri-Port, Uri-Path or Uri-Query options (each of which MUST NOT be included in a request containing the Proxy-Uri Option).
Proxy-Uriオプションは、Uri-Host、Uri-Port、Uri-Path、またはUri-Queryオプションのいずれよりも優先する必要があります（それぞれをProxy-Uriオプションを含むリクエストに含めることはできません）。
As a special case to simplify many proxy clients, the absolute-URI can be constructed from the Uri-* options. When a Proxy-Scheme Option is present, the absolute-URI is constructed as follows: a CoAP URI is constructed from the Uri-* options as defined in Section 6.5. In the resulting URI, the initial scheme up to, but not including, the following colon is then replaced by the content of the Proxy-Scheme Option. Note that this case is only applicable if the components of the desired URI other than the scheme component actually can be expressed using Uri-* options; for example, to represent a URI with a userinfo component in the authority, only Proxy-Uri can be used.
多くのプロキシクライアントを簡略化する特殊なケースとして、絶対URIはUri- *オプションから構築できます。 Proxy-Schemeオプションが存在する場合、absolute-URIは次のように構築されます。6.5で定義されているように、CoAP URIはUri- *オプションから構築されます。結果のURIでは、次のコロンまでの最初のスキームは含まれませんが、Proxy-Schemeオプションのコンテンツに置き換えられます。このケースは、スキームコンポーネント以外の目的のURIのコンポーネントが実際にUri- *オプションを使用して表現できる場合にのみ適用できることに注意してください。たとえば、権限内のuserinfoコンポーネントでURIを表すには、Proxy-Uriのみを使用できます。
The Content-Format Option indicates the representation format of the message payload. The representation format is given as a numeric Content-Format identifier that is defined in the "CoAP Content-Formats" registry (Section 12.3). In the absence of the option, no default value is assumed, i.e., the representation format of any representation message payload is indeterminate (Section 5.5).
Content-Formatオプションは、メッセージペイロードの表現形式を示します。表現形式は、「CoAP Content-Formats」レジストリ（セクション12.3）で定義されている数値のContent-Format識別子として指定されます。オプションがない場合、デフォルト値は想定されません。つまり、表現メッセージのペイロードの表現形式は不確定です（セクション5.5）。
The CoAP Accept option can be used to indicate which Content-Format is acceptable to the client. The representation format is given as a numeric Content-Format identifier that is defined in the "CoAP Content-Formats" registry (Section 12.3). If no Accept option is given, the client does not express a preference (thus no default value is assumed). The client prefers the representation returned by the server to be in the Content-Format indicated. The server returns the preferred Content-Format if available. If the preferred Content-Format cannot be returned, then a 4.06 "Not Acceptable" MUST be sent as a response, unless another error code takes precedence for this response.
CoAP Acceptオプションは、どのContent-Formatがクライアントに受け入れられるかを示すために使用できます。表現形式は、「CoAP Content-Formats」レジストリ（セクション12.3）で定義されている数値のContent-Format識別子として指定されます。 Acceptオプションが指定されていない場合、クライアントはプリファレンスを表現しません（したがって、デフォルト値は想定されていません）。クライアントは、サーバーによって返された表現が、示されたContent-Formatであるのを好みます。可能な場合、サーバーは優先コンテンツ形式を返します。推奨されるContent-Formatを返せない場合は、この応答で別のエラーコードが優先されない限り、4.06 "Not Acceptable"を応答として送信する必要があります。
The Max-Age Option indicates the maximum time a response may be cached before it is considered not fresh (see Section 5.6.1).
Max-Age Optionは、フレッシュではないと見なされる前に応答がキャッシュされる最大時間を示します（セクション5.6.1を参照）。
The option value is an integer number of seconds between 0 and 2**32-1 inclusive (about 136.1 years). A default value of 60 seconds is assumed in the absence of the option in a response.
オプション値は、0から2 ** 32-1までの秒数の整数です（約136.1年）。応答にオプションがない場合、デフォルト値の60秒が想定されます。
The value is intended to be current at the time of transmission. Servers that provide resources with strict tolerances on the value of Max-Age SHOULD update the value before each retransmission. (See also Section 5.7.1.)
この値は、送信時の最新の値です。 Max-Ageの値に厳格な許容範囲を持つリソースを提供するサーバーは、各再送信前に値を更新する必要があります（SHOULD）。 （セクション5.7.1も参照してください。）
An entity-tag is intended for use as a resource-local identifier for differentiating between representations of the same resource that vary over time. It is generated by the server providing the resource, which may generate it in any number of ways including a version, checksum, hash, or time. An endpoint receiving an entity-tag MUST treat it as opaque and make no assumptions about its content or structure. (Endpoints that generate an entity-tag are encouraged to use the most compact representation possible, in particular in regards to clients and intermediaries that may want to store multiple ETag values.)
エンティティタグは、時間の経過とともに変化する同じリソースの表現を区別するためのリソースローカル識別子としての使用を目的としています。これは、リソースを提供するサーバーによって生成され、バージョン、チェックサム、ハッシュ、時間など、さまざまな方法で生成されます。エンティティタグを受信するエンドポイントは、それを不透明として扱い、その内容や構造について何も仮定してはなりません（MUST）。 （エンティティタグを生成するエンドポイントでは、特に複数のETag値を格納する可能性のあるクライアントおよび仲介者に関して、可能な限りコンパクトな表現を使用することが推奨されます。）
The ETag Option in a response provides the current value (i.e., after the request was processed) of the entity-tag for the "tagged representation". If no Location-* options are present, the tagged representation is the selected representation (Section 5.5.3) of the target resource. If one or more Location-* options are present and thus a location URI is indicated (Section 5.10.7), the tagged representation is the representation that would be retrieved by a GET request to the location URI.
応答のETagオプションは、「タグ付き表現」のエンティティタグの現在の値（つまり、リクエストが処理された後）を提供します。 Location- *オプションが存在しない場合、タグ付き表現は、ターゲットリソースの選択された表現（セクション5.5.3）です。 1つ以上のLocation- *オプションが存在し、場所URIが示されている場合（セクション5.10.7）、タグ付き表現は、場所URIへのGET要求によって取得される表現です。
An ETag response option can be included with any response for which there is a tagged representation (e.g., it would not be meaningful in a 4.04 or 4.00 response). The ETag Option MUST NOT occur more than once in a response.
ETag応答オプションは、タグ付き表現がある任意の応答に含めることができます（たとえば、4.04または4.00応答では意味がありません）。 ETagオプションは、応答で複数回発生してはなりません。
There is no default value for the ETag Option; if it is not present in a response, the server makes no statement about the entity-tag for the tagged representation.
ETagオプションのデフォルト値はありません。応答に含まれていない場合、サーバーはタグ付き表現のエンティティタグについての記述を行いません。
In a GET request, an endpoint that has one or more representations previously obtained from the resource, and has obtained ETag response options with these, can specify an instance of the ETag Option for one or more of these stored responses.
GETリクエストでは、以前にリソースから取得した1つ以上の表現を持ち、これらを使用してETag応答オプションを取得したエンドポイントは、これらの格納された応答の1つ以上にETagオプションのインスタンスを指定できます。
A server can issue a 2.03 Valid response (Section 5.9.1.3) in place of a 2.05 Content response if one of the ETags given is the entity-tag for the current representation, i.e., is valid; the 2.03 Valid response then echoes this specific ETag in a response option.
指定されたETagの1つが現在の表現のエンティティタグである場合、つまり有効である場合、サーバーは2.05コンテンツ応答の代わりに2.03有効応答（セクション5.9.1.3）を発行できます。 2.03の有効な応答は、この特定のETagを応答オプションにエコーします。
In effect, a client can determine if any of the stored representations is current (see Section 5.6.2) without needing to transfer them again.
実際、クライアントは、格納された表現のいずれかが最新のものであるかどうかを判断できます（5.6.2を参照）。それらを再度転送する必要はありません。
The ETag Option MAY occur zero, one, or multiple times in a request.
ETagオプションは、リクエストで0回、1回、または複数回発生する場合があります。
The Location-Path and Location-Query Options together indicate a relative URI that consists either of an absolute path, a query string, or both. A combination of these options is included in a 2.01 (Created) response to indicate the location of the resource created as the result of a POST request (see Section 5.8.2). The location is resolved relative to the request URI.
Location-PathおよびLocation-Queryオプションは共に、絶対パス、クエリ文字列、またはその両方で構成される相対URIを示します。これらのオプションの組み合わせは、POSTリクエストの結果として作成されたリソースの場所を示すために、2.01（Created）レスポンスに含まれています（セクション5.8.2を参照）。場所は、リクエストURIを基準に解決されます。
If a response with one or more Location-Path and/or Location-Query Options passes through a cache that interprets these options and the implied URI identifies one or more currently stored responses, those entries MUST be marked as not fresh.
1つ以上のLocation-Pathおよび/またはLocation-Queryオプションを含む応答がこれらのオプションを解釈するキャッシュを通過し、暗黙のURIが1つ以上の現在格納されている応答を識別する場合、それらのエントリは未更新としてマークする必要があります。
Each Location-Path Option specifies one segment of the absolute path to the resource, and each Location-Query Option specifies one argument parameterizing the resource. The Location-Path and Location-Query Option can contain any character sequence. No percent-encoding is performed. The value of a Location-Path Option MUST NOT be "." or "..".
各Location-Pathオプションはリソースへの絶対パスの1つのセグメントを指定し、各Location-Queryオプションはリソースをパラメーター化する1つの引数を指定します。 Location-PathおよびLocation-Queryオプションには、任意の文字シーケンスを含めることができます。パーセントエンコーディングは実行されません。 Location-Pathオプションの値は「。」であってはなりません。または「..」。
The steps for constructing the location URI from the options are analogous to Section 6.5, except that the first five steps are skipped and the result is a relative URI-reference, which is then interpreted relative to the request URI. Note that the relative URI-reference constructed this way always includes an absolute path (e.g., leaving out Location-Path but supplying Location-Query means the path component in the URI is "/").
オプションからロケーションURIを構築する手順は、最初の5つの手順がスキップされ、結果が相対URI参照になることを除いて、セクション6.5に類似しています。これは、要求URIに関連して解釈されます。この方法で作成された相対URI参照には常に絶対パスが含まれていることに注意してください（たとえば、Location-Pathを省略しますが、Location-Queryを指定すると、URIのパスコンポーネントが「/」になります）。
The options that are used to compute the relative URI-reference are collectively called Location-* options. Beyond Location-Path and Location-Query, more Location-* options may be defined in the future and have been reserved option numbers 128, 132, 136, and 140. If any of these reserved option numbers occurs in addition to Location-Path and/or Location-Query and are not supported, then a 4.02 (Bad Option) error MUST be returned.
相対URI参照の計算に使用されるオプションは、まとめてLocation- *オプションと呼ばれます。 Location-PathおよびLocation-Queryに加えて、将来的にはより多くのLocation- *オプションが定義される可能性があり、オプション番号128、132、136、および140が予約されています。これらの予約オプション番号のいずれかがLocation-Pathおよび/またはLocation-Queryがサポートされていない場合は、4.02（不良オプション）エラーを返す必要があります。
Conditional request options enable a client to ask the server to perform the request only if certain conditions specified by the option are fulfilled.
条件付き要求オプションを使用すると、オプションで指定された特定の条件が満たされた場合にのみ、クライアントがサーバーに要求を実行するよう要求できます。
For each of these options, if the condition given is not fulfilled, then the server MUST NOT perform the requested method. Instead, the server MUST respond with the 4.12 (Precondition Failed) Response Code.
これらのオプションのそれぞれについて、指定された条件が満たされない場合、サーバーは要求されたメソッドを実行してはなりません（MUST NOT）。代わりに、サーバーは4.12（前提条件失敗）応答コードで応答する必要があります。
If the condition is fulfilled, the server performs the request method as if the conditional request options were not present.
条件が満たされると、サーバーは、条件付き要求オプションが存在しないかのように要求メソッドを実行します。
If the request would, without the conditional request options, result in anything other than a 2.xx or 4.12 Response Code, then any conditional request options MAY be ignored.
条件付きリクエストオプションなしでリクエストが2.xxまたは4.12レスポンスコード以外の結果になる場合、条件付きリクエストオプションはすべて無視される場合があります。
The If-Match Option MAY be used to make a request conditional on the current existence or value of an ETag for one or more representations of the target resource. If-Match is generally useful for resource update requests, such as PUT requests, as a means for protecting against accidental overwrites when multiple clients are acting in parallel on the same resource (i.e., the "lost update" problem).
If-Matchオプションを使用して、ターゲットリソースの1つ以上の表現に対するETagの現在の存在または値に基づいて要求を行うことができます（MAY）。 If-Matchは、通常、複数のクライアントが同じリソース上で並行して動作しているときの偶発的な上書き（つまり、「失われた更新」の問題）から保護する手段として、PUT要求などのリソース更新要求に役立ちます。
The value of an If-Match option is either an ETag or the empty string. An If-Match option with an ETag matches a representation with that exact ETag. An If-Match option with an empty value matches any existing representation (i.e., it places the precondition on the existence of any current representation for the target resource).
If-Matchオプションの値は、ETagまたは空の文字列です。 ETagを使用したIf-Matchオプションは、その正確なETagを使用した表現と一致します。空の値を持つIf-Matchオプションは、既存の表現と一致します（つまり、ターゲットリソースの現在の表現が存在することを前提条件とします）。
The If-Match Option can occur multiple times. If any of the options match, then the condition is fulfilled.
If-Matchオプションは複数回発生する可能性があります。オプションのいずれかが一致すると、条件が満たされます。
If there is one or more If-Match Options, but none of the options match, then the condition is not fulfilled.
If-Matchオプションが1つ以上あるが、どのオプションも一致しない場合、条件は満たされません。
The If-None-Match Option MAY be used to make a request conditional on the nonexistence of the target resource. If-None-Match is useful for resource creation requests, such as PUT requests, as a means for protecting against accidental overwrites when multiple clients are acting in parallel on the same resource. The If-None-Match Option carries no value.
If-None-Matchオプションを使用して、ターゲットリソースが存在しないことを条件としてリクエストを作成できます。 If-None-Matchは、PUTリクエストなどのリソース作成リクエストで、複数のクライアントが同じリソースで並行して動作している場合の偶発的な上書きを防ぐ手段として役立ちます。 If-None-Matchオプションには値がありません。
If the target resource does exist, then the condition is not fulfilled.
ターゲットリソースが存在する場合、条件は満たされません。
(It is not very useful to combine If-Match and If-None-Match options in one request, because the condition will then never be fulfilled.)
（条件が満たされないため、1つのリクエストでIf-MatchオプションとIf-None-Matchオプションを組み合わせるのはあまり役に立ちません。）
The Size1 option provides size information about the resource representation in a request. The option value is an integer number of bytes. Its main use is with block-wise transfers [BLOCK]. In the present specification, it is used in 4.13 responses (Section 5.9.2.9) to indicate the maximum size of request entity that the server is able and willing to handle.
Size1オプションは、リクエスト内のリソース表現に関するサイズ情報を提供します。オプション値はバイト数の整数です。主な用途は、ブロック単位の転送[BLOCK]です。本明細書では、4.13応答（5.9.2.9節）で使用され、サーバーが処理できる、処理能力のある要求エンティティの最大サイズを示します。
CoAP uses the "coap" and "coaps" URI schemes for identifying CoAP resources and providing a means of locating the resource. Resources are organized hierarchically and governed by a potential CoAP origin server listening for CoAP requests ("coap") or DTLS-secured CoAP requests ("coaps") on a given UDP port. The CoAP server is identified via the generic syntax's authority component, which includes a host component and optional UDP port number. The remainder of the URI is considered to be identifying a resource that can be operated on by the methods defined by the CoAP protocol. The "coap" and "coaps" URI schemes can thus be compared to the "http" and "https" URI schemes, respectively.
CoAPは、「coap」および「coaps」URIスキームを使用して、CoAPリソースを識別し、リソースを見つける手段を提供します。リソースは階層的に編成され、特定のUDPポートでCoAP要求（「coap」）またはDTLSで保護されたCoAP要求（「coap」）をリッスンする潜在的なCoAPオリジンサーバーによって管理されます。 CoAPサーバーは、ホストコンポーネントとオプションのUDPポート番号を含む、汎用構文の権限コンポーネントを介して識別されます。 URIの残りの部分は、CoAPプロトコルで定義されたメソッドで操作できるリソースを識別していると見なされます。したがって、「coap」および「coaps」URIスキームは、それぞれ「http」および「https」URIスキームと比較できます。
The syntax of the "coap" and "coaps" URI schemes is specified in this section in Augmented Backus-Naur Form (ABNF) [RFC5234]. The definitions of "host", "port", "path-abempty", "query", "segment", "IP-literal", "IPv4address", and "reg-name" are adopted from [RFC3986].
「coap」および「coaps」URIスキームの構文は、このセクションのAugmented Backus-Naur Form（ABNF）[RFC5234]で指定されています。 「host」、「port」、「path-abempty」、「query」、「segment」、「IP-literal」、「IPv4address」、および「reg-name」の定義は、[RFC3986]から採用されています。
Implementation Note: Unfortunately, over time, the URI format has acquired significant complexity. Implementers are encouraged to examine [RFC3986] closely. For example, the ABNF for IPv6 addresses is more complicated than maybe expected. Also, implementers should take care to perform the processing of percent-decoding or percent-encoding exactly once on the way from a URI to its decoded components or back. Percent-encoding is crucial for data transparency but may lead to unusual results such as a slash character in a path component.
実装上の注意：残念ながら、時間の経過とともに、URI形式はかなり複雑になりました。実装者は[RFC3986]を綿密に検討することが奨励されています。たとえば、IPv6アドレスのABNFは、予想よりも複雑です。また、実装者は、URIからそのデコードされたコンポーネントへまたはその逆の途中で、パーセントデコードまたはパーセントエンコードの処理を1回だけ実行するように注意する必要があります。パーセントエンコーディングはデータの透過性にとって重要ですが、パスコンポーネントにスラッシュ文字などの異常な結果が生じる可能性があります。
coap-URI = "coap:" "//" host [ ":" port ] path-abempty [ "?" query ]
If the host component is provided as an IP-literal or IPv4address, then the CoAP server can be reached at that IP address. If host is a registered name, then that name is considered an indirect identifier and the endpoint might use a name resolution service, such as DNS, to find the address of that host. The host MUST NOT be empty; if a URI is received with a missing authority or an empty host, then it MUST be considered invalid. The port subcomponent indicates the UDP port at which the CoAP server is located. If it is empty or not given, then the default port 5683 is assumed.
ホストコンポーネントがIPリテラルまたはIPv4アドレスとして提供されている場合、CoAPサーバーにはそのIPアドレスで到達できます。ホストが登録名の場合、その名前は間接識別子と見なされ、エンドポイントはDNSなどの名前解決サービスを使用してそのホストのアドレスを検索する場合があります。ホストを空にすることはできません。権限がない、または空のホストでURIを受信した場合、そのURIは無効であると見なされます。ポートサブコンポーネントは、CoAPサーバーが配置されているUDPポートを示します。空の場合、または指定されていない場合は、デフォルトのポート5683が想定されます。
The path identifies a resource within the scope of the host and port. It consists of a sequence of path segments separated by a slash character (U+002F SOLIDUS "/").
パスは、ホストとポートのスコープ内のリソースを識別します。これは、スラッシュ文字（U + 002F SOLIDUS "/"）で区切られた一連のパスセグメントで構成されます。
The query serves to further parameterize the resource. It consists of a sequence of arguments separated by an ampersand character (U+0026 AMPERSAND "&"). An argument is often in the form of a "key=value" pair.
クエリは、リソースをさらにパラメーター化するのに役立ちます。アンパサンド文字（U + 0026 AMPERSAND "＆"）で区切られた一連の引数で構成されます。引数は多くの場合、「キー=値」のペアの形式です。
The "coap" URI scheme supports the path prefix "/.well-known/" defined by [RFC5785] for "well-known locations" in the namespace of a host. This enables discovery of policy or other information about a host ("site-wide metadata"), such as hosted resources (see Section 7).
「coap」URIスキームは、ホストの名前空間の「よく知られた場所」のために[RFC5785]によって定義されたパス接頭辞「/.well-known/」をサポートします。これにより、ホストされているリソースなど、ホストに関するポリシーやその他の情報（「サイト全体のメタデータ」）を検出できます（セクション7を参照）。
Application designers are encouraged to make use of short but descriptive URIs. As the environments that CoAP is used in are usually constrained for bandwidth and energy, the trade-off between these two qualities should lean towards the shortness, without ignoring descriptiveness.
アプリケーション設計者は、短いが説明的なURIを使用することをお勧めします。 CoAPが使用される環境では、通常、帯域幅とエネルギーが制限されているため、説明を無視することなく、これら2つの品質の間のトレードオフが短さを優先する必要があります。
coaps-URI = "coaps:" "//" host [ ":" port ] path-abempty
[ "?" query ]
All of the requirements listed above for the "coap" scheme are also requirements for the "coaps" scheme, except that a default UDP port of 5684 is assumed if the port subcomponent is empty or not given, and the UDP datagrams MUST be secured through the use of DTLS as described in Section 9.1.
上記の「coap」スキームのすべての要件は、「coaps」スキームの要件でもあります。ただし、ポートのサブコンポーネントが空または指定されていない場合、デフォルトのUDPポート5684が想定され、UDPデータグラムは、セクション9.1で説明されているDTLSの使用。
Considerations for caching of responses to "coaps" identified requests are discussed in Section 11.2.
「coaps」で識別された要求への応答のキャッシュに関する考慮事項については、セクション11.2で説明します。
Resources made available via the "coaps" scheme have no shared identity with the "coap" scheme even if their resource identifiers indicate the same authority (the same host listening to the same UDP port). They are distinct namespaces and are considered to be distinct origin servers.
"coaps"スキームを介して利用可能にされたリソースは、リソース識別子が同じ機関（同じホストが同じUDPポートをリッスンしている）を示す場合でも、 "coap"スキームとの共有IDを持ちません。それらは別個の名前空間であり、別個のオリジンサーバーと見なされます。
Since the "coap" and "coaps" schemes conform to the URI generic syntax, such URIs are normalized and compared according to the algorithm defined in [RFC3986], Section 6, using the defaults described above for each scheme.
「coap」および「coaps」スキームはURIの一般的な構文に準拠しているため、これらのURIは正規化され、[RFC3986]、セクション6で定義されたアルゴリズムに従って、各スキームについて上記のデフォルトを使用して比較されます。
If the port is equal to the default port for a scheme, the normal form is to elide the port subcomponent. Likewise, an empty path component is equivalent to an absolute path of "/", so the normal form is to provide a path of "/" instead. The scheme and host are case insensitive and normally provided in lowercase; IP-literals are in recommended form [RFC5952]; all other components are compared in a case-sensitive manner. Characters other than those in the "reserved" set are equivalent to their percent-encoded bytes (see [RFC3986], Section 2.1): the normal form is to not encode them.
ポートがスキームのデフォルトポートと等しい場合、通常の形式はポートサブコンポーネントを省略します。同様に、空のパスコンポーネントは「/」の絶対パスに相当するため、通常の形式では、代わりに「/」のパスを指定します。スキームとホストは大文字と小文字を区別せず、通常は小文字で提供されます。 IPリテラルは推奨される形式[RFC5952]です。他のすべてのコンポーネントは、大文字と小文字を区別して比較されます。 「予約済み」セットの文字以外の文字は、パーセントエンコードされたバイトに相当します（[RFC3986]、セクション2.1を参照）。通常の形式では、エンコードされません。
For example, the following three URIs are equivalent and cause the same options and option values to appear in the CoAP messages:
たとえば、次の3つのURIは同等であり、CoAPメッセージに同じオプションとオプション値が表示されます。
coap://example.com:5683/~sensors/temp.xml
coap://EXAMPLE.com/%7Esensors/temp.xml
coap://EXAMPLE.com:/%7esensors/temp.xml
The steps to parse a request's options from a string |url| are as follows. These steps either result in zero or more of the Uri-Host, Uri-Port, Uri-Path, and Uri-Query Options being included in the request or they fail.
文字列からリクエストのオプションを解析する手順| url |以下の通り。これらの手順により、リクエストに含まれるUri-Host、Uri-Port、Uri-Path、およびUri-Queryオプションが0個以上になるか、失敗します。
1. If the |url| string is not an absolute URI ([RFC3986]), then fail this algorithm.
1. | url |文字列が絶対URI（[RFC3986]）ではない場合、このアルゴリズムは失敗します。
2. Resolve the |url| string using the process of reference resolution defined by [RFC3986]. At this stage, the URL is in ASCII encoding [RFC0020], even though the decoded components will be interpreted in UTF-8 [RFC3629] after steps 5, 8, and 9.
2. | url |を解決する[RFC3986]で定義された参照解決のプロセスを使用する文字列。この段階では、デコードされたコンポーネントはステップ5、8、および9の後でUTF-8 [RFC3629]で解釈されますが、URLはASCIIエンコード[RFC0020]です。
NOTE: It doesn't matter what it is resolved relative to, since we already know it is an absolute URL at this point.
注：この時点では絶対URLであることはすでにわかっているため、それが何に対して解決されるかは関係ありません。
3. If |url| does not have a <scheme> component whose value, when converted to ASCII lowercase, is "coap" or "coaps", then fail this algorithm.
3. | url |の場合値がASCII小文字に変換されたときに「coap」または「coaps」である<scheme>コンポーネントがない場合、このアルゴリズムは失敗します。
4. If |url| has a <fragment> component, then fail this algorithm.
4. | url |の場合<fragment>コンポーネントがある場合、このアルゴリズムは失敗します。
5. If the <host> component of |url| does not represent the request's destination IP address as an IP-literal or IPv4address, include a Uri-Host Option and let that option's value be the value of the <host> component of |url|, converted to ASCII lowercase, and then convert all percent-encodings ("%" followed by two hexadecimal digits) to the corresponding characters.
5. | url |の<host>コンポーネントがリクエストの宛先IPアドレスをIPリテラルまたはIPv4アドレスとして表さず、Uri-Hostオプションを含め、そのオプションの値を| url |の<host>コンポーネントの値にし、ASCII小文字に変換して、すべて変換します。パーセントエンコーディング（ "％"の後に2桁の16進数字）を対応する文字に。
NOTE: In the usual case where the request's destination IP address is derived from the host part, this ensures that a Uri-Host Option is only used for a <host> component of the form reg-name.
注：リクエストの宛先IPアドレスがホスト部分から取得される通常の場合、これにより、Uri-Hostオプションがreg-name形式の<host>コンポーネントにのみ使用されることが保証されます。
6. If |url| has a <port> component, then let |port| be that component's value interpreted as a decimal integer; otherwise, let |port| be the default port for the scheme.
6. | url |の場合<port>コンポーネントがある場合は、| port | 10進整数として解釈されるコンポーネントの値であること。それ以外の場合は、|ポート|スキームのデフォルトポートです。
7. If |port| does not equal the request's destination UDP port, include a Uri-Port Option and let that option's value be |port|.
7. | port |の場合リクエストの宛先UDPポートと同じではなく、URIポートオプションを含め、そのオプションの値を|ポート|にします。
8. If the value of the <path> component of |url| is empty or consists of a single slash character (U+002F SOLIDUS "/"), then move to the next step.
8. | url |の<path>コンポーネントの値空であるか、単一のスラッシュ文字（U + 002F SOLIDUS "/"）で構成されている場合、次のステップに進みます。
Otherwise, for each segment in the <path> component, include a Uri-Path Option and let that option's value be the segment (not including the delimiting slash characters) after converting each percent-encoding ("%" followed by two hexadecimal digits) to the corresponding byte.
それ以外の場合は、<path>コンポーネントの各セグメントにUri-Pathオプションを含め、パーセントエンコード（「％」とそれに続く2桁の16進数）を変換した後、そのオプションの値をセグメント（区切りスラッシュ文字を含まない）にします。対応するバイトに。
9. If |url| has a <query> component, then, for each argument in the <query> component, include a Uri-Query Option and let that option's value be the argument (not including the question mark and the delimiting ampersand characters) after converting each percent-encoding to the corresponding byte.
9. | url |の場合<query>コンポーネントがある場合、<query>コンポーネントの各引数にUri-Queryオプションを含め、各パーセントを変換した後、そのオプションの値を引数（疑問符と区切り記号のアンパサンド文字は含まない）にします対応するバイトへのエンコーディング。
Note that these rules completely resolve any percent-encoding.
これらのルールは、パーセントエンコーディングを完全に解決することに注意してください。
The steps to construct a URI from a request's options are as follows. These steps either result in a URI or they fail. In these steps, percent-encoding a character means replacing each of its (UTF-8-encoded) bytes by a "%" character followed by two hexadecimal digits representing the byte, where the digits A-F are in uppercase (as defined in Section 2.1 of [RFC3986]; to reduce variability, the hexadecimal notation for percent-encoding in CoAP URIs MUST use uppercase letters). The definitions of "unreserved" and "sub-delims" are adopted from [RFC3986].
リクエストのオプションからURIを構築する手順は次のとおりです。これらのステップは、URIになるか、失敗します。これらの手順では、文字をパーセントエンコードすると、その文字の各（UTF-8エンコード）バイトを「％」文字で置き換え、その後にバイトを表す2つの16進数字が続きます。 of [RFC3986];ばらつきを減らすために、CoAP URIでのパーセントエンコーディングの16進表記では大文字を使用する必要があります）。 「未予約」および「サブデリム」の定義は、[RFC3986]から採用されています。
1. If the request is secured using DTLS, let |url| be the string "coaps://". Otherwise, let |url| be the string "coap://".
1. リクエストがDTLSを使用して保護されている場合は、| url |文字列は "coaps：//"です。それ以外の場合は、| url |文字列は "coap：//"です。
2. If the request includes a Uri-Host Option, let |host| be that option's value, where any non-ASCII characters are replaced by their corresponding percent-encoding. If |host| is not a valid reg-name or IP-literal or IPv4address, fail the algorithm. If the request does not include a Uri-Host Option, let |host| be the IP-literal (making use of the conventions of [RFC5952]) or IPv4address representing the request's destination IP address.
2. リクエストにURIホストオプションが含まれている場合は、| host |そのオプションの値であり、非ASCII文字は対応するパーセントエンコーディングに置き換えられます。 | host |の場合有効なreg-nameまたはIP-literalまたはIPv4addressではありません。アルゴリズムを失敗させます。リクエストにURIホストオプションが含まれていない場合は、| host | IPリテラル（[RFC5952]の規則を使用）または要求の宛先IPアドレスを表すIPv4アドレス。
3. Append |host| to |url|.
3. | host |を追加| url |へ。
4. If the request includes a Uri-Port Option, let |port| be that option's value. Otherwise, let |port| be the request's destination UDP port.
4. リクエストにURIポートオプションが含まれている場合は、| port |そのオプションの値である。それ以外の場合は、|ポート|リクエストの宛先UDPポート。
5. If |port| is not the default port for the scheme, then append a single U+003A COLON character (:) followed by the decimal representation of |port| to |url|.
5. | port |の場合スキームのデフォルトのポートではない場合、単一のU + 003Aコロン文字（:)を追加し、その後に10進表記の|ポート|を続けます。 | url |へ。
6. Let |resource name| be the empty string. For each Uri-Path Option in the request, append a single character U+002F SOLIDUS (/) followed by the option's value to |resource name|, after converting any character that is not either in the "unreserved" set, in the "sub-delims" set, a U+003A COLON (:) character, or a U+0040 COMMERCIAL AT (@) character to its percent-encoded form.
6. |リソース名|空の文字列である。リクエスト内の各Uri-Pathオプションについて、「予約されていない」セットのいずれにもない文字を「リソース名」に変換した後、1文字のU + 002F SOLIDUS（/）に続けてオプションの値を|リソース名|に追加します。サブデリミタ」セット、U + 003Aコロン（:)文字、またはU + 0040 COMMERCIAL AT（@）文字をパーセントエンコード形式に。
7. If |resource name| is the empty string, set it to a single character U+002F SOLIDUS (/).
7. |リソース名|空の文字列です。1文字のU + 002F SOLIDUS（/）に設定します。
8. For each Uri-Query Option in the request, append a single character U+003F QUESTION MARK (?) (first option) or U+0026 AMPERSAND (&) (subsequent options) followed by the option's value to |resource name|, after converting any character that is not either in the "unreserved" set, in the "sub-delims" set (except U+0026 AMPERSAND (&)), a U+003A COLON (:), a U+0040 COMMERCIAL AT (@), a U+002F SOLIDUS (/), or a U+003F QUESTION MARK (?) character to its percent-encoded form.
8. リクエスト内のUri-Queryオプションごとに、1文字のU + 003F QUESTION MARK（？）（最初のオプション）またはU + 0026 AMPERSAND（＆）（後続のオプション）を追加し、オプションの値を|リソース名|の後に追加します。 「予約されていない」セット、「サブデリミタ」セット（U + 0026 AMPERSAND（＆）を除く）、U + 003Aコロン（:)、U + 0040 COMMERCIAL AT（@ ）、U + 002F SOLIDUS（/）、またはU + 003F QUESTION MARK（？）文字をパーセントエンコード形式に変換します。
9. Append |resource name| to |url|.
9. 追加|リソース名| | url |へ。
10. Return |url|.
10. | url |を返します。
Note that these steps have been designed to lead to a URI in normal form (see Section 6.3).
これらのステップは、通常の形式のURIにつながるように設計されていることに注意してください（セクション6.3を参照）。
As a part of discovering the services offered by a CoAP server, a client has to learn about the endpoint used by a server.
CoAPサーバーが提供するサービスを検出する一環として、クライアントはサーバーが使用するエンドポイントについて知る必要があります。
A server is discovered by a client (knowing or) learning a URI that references a resource in the namespace of the server. Alternatively, clients can use multicast CoAP (see Section 8) and the "All CoAP Nodes" multicast address to find CoAP servers.
サーバーは、サーバーの名前空間内のリソースを参照するURIを（知っているか）学習しているクライアントによって発見されます。または、クライアントはマルチキャストCoAP（セクション8を参照）と「すべてのCoAPノード」マルチキャストアドレスを使用してCoAPサーバーを見つけることができます。
Unless the port subcomponent in a "coap" or "coaps" URI indicates the UDP port at which the CoAP server is located, the server is assumed to be reachable at the default port.
「coap」または「coaps」URIのポートサブコンポーネントがCoAPサーバーが配置されているUDPポートを示さない限り、サーバーはデフォルトポートで到達可能であると見なされます。
The CoAP default port number 5683 MUST be supported by a server that offers resources for resource discovery (see Section 7.2 below) and SHOULD be supported for providing access to other resources. The default port number 5684 for DTLS-secured CoAP MAY be supported by a server for resource discovery and for providing access to other resources. In addition, other endpoints may be hosted at other ports, e.g., in the dynamic port space.
CoAPのデフォルトポート番号5683は、リソースディスカバリ用のリソースを提供するサーバーでサポートされている必要があり（以下のセクション7.2を参照）、他のリソースへのアクセスを提供するためにサポートされている必要があります（SHOULD）。 DTLSで保護されたCoAPのデフォルトのポート番号5684は、リソースの発見と他のリソースへのアクセスの提供のためにサーバーでサポートされる場合があります。さらに、他のエンドポイントは、動的ポートスペースなどの他のポートでホストされている場合があります。
Implementation Note: When a CoAP server is hosted by a 6LoWPAN node, header compression efficiency is improved when it also supports a port number in the 61616-61631 compressed UDP port space defined in [RFC4944] and [RFC6282]. (Note that, as its UDP port differs from the default port, it is a different endpoint from the server at the default port.)
実装上の注意：CoAPサーバーが6LoWPANノードでホストされている場合、[RFC4944]と[RFC6282]で定義されている61616-61631圧縮UDPポートスペースのポート番号もサポートすると、ヘッダー圧縮効率が向上します。 （UDPポートはデフォルトポートとは異なるため、デフォルトポートにあるサーバーとは異なるエンドポイントです。）
The discovery of resources offered by a CoAP endpoint is extremely important in machine-to-machine applications where there are no humans in the loop and static interfaces result in fragility. To maximize interoperability in a CoRE environment, a CoAP endpoint SHOULD support the CoRE Link Format of discoverable resources as described in [RFC6690], except where fully manual configuration is desired. It is up to the server which resources are made discoverable (if any).
CoAPエンドポイントによって提供されるリソースの発見は、ループ内に人間が存在せず、静的インターフェースが脆弱性をもたらすマシンツーマシンアプリケーションでは非常に重要です。 CoRE環境での相互運用性を最大化するために、CoAPエンドポイントは、完全に手動の構成が必要な場合を除いて、[RFC6690]で説明されている検出可能なリソースのCoREリンク形式をサポートする必要があります（SHOULD）。リソースを（もしあれば）検出可能にするかどうかはサーバー次第です。
This section defines a new Web Linking [RFC5988] attribute for use with [RFC6690]. The Content-Format code "ct" attribute provides a hint about the Content-Formats this resource returns. Note that this is only a hint, and it does not override the Content-Format Option of a CoAP response obtained by actually requesting the representation of the resource. The value is in the CoAP identifier code format as a decimal ASCII integer and MUST be in the range of 0-65535 (16-bit unsigned integer). For example, "application/xml" would be indicated as "ct=41". If no Content-Format code attribute is present, then nothing about the type can be assumed. The Content-Format code attribute MAY include a space-separated sequence of Content-Format codes, indicating that multiple content-formats are available. The syntax of the attribute value is summarized in the production "ct-value" in Figure 12, where "cardinal", "SP", and "DQUOTE" are defined as in [RFC6690].
このセクションでは、[RFC6690]で使用する新しいWebリンク[RFC5988]属性を定義します。 Content-Formatコードの「ct」属性は、このリソースが返すContent-Formatsに関するヒントを提供します。これはヒントにすぎず、実際にリソースの表現を要求することによって取得されたCoAP応答のContent-Formatオプションをオーバーライドしないことに注意してください。値は、10進ASCII整数としてCoAP識別子コード形式であり、0〜65535（16ビットの符号なし整数）の範囲でなければなりません。たとえば、「application / xml」は「ct = 41」と示されます。 Content-Formatコード属性が存在しない場合、タイプについては何も想定できません。 Content-Formatコード属性には、スペースで区切られたContent-Formatコードのシーケンスを含めることができます。これは、複数のcontent-formatsが利用可能であることを示します。属性値の構文は、図12のプロダクション「ct-value」に要約されています。「cardinal」、「SP」、および「DQUOTE」は、[RFC6690]のように定義されています。
ct-value = cardinal
/ DQUOTE cardinal *( 1*SP cardinal ) DQUOTE
Figure 12
図12
CoAP supports making requests to an IP multicast group. This is defined by a series of deltas to unicast CoAP. A more general discussion of group communication with CoAP is in [GROUPCOMM].
CoAPは、IPマルチキャストグループへの要求の作成をサポートしています。これは、ユニキャストCoAPに対する一連のデルタによって定義されます。 CoAPとのグループ通信のより一般的な議論は[GROUPCOMM]にあります。
CoAP endpoints that offer services that they want other endpoints to be able to find using multicast service discovery join one or more of the appropriate all-CoAP-node multicast addresses (Section 12.8) and listen on the default CoAP port. Note that an endpoint might receive multicast requests on other multicast addresses, including the all-nodes IPv6 address (or via broadcast on IPv4); an endpoint MUST therefore be prepared to receive such messages but MAY ignore them if multicast service discovery is not desired.
他のエンドポイントがマルチキャストサービスディスカバリを使用して検索できるようにするサービスを提供するCoAPエンドポイントは、1つ以上の適切な全CoAPノードマルチキャストアドレスに参加し（セクション12.8）、デフォルトのCoAPポートでリッスンします。エンドポイントは、全ノードのIPv6アドレスを含む他のマルチキャストアドレスで（またはIPv4のブロードキャストを介して）マルチキャスト要求を受信する場合があることに注意してください。したがって、エンドポイントはそのようなメッセージを受信する準備ができていなければなりません（MUST）が、マルチキャストサービスディスカバリが望まれない場合は、それらを無視してもよい（MAY）。
A multicast request is characterized by being transported in a CoAP message that is addressed to an IP multicast address instead of a CoAP endpoint. Such multicast requests MUST be Non-confirmable.
マルチキャスト要求は、CoAPエンドポイントではなくIPマルチキャストアドレスにアドレス指定されたCoAPメッセージで転送されることを特徴としています。このようなマルチキャスト要求は確認不可でなければなりません。
A server SHOULD be aware that a request arrived via multicast, e.g., by making use of modern APIs such as IPV6_RECVPKTINFO [RFC3542], if available.
サーバーは、たとえば、可能であればIPV6_RECVPKTINFO [RFC3542]などの最新のAPIを利用することにより、マルチキャスト経由でリクエストが到着したことを認識する必要があります。
To avoid an implosion of error responses, when a server is aware that a request arrived via multicast, it MUST NOT return a Reset message in reply to a Non-confirmable message. If it is not aware, it MAY return a Reset message in reply to a Non-confirmable message as usual. Because such a Reset message will look identical to one for a unicast message from the sender, the sender MUST avoid using a Message ID that is also still active from this endpoint with any unicast endpoint that might receive the multicast message.
エラー応答の急増を回避するために、サーバーがリクエストがマルチキャストを介して到着したことを認識している場合、確認できないメッセージに応答してリセットメッセージを返してはなりません。認識していない場合は、通常どおり確認できないメッセージに応答してリセットメッセージを返すことがあります。このようなリセットメッセージは送信者からのユニキャストメッセージの場合と同じように見えるため、送信者は、このエンドポイントからまだアクティブなメッセージIDを、マルチキャストメッセージを受信する可能性のあるユニキャストエンドポイントで使用しないようにする必要があります。
At the time of writing, multicast messages can only be carried in UDP not in DTLS. This means that the security modes defined for CoAP in this document are not applicable to multicast.
現時点では、マルチキャストメッセージはUDPでのみ伝送でき、DTLSでは伝送できません。つまり、このドキュメントでCoAPに定義されているセキュリティモードは、マルチキャストには適用されません。
When a server is aware that a request arrived via multicast, the server MAY always ignore the request, in particular if it doesn't have anything useful to respond (e.g., if it only has an empty payload or an error response). The decision for this may depend on the application. (For example, in query filtering as described in [RFC6690], a server should not respond to a multicast request if the filter does not match. More examples are in [GROUPCOMM].)
サーバーがリクエストがマルチキャストを介して到着したことを認識している場合、特に応答に役立つものがない場合（たとえば、空のペイロードまたはエラー応答しかない場合）、サーバーは常にそのリクエストを無視してもよい（MAY）この決定は、アプリケーションによって異なります。 （たとえば、[RFC6690]で説明されているクエリフィルタリングでは、フィルターが一致しない場合、サーバーはマルチキャスト要求に応答してはなりません。他の例は[GROUPCOMM]にあります。）
If a server does decide to respond to a multicast request, it should not respond immediately. Instead, it should pick a duration for the period of time during which it intends to respond. For the purposes of this exposition, we call the length of this period the Leisure. The specific value of this Leisure may depend on the application or MAY be derived as described below. The server SHOULD then pick a random point of time within the chosen leisure period to send back the unicast response to the multicast request. If further responses need to be sent based on the same multicast address membership, a new leisure period starts at the earliest after the previous one finishes.
サーバーがマルチキャスト要求に応答することを決定した場合、サーバーはすぐに応答するべきではありません。代わりに、応答する予定の期間を選択する必要があります。この説明のために、この期間の長さをレジャーと呼びます。このレジャーの具体的な値は、アプリケーションによって異なる場合があります。または、以下に説明するように導出される場合があります。次に、サーバーは、選択された余暇期間内のランダムな時点を選択して、ユニキャスト応答をマルチキャスト要求に返信する必要があります（SHOULD）。同じマルチキャストアドレスメンバーシップに基づいてさらに応答を送信する必要がある場合は、前の応答が終了した後、できるだけ早く新しい余暇期間が始まります。
To compute a value for Leisure, the server should have a group size estimate G, a target data transfer rate R (which both should be chosen conservatively), and an estimated response size S; a rough lower bound for Leisure can then be computed as
Leisureの値を計算するには、サーバーにグループサイズの推定値G、ターゲットデータ転送速度R（どちらも控えめに選択する必要があります）、および推定応答サイズSが必要です。レジャーのおおよその下限は、次のように計算できます。
lb_Leisure = S * G / R
For example, for a multicast request with link-local scope on a 2.4 GHz IEEE 802.15.4 (6LoWPAN) network, G could be (relatively conservatively) set to 100, S to 100 bytes, and the target rate to 8 kbit/s = 1 kB/s. The resulting lower bound for the Leisure is 10 seconds.
たとえば、2.4 GHz IEEE 802.15.4（6LoWPAN）ネットワーク上のリンクローカルスコープのマルチキャスト要求の場合、Gは（比較的控えめに）100、Sは100バイト、ターゲットレートは8 kbit / sに設定できます。 = 1 kB /秒。レジャーの結果の下限は10秒です。
If a CoAP endpoint does not have suitable data to compute a value for Leisure, it MAY resort to DEFAULT_LEISURE.
CoAPエンドポイントにLeisureの値を計算するための適切なデータがない場合、それはDEFAULT_LEISUREに頼ることができます（MAY）。
When matching a response to a multicast request, only the token MUST match; the source endpoint of the response does not need to (and will not) be the same as the destination endpoint of the original request.
マルチキャスト要求への応答を照合する場合は、トークンのみが一致する必要があります。応答のソースエンドポイントは、元のリクエストの宛先エンドポイントと同じである必要はありません（同じである必要もありません）。
For the purposes of interpreting the Location-* options and any links embedded in the representation, the request URI (i.e., the base URI relative to which the response is interpreted) is formed by replacing the multicast address in the Host component of the original request URI by the literal IP address of the endpoint actually responding.
Location- *オプションおよび表現に埋め込まれたリンクを解釈するために、元の要求のホストコンポーネントのマルチキャストアドレスを置き換えることにより、要求URI（つまり、応答の解釈に関連するベースURI）が形成されます。実際に応答するエンドポイントのリテラルIPアドレスによるURI。
When a client makes a multicast request, it always makes a new request to the multicast group (since there may be new group members that joined meanwhile or ones that did not get the previous request). It MAY update a cache with the received responses. Then, it uses both cached-still-fresh and new responses as the result of the request.
クライアントがマルチキャスト要求を行うとき、それは常にマルチキャストグループに新しい要求を行います（その間に参加した新しいグループメンバーまたは前の要求を取得しなかったグループメンバーが存在する可能性があるため）。受信した応答でキャッシュを更新する場合があります。次に、リクエストの結果として、キャッシュされたまだ新しい応答と新しい応答の両方を使用します。
A response received in reply to a GET request to a multicast group MAY be used to satisfy a subsequent request on the related unicast request URI. The unicast request URI is obtained by replacing the authority part of the request URI with the transport-layer source address of the response message.
マルチキャストグループへのGET要求への応答として受信した応答は、関連するユニキャスト要求URIでの後続の要求を満たすために使用される場合があります。ユニキャスト要求URIは、要求URIの権限部分を応答メッセージのトランスポート層送信元アドレスに置き換えることによって取得されます。
A cache MAY revalidate a response by making a GET request on the related unicast request URI.
キャッシュは、関連するユニキャストリクエストURIでGETリクエストを行うことにより、レスポンスを再検証する場合があります。
A GET request to a multicast group MUST NOT contain an ETag option. A mechanism to suppress responses the client already has is left for further study.
マルチキャストグループへのGETリクエストには、ETagオプションを含めることはできません。クライアントがすでに持っている応答を抑制するメカニズムは、今後の検討課題です。
When a forward-proxy receives a request with a Proxy-Uri or URI constructed from Proxy-Scheme that indicates a multicast address, the proxy obtains a set of responses as described above and sends all responses (both cached-still-fresh and new) back to the original client.
フォワードプロキシが、マルチキャストアドレスを示すProxy-Schemeから構築されたProxy-UriまたはURIを含む要求を受信すると、プロキシは上記のように一連の応答を取得し、すべての応答（cached-still-freshとnewの両方）を送信します。元のクライアントに戻ります。
This specification does not provide a way to indicate the unicast-modified request URI (base URI) in responses thus forwarded. Proxying multicast requests is discussed in more detail in [GROUPCOMM]; one proposal to address the base URI issue can be found in Section 3 of [CoAP-MISC].
この仕様は、このように転送された応答でユニキャスト変更された要求URI（ベースURI）を示す方法を提供しません。マルチキャストリクエストのプロキシについては、[GROUPCOMM]で詳しく説明しています。ベースURIの問題に対処する1つの提案は、[CoAP-MISC]のセクション3にあります。
This section defines the DTLS binding for CoAP.
このセクションでは、CoAPのDTLSバインディングを定義します。
During the provisioning phase, a CoAP device is provided with the security information that it needs, including keying materials and access control lists. This specification defines provisioning for the RawPublicKey mode in Section 9.1.3.2.1. At the end of the provisioning phase, the device will be in one of four security modes with the following information for the given mode. The NoSec and RawPublicKey modes are mandatory to implement for this specification.
プロビジョニング段階では、CoAPデバイスには、キー情報やアクセス制御リストなど、必要なセキュリティ情報が提供されます。この仕様は、セクション9.1.3.2.1でRawPublicKeyモードのプロビジョニングを定義しています。プロビジョニングフェーズの最後に、デバイスは4つのセキュリティモードの1つになり、特定のモードに関する次の情報が表示されます。 NoSecおよびRawPublicKeyモードは、この仕様の実装に必須です。
NoSec: There is no protocol-level security (DTLS is disabled). Alternative techniques to provide lower-layer security SHOULD be used when appropriate. The use of IPsec is discussed in [IPsec-CoAP]. Certain link layers in use with constrained nodes also provide link-layer security, which may be appropriate with proper key management.
NoSec：プロトコルレベルのセキュリティはありません（DTLSは無効です）。下位層のセキュリティを提供する代替技術は、必要に応じて使用する必要があります。 IPsecの使用については、[IPsec-CoAP]で説明されています。制約されたノードで使用されている特定のリンク層もリンク層セキュリティを提供します。これは適切なキー管理に適している場合があります。
PreSharedKey: DTLS is enabled, there is a list of pre-shared keys [RFC4279], and each key includes a list of which nodes it can be used to communicate with as described in Section 9.1.3.1. At the extreme, there may be one key for each node this CoAP node needs to communicate with (1:1 node/key ratio). Conversely, if more than two entities share a specific pre-shared key, this key only enables the entities to authenticate as a member of that group and not as a specific peer.
PreSharedKey：DTLSが有効で、事前共有キーのリスト[RFC4279]があり、各キーには、9.1.3.1項で説明されているように、通信に使用できるノードのリストが含まれています。極端な場合、このCoAPノードが通信する必要があるノードごとに1つのキーがある場合があります（1：1のノード/キーの比率）。逆に、3つ以上のエンティティが特定の事前共有キーを共有している場合、このキーを使用すると、エンティティは特定のピアではなく、そのグループのメンバーとして認証されます。
RawPublicKey: DTLS is enabled and the device has an asymmetric key pair without a certificate (a raw public key) that is validated using an out-of-band mechanism [RFC7250] as described in Section 9.1.3.2. The device also has an identity calculated from the public key and a list of identities of the nodes it can communicate with.
RawPublicKey：DTLSが有効になっていて、デバイスには、9.1.3.2で説明されているアウトオブバンドメカニズム[RFC7250]を使用して検証される証明書（生の公開鍵）なしの非対称鍵ペアがあります。デバイスには、公開鍵から計算されたIDと、通信できるノードのIDのリストも含まれています。
Certificate: DTLS is enabled and the device has an asymmetric key pair with an X.509 certificate [RFC5280] that binds it to its subject and is signed by some common trust root as described in Section 9.1.3.3. The device also has a list of root trust anchors that can be used for validating a certificate.
証明書：DTLSが有効になっていて、デバイスにX.509証明書[RFC5280]の非対称キーペアがあり、それをサブジェクトにバインドし、セクション9.1.3.3で説明されているいくつかの一般的な信頼ルートによって署名されている。デバイスには、証明書の検証に使用できるルートトラストアンカーのリストもあります。
In the "NoSec" mode, the system simply sends the packets over normal UDP over IP and is indicated by the "coap" scheme and the CoAP default port. The system is secured only by keeping attackers from being able to send or receive packets from the network with the CoAP nodes; see Section 11.5 for an additional complication with this approach.
「NoSec」モードでは、システムは通常のUDP over IPを介してパケットを送信するだけであり、「coap」スキームとCoAPデフォルトポートによって示されます。システムは、攻撃者がCoAPノードを使用してネットワークからパケットを送受信できないようにすることによってのみ保護されます。このアプローチのさらなる複雑さについては、セクション11.5を参照してください。
The other three security modes are achieved using DTLS and are indicated by the "coaps" scheme and DTLS-secured CoAP default port. The result is a security association that can be used to authenticate (within the limits of the security model) and, based on this authentication, authorize the communication partner. CoAP itself does not provide protocol primitives for authentication or authorization; where this is required, it can either be provided by communication security (i.e., IPsec or DTLS) or by object security (within the payload). Devices that require authorization for certain operations are expected to require one of these two forms of security. Necessarily, where an intermediary is involved, communication security only works when that intermediary is part of the trust relationships. CoAP does not provide a way to forward different levels of authorization that clients may have with an intermediary to further intermediaries or origin servers -- it therefore may be required to perform all authorization at the first intermediary.
他の3つのセキュリティモードはDTLSを使用して実現され、「coaps」スキームとDTLSで保護されたCoAPデフォルトポートによって示されます。その結果、認証（セキュリティモデルの制限内）に使用できるセキュリティアソシエーションが作成され、この認証に基づいて通信パートナーを承認します。 CoAP自体は、認証または許可のためのプロトコルプリミティブを提供しません。これが必要な場合は、通信セキュリティ（つまり、IPsecまたはDTLS）またはオブジェクトセキュリティ（ペイロード内）によって提供できます。特定の操作に承認が必要なデバイスには、これら2つの形式のセキュリティのいずれかが必要であると予想されます。必然的に、仲介者が関与する場合、通信セキュリティは、仲介者が信頼関係の一部である場合にのみ機能します。 CoAPは、クライアントが仲介者とともに持つ可能性があるさまざまなレベルの承認を、他の仲介者またはオリジンサーバーに転送する方法を提供しません。したがって、最初の仲介者ですべての承認を実行する必要がある場合があります。
Just as HTTP is secured using Transport Layer Security (TLS) over TCP, CoAP is secured using Datagram TLS (DTLS) [RFC6347] over UDP (see Figure 13). This section defines the CoAP binding to DTLS, along with the minimal mandatory-to-implement configurations appropriate for constrained environments. The binding is defined by a series of deltas to unicast CoAP. In practice, DTLS is TLS with added features to deal with the unreliable nature of the UDP transport.
HTTPがTCP上のトランスポート層セキュリティ（TLS）を使用して保護されるのと同様に、CoAPはUDPを介したデータグラムTLS（DTLS）[RFC6347]を使用して保護されます（図13を参照）。このセクションでは、DTLSへのCoAPバインディングを、制約された環境に適した最小限の必須から実装までの構成とともに定義します。バインディングは、ユニキャストCoAPへの一連のデルタによって定義されます。実際には、DTLSは、UDPトランスポートの信頼できない性質に対処するための追加機能を備えたTLSです。
+----------------------+
| Application |
+----------------------+
+----------------------+
| Requests/Responses |
|----------------------| CoAP
| Messages |
+----------------------+
+----------------------+
| DTLS |
+----------------------+
+----------------------+
| UDP |
+----------------------+
Figure 13: Abstract Layering of DTLS-Secured CoAP
図13：DTLSで保護されたCoAPの抽象レイヤリング
In some constrained nodes (limited flash and/or RAM) and networks (limited bandwidth or high scalability requirements), and depending on the specific cipher suites in use, all modes of DTLS may not be applicable. Some DTLS cipher suites can add significant implementation complexity as well as some initial handshake overhead needed when setting up the security association. Once the initial handshake is completed, DTLS adds a limited per-datagram overhead of approximately 13 bytes, not including any initialization vectors/ nonces (e.g., 8 bytes with TLS_PSK_WITH_AES_128_CCM_8 [RFC6655]), integrity check values (e.g., 8 bytes with TLS_PSK_WITH_AES_128_CCM_8 [RFC6655]), and padding required by the cipher suite. Whether the use of a given mode of DTLS is applicable for a CoAP-based application should be carefully weighed considering the specific cipher suites that may be applicable, whether the session maintenance makes it compatible with application flows, and whether sufficient resources are available on the constrained nodes and for the added network overhead. (For some modes of using DTLS, this specification identifies a mandatory-to-implement cipher suite. This is an implementation requirement to maximize interoperability in those cases where these cipher suites are indeed appropriate. The specific security policies of an application may determine the actual set of cipher suites that can be used.) DTLS is not applicable to group keying (multicast communication); however, it may be a component in a future group key management protocol.
一部の制約付きノード（フラッシュやRAMが制限されている）およびネットワーク（帯域幅が制限されている、またはスケーラビリティ要件が高い）では、使用中の特定の暗号スイートによっては、DTLSのすべてのモードが適用されない場合があります。一部のDTLS暗号スイートは、セキュリティアソシエーションを設定するときに必要な初期のハンドシェイクオーバーヘッドだけでなく、実装の複雑さを大幅に追加する可能性があります。最初のハンドシェイクが完了すると、DTLSは約13バイトの制限されたデータグラムごとのオーバーヘッドを追加します。初期化ベクトル/ノンス（たとえば、TLS_PSK_WITH_AES_128_CCM_8 [RFC6655]の8バイト）、整合性チェック値（たとえば、TLS_PSK_WITH_AES_128_CCM_8 [8バイトの8バイト）は含まれませんRFC6655]）、および暗号スイートに必要なパディング。 DTLSの特定のモードの使用がCoAPベースのアプリケーションに適用可能かどうかは、適用可能な特定の暗号スイート、セッションのメンテナンスによりアプリケーションフローとの互換性が確保されるかどうか、およびで十分なリソースが利用可能かどうかを考慮して慎重に検討する必要があります制約されたノードと追加されたネットワークオーバーヘッド。 （DTLSを使用する一部のモードでは、この仕様は必須から実装までの暗号スイートを識別します。これは、これらの暗号スイートが実際に適切である場合に相互運用性を最大化するための実装要件です。アプリケーションの特定のセキュリティポリシーは、実際の使用できる暗号スイートのセット。）DTLSはグループキーイング（マルチキャスト通信）には適用されません。ただし、将来のグループキー管理プロトコルのコンポーネントになる可能性があります。
The endpoint acting as the CoAP client should also act as the DTLS client. It should initiate a session to the server on the appropriate port. When the DTLS handshake has finished, the client may initiate the first CoAP request. All CoAP messages MUST be sent as DTLS "application data".
CoAPクライアントとして機能するエンドポイントは、DTLSクライアントとしても機能する必要があります。適切なポートでサーバーへのセッションを開始する必要があります。 DTLSハンドシェイクが完了すると、クライアントは最初のCoAP要求を開始できます。すべてのCoAPメッセージは、DTLS「アプリケーションデータ」として送信する必要があります。
The following rules are added for matching an Acknowledgement message or Reset message to a Confirmable message, or a Reset message to a Non-confirmable message: The DTLS session MUST be the same, and the epoch MUST be the same.
確認メッセージまたはリセットメッセージを確認可能メッセージに、またはリセットメッセージを確認不可能メッセージに一致させるために、次のルールが追加されます。DTLSセッションは同じである必要があり、エポックは同じである必要があります。
A message is the same when it is sent within the same DTLS session and same epoch and has the same Message ID.
同じDTLSセッションおよび同じエポック内で送信され、同じメッセージIDを持つメッセージは同じです。
Note: When a Confirmable message is retransmitted, a new DTLS sequence_number is used for each attempt, even though the CoAP Message ID stays the same. So a recipient still has to perform deduplication as described in Section 4.5. Retransmissions MUST NOT be performed across epochs.
注：確認可能メッセージが再送信されると、CoAPメッセージIDが同じである場合でも、試行ごとに新しいDTLS sequence_numberが使用されます。そのため、セクション4.5で説明されているように、受信者は重複排除を実行する必要があります。再送信は、エポック全体で実行してはなりません。
DTLS connections in RawPublicKey and Certificate mode are set up using mutual authentication so they can remain up and be reused for future message exchanges in either direction. Devices can close a DTLS connection when they need to recover resources, but in general they should keep the connection up for as long as possible. Closing the DTLS connection after every CoAP message exchange is very inefficient.
RawPublicKeyおよび証明書モードのDTLS接続は相互認証を使用してセットアップされるため、接続を維持し、今後のいずれかの方向でのメッセージ交換に再利用できます。デバイスは、リソースを回復する必要があるときにDTLS接続を閉じることができますが、一般的には、接続を可能な限り長く維持する必要があります。 CoAPメッセージを交換するたびにDTLS接続を閉じることは、非常に非効率的です。
The following rules are added for matching a response to a request: The DTLS session MUST be the same, and the epoch MUST be the same.
要求への応答を照合するために、次のルールが追加されます。DTLSセッションは同じである必要があり、エポックは同じである必要があります。
This means the response to a DTLS secured request MUST always be DTLS secured using the same security session and epoch. Any attempt to supply a NoSec response to a DTLS request simply does not match the request and therefore MUST be rejected (unless it does match an unrelated NoSec request).
つまり、DTLSで保護されたリクエストへの応答は、常に同じセキュリティセッションとエポックを使用してDTLSで保護されている必要があります。 DTLS要求へのNoSec応答を提供しようとする試みは、単に要求と一致しないため、拒否されなければなりません（無関係なNoSec要求と一致しない限り）。
Devices SHOULD support the Server Name Indication (SNI) to indicate their authority in the SNI HostName field as defined in Section 3 of [RFC6066]. This is needed so that when a host that acts as a virtual server for multiple Authorities receives a new DTLS connection, it knows which keys to use for the DTLS session.
デバイスは、[RFC6066]のセクション3で定義されているように、SNI HostNameフィールドで権限を示すサーバー名表示（SNI）をサポートする必要があります（SHOULD）。これは、複数の機関の仮想サーバーとして機能するホストが新しいDTLS接続を受信したときに、DTLSセッションに使用するキーを認識するために必要です。
When forming a connection to a new node, the system selects an appropriate key based on which nodes it is trying to reach and then forms a DTLS session using a PSK (Pre-Shared Key) mode of DTLS. Implementations in these modes MUST support the mandatory-to-implement cipher suite TLS_PSK_WITH_AES_128_CCM_8 as specified in [RFC6655].
新しいノードへの接続を形成するとき、システムは到達しようとしているノードに基づいて適切なキーを選択し、DTLSのPSK（事前共有キー）モードを使用してDTLSセッションを形成します。これらのモードの実装は、[RFC6655]で指定されているように、必須から実装までの暗号スイートTLS_PSK_WITH_AES_128_CCM_8をサポートする必要があります。
Depending on the commissioning model, applications may need to define an application profile for identity hints (as required and detailed in Section 5.2 of [RFC4279]) to enable the use of PSK identity hints.
コミッショニングモデルによっては、PSK IDヒントの使用を有効にするために、アプリケーションがIDヒントのアプリケーションプロファイルを定義する必要がある場合があります（[RFC4279]のセクション5.2で必要かつ詳細に記載）。
The security considerations of Section 7 of [RFC4279] apply. In particular, applications should carefully weigh whether or not they need Perfect Forward Secrecy (PFS) and select an appropriate cipher suite (Section 7.1 of [RFC4279]). The entropy of the PSK must be sufficient to mitigate against brute-force and (where the PSK is not chosen randomly but by a human) dictionary attacks (Section 7.2 of [RFC4279]). The cleartext communication of client identities may leak data or compromise privacy (Section 7.3 of [RFC4279]).
[RFC4279]のセクション7のセキュリティに関する考慮事項が適用されます。特に、アプリケーションは、Perfect Forward Secrecy（PFS）が必要かどうかを慎重に検討し、適切な暗号スイートを選択する必要があります（[RFC4279]のセクション7.1）。 PSKのエントロピーは、ブルートフォースと（PSKがランダムにではなく人間によって選択された場合）辞書攻撃を軽減するのに十分である必要があります（[RFC4279]のセクション7.2）。クライアントIDのクリアテキスト通信は、データの漏洩やプライバシーの侵害を引き起こす可能性があります（[RFC4279]のセクション7.3）。
In this mode, the device has an asymmetric key pair but without an X.509 certificate (called a raw public key); for example, the asymmetric key pair is generated by the manufacturer and installed on the device (see also Section 11.6). A device MAY be configured with multiple raw public keys. The type and length of the raw public key depends on the cipher suite used. Implementations in RawPublicKey mode MUST support the mandatory-to-implement cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 as specified in [RFC7251], [RFC5246], and [RFC4492]. The key used MUST be ECDSA capable. The curve secp256r1 MUST be supported [RFC4492]; this curve is equivalent to the NIST P-256 curve. The hash algorithm is SHA-256. Implementations MUST use the Supported Elliptic Curves and Supported Point Formats Extensions [RFC4492]; the uncompressed point format MUST be supported; [RFC6090] can be used as an implementation method. Some guidance relevant to the implementation of this cipher suite can be found in [W3CXMLSEC]. The mechanism for using raw public keys with TLS is specified in [RFC7250].
このモードでは、デバイスには非対称キーペアがありますが、X.509証明書（生の公開キーと呼ばれます）はありません。たとえば、非対称キーペアは製造元によって生成され、デバイスにインストールされます（セクション11.6も参照）。デバイスは、複数の未加工の公開鍵で構成できます。生の公開鍵のタイプと長さは、使用する暗号スイートによって異なります。 RawPublicKeyモードでの実装は、[RFC7251]、[RFC5246]、および[RFC4492]で指定されているように、必須から実装までの暗号スイートTLS_ECDHE_ECDSA_WITH_AES_128_CCM_8をサポートする必要があります。使用される鍵はECDSA対応でなければなりません。曲線secp256r1はサポートされなければなりません[RFC4492]。この曲線は、NIST P-256曲線と同等です。ハッシュアルゴリズムはSHA-256です。実装では、サポートされる楕円曲線とサポートされるポイント形式の拡張[RFC4492]を使用する必要があります。非圧縮ポイント形式をサポートする必要があります。 [RFC6090]は実装方法として使用できます。この暗号スイートの実装に関するいくつかのガイダンスは、[W3CXMLSEC]にあります。 TLSで生の公開鍵を使用するメカニズムは、[RFC7250]で指定されています。
Implementation Note: Specifically, this means the extensions listed in Figure 14 with at least the values listed will be present in the DTLS handshake.
実装メモ：具体的には、これは、図14にリストされている拡張と、少なくともリストされている値がDTLSハンドシェイクに存在することを意味します。
Extension: elliptic_curves Type: elliptic_curves (0x000a) Length: 4 Elliptic Curves Length: 2 Elliptic curves (1 curve) Elliptic curve: secp256r1 (0x0017)
拡張子：elliptic_curvesタイプ：elliptic_curves（0x000a）長さ：4楕円曲線長さ：2楕円曲線（1曲線）楕円曲線：secp256r1（0x0017）
Extension: ec_point_formats Type: ec_point_formats (0x000b) Length: 2 EC point formats Length: 1 Elliptic curves point formats (1) EC point format: uncompressed (0)
拡張子：ec_point_formatsタイプ：ec_point_formats（0x000b）長さ：2 ECポイント形式長さ：1楕円曲線ポイント形式（1）ECポイント形式：非圧縮（0）
Extension: signature_algorithms Type: signature_algorithms (0x000d) Length: 4 Data (4 bytes): 00 02 04 03 HashAlgorithm: sha256 (4) SignatureAlgorithm: ecdsa (3)
拡張子：signature_algorithmsタイプ：signature_algorithms（0x000d）長さ：4データ（4バイト）：00 02 04 03 HashAlgorithm：sha256（4）SignatureAlgorithm：ecdsa（3）
Figure 14: DTLS Extensions Present for TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8
図14：TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8に存在するDTLS拡張
The RawPublicKey mode was designed to be easily provisioned in M2M deployments. It is assumed that each device has an appropriate asymmetric public key pair installed. An identifier is calculated by the endpoint from the public key as described in Section 2 of [RFC6920]. All implementations that support checking RawPublicKey identities MUST support at least the sha-256-120 mode (SHA-256 truncated to 120 bits). Implementations SHOULD also support longer length identifiers and MAY support shorter lengths. Note that the shorter lengths provide less security against attacks, and their use is NOT RECOMMENDED.
RawPublicKeyモードは、M2Mデプロイメントで簡単にプロビジョニングできるように設計されています。各デバイスには適切な非対称公開鍵ペアがインストールされていると想定されています。 [RFC6920]のセクション2で説明されているように、識別子は公開鍵からエンドポイントによって計算されます。 RawPublicKeyアイデンティティのチェックをサポートするすべての実装は、少なくともsha-256-120モード（120ビットに切り捨てられたSHA-256）をサポートする必要があります。実装はまた、より長い識別子をサポートするべきであり（SHOULD）、より短い長さをサポートしてもよい（MAY）。長さが短いと、攻撃に対するセキュリティが低下するため、その使用はお勧めしません。
Depending on how identifiers are given to the system that verifies them, support for URI, binary, and/or human-speakable format [RFC6920] needs to be implemented. All implementations SHOULD support the binary mode, and implementations that have a user interface SHOULD also support the human-speakable format.
識別子を検証するシステムに識別子を与える方法に応じて、URI、バイナリ、および/または人間が話すことができる形式[RFC6920]のサポートを実装する必要があります。すべての実装はバイナリモードをサポートする必要があり（SHOULD）、ユーザーインターフェイスを持つ実装は人間が話すことができる形式もサポートする必要があります（SHOULD）。
During provisioning, the identifier of each node is collected, for example, by reading a barcode on the outside of the device or by obtaining a pre-compiled list of the identifiers. These identifiers are then installed in the corresponding endpoint, for example, an M2M data collection server. The identifier is used for two purposes, to associate the endpoint with further device information and to perform access control. During (initial and ongoing) provisioning, an access control list of identifiers with which the device may start DTLS sessions SHOULD also be installed and maintained.
プロビジョニング中、各ノードの識別子は、たとえば、デバイスの外側にあるバーコードを読み取ることによって、または識別子の事前にコンパイルされたリストを取得することによって収集されます。これらの識別子は、対応するエンドポイント（M2Mデータ収集サーバーなど）にインストールされます。識別子は、エンドポイントを追加のデバイス情報に関連付け、アクセス制御を実行するという2つの目的で使用されます。 （初期および進行中の）プロビジョニング中に、デバイスがDTLSセッションを開始できる識別子のアクセス制御リストもインストールして維持する必要があります（SHOULD）。
Implementations in Certificate Mode MUST support the mandatory-to-implement cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 as specified in [RFC7251], [RFC5246], and [RFC4492]. Namely, the certificate includes a SubjectPublicKeyInfo that indicates an algorithm of id-ecPublicKey with namedCurves secp256r1 [RFC5480]; the public key format is uncompressed [RFC5480]; the hash algorithm is SHA-256; if included, the key usage extension indicates digitalSignature. Certificates MUST be signed with ECDSA using secp256r1, and the signature MUST use SHA-256. The key used MUST be ECDSA capable. The curve secp256r1 MUST be supported [RFC4492]; this curve is equivalent to the NIST P-256 curve. The hash algorithm is SHA-256. Implementations MUST use the Supported Elliptic Curves and Supported Point Formats Extensions [RFC4492]; the uncompressed point format MUST be supported; [RFC6090] can be used as an implementation method.
証明書モードでの実装は、[RFC7251]、[RFC5246]、および[RFC4492]で指定されているように、必須から実装までの暗号スイートTLS_ECDHE_ECDSA_WITH_AES_128_CCM_8をサポートする必要があります。つまり、証明書には、namedCurves secp256r1 [RFC5480]を使用したid-ecPublicKeyのアルゴリズムを示すSubjectPublicKeyInfoが含まれています。公開鍵の形式は圧縮されていません[RFC5480]。ハッシュアルゴリズムはSHA-256です。含まれている場合、キー使用法拡張はdigitalSignatureを示します。証明書は、secp256r1を使用してECDSAで署名する必要があり、署名はSHA-256を使用する必要があります。使用される鍵はECDSA対応でなければなりません。曲線secp256r1はサポートされなければなりません[RFC4492]。この曲線は、NIST P-256曲線と同等です。ハッシュアルゴリズムはSHA-256です。実装では、サポートされる楕円曲線とサポートされるポイント形式の拡張[RFC4492]を使用する必要があります。非圧縮ポイント形式をサポートする必要があります。 [RFC6090]は実装方法として使用できます。
The subject in the certificate would be built out of a long-term unique identifier for the device such as the EUI-64 [EUI64]. The subject could also be based on the Fully Qualified Domain Name (FQDN) that was used as the Host part of the CoAP URI. However, the device's IP address should not typically be used as the subject, as it would change over time. The discovery process used in the system would build up the mapping between IP addresses of the given devices and the subject for each device. Some devices could have more than one subject and would need more than a single certificate.
証明書のサブジェクトは、EUI-64 [EUI64]などのデバイスの長期の一意の識別子から構築されます。サブジェクトは、CoAP URIのホスト部分として使用された完全修飾ドメイン名（FQDN）に基づくこともできます。ただし、デバイスのIPアドレスは時間の経過とともに変化するため、通常はサブジェクトとして使用しないでください。システムで使用される検出プロセスは、特定のデバイスのIPアドレスと各デバイスのサブジェクト間のマッピングを構築します。一部のデバイスには複数のサブジェクトがあり、複数の証明書が必要になる場合があります。
When a new connection is formed, the certificate from the remote device needs to be verified. If the CoAP node has a source of absolute time, then the node SHOULD check that the validity dates of the certificate are within range. The certificate MUST be validated as appropriate for the security requirements, using functionality equivalent to the algorithm specified in Section 6 of [RFC5280]. If the certificate contains a SubjectAltName, then the authority of the request URI MUST match at least one of the authorities of any CoAP URI found in a field of URI type in the SubjectAltName set. If there is no SubjectAltName in the certificate, then the authority of the request URI MUST match the Common Name (CN) found in the certificate using the matching rules defined in [RFC3280] with the exception that certificates with wildcards are not allowed.
新しい接続が形成されたら、リモートデバイスからの証明書を確認する必要があります。 CoAPノードに絶対時刻のソースがある場合、ノードは証明書の有効期限が範囲内であることを確認する必要があります（SHOULD）。 [RFC5280]のセクション6で指定されたアルゴリズムと同等の機能を使用して、セキュリティ要件に応じて証明書を検証する必要があります。証明書にSubjectAltNameが含まれている場合、要求URIの機関は、SubjectAltNameセットのURIタイプのフィールドにある任意のCoAP URIの機関の少なくとも1つと一致する必要があります。証明書にSubjectAltNameがない場合、リクエストURIの機関は、[RFC3280]で定義されている一致ルールを使用して、証明書にある共通名（CN）と一致する必要があります。ただし、ワイルドカードを含む証明書は許可されません。
CoRE support for certificate status checking requires further study. As a mapping of the Online Certificate Status Protocol (OCSP) [RFC6960] onto CoAP is not currently defined and OCSP may also not be easily applicable in all environments, an alternative approach may be using the TLS Certificate Status Request extension (Section 8 of [RFC6066]; also known as "OCSP stapling") or preferably the Multiple Certificate Status Extension ([RFC6961]), if available.
証明書ステータスチェックのCoREサポートには、さらに調査が必要です。オンライン証明書ステータスプロトコル（OCSP）[RFC6960]のCoAPへのマッピングは現在定義されておらず、OCSPもすべての環境で簡単に適用できない可能性があるため、TLS証明書ステータスリクエスト拡張を使用する別のアプローチがあります（[ RFC6066]; "OCSP stapling"としても知られています）または、可能であれば、複数証明書ステータス拡張（[RFC6961]）。
If the system has a shared key in addition to the certificate, then a cipher suite that includes the shared key such as TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA [RFC5489] SHOULD be used.
システムに証明書に加えて共有鍵がある場合、TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA [RFC5489]などの共有鍵を含む暗号スイートを使用する必要があります（SHOULD）。
CoAP supports a limited subset of HTTP functionality, and thus cross-protocol proxying to HTTP is straightforward. There might be several reasons for proxying between CoAP and HTTP, for example, when designing a web interface for use over either protocol or when realizing a CoAP-HTTP proxy. Likewise, CoAP could equally be proxied to other protocols such as XMPP [RFC6120] or SIP [RFC3264]; the definition of these mechanisms is out of scope for this specification.
CoAPはHTTP機能の限定されたサブセットをサポートしているため、HTTPへのクロスプロトコルプロキシは簡単です。 CoAPとHTTPの間のプロキシには、たとえば、プロトコルを介して使用するWebインターフェイスを設計するときや、CoAP-HTTPプロキシを実現するときなど、いくつかの理由が考えられます。同様に、CoAPはXMPP [RFC6120]やSIP [RFC3264]などの他のプロトコルに同様にプロキシできます。これらのメカニズムの定義は、この仕様の範囲外です。
There are two possible directions to access a resource via a forward-proxy:
フォワードプロキシを介してリソースにアクセスするには、次の2つの方法があります。
CoAP-HTTP Proxying: Enables CoAP clients to access resources on HTTP servers through an intermediary. This is initiated by including the Proxy-Uri or Proxy-Scheme Option with an "http" or "https" URI in a CoAP request to a CoAP-HTTP proxy.
CoAP-HTTPプロキシ：CoAPクライアントが仲介経由でHTTPサーバー上のリソースにアクセスできるようにします。これは、CoAP-HTTPプロキシへのCoAPリクエストに「http」または「https」URIのProxy-UriまたはProxy-Schemeオプションを含めることで開始されます。
HTTP-CoAP Proxying: Enables HTTP clients to access resources on CoAP servers through an intermediary. This is initiated by specifying a "coap" or "coaps" URI in the Request-Line of an HTTP request to an HTTP-CoAP proxy.
HTTP-CoAPプロキシ：HTTPクライアントが中間経由でCoAPサーバー上のリソースにアクセスできるようにします。これは、HTTP-CoAPプロキシへのHTTPリクエストのRequest-Lineに「coap」または「coaps」URIを指定することで開始されます。
Either way, only the request/response model of CoAP is mapped to HTTP. The underlying model of Confirmable or Non-confirmable messages, etc., is invisible and MUST have no effect on a proxy function. The following sections describe the handling of requests to a forward-proxy. Reverse-proxies are not specified, as the proxy function is transparent to the client with the proxy acting as if it were the origin server. However, similar considerations apply to reverse-proxies as to forward-proxies, and there generally will be an expectation that reverse-proxies operate in a similar way forward-proxies would. As an implementation note, HTTP client libraries may make it hard to operate an HTTP-CoAP forward-proxy by not providing a way to put a CoAP URI on the HTTP Request-Line; reverse-proxying may therefore lead to wider applicability of a proxy. A separate specification may define a convention for URIs operating such an HTTP-CoAP reverse-proxy [MAPPING].
どちらの方法でも、CoAPの要求/応答モデルのみがHTTPにマップされます。確認可能または確認不可能なメッセージなどの基礎となるモデルは非表示であり、プロキシ機能に影響を与えてはなりません（MUST）。次のセクションでは、フォワードプロキシへのリクエストの処理について説明します。プロキシ機能はクライアントに対して透過的であり、プロキシがオリジンサーバーであるかのように動作するため、リバースプロキシは指定されていません。ただし、フォワードプロキシと同様にリバースプロキシにも同様の考慮事項が適用され、リバースプロキシはフォワードプロキシと同じように動作することが一般的に予想されます。実装ノートとして、HTTPクライアントライブラリは、CoAP URIをHTTPリクエストラインに配置する方法を提供しないことにより、HTTP-CoAPフォワードプロキシの操作を困難にする場合があります。したがって、リバースプロキシは、プロキシのより広い適用範囲につながる可能性があります。別の仕様では、このようなHTTP-CoAPリバースプロキシ[MAPPING]を操作するURIの規則を定義できます。
If a request contains a Proxy-Uri or Proxy-Scheme Option with an 'http' or 'https' URI [RFC2616], then the receiving CoAP endpoint (called "the proxy" henceforth) is requested to perform the operation specified by the request method on the indicated HTTP resource and return the result to the client. (See also Section 5.7 for how the request to the proxy is formulated, including security requirements.)
リクエストに 'http'または 'https' URIのProxy-UriまたはProxy-Schemeオプションが含まれている場合[RFC2616]、リクエストで指定された操作を実行するために受信CoAPエンドポイント（以降「プロキシ」と呼ばれます）がリクエストされます示されたHTTPリソースのメソッドを呼び出し、結果をクライアントに返します。 （セキュリティ要件を含め、プロキシへのリクエストがどのように作成されるかについては、セクション5.7も参照してください。）
This section specifies for any CoAP request the CoAP response that the proxy should return to the client. How the proxy actually satisfies the request is an implementation detail, although the typical case is expected to be that the proxy translates and forwards the request to an HTTP origin server.
このセクションでは、CoAP要求に対して、プロキシがクライアントに返す必要があるCoAP応答を指定します。プロキシが実際に要求を満たす方法は実装の詳細ですが、典型的なケースは、プロキシが要求を変換してHTTPオリジンサーバーに転送することです。
Since HTTP and CoAP share the basic set of request methods, performing a CoAP request on an HTTP resource is not so different from performing it on a CoAP resource. The meanings of the individual CoAP methods when performed on HTTP resources are explained in the subsections of this section.
HTTPとCoAPは要求メソッドの基本セットを共有しているため、HTTPリソースでのCoAP要求の実行は、CoAPリソースでの実行とそれほど変わりません。 HTTPリソースで実行されるときの個々のCoAPメソッドの意味は、このセクションのサブセクションで説明されています。
If the proxy is unable or unwilling to service a request with an HTTP URI, a 5.05 (Proxying Not Supported) response is returned to the client. If the proxy services the request by interacting with a third party (such as the HTTP origin server) and is unable to obtain a result within a reasonable time frame, a 5.04 (Gateway Timeout) response is returned; if a result can be obtained but is not understood, a 5.02 (Bad Gateway) response is returned.
プロキシがHTTP URIを使用して要求を処理できない、または処理を望まない場合、5.05（プロキシはサポートされていません）応答がクライアントに返されます。プロキシーがサード・パーティー（HTTPオリジン・サーバーなど）と対話することによって要求を処理し、妥当な時間内に結果を取得できない場合、5.04（ゲートウェイ・タイムアウト）応答が返されます。結果を取得できても理解できない場合は、5.02（Bad Gateway）応答が返されます。
The GET method requests the proxy to return a representation of the HTTP resource identified by the request URI.
GETメソッドは、リクエストURIで識別されるHTTPリソースの表現を返すようにプロキシに要求します。
Upon success, a 2.05 (Content) Response Code SHOULD be returned. The payload of the response MUST be a representation of the target HTTP resource, and the Content-Format Option MUST be set accordingly. The response MUST indicate a Max-Age value that is no greater than the remaining time the representation can be considered fresh. If the HTTP entity has an entity-tag, the proxy SHOULD include an ETag Option in the response and process ETag Options in requests as described below.
成功すると、2.05（コンテンツ）応答コードが返されるべきです（SHOULD）。応答のペイロードはターゲットHTTPリソースの表現でなければならず、それに応じてContent-Formatオプションを設定する必要があります。応答は、表現が新鮮であると考えることができる残りの時間より大きくない最大年齢値を示さなければなりません。 HTTPエンティティにエンティティタグがある場合、プロキシは、応答にETagオプションを含め、以下で説明するようにリクエストのETagオプションを処理する必要があります（SHOULD）。
A client can influence the processing of a GET request by including the following option:
クライアントは、次のオプションを含めることにより、GETリクエストの処理に影響を与えることができます。
Accept: The request MAY include an Accept Option, identifying the preferred response content-format.
Accept：リクエストにはAccept Optionを含めることができ、優先する応答コンテンツ形式を識別できます。
ETag: The request MAY include one or more ETag Options, identifying responses that the client has stored. This requests the proxy to send a 2.03 (Valid) response whenever it would send a 2.05 (Content) response with an entity-tag in the requested set otherwise. Note that CoAP ETags are always strong ETags in the HTTP sense; CoAP does not have the equivalent of HTTP weak ETags, and there is no good way to make use of these in a cross-proxy.
ETag：リクエストには、クライアントが保存した応答を識別する1つ以上のETagオプションが含まれる場合があります。これは、要求されたセットにエンティティタグを含む2.05（コンテンツ）応答を送信する場合は常に、プロキシに2.03（有効）応答を送信するように要求します。 CoAP ETagは常にHTTPの意味で強力なETagであることに注意してください。 CoAPには、HTTPウィークETagに相当するものがなく、クロスプロキシでこれらを使用する良い方法はありません。
The PUT method requests the proxy to update or create the HTTP resource identified by the request URI with the enclosed representation.
PUTメソッドは、囲まれた表現で要求URIによって識別されるHTTPリソースを更新または作成するようにプロキシに要求します。
If a new resource is created at the request URI, a 2.01 (Created) response MUST be returned to the client. If an existing resource is modified, a 2.04 (Changed) response MUST be returned to indicate successful completion of the request.
リクエストURIで新しいリソースが作成される場合、2.01（Created）応答がクライアントに返されなければなりません（MUST）。既存のリソースが変更された場合、リクエストが正常に完了したことを示すために、2.04（変更）応答を返さなければなりません（MUST）。
The DELETE method requests the proxy to delete the HTTP resource identified by the request URI at the HTTP origin server.
DELETEメソッドは、HTTPオリジンサーバーのリクエストURIで識別されるHTTPリソースを削除するようにプロキシにリクエストします。
A 2.02 (Deleted) response MUST be returned to the client upon success or if the resource does not exist at the time of the request.
成功時、またはリクエスト時にリソースが存在しない場合は、2.02（削除済み）応答をクライアントに返す必要があります。
The POST method requests the proxy to have the representation enclosed in the request be processed by the HTTP origin server. The actual function performed by the POST method is determined by the origin server and dependent on the resource identified by the request URI.
POSTメソッドは、要求に含まれる表現がHTTPオリジンサーバーによって処理されるようにプロキシに要求します。 POSTメソッドによって実行される実際の機能は、オリジンサーバーによって決定され、リクエストURIによって識別されるリソースに依存します。
If the action performed by the POST method does not result in a resource that can be identified by a URI, a 2.04 (Changed) response MUST be returned to the client. If a resource has been created on the origin server, a 2.01 (Created) response MUST be returned.
POSTメソッドによって実行されるアクションの結果、URIで識別できるリソースにならない場合は、2.04（変更済み）応答をクライアントに返す必要があります。オリジンサーバーでリソースが作成されている場合、2.01（Created）応答が返されなければなりません（MUST）。
If an HTTP request contains a Request-URI with a "coap" or "coaps" URI, then the receiving HTTP endpoint (called "the proxy" henceforth) is requested to perform the operation specified by the request method on the indicated CoAP resource and return the result to the client.
HTTPリクエストに「coap」または「coaps」URIを持つRequest-URIが含まれている場合、受信HTTPエンドポイント（以降「プロキシ」と呼ばれる）は、指定されたCoAPリソースでリクエストメソッドによって指定された操作を実行するように要求されます。結果をクライアントに返します。
This section specifies for any HTTP request the HTTP response that the proxy should return to the client. Unless otherwise specified, all the statements made are RECOMMENDED behavior; some highly constrained implementations may need to resort to shortcuts. How the proxy actually satisfies the request is an implementation detail, although the typical case is expected to be that the proxy translates and forwards the request to a CoAP origin server. The meanings of the individual HTTP methods when performed on CoAP resources are explained in the subsections of this section.
このセクションでは、すべてのHTTPリクエストに対して、プロキシがクライアントに返す必要があるHTTP応答を指定します。特に指定のない限り、行われたすべてのステートメントは推奨される動作です。一部の非常に制約のある実装では、ショートカットを使用する必要がある場合があります。プロキシが実際に要求を満たす方法は実装の詳細ですが、典型的なケースは、プロキシが要求を変換してCoAPオリジンサーバーに転送する場合です。 CoAPリソースで実行されるときの個々のHTTPメソッドの意味は、このセクションのサブセクションで説明されています。
If the proxy is unable or unwilling to service a request with a CoAP URI, a 501 (Not Implemented) response is returned to the client. If the proxy services the request by interacting with a third party (such as the CoAP origin server) and is unable to obtain a result within a reasonable time frame, a 504 (Gateway Timeout) response is returned; if a result can be obtained but is not understood, a 502 (Bad Gateway) response is returned.
プロキシがCoAP URIを使用して要求を処理できない、または処理を望まない場合、501（実装されていません）応答がクライアントに返されます。プロキシがサードパーティ（CoAPオリジンサーバーなど）とやり取りして要求を処理し、妥当な時間内に結果を取得できない場合は、504（ゲートウェイタイムアウト）応答が返されます。結果は取得できても理解できない場合は、502（不正なゲートウェイ）応答が返されます。
As the OPTIONS and TRACE methods are not supported in CoAP, a 501 (Not Implemented) error MUST be returned to the client.
OPTIONSおよびTRACEメソッドはCoAPでサポートされていないため、501（実装されていません）エラーをクライアントに返す必要があります。
The GET method requests the proxy to return a representation of the CoAP resource identified by the Request-URI.
GETメソッドは、Request-URIで識別されたCoAPリソースの表現を返すようにプロキシに要求します。
Upon success, a 200 (OK) response is returned. The payload of the response MUST be a representation of the target CoAP resource, and the Content-Type and Content-Encoding header fields MUST be set accordingly. The response MUST indicate a max-age directive that indicates a value no greater than the remaining time the representation can be considered fresh. If the CoAP response has an ETag option, the proxy should include an ETag header field in the response.
成功すると、200（OK）応答が返されます。応答のペイロードはターゲットCoAPリソースの表現でなければならず、それに応じてContent-TypeおよびContent-Encodingヘッダーフィールドを設定する必要があります。応答は、表現が新鮮であると見なすことができる残り時間以下の値を示すmax-ageディレクティブを示さなければなりません（MUST）。 CoAP応答にETagオプションがある場合、プロキシは応答にETagヘッダーフィールドを含める必要があります。
A client can influence the processing of a GET request by including the following options:
クライアントは、次のオプションを含めることにより、GETリクエストの処理に影響を与えることができます。
Accept: The most-preferred media type of the HTTP Accept header field in a request is mapped to a CoAP Accept option. HTTP Accept media-type ranges, parameters, and extensions are not supported by the CoAP Accept option. If the proxy cannot send a response that is acceptable according to the combined Accept field value, then the proxy sends a 406 (Not Acceptable) response. The proxy MAY then retry the request with further media types from the HTTP Accept header field.
Accept：リクエスト内の最も好ましいHTTP Acceptヘッダーフィールドのメディアタイプは、CoAP Acceptオプションにマッピングされます。 HTTP Acceptメディアタイプの範囲、パラメータ、および拡張機能は、CoAP Acceptオプションではサポートされていません。プロキシが結合されたAcceptフィールドの値に従って許容可能な応答を送信できない場合、プロキシは406（Not Acceptable）応答を送信します。次にプロキシは、HTTP Acceptヘッダーフィールドからの追加のメディアタイプを使用してリクエストを再試行してもよい（MAY）。
Conditional GETs: Conditional HTTP GET requests that include an "If-Match" or "If-None-Match" request-header field can be mapped to a corresponding CoAP request. The "If-Modified-Since" and "If-Unmodified-Since" request-header fields are not directly supported by CoAP but are implemented locally by a caching proxy.
条件付きGET：「If-Match」または「If-None-Match」リクエストヘッダーフィールドを含む条件付きHTTP GETリクエストは、対応するCoAPリクエストにマッピングできます。 「If-Modified-Since」および「If-Unmodified-Since」リクエストヘッダーフィールドは、CoAPでは直接サポートされていませんが、キャッシュプロキシによってローカルに実装されています。
The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response.
HEADメソッドは、サーバーが応答でメッセージ本文を返してはならないことを除いて、GETと同じです。
Although there is no direct equivalent of HTTP's HEAD method in CoAP, an HTTP-CoAP proxy responds to HEAD requests for CoAP resources, and the HTTP headers are returned without a message-body.
CoAPにはHTTPのHEADメソッドに直接相当するものはありませんが、HTTP-CoAPプロキシはCoAPリソースのHEADリクエストに応答し、HTTPヘッダーはメッセージ本文なしで返されます。
Implementation Note: An HTTP-CoAP proxy may want to try using a block-wise transfer option [BLOCK] to minimize the amount of data actually transferred, but it needs to be prepared for the case that the origin server does not support block-wise transfers.
実装上の注意：HTTP-CoAPプロキシは、ブロック単位の転送オプション[BLOCK]を使用して実際に転送されるデータの量を最小限に抑えようとする場合がありますが、オリジンサーバーがブロック単位でサポートしていない場合に備えて準備する必要があります。転送。
The POST method requests the proxy to have the representation enclosed in the request be processed by the CoAP origin server. The actual function performed by the POST method is determined by the origin server and dependent on the resource identified by the request URI.
POSTメソッドは、要求に含まれる表現がCoAPオリジンサーバーによって処理されるようにプロキシに要求します。 POSTメソッドによって実行される実際の機能は、オリジンサーバーによって決定され、リクエストURIによって識別されるリソースに依存します。
If the action performed by the POST method does not result in a resource that can be identified by a URI, a 200 (OK) or 204 (No Content) response MUST be returned to the client. If a resource has been created on the origin server, a 201 (Created) response MUST be returned.
POSTメソッドによって実行されるアクションの結果、URIで識別できるリソースが得られない場合は、200（OK）または204（No Content）応答をクライアントに返す必要があります。オリジンサーバーでリソースが作成されている場合、201（Created）応答が返される必要があります。
If any of the Location-* Options are present in the CoAP response, a Location header field constructed from the values of these options is returned.
CoAP応答にLocation- *オプションのいずれかが存在する場合、これらのオプションの値から構築されたLocationヘッダーフィールドが返されます。
The PUT method requests the proxy to update or create the CoAP resource identified by the Request-URI with the enclosed representation.
PUTメソッドは、囲まれた表現でRequest-URIによって識別されるCoAPリソースを更新または作成するようにプロキシに要求します。
If a new resource is created at the Request-URI, a 201 (Created) response is returned to the client. If an existing resource is modified, either the 200 (OK) or 204 (No Content) Response Codes is sent to indicate successful completion of the request.
Request-URIで新しいリソースが作成されると、201（Created）応答がクライアントに返されます。既存のリソースが変更された場合、要求が正常に完了したことを示すために、200（OK）または204（コンテンツなし）応答コードが送信されます。
The DELETE method requests the proxy to delete the CoAP resource identified by the Request-URI at the CoAP origin server.
DELETEメソッドは、CoAPオリジンサーバーのRequest-URIで識別されるCoAPリソースを削除するようにプロキシに要求します。
A successful response is 200 (OK) if the response includes an entity describing the status or 204 (No Content) if the action has been enacted but the response does not include an entity.
成功した応答は、ステータスを説明するエンティティが応答に含まれている場合は200（OK）です。アクションが実行されたが応答にエンティティが含まれていない場合は、204（コンテンツなし）です。
This method cannot currently be satisfied by an HTTP-CoAP proxy function, as TLS to DTLS tunneling has not yet been specified. For now, a 501 (Not Implemented) error is returned to the client.
TLSからDTLSへのトンネリングがまだ指定されていないため、現在、このメソッドはHTTP-CoAPプロキシー機能では満たすことができません。現時点では、501（未実装）エラーがクライアントに返されます。
This section analyzes the possible threats to the protocol. It is meant to inform protocol and application developers about the security limitations of CoAP as described in this document. As CoAP realizes a subset of the features in HTTP/1.1, the security considerations in Section 15 of [RFC2616] are also pertinent to CoAP. This section concentrates on describing limitations specific to CoAP.
このセクションでは、プロトコルに対する潜在的な脅威を分析します。このドキュメントで説明されているように、CoAPのセキュリティ制限についてプロトコルおよびアプリケーション開発者に通知することを目的としています。 CoAPはHTTP / 1.1の機能のサブセットを実現するため、[RFC2616]のセクション15のセキュリティに関する考慮事項もCoAPに関連しています。このセクションでは、CoAPに固有の制限について説明します。
A network-facing application can exhibit vulnerabilities in its processing logic for incoming packets. Complex parsers are well-known as a likely source of such vulnerabilities, such as the ability to remotely crash a node, or even remotely execute arbitrary code on it. CoAP attempts to narrow the opportunities for introducing such vulnerabilities by reducing parser complexity, by giving the entire range of encodable values a meaning where possible, and by aggressively reducing complexity that is often caused by unnecessary choice between multiple representations that mean the same thing. Much of the URI processing has been moved to the clients, further reducing the opportunities for introducing vulnerabilities into the servers. Even so, the URI processing code in CoAP implementations is likely to be a large source of remaining vulnerabilities and should be implemented with special care. CoAP access control implementations need to ensure they don't introduce vulnerabilities through discrepancies between the code deriving access control decisions from a URI and the code finally serving up the resource addressed by the URI. The most complex parser remaining could be the one for the CoRE Link Format, although this also has been designed with a goal of reduced implementation complexity [RFC6690]. (See also Section 15.2 of [RFC2616].)
ネットワークに面したアプリケーションは、着信パケットの処理ロジックに脆弱性を示す可能性があります。複雑なパーサーは、ノードをリモートでクラッシュさせたり、ノード上で任意のコードをリモートで実行したりするなど、このような脆弱性の発生源としてよく知られています。 CoAPは、パーサーの複雑さを減らし、エンコード可能な値の範囲全体に可能な限り意味を与えることにより、そして同じことを意味する複数の表現間の不必要な選択によってしばしば引き起こされる複雑さを積極的に減らすことにより、そのような脆弱性を導入する機会を狭めようとします。 URI処理の多くはクライアントに移されており、サーバーに脆弱性を導入する機会をさらに減らしています。それでも、CoAP実装のURI処理コードは、残りの脆弱性の大きな原因となる可能性が高く、特に注意して実装する必要があります。 CoAPアクセスコントロールの実装では、URIからアクセスコントロールの決定を導き出すコードと、URIによってアドレス指定されたリソースを最終的に処理するコードとの不一致により、脆弱性が導入されないようにする必要があります。残りの最も複雑なパーサーは、CoREリンクフォーマットのパーサーである可能性がありますが、これも実装の複雑さを軽減することを目的として設計されています[RFC6690]。 （[RFC2616]のセクション15.2も参照してください）。
As mentioned in Section 15.7 of [RFC2616], proxies are by their very nature men-in-the-middle, breaking any IPsec or DTLS protection that a direct CoAP message exchange might have. They are therefore interesting targets for breaking confidentiality or integrity of CoAP message exchanges. As noted in [RFC2616], they are also interesting targets for breaking availability.
[RFC2616]のセクション15.7で述べたように、プロキシは本質的に中間者であり、直接CoAPメッセージ交換が持つ可能性のあるIPsecまたはDTLS保護を破っています。したがって、これらはCoAPメッセージ交換の機密性または整合性を壊すための興味深いターゲットです。 [RFC2616]で述べたように、これらは可用性を壊すための興味深いターゲットでもあります。
The threat to confidentiality and integrity of request/response data is amplified where proxies also cache. Note that CoAP does not define any of the cache-suppressing Cache-Control options that HTTP/1.1 provides to better protect sensitive data.
リクエスト/レスポンスデータの機密性と整合性に対する脅威は、プロキシもキャッシュする場所で増幅されます。 CoAPは、HTTP / 1.1が機密データをよりよく保護するために提供するキャッシュ抑制Cache-Controlオプションを定義しないことに注意してください。
For a caching implementation, any access control considerations that would apply to making the request that generated the cache entry also need to be applied to the value in the cache. This is relevant for clients that implement multiple security domains, as well as for proxies that may serve multiple clients. Also, a caching proxy MUST NOT make cached values available to requests that have lesser transport-security properties than those the proxy would require to perform request forwarding in the first place.
キャッシング実装の場合、キャッシュエントリを生成したリクエストの作成に適用されるアクセス制御の考慮事項も、キャッシュ内の値に適用する必要があります。これは、複数のセキュリティドメインを実装するクライアントと、複数のクライアントにサービスを提供するプロキシに関連します。また、キャッシングプロキシは、最初にリクエスト転送を実行するためにプロキシが必要とするよりもトランスポートセキュリティプロパティが少ないリクエストに対して、キャッシュされた値を利用可能にしてはなりません（MUST NOT）。
Unlike the "coap" scheme, responses to "coaps" identified requests are never "public" and thus MUST NOT be reused for shared caching, unless the cache is able to make equivalent access control decisions to the ones that led to the cached entry. They can, however, be reused in a private cache if the message is cacheable by default in CoAP.
「coap」スキームとは異なり、「coaps」で識別された要求への応答は「public」になることは決してないため、キャッシュが、キャッシュされたエントリにつながったものと同等のアクセス制御決定を行うことができない限り、共有キャッシングに再利用してはなりません。ただし、メッセージがデフォルトでCoAPにキャッシュ可能な場合は、プライベートキャッシュで再利用できます。
Finally, a proxy that fans out Separate Responses (as opposed to piggybacked Responses) to multiple original requesters may provide additional amplification (see Section 11.3).
最後に、複数の元のリクエスタに個別の応答（ピギーバックされた応答ではなく）をファンアウトするプロキシは、追加の増幅を提供する場合があります（セクション11.3を参照）。
CoAP servers generally reply to a request packet with a response packet. This response packet may be significantly larger than the request packet. An attacker might use CoAP nodes to turn a small attack packet into a larger attack packet, an approach known as amplification. There is therefore a danger that CoAP nodes could become implicated in denial-of-service (DoS) attacks by using the amplifying properties of the protocol: an attacker that is attempting to overload a victim but is limited in the amount of traffic it can generate can use amplification to generate a larger amount of traffic.
CoAPサーバーは通常、要求パケットに応答パケットで応答します。この応答パケットは、要求パケットより大幅に大きくなる可能性があります。攻撃者はCoAPノードを使用して、小さな攻撃パケットをより大きな攻撃パケットに変えることができます。これは、増幅と呼ばれるアプローチです。したがって、プロトコルの増幅プロパティを使用することにより、CoAPノードがサービス拒否（DoS）攻撃に関与する危険性があります。攻撃者は、被害者に過負荷をかけようとしているが、生成できるトラフィックの量が制限されています。増幅を使用して、より多くのトラフィックを生成できます。
This is particularly a problem in nodes that enable NoSec access, are accessible from an attacker, and can access potential victims (e.g., on the general Internet), as the UDP protocol provides no way to verify the source address given in the request packet. An attacker need only place the IP address of the victim in the source address of a suitable request packet to generate a larger packet directed at the victim.
これは、NoSecアクセスを有効にし、攻撃者からアクセス可能であり、潜在的な被害者（たとえば、一般的なインターネット上）にアクセスできるノードで特に問題になります。UDPプロトコルは、要求パケットで指定された送信元アドレスを確認する方法を提供しないためです。攻撃者は、被害者に向けられたより大きなパケットを生成するために、被害者のIPアドレスを適切な要求パケットの送信元アドレスに配置するだけで済みます。
As a mitigating factor, many constrained networks will only be able to generate a small amount of traffic, which may make CoAP nodes less attractive for this attack. However, the limited capacity of the constrained network makes the network itself a likely victim of an amplification attack.
緩和要因として、制限されたネットワークの多くは少量のトラフィックしか生成できないため、CoAPノードがこの攻撃に対して魅力的でなくなる可能性があります。ただし、制約されたネットワークの容量が限られているため、ネットワーク自体が増幅攻撃の犠牲になる可能性があります。
Therefore, large amplification factors SHOULD NOT be provided in the response if the request is not authenticated. A CoAP server can reduce the amount of amplification it provides to an attacker by using slicing/blocking modes of CoAP [BLOCK] and offering large resource representations only in relatively small slices. For example, for a 1000-byte resource, a 10-byte request might result in an 80-byte response (with a 64-byte block) instead of a 1016-byte response, considerably reducing the amplification provided.
したがって、リクエストが認証されていない場合は、レスポンスに大きな増幅係数を指定しないでください。 CoAPサーバーは、CoAP [BLOCK]のスライシング/ブロッキングモードを使用して、比較的小さなスライスでのみ大きなリソース表現を提供することにより、攻撃者に提供する増幅の量を減らすことができます。たとえば、1000バイトのリソースの場合、10バイトのリクエストでは、1016バイトのレスポンスではなく、80バイトのレスポンス（64バイトのブロック）が返され、提供される増幅が大幅に減少します。
CoAP also supports the use of multicast IP addresses in requests, an important requirement for M2M. Multicast CoAP requests may be the source of accidental or deliberate DoS attacks, especially over constrained networks. This specification attempts to reduce the amplification effects of multicast requests by limiting when a response is returned. To limit the possibility of malicious use, CoAP servers SHOULD NOT accept multicast requests that can not be authenticated in some way, cryptographically or by some multicast boundary limiting the potential sources. If possible, a CoAP server SHOULD limit the support for multicast requests to the specific resources where the feature is required.
CoAPは、M2Mの重要な要件であるリクエストでのマルチキャストIPアドレスの使用もサポートしています。マルチキャストCoAP要求は、特に制約のあるネットワーク上で、偶発的または故意のDoS攻撃の原因となる可能性があります。この仕様は、応答が返されるタイミングを制限することにより、マルチキャスト要求の増幅効果を低減しようとします。悪意のある使用の可能性を制限するために、CoAPサーバーは、何らかの方法で、暗号的に、または潜在的なソースを制限するいくつかのマルチキャスト境界によって認証できないマルチキャスト要求を受け入れないでください。可能であれば、CoAPサーバーは、マルチキャスト要求のサポートを、機能が必要な特定のリソースに制限する必要があります（SHOULD）。
On some general-purpose operating systems providing a POSIX-style API [IEEE1003.1], it is not straightforward to find out whether a packet received was addressed to a multicast address. While many implementations will know whether they have joined a multicast group, this creates a problem for packets addressed to multicast addresses of the form FF0x::1, which are received by every IPv6 node. Implementations SHOULD make use of modern APIs such as IPV6_RECVPKTINFO [RFC3542], if available, to make this determination.
POSIXスタイルのAPI [IEEE1003.1]を提供する一部の汎用オペレーティングシステムでは、受信したパケットがマルチキャストアドレス宛てかどうかを確認するのは簡単ではありません。多くの実装は、マルチキャストグループに参加したかどうかを認識しますが、これにより、すべてのIPv6ノードが受信するFF0x :: 1形式のマルチキャストアドレス宛のパケットに問題が発生します。実装は、可能であれば、IPV6_RECVPKTINFO [RFC3542]などの最新のAPIを使用してこの決定を行う必要があります。
Due to the lack of a handshake in UDP, a rogue endpoint that is free to read and write messages carried by the constrained network (i.e., NoSec or PreSharedKey deployments with a nodes/key ratio > 1:1), may easily attack a single endpoint, a group of endpoints, as well as the whole network, e.g., by:
UDPにはハンドシェイクがないため、制約されたネットワーク（ノード/キーの比率が1：1を超えるNoSecまたはPreSharedKeyデプロイメント）によって運ばれるメッセージを自由に読み書きできる不正なエンドポイントは、単一のノードを簡単に攻撃する可能性があります。エンドポイント、エンドポイントのグループ、およびネットワーク全体。例：
1. spoofing a Reset message in response to a Confirmable message or Non-confirmable message, thus making an endpoint "deaf"; or
1. ConfirmableメッセージまたはNon-confirmableメッセージに応答してリセットメッセージをスプーフィングし、エンドポイントを「聴覚障害者」にします。または
2. spoofing an ACK in response to a CON message, thus potentially preventing the sender of the CON message from retransmitting, and drowning out the actual response; or
2. CONメッセージへの応答としてACKをスプーフィングすることにより、CONメッセージの送信者が再送信されないようにし、実際の応答を溺死させる可能性があります。または
3. spoofing the entire response with forged payload/options (this has different levels of impact: from single-response disruption, to much bolder attacks on the supporting infrastructure, e.g., poisoning proxy caches, or tricking validation/lookup interfaces in resource directories and, more generally, any component that stores global network state and uses CoAP as the messaging facility to handle setting or updating state is a potential target.); or
3. 偽造されたペイロード/オプションで応答全体を偽装する（これにはさまざまなレベルの影響があります：単一応答の中断から、サポートインフラストラクチャへのはるかに大胆な攻撃（プロキシキャッシュの汚染、リソースディレクトリ内の検証/ルックアップインターフェイスのだましなど）など。一般に、グローバルネットワークの状態を保存し、状態の設定または更新を処理するメッセージング機能としてCoAPを使用するコンポーネントがターゲットになる可能性があります。）;または
4. spoofing a multicast request for a target node; this may result in network congestion/collapse, a DoS attack on the victim, or forced wake-up from sleeping; or
4. ターゲットノードへのマルチキャスト要求のスプーフィング。これにより、ネットワークの輻輳/崩壊、被害者へのDoS攻撃、またはスリープからの強制的なウェイクアップが発生する可能性があります。または
5. spoofing observe messages, etc.
5. 監視メッセージのなりすましなど
Response spoofing by off-path attackers can be detected and mitigated even without transport layer security by choosing a nontrivial, randomized token in the request (Section 5.3.1). [RFC4086] discusses randomness requirements for security.
リクエストで重要ではないランダム化されたトークンを選択することにより、トランスポート層のセキュリティがなくても、オフパス攻撃者による応答のなりすましを検出して軽減できます（セクション5.3.1）。 [RFC4086]は、セキュリティのランダム性要件について説明しています。
In principle, other kinds of spoofing can be detected by CoAP only in case Confirmable message semantics is used, because of unexpected Acknowledgement or Reset messages coming from the deceived endpoint. But this imposes keeping track of the used Message IDs, which is not always possible, and moreover detection becomes available usually after the damage is already done. This kind of attack can be prevented using security modes other than NoSec.
原則として、他の種類のスプーフィングは、確認可能なメッセージセマンティクスが使用されている場合にのみCoAPで検出できます。これは、不正なエンドポイントからの予期しない確認またはリセットメッセージが原因です。しかし、これは常に使用できるとは限らない、使用されたメッセージIDの追跡を課します。さらに、通常は損傷が既に行われた後に検出が利用可能になります。この種の攻撃は、NoSec以外のセキュリティモードを使用して防止できます。
With or without source address spoofing, a client can attempt to overload a server by sending requests, preferably complex ones, to a server; address spoofing makes tracing back, and blocking, this attack harder. Given that the cost of a CON request is small, this attack can easily be executed. Under this attack, a constrained node with limited total energy available may exhaust that energy much more quickly than planned (battery depletion attack). Also, if the client uses a Confirmable message and the server responds with a Confirmable separate response to a (possibly spoofed) address that does not respond, the server will have to allocate buffer and retransmission logic for each response up to the exhaustion of MAX_TRANSMIT_SPAN, making it more likely that it runs out of resources for processing legitimate traffic. The latter problem can be mitigated somewhat by limiting the rate of responses as discussed in Section 4.7. An attacker could also spoof the address of a legitimate client; this might cause the server, if it uses separate responses, to block legitimate responses to that client because of NSTART=1. All these attacks can be prevented using a security mode other than NoSec, thus leaving only attacks on the security protocol.
送信元アドレスのスプーフィングの有無にかかわらず、クライアントはリクエスト（できれば複雑なリクエスト）をサーバーに送信することにより、サーバーに過負荷をかけることができます。アドレススプーフィングは、この攻撃の追跡とブロックを困難にします。 CONリクエストのコストは小さいため、この攻撃は簡単に実行できます。この攻撃では、利用可能な総エネルギーが限られている制約付きノードは、計画よりもはるかに速くそのエネルギーを使い果たす可能性があります（バッテリー枯渇攻撃）。また、クライアントがConfirmableメッセージを使用し、サーバーが応答しない（なりすましの可能性がある）アドレスに対して確認可能な個別の応答で応答する場合、サーバーはMAX_TRANSMIT_SPANの枯渇まで各応答にバッファーと再送信ロジックを割り当てる必要があります。正当なトラフィックを処理するためのリソースが不足する可能性が高くなります。後者の問題は、セクション4.7で説明するように、応答率を制限することで多少緩和できます。攻撃者は、正当なクライアントのアドレスを偽装する可能性もあります。これにより、サーバーは、個別の応答を使用する場合、NSTART = 1のためにそのクライアントへの正当な応答をブロックする可能性があります。これらすべての攻撃は、NoSec以外のセキュリティモードを使用して防止できるため、セキュリティプロトコルへの攻撃のみが残ります。
The ability to incite a CoAP endpoint to send packets to a fake source address can be used not only for amplification, but also for cross-protocol attacks against a victim listening to UDP packets at a given address (IP address and port). This would occur as follows:
CoAPエンドポイントを誘導して偽の送信元アドレスにパケットを送信する機能は、増幅だけでなく、特定のアドレス（IPアドレスおよびポート）でUDPパケットをリッスンしている被害者に対するクロスプロトコル攻撃にも使用できます。これは次のように発生します。
o The attacker sends a message to a CoAP endpoint with the given address as the fake source address.
o 攻撃者は、指定されたアドレスを偽の送信元アドレスとして、CoAPエンドポイントにメッセージを送信します。
o The CoAP endpoint replies with a message to the given source address.
o CoAPエンドポイントは、指定された送信元アドレスにメッセージで応答します。
o The victim at the given address receives a UDP packet that it interprets according to the rules of a different protocol.
o 指定されたアドレスの被害者は、別のプロトコルのルールに従って解釈するUDPパケットを受信します。
This may be used to circumvent firewall rules that prevent direct communication from the attacker to the victim but happen to allow communication from the CoAP endpoint (which may also host a valid role in the other protocol) to the victim.
これは、攻撃者から被害者への直接通信を防止し、CoAPエンドポイント（他のプロトコルで有効な役割もホストしている可能性があります）から被害者への通信を許可するファイアウォールルールを回避するために使用できます。
Also, CoAP endpoints may be the victim of a cross-protocol attack generated through an endpoint of another UDP-based protocol such as DNS. In both cases, attacks are possible if the security properties of the endpoints rely on checking IP addresses (and firewalling off direct attacks sent from outside using fake IP addresses). In general, because of their lack of context, UDP-based protocols are relatively easy targets for cross-protocol attacks.
また、CoAPエンドポイントは、DNSなどの別のUDPベースのプロトコルのエンドポイントを介して生成されたクロスプロトコル攻撃の犠牲になる可能性があります。どちらの場合も、エンドポイントのセキュリティプロパティがIPアドレスのチェック（および偽のIPアドレスを使用して外部から送信される直接攻撃をファイアウォールで遮断する）に依存している場合、攻撃が可能です。一般に、コンテキストが不足しているため、UDPベースのプロトコルは、クロスプロトコル攻撃の比較的簡単なターゲットです。
Finally, CoAP URIs transported by other means could be used to incite clients to send messages to endpoints of other protocols.
最後に、他の手段で転送されたCoAP URIを使用して、他のプロトコルのエンドポイントにメッセージを送信するようクライアントに要求することができます。
One mitigation against cross-protocol attacks is strict checking of the syntax of packets received, combined with sufficient difference in syntax. As an example, it might help if it were difficult to incite a DNS server to send a DNS response that would pass the checks of a CoAP endpoint. Unfortunately, the first two bytes of a DNS reply are an ID that can be chosen by the attacker and that map into the interesting part of the CoAP header, and the next two bytes are then interpreted as CoAP's Message ID (i.e., any value is acceptable). The DNS count words may be interpreted as multiple instances of a (nonexistent but elective) CoAP option 0, or possibly as a Token. The echoed query finally may be manufactured by the attacker to achieve a desired effect on the CoAP endpoint; the response added by the server (if any) might then just be interpreted as added payload.
クロスプロトコル攻撃に対する緩和策の1つは、受信したパケットの構文を厳密にチェックし、構文に十分な違いがあることです。例として、CoAPエンドポイントのチェックに合格するDNS応答を送信するようにDNSサーバーを誘導することが困難な場合に役立つことがあります。残念ながら、DNS応答の最初の2バイトは、攻撃者が選択できるIDであり、CoAPヘッダーの対象部分にマップされ、次の2バイトはCoAPのメッセージIDとして解釈されます（つまり、任意の値は許容）。 DNSカウントワードは、（存在しないが選択可能な）CoAPオプション0の複数のインスタンスとして、またはトークンとして解釈される場合があります。エコーされたクエリは、最終的にCoAPエンドポイントに目的の効果を達成するために攻撃者によって作成される可能性があります。サーバーによって追加された応答（存在する場合）は、追加されたペイロードとして解釈される場合があります。
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID | T, TKL, code
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode |AA|TC|RD|RA| Z | RCODE | Message ID
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT | (options 0)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT | (options 0)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT | (options 0)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT | (options 0)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 15: DNS Header ([RFC1035], Section 4.1.1) vs. CoAP Message
図15：DNSヘッダー（[RFC1035]、セクション4.1.1）とCoAPメッセージ
In general, for any pair of protocols, one of the protocols can very well have been designed in a way that enables an attacker to cause the generation of replies that look like messages of the other protocol. It is often much harder to ensure or prove the absence of viable attacks than to generate examples that may not yet completely enable an attack but might be further developed by more creative minds. Cross-protocol attacks can therefore only be completely mitigated if endpoints don't authorize actions desired by an attacker just based on trusting the source IP address of a packet. Conversely, a NoSec environment that completely relies on a firewall for CoAP security not only needs to firewall off the CoAP endpoints but also all other endpoints that might be incited to send UDP messages to CoAP endpoints using some other UDP-based protocol.
一般に、どのプロトコルペアでも、攻撃者が他のプロトコルのメッセージのように見える応答を生成できるように、プロトコルの1つを設計することができます。実行可能な攻撃がないことを確認または証明することは、まだ攻撃を完全には有効にしない可能性があるが、より創造的な心によってさらに開発される可能性のある例を生成するよりもしばしば困難です。したがって、クロスプロトコル攻撃を完全に軽減できるのは、エンドポイントが、パケットの送信元IPアドレスの信頼に基づいて攻撃者が望むアクションを許可しない場合のみです。逆に、CoAPセキュリティをファイアウォールに完全に依存するNoSec環境では、CoAPエンドポイントだけでなく、他のUDPベースのプロトコルを使用してCoAPエンドポイントにUDPメッセージを送信するように誘導される可能性のある他のすべてのエンドポイントもファイアウォールで保護する必要があります。
In addition to the considerations above, the security considerations for DTLS with respect to cross-protocol attacks apply. For example, if the same DTLS security association ("connection") is used to carry data of multiple protocols, DTLS no longer provides protection against cross-protocol attacks between these protocols.
上記の考慮事項に加えて、クロスプロトコル攻撃に関するDTLSのセキュリティの考慮事項が適用されます。たとえば、同じDTLSセキュリティアソシエーション（「接続」）を使用して複数のプロトコルのデータを伝送する場合、DTLSはこれらのプロトコル間のクロスプロトコル攻撃に対する保護を提供しなくなります。
Implementers on constrained nodes often find themselves without a good source of entropy [RFC4086]. If that is the case, the node MUST NOT be used for processes that require good entropy, such as key generation. Instead, keys should be generated externally and added to the device during manufacturing or commissioning.
制約されたノードの実装者は、エントロピーの適切なソースなしに自分自身を見つけることがよくあります[RFC4086]。その場合、ノードは、キー生成などの良好なエントロピーを必要とするプロセスに使用してはなりません（MUST NOT）。代わりに、キーを外部で生成し、製造中または試運転中にデバイスに追加する必要があります。
Due to their low processing power, constrained nodes are particularly susceptible to timing attacks. Special care must be taken in implementation of cryptographic primitives.
処理能力が低いため、制約のあるノードは特にタイミング攻撃の影響を受けやすくなります。暗号化プリミティブの実装には、特別な注意が必要です。
Large numbers of constrained nodes will be installed in exposed environments and will have little resistance to tampering, including recovery of keying materials. This needs to be considered when defining the scope of credentials assigned to them. In particular, assigning a shared key to a group of nodes may make any single constrained node a target for subverting the entire group.
制限された多数のノードが露出した環境にインストールされ、鍵情報の回復などの改ざんに対する耐性がほとんどありません。それらに割り当てられた資格情報の範囲を定義するとき、これを考慮する必要があります。特に、ノードのグループに共有キーを割り当てると、単一の制約されたノードがグループ全体を破壊するターゲットになる場合があります。
This document defines two sub-registries for the values of the Code field in the CoAP header within the "Constrained RESTful Environments (CoRE) Parameters" registry, hereafter referred to as the "CoRE Parameters" registry.
このドキュメントでは、「Constrained RESTful Environments（CoRE）Parameters」レジストリ内のCoAPヘッダーのCodeフィールドの値に対して2つのサブレジストリを定義します。以降、「CoREパラメータ」レジストリと呼びます。
Values in the two sub-registries are eight-bit values notated as three decimal digits c.dd separated by a period between the first and the second digit; the first digit c is between 0 and 7 and denotes the code class; the second and third digits dd denote a decimal number between 00 and 31 for the detail.
2つのサブレジストリの値は、1桁と2桁の間のピリオドで区切られた3桁の10進数c.ddとして表記された8ビット値です。最初の桁cは0から7の間で、コードクラスを示します。 2桁目と3桁目のddは、詳細を表す00から31までの10進数を示します。
All Code values are assigned by sub-registries according to the following ranges:
すべてのコード値は、次の範囲に従ってサブレジストリによって割り当てられます。
0.00 Indicates an Empty message (see Section 4.1).
0.00 空のメッセージを示します（セクション4.1を参照）。
0.01-0.31 Indicates a request. Values in this range are assigned by the "CoAP Method Codes" sub-registry (see Section 12.1.1).
0.01-0.31要求を示します。この範囲の値は、「CoAPメソッドコード」サブレジストリによって割り当てられます（セクション12.1.1を参照）。
1.00-1.31 Reserved
1.00-1.31予約済み
2.00-5.31 Indicates a response. Values in this range are assigned by the "CoAP Response Codes" sub-registry (see Section 12.1.2).
2.00-5.31応答を示します。この範囲の値は、「CoAP応答コード」サブレジストリによって割り当てられます（セクション12.1.2を参照）。
6.00-7.31 Reserved
6.00〜7.31予約済み
The name of the sub-registry is "CoAP Method Codes".
サブレジストリの名前は「CoAPメソッドコード」です。
Each entry in the sub-registry must include the Method Code in the range 0.01-0.31, the name of the method, and a reference to the method's documentation.
サブレジストリの各エントリには、範囲0.01〜0.31のメソッドコード、メソッドの名前、およびメソッドのドキュメントへの参照を含める必要があります。
Initial entries in this sub-registry are as follows:
このサブレジストリの最初のエントリは次のとおりです。
+------+--------+-----------+
| Code | Name | Reference |
+------+--------+-----------+
| 0.01 | GET | [RFC7252] |
| 0.02 | POST | [RFC7252] |
| 0.03 | PUT | [RFC7252] |
| 0.04 | DELETE | [RFC7252] |
+------+--------+-----------+
Table 5: CoAP Method Codes
表5：CoAPメソッドコード
All other Method Codes are Unassigned.
他のすべてのメソッドコードは割り当てられていません。
The IANA policy for future additions to this sub-registry is "IETF Review or IESG Approval" as described in [RFC5226].
このサブレジストリに将来追加されるIANAポリシーは、[RFC5226]で説明されている「IETFレビューまたはIESG承認」です。
The documentation of a Method Code should specify the semantics of a request with that code, including the following properties:
メソッドコードのドキュメントでは、次のプロパティを含む、そのコードを含むリクエストのセマンティクスを指定する必要があります。
o The Response Codes the method returns in the success case.
o メソッドが成功した場合にメソッドが返す応答コード。
o Whether the method is idempotent, safe, or both.
o メソッドがべき等、安全、またはその両方であるかどうか。
The name of the sub-registry is "CoAP Response Codes".
サブレジストリの名前は「CoAP Response Codes」です。
Each entry in the sub-registry must include the Response Code in the range 2.00-5.31, a description of the Response Code, and a reference to the Response Code's documentation.
サブレジストリの各エントリには、2.00〜5.31の範囲の応答コード、応答コードの説明、および応答コードのドキュメントへの参照を含める必要があります。
Initial entries in this sub-registry are as follows:
このサブレジストリの最初のエントリは次のとおりです。
+------+------------------------------+-----------+
| Code | Description | Reference |
+------+------------------------------+-----------+
| 2.01 | Created | [RFC7252] |
| 2.02 | Deleted | [RFC7252] |
| 2.03 | Valid | [RFC7252] |
| 2.04 | Changed | [RFC7252] |
| 2.05 | Content | [RFC7252] |
| 4.00 | Bad Request | [RFC7252] |
| 4.01 | Unauthorized | [RFC7252] |
| 4.02 | Bad Option | [RFC7252] |
| 4.03 | Forbidden | [RFC7252] |
| 4.04 | Not Found | [RFC7252] |
| 4.05 | Method Not Allowed | [RFC7252] |
| 4.06 | Not Acceptable | [RFC7252] |
| 4.12 | Precondition Failed | [RFC7252] |
| 4.13 | Request Entity Too Large | [RFC7252] |
| 4.15 | Unsupported Content-Format | [RFC7252] |
| 5.00 | Internal Server Error | [RFC7252] |
| 5.01 | Not Implemented | [RFC7252] |
| 5.02 | Bad Gateway | [RFC7252] |
| 5.03 | Service Unavailable | [RFC7252] |
| 5.04 | Gateway Timeout | [RFC7252] |
| 5.05 | Proxying Not Supported | [RFC7252] |
+------+------------------------------+-----------+
Table 6: CoAP Response Codes
表6：CoAP応答コード
The Response Codes 3.00-3.31 are Reserved for future use. All other Response Codes are Unassigned.
応答コード3.00〜3.31は、将来の使用のために予約されています。他のすべての応答コードは割り当てられていません。
The IANA policy for future additions to this sub-registry is "IETF Review or IESG Approval" as described in [RFC5226].
このサブレジストリに将来追加されるIANAポリシーは、[RFC5226]で説明されている「IETFレビューまたはIESG承認」です。
The documentation of a Response Code should specify the semantics of a response with that code, including the following properties:
応答コードのドキュメントでは、次のプロパティを含む、そのコードでの応答のセマンティクスを指定する必要があります。
o The methods the Response Code applies to.
o 応答コードが適用されるメソッド。
o Whether payload is required, optional, or not allowed.
o ペイロードが必須か、オプションか、または許可されていないか。
o The semantics of the payload. For example, the payload of a 2.05 (Content) response is a representation of the target resource; the payload in an error response is a human-readable diagnostic payload.
o ペイロードのセマンティクス。たとえば、2.05（コンテンツ）応答のペイロードは、ターゲットリソースの表現です。エラー応答のペイロードは、人間が読める診断ペイロードです。
o The format of the payload. For example, the format in a 2.05 (Content) response is indicated by the Content-Format Option; the format of the payload in an error response is always Net-Unicode text.
o ペイロードの形式。たとえば、2.05（コンテンツ）応答の形式は、コンテンツ形式オプションによって示されます。エラー応答のペイロードの形式は常にNet-Unicodeテキストです。
o Whether the response is cacheable according to the freshness model.
o フレッシュネスモデルに従って応答がキャッシュ可能かどうか。
o Whether the response is validatable according to the validation model.
o 応答が検証モデルに従って検証可能かどうか。
o Whether the response causes a cache to mark responses stored for the request URI as not fresh.
o 応答により、キャッシュが要求URI用に保存された応答を最新でないものとしてマークするかどうか。
This document defines a sub-registry for the Option Numbers used in CoAP options within the "CoRE Parameters" registry. The name of the sub-registry is "CoAP Option Numbers".
このドキュメントでは、「CoREパラメータ」レジストリ内のCoAPオプションで使用されるオプション番号のサブレジストリを定義します。サブレジストリの名前は「CoAP Option Numbers」です。
Each entry in the sub-registry must include the Option Number, the name of the option, and a reference to the option's documentation.
サブレジストリの各エントリには、オプション番号、オプションの名前、およびオプションのドキュメントへの参照を含める必要があります。
Initial entries in this sub-registry are as follows:
このサブレジストリの最初のエントリは次のとおりです。
+--------+------------------+-----------+
| Number | Name | Reference |
+--------+------------------+-----------+
| 0 | (Reserved) | [RFC7252] |
| 1 | If-Match | [RFC7252] |
| 3 | Uri-Host | [RFC7252] |
| 4 | ETag | [RFC7252] |
| 5 | If-None-Match | [RFC7252] |
| 7 | Uri-Port | [RFC7252] |
| 8 | Location-Path | [RFC7252] |
| 11 | Uri-Path | [RFC7252] |
| 12 | Content-Format | [RFC7252] |
| 14 | Max-Age | [RFC7252] |
| 15 | Uri-Query | [RFC7252] |
| 17 | Accept | [RFC7252] |
| 20 | Location-Query | [RFC7252] |
| 35 | Proxy-Uri | [RFC7252] |
| 39 | Proxy-Scheme | [RFC7252] |
| 60 | Size1 | [RFC7252] |
| 128 | (Reserved) | [RFC7252] |
| 132 | (Reserved) | [RFC7252] |
| 136 | (Reserved) | [RFC7252] |
| 140 | (Reserved) | [RFC7252] |
+--------+------------------+-----------+
Table 7: CoAP Option Numbers
表7：CoAPオプション番号
The IANA policy for future additions to this sub-registry is split into three tiers as follows. The range of 0..255 is reserved for options defined by the IETF (IETF Review or IESG Approval). The range of 256..2047 is reserved for commonly used options with public specifications (Specification Required). The range of 2048..64999 is for all other options including private or vendor-specific ones, which undergo a Designated Expert review to help ensure that the option semantics are defined correctly. The option numbers between 65000 and 65535 inclusive are reserved for experiments. They are not meant for vendor-specific use of any kind and MUST NOT be used in operational deployments.
このサブレジストリに将来追加されるIANAポリシーは、次のように3つの層に分かれています。 0..255の範囲は、IETF（IETFレビューまたはIESG承認）によって定義されたオプション用に予約されています。 256..2047の範囲は、一般仕様で一般的に使用されるオプション用に予約されています（仕様が必要）。 2048..64999の範囲は、オプションのセマンティクスが正しく定義されていることを確認するためにDesignated Expertの審査を受ける、プライベートまたはベンダー固有のオプションを含む他のすべてのオプション用です。 65000から65535までのオプション番号は、実験用に予約されています。これらは、ベンダー固有の使用を目的としたものではなく、運用展開で使用してはなりません。
+-------------+---------------------------------------+
| Range | Registration Procedures |
+-------------+---------------------------------------+
| 0-255 | IETF Review or IESG Approval |
| 256-2047 | Specification Required |
| 2048-64999 | Expert Review |
| 65000-65535 | Experimental use (no operational use) |
+-------------+---------------------------------------+
Table 8: CoAP Option Numbers: Registration Procedures
表8：CoAPオプション番号：登録手順
The documentation of an Option Number should specify the semantics of an option with that number, including the following properties:
オプション番号のドキュメントでは、次のプロパティを含む、その番号のオプションのセマンティクスを指定する必要があります。
o The meaning of the option in a request.
o リクエスト内のオプションの意味。
o The meaning of the option in a response.
o 応答におけるオプションの意味。
o Whether the option is critical or elective, as determined by the Option Number.
o オプション番号によって決定される、オプションが重要であるか選択的であるか。
o Whether the option is Safe-to-Forward, and, if yes, whether it is part of the Cache-Key, as determined by the Option Number (see Section 5.4.2).
o オプションが転送しても安全かどうか、そうである場合は、オプション番号によって決定されるように、キャッシュキーの一部であるかどうか（セクション5.4.2を参照）。
o The format and length of the option's value.
o オプションの値の形式と長さ。
o Whether the option must occur at most once or whether it can occur multiple times.
o オプションが最大で1回発生する必要があるか、それとも複数回発生する可能性があるか。
o The default value, if any. For a critical option with a default value, a discussion on how the default value enables processing by implementations that do not support the critical option (Section 5.4.4).
o もしあれば、デフォルト値。デフォルト値を持つクリティカルオプションの場合、デフォルト値がクリティカルオプションをサポートしない実装による処理をどのように有効にするかについての議論（セクション5.4.4）。
Internet media types are identified by a string, such as "application/xml" [RFC2046]. In order to minimize the overhead of using these media types to indicate the format of payloads, this document defines a sub-registry for a subset of Internet media types to be used in CoAP and assigns each, in combination with a content-coding, a numeric identifier. The name of the sub-registry is "CoAP Content-Formats", within the "CoRE Parameters" registry.
インターネットメディアタイプは、「application / xml」[RFC2046]などの文字列で識別されます。これらのメディアタイプを使用してペイロードの形式を示すオーバーヘッドを最小限に抑えるために、このドキュメントでは、CoAPで使用されるインターネットメディアタイプのサブセットのサブレジストリを定義し、コンテンツコーディングと組み合わせて、それぞれを割り当てます。数値識別子。サブレジストリーの名前は、「CoRE Parameters」レジストリー内の「CoAP Content-Formats」です。
Each entry in the sub-registry must include the media type registered with IANA, the numeric identifier in the range 0-65535 to be used for that media type in CoAP, the content-coding associated with this identifier, and a reference to a document describing what a payload with that media type means semantically.
サブレジストリの各エントリには、IANAに登録されたメディアタイプ、CoAPでそのメディアタイプに使用される0〜65535の範囲の数値識別子、この識別子に関連付けられたコンテンツコーディング、およびドキュメントへの参照が含まれている必要があります。そのメディアタイプのペイロードが意味的に何を意味するかを説明します。
CoAP does not include a separate way to convey content-encoding information with a request or response, and for that reason the content-encoding is also specified for each identifier (if any). If multiple content-encodings will be used with a media type, then a separate Content-Format identifier for each is to be registered. Similarly, other parameters related to an Internet media type, such as level, can be defined for a CoAP Content-Format entry.
CoAPには、要求または応答でコンテンツエンコーディング情報を伝達する別の方法はありません。そのため、コンテンツエンコーディングは、各識別子（存在する場合）にも指定されます。メディアタイプで複数のcontent-encodingsが使用される場合、それぞれに個別のContent-Format識別子が登録されます。同様に、レベルなどのインターネットメディアタイプに関連する他のパラメータは、CoAP Content-Formatエントリに対して定義できます。
Initial entries in this sub-registry are as follows:
このサブレジストリの最初のエントリは次のとおりです。
+--------------------------+----------+----+------------------------+
| Media type | Encoding | ID | Reference |
+--------------------------+----------+----+------------------------+
| text/plain; | - | 0 | [RFC2046] [RFC3676] |
| charset=utf-8 | | | [RFC5147] |
| application/link-format | - | 40 | [RFC6690] |
| application/xml | - | 41 | [RFC3023] |
| application/octet-stream | - | 42 | [RFC2045] [RFC2046] |
| application/exi | - | 47 | [REC-exi-20140211] |
| application/json | - | 50 | [RFC7159] |
+--------------------------+----------+----+------------------------+
Table 9: CoAP Content-Formats
表9：CoAPコンテンツ形式
The identifiers between 65000 and 65535 inclusive are reserved for experiments. They are not meant for vendor-specific use of any kind and MUST NOT be used in operational deployments. The identifiers between 256 and 9999 are reserved for future use in IETF specifications (IETF Review or IESG Approval). All other identifiers are Unassigned.
65000〜65535の識別子は実験用に予約されています。これらは、ベンダー固有の使用を目的としたものではなく、運用展開で使用してはなりません。 256〜9999の識別子は、IETF仕様（IETFレビューまたはIESG承認）で将来使用するために予約されています。他のすべての識別子は割り当てられていません。
Because the namespace of single-byte identifiers is so small, the IANA policy for future additions in the range 0-255 inclusive to the sub-registry is "Expert Review" as described in [RFC5226]. The IANA policy for additions in the range 10000-64999 inclusive is "First Come First Served" as described in [RFC5226]. This is summarized in the following table.
シングルバイト識別子の名前空間は非常に小さいため、[RFC5226]で説明されているように、サブレジストリに0〜255の範囲で将来追加されるIANAポリシーは「エキスパートレビュー」です。 [RFC5226]で説明されているように、10000〜64999の範囲の追加に関するIANAポリシーは「先着順」です。これを次の表にまとめます。
+-------------+---------------------------------------+
| Range | Registration Procedures |
+-------------+---------------------------------------+
| 0-255 | Expert Review |
| 256-9999 | IETF Review or IESG Approval |
| 10000-64999 | First Come First Served |
| 65000-65535 | Experimental use (no operational use) |
+-------------+---------------------------------------+
Table 10: CoAP Content-Formats: Registration Procedures
表10：CoAPコンテンツ形式：登録手順
In machine-to-machine applications, it is not expected that generic Internet media types such as text/plain, application/xml or application/octet-stream are useful for real applications in the long term. It is recommended that M2M applications making use of CoAP request new Internet media types from IANA indicating semantic information about how to create or parse a payload. For example, a Smart Energy application payload carried as XML might request a more specific type like application/se+xml or application/se-exi.
マシンツーマシンアプリケーションでは、text / plain、application / xml、application / octet-streamなどの一般的なインターネットメディアタイプが実際のアプリケーションで長期的に役立つとは考えられていません。 CoAPを使用するM2Mアプリケーションは、ペイロードの作成または解析方法に関するセマンティック情報を示す新しいインターネットメディアタイプをIANAに要求することをお勧めします。たとえば、XMLとして伝送されるSmart Energyアプリケーションペイロードは、application / se + xmlやapplication / se-exiのようなより具体的なタイプを要求する場合があります。
This document contains the request for the registration of the Uniform Resource Identifier (URI) scheme "coap". The registration request complies with [RFC4395].
このドキュメントには、Uniform Resource Identifier（URI）スキーム「coap」の登録要求が含まれています。登録リクエストは[RFC4395]に準拠しています。
URI scheme name. coap
うり ｓちぇめ なめ。 こあｐ
Status. Permanent.
状態。永久。
URI scheme syntax. Defined in Section 6.1 of [RFC7252].
URIスキームの構文。 [RFC7252]のセクション6.1で定義されています。
URI scheme semantics. The "coap" URI scheme provides a way to identify resources that are potentially accessible over the Constrained Application Protocol (CoAP). The resources can be located by contacting the governing CoAP server and operated on by sending CoAP requests to the server. This scheme can thus be compared to the "http" URI scheme [RFC2616]. See Section 6 of [RFC7252] for the details of operation.
URIスキームのセマンティクス。 「coap」URIスキームは、Constrained Application Protocol（CoAP）を介して潜在的にアクセス可能なリソースを識別する方法を提供します。リソースは、管理しているCoAPサーバーに接続することで検索でき、CoAP要求をサーバーに送信することで操作できます。したがって、このスキームは「http」URIスキーム[RFC2616]と比較できます。操作の詳細については、[RFC7252]のセクション6を参照してください。
Encoding considerations. The scheme encoding conforms to the encoding rules established for URIs in [RFC3986], i.e., internationalized and reserved characters are expressed using UTF-8-based percent-encoding.
エンコーディングに関する考慮事項。スキームエンコーディングは、[RFC3986]のURIに対して確立されたエンコーディングルールに準拠しています。つまり、国際化された予約文字は、UTF-8ベースのパーセントエンコーディングを使用して表現されます。
Applications/protocols that use this URI scheme name. The scheme is used by CoAP endpoints to access CoAP resources.
このURIスキーム名を使用するアプリケーション/プロトコル。このスキームは、CoAPエンドポイントがCoAPリソースにアクセスするために使用されます。
Interoperability considerations. None.
相互運用性に関する考慮事項。なし。
Security considerations. See Section 11.1 of [RFC7252].
セキュリティに関する考慮事項。 [RFC7252]のセクション11.1を参照してください。
Contact. IETF Chair <chair@ietf.org>
連絡先。 IETF議長<chair@ietf.org>
Author/Change controller.
IESG <iesg@ietf.org>
References. [RFC7252]
参照。 [RFC7252]
This document contains the request for the registration of the Uniform Resource Identifier (URI) scheme "coaps". The registration request complies with [RFC4395].
このドキュメントには、Uniform Resource Identifier（URI）スキーム「coaps」の登録要求が含まれています。登録リクエストは[RFC4395]に準拠しています。
URI scheme name. coaps
うり ｓちぇめ なめ。 こあｐｓ
Status. Permanent.
状態。永久。
URI scheme syntax. Defined in Section 6.2 of [RFC7252].
URIスキームの構文。 [RFC7252]のセクション6.2で定義されています。
URI scheme semantics. The "coaps" URI scheme provides a way to identify resources that are potentially accessible over the Constrained Application Protocol (CoAP) using Datagram Transport Layer Security (DTLS) for transport security. The resources can be located by contacting the governing CoAP server and operated on by sending CoAP requests to the server. This scheme can thus be compared to the "https" URI scheme [RFC2616]. See Section 6 of [RFC7252] for the details of operation.
URIスキームのセマンティクス。 「coaps」URIスキームは、トランスポートセキュリティのためにデータグラムトランスポート層セキュリティ（DTLS）を使用して、Constrained Application Protocol（CoAP）を介してアクセス可能なリソースを識別する方法を提供します。リソースは、管理しているCoAPサーバーに接続することで検索でき、CoAP要求をサーバーに送信することで操作できます。したがって、このスキームは「https」URIスキーム[RFC2616]と比較できます。操作の詳細については、[RFC7252]のセクション6を参照してください。
Encoding considerations. The scheme encoding conforms to the encoding rules established for URIs in [RFC3986], i.e., internationalized and reserved characters are expressed using UTF-8-based percent-encoding.
エンコーディングに関する考慮事項。スキームエンコーディングは、[RFC3986]のURIに対して確立されたエンコーディングルールに準拠しています。つまり、国際化された予約文字は、UTF-8ベースのパーセントエンコーディングを使用して表現されます。
Applications/protocols that use this URI scheme name. The scheme is used by CoAP endpoints to access CoAP resources using DTLS.
このURIスキーム名を使用するアプリケーション/プロトコル。このスキームは、DTLSを使用してCoAPリソースにアクセスするためにCoAPエンドポイントによって使用されます。
Interoperability considerations. None.
相互運用性に関する考慮事項。なし。
Security considerations. See Section 11.1 of [RFC7252].
セキュリティに関する考慮事項。 [RFC7252]のセクション11.1を参照してください。
Contact. IETF Chair <chair@ietf.org>
連絡先。 IETF議長<chair@ietf.org>
Author/Change controller.
IESG <iesg@ietf.org>
References. [RFC7252]
参照。 [RFC7252]
One of the functions of CoAP is resource discovery: a CoAP client can ask a CoAP server about the resources offered by it (see Section 7). To enable resource discovery just based on the knowledge of an IP address, the CoAP port for resource discovery needs to be standardized.
CoAPの機能の1つはリソース検出です。CoAPクライアントは、CoAPサーバーが提供するリソースについてCoAPサーバーに問い合わせることができます（セクション7を参照）。 IPアドレスの知識だけに基づいてリソース検出を有効にするには、リソース検出用のCoAPポートを標準化する必要があります。
IANA has assigned the port number 5683 and the service name "coap", in accordance with [RFC6335].
IANAは、[RFC6335]に従って、ポート番号5683とサービス名「coap」を割り当てました。
Besides unicast, CoAP can be used with both multicast and anycast.
ユニキャスト以外に、CoAPはマルチキャストとエニーキャストの両方で使用できます。
Service Name. coap
サービス名。粗末
Transport Protocol. udp
トランスポートプロトコル。 udp
Assignee. IESG <iesg@ietf.org>
譲受人。 IESG <iesg@ietf.org>
Contact. IETF Chair <chair@ietf.org>
連絡先。 IETF議長<chair@ietf.org>
Description. Constrained Application Protocol (CoAP)
説明。制約付きアプリケーションプロトコル（CoAP）
Reference. [RFC7252]
参照。 [RFC7252]
Port Number. 5683
ポート番号。 5683
CoAP resource discovery may also be provided using the DTLS-secured CoAP "coaps" scheme. Thus, the CoAP port for secure resource discovery needs to be standardized.
CoAPリソースディスカバリは、DTLSで保護されたCoAP「coaps」方式を使用して提供することもできます。したがって、安全なリソース検出のためのCoAPポートを標準化する必要があります。
IANA has assigned the port number 5684 and the service name "coaps", in accordance with [RFC6335].
IANAは、[RFC6335]に従って、ポート番号5684とサービス名「coaps」を割り当てました。
Besides unicast, DTLS-secured CoAP can be used with anycast.
ユニキャスト以外に、DTLSで保護されたCoAPをエニーキャストで使用できます。
Service Name. coaps
サービス名。ひさし
Transport Protocol. udp
トランスポートプロトコル。 udp
Assignee. IESG <iesg@ietf.org>
譲受人。 IESG <iesg@ietf.org>
Contact. IETF Chair <chair@ietf.org>
連絡先。 IETF議長<chair@ietf.org>
Description. DTLS-secured CoAP
説明。 DTLSで保護されたCoAP
Reference. [RFC7252]
参照。 [RFC7252]
Port Number. 5684
ポート番号。 5684
Section 8, "Multicast CoAP", defines the use of multicast. IANA has assigned the following multicast addresses for use by CoAP nodes:
セクション8「マルチキャストCoAP」は、マルチキャストの使用を定義しています。 IANAは、CoAPノードが使用する次のマルチキャストアドレスを割り当てています。
IPv4 -- "All CoAP Nodes" address 224.0.1.187, from the "IPv4 Multicast Address Space Registry". As the address is used for discovery that may span beyond a single network, it has come from the Internetwork Control Block (224.0.1.x, RFC 5771).
IPv4-「IPv4マルチキャストアドレススペースレジストリ」の「すべてのCoAPノード」アドレス224.0.1.187。このアドレスは、単一のネットワークを超える可能性のあるディスカバリーに使用されるため、インターネットワーク制御ブロック（224.0.1.x、RFC 5771）からのものです。
IPv6 -- "All CoAP Nodes" address FF0X::FD, from the "IPv6 Multicast Address Space Registry", in the "Variable Scope Multicast Addresses" space (RFC 3307). Note that there is a distinct multicast address for each scope that interested CoAP nodes should listen to; CoAP needs the Link-Local and Site-Local scopes only.
IPv6-「すべてのCoAPノード」アドレスFF0X :: FD、「IPv6マルチキャストアドレススペースレジストリ」の「可変スコープマルチキャストアドレス」スペース（RFC 3307）。関心のあるCoAPノードがリッスンする必要があるスコープごとに個別のマルチキャストアドレスがあることに注意してください。 CoAPには、Link-LocalスコープとSite-Localスコープのみが必要です。
Brian Frank was a contributor to and coauthor of early versions of this specification.
ブライアン・フランクは、この仕様の初期バージョンへの寄稿者および共著者でした。
Special thanks to Peter Bigot, Esko Dijk, and Cullen Jennings for substantial contributions to the ideas and text in the document, along with countless detailed reviews and discussions.
ドキュメントのアイデアとテキストに多大な貢献をしてくれたPeter Bigot、Esko Dijk、およびCullen Jenningsに、数え切れないほどの詳細なレビューとディスカッションに感謝します。
Thanks to Floris Van den Abeele, Anthony Baire, Ed Beroset, Berta Carballido, Angelo P. Castellani, Gilbert Clark, Robert Cragie, Pierre David, Esko Dijk, Lisa Dusseault, Mehmet Ersue, Thomas Fossati, Tobias Gondrom, Bert Greevenbosch, Tom Herbst, Jeroen Hoebeke, Richard Kelsey, Sye Loong Keoh, Ari Keranen, Matthias Kovatsch, Avi Lior, Stephan Lohse, Salvatore Loreto, Kerry Lynn, Andrew McGregor, Alexey Melnikov, Guido Moritz, Petri Mutka, Colin O'Flynn, Charles Palmer, Adriano Pezzuto, Thomas Poetsch, Robert Quattlebaum, Akbar Rahman, Eric Rescorla, Dan Romascanu, David Ryan, Peter Saint-Andre, Szymon Sasin, Michael Scharf, Dale Seed, Robby Simpson, Peter van der Stok, Michael Stuber, Linyi Tian, Gilman Tolle, Matthieu Vial, Maciej Wasilak, Fan Xianyou, and Alper Yegin for helpful comments and discussions that have shaped the document. Special thanks also to the responsible IETF area director at the time of completion, Barry Leiba, and the IESG reviewers, Adrian Farrel, Martin Stiemerling, Pete Resnick, Richard Barnes, Sean Turner, Spencer Dawkins, Stephen Farrell, and Ted Lemon, who contributed in-depth reviews.
フロリス・ヴァン・デン・アビーレ、アンソニー・ベイル、エド・ベロセット、ベルタ・カルバリド、アンジェロ・P・カステラーニ、ギルバート・クラーク、ロバート・クラギー、ピエール・デイビッド、エスコ・ダイク、リサ・デュスー、メメット・エルスエ、トーマス・フォッサティ、トビアス・ゴンドロム、バート・グリーベンボッシュ、トム・ハーブスト、Jeroen Hoebeke、Richard Kelsey、Sye Loong Keoh、Ari Keranen、Matthias Kovatsch、Avi Lior、Stephan Lohse、Salvatore Loreto、Kerry Lynn、Andrew McGregor、Alexey Melnikov、Guido Moritz、Petri Mutka、Colin O'Flynn、Charles Palmer、Adri Pezzuto、Thomas Poetsch、Robert Quattlebaum、Akbar Rahman、Eric Rescorla、Dan Romascanu、David Ryan、Peter Saint-Andre、Szymon Sasin、Michael Scharf、Dale Seed、Robby Simpson、Peter van der Stok、Michael Stuber、Linyi Tian、Gilman Tolle 、Matthieu Vial、Maciej Wasilak、Fan Xianyou、およびAlper Yeginが、ドキュメントを形成した有益なコメントとディスカッションを提供しました。完成時に責任あるIETFエリアディレクターであるバリーレイバ、およびIESGレビュー担当者であるAdrian Farrel、Martin Stiemerling、Pete Resnick、Richard Barnes、Sean Turner、Spencer Dawkins、Stephen Farrell、およびTed Lemonにも貢献してくれました。詳細なレビュー。
Some of the text has been borrowed from the working documents of the IETF HTTPBIS working group.
テキストの一部は、IETF HTTPBISワーキンググループのワーキングドキュメントから借用されました。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768] Postel、J。、「User Datagram Protocol」、STD 6、RFC 768、1980年8月。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045] Freed、N。およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part One：Format of Internet Message Bodies」、RFC 2045、1996年11月。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC2046] Freed、N。およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part Two：Media Types」、RFC 2046、1996年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[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, June 1999.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「Hypertext Transfer Protocol-HTTP / 1.1」 、RFC 2616、1999年6月。
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3023] Murata、M.、St。Laurent、S。、およびD. Kohn、「XML Media Types」、RFC 3023、2001年1月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、2003年11月。
[RFC3676] Gellens, R., "The Text/Plain Format and DelSp Parameters", RFC 3676, February 2004.
[RFC3676] Gellens、R。、「The Text / Plain Format and DelSp Parameters」、RFC 3676、2004年2月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、2005年1月。
[RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, December 2005.
[RFC4279] Eronen、P。およびH. Tschofenig、「トランスポート層セキュリティ（TLS）の事前共有鍵暗号スイート」、RFC 4279、2005年12月。
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", BCP 35, RFC 4395, February 2006.
[RFC4395] Hansen、T.、Hardie、T。、およびL. Masinter、「新しいURIスキームのガイドラインと登録手順」、BCP 35、RFC 4395、2006年2月。
[RFC5147] Wilde, E. and M. Duerst, "URI Fragment Identifiers for the text/plain Media Type", RFC 5147, April 2008.
[RFC5147] Wilde、E.、M。Duerst、「text / plain Media TypeのURIフラグメント識別子」、RFC 5147、2008年4月。
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, March 2008.
[RFC5198] Klensin、J。およびM. Padlipsky、「Network InterchangeのUnicode形式」、RFC 5198、2008年3月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、2008年1月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、2008年8月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、2008年5月。
[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, "Elliptic Curve Cryptography Subject Public Key Information", RFC 5480, March 2009.
[RFC5480]ターナー、S。、ブラウン、D。、ユウ、K。、ハウズリー、R。、およびT.ポーク、「楕円曲線暗号サブジェクト公開鍵情報」、RFC 5480、2009年3月。
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, April 2010.
[RFC5785]ノッティンガム、M。およびE.ハマーラハブ、「Defining Well-Known Uniform Resource Identifiers（URIs）」、RFC 5785、2010年4月。
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010.
[RFC5952] Kawamura、S. and M. Kawashima、 "A Recommendation for IPv6 Address Text Representation"、RFC 5952、August 2010。
[RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010.
[RFC5988]ノッティンガム、M。、「Webリンク」、RFC 5988、2010年10月。
[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, January 2011.
[RFC6066] Eastlake、D。、「Transport Layer Security（TLS）Extensions：Extension Definitions」、RFC 6066、2011年1月。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012.
[RFC6347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security Version 1.2」、RFC 6347、2012年1月。
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, August 2012.
[RFC6690] Shelby、Z。、「Constrained RESTful Environments（CoRE）Link Format」、RFC 6690、2012年8月。
[RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., Keranen, A., and P. Hallam-Baker, "Naming Things with Hashes", RFC 6920, April 2013.
[RFC6920] Farrell、S.、Kutscher、D.、Dannewitz、C.、Ohlman、B.、Keranen、A。、およびP. Hallam-Baker、「Naming Things with Hashes」、RFC 6920、2013年4月。
[RFC7250] Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and T. Kivinen, "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7250, June 2014.
[RFC7250] Wouters、P.、Tschofenig、H.、Gilmore、J.、Weiler、S。、およびT. Kivinen、「トランスポート層セキュリティ（TLS）およびデータグラムトランスポート層セキュリティ（DTLS）での生の公開鍵の使用」、 RFC 7250、2014年6月。
[RFC7251] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES-CCM Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)", RFC 7251, June 2014.
[RFC7251] McGrew、D.、Bailey、D.、Campagna、M。、およびR. Dugal、「AES-CCM Elliptic Curve Cryptography（ECC）Cipher Suites for Transport Layer Security（TLS）」、RFC 7251、2014年6月。
[BLOCK] Bormann, C. and Z. Shelby, "Blockwise transfers in CoAP", Work in Progress, October 2013.
[ブロック] Bormann、C.、Z。Shelby、「Blockwise transfer in CoAP」、Work in Progress、2013年10月。
[CoAP-MISC] Bormann, C. and K. Hartke, "Miscellaneous additions to CoAP", Work in Progress, December 2013.
[CoAP-MISC] Bormann、C.およびK. Hartke、「CoAPへのその他の追加」、作業中、2013年12月。
[EUI64] IEEE Standards Association, "Guidelines for 64-bit Global Identifier (EUI-64 (TM))", Registration Authority Tutorials, April 2010, <http://standards.ieee.org/regauth/ oui/tutorials/EUI64.html>.
[EUI64] IEEE規格協会、「64ビットグローバル識別子（EUI-64（TM））のガイドライン」、登録機関チュートリアル、2010年4月、<http://standards.ieee.org/regauth/ oui / tutorials / EUI64 .html>。
[GROUPCOMM] Rahman, A. and E. Dijk, "Group Communication for CoAP", Work in Progress, December 2013.
[GROUPCOMM]ラーマンA.およびE.ダイク、「CoAPのためのグループ通信」、作業中、2013年12月。
[HHGTTG] Adams, D., "The Hitchhiker's Guide to the Galaxy", Pan Books ISBN 3320258648, 1979.
[HHGTTG]アダムス、D。、「銀河へのヒッチハイカーのガイド」、Pan Books ISBN 3320258648、1979。
[IEEE1003.1] IEEE and The Open Group, "Portable Operating System Interface (POSIX)", The Open Group Base Specifications Issue 7, IEEE 1003.1, 2013 Edition, <http://pubs.opengroup.org/onlinepubs/9699919799/>.
[IEEE1003.1] IEEEおよびThe Open Group、「Portable Operating System Interface（POSIX）」、The Open Group Base Specifications Issue 7、IEEE 1003.1、2013 Edition、<http://pubs.opengroup.org/onlinepubs/9699919799/ >。
[IPsec-CoAP] Bormann, C., "Using CoAP with IPsec", Work in Progress, December 2012.
[IPsec-CoAP] Bormann、C。、「Using CoAP with IPsec」、Work in Progress、2012年12月。
[MAPPING] Castellani, A., Loreto, S., Rahman, A., Fossati, T., and E. Dijk, "Guidelines for HTTP-CoAP Mapping Implementations", Work in Progress, February 2014.
[マッピング] Castellani、A.、Loreto、S.、Rahman、A.、Fossati、T。、およびE. Dijk、「HTTP-CoAPマッピング実装のガイドライン」、進行中の作業、2014年2月。
[OBSERVE] Hartke, K., "Observing Resources in CoAP", Work in Progress, April 2014.
[OBSERVE] Hartke、K。、「Observing Resources in CoAP」、Work in Progress、2014年4月。
[REC-exi-20140211] Schneider, J., Kamiya, T., Peintner, D., and R. Kyusakov, "Efficient XML Interchange (EXI) Format 1.0 (Second Edition)", W3C Recommendation REC-exi-20140211, February 2014, <http://www.w3.org/TR/2014/REC-exi-20140211/>.
[REC-exi-20140211] Schneider、J.、Kamiya、T.、Peintner、D。、およびR. Kyusakov、「Efficient XML Interchange（EXI）Format 1.0（Second Edition）」、W3C Recommendation REC-exi-20140211、 2014年2月、<http://www.w3.org/TR/2014/REC-exi-20140211/>。
[REST] Fielding, R., "Architectural Styles and the Design of Network-based Software Architectures", Ph.D. Dissertation, University of California, Irvine, 2000, <http://www.ics.uci.edu/~fielding/pubs/dissertation/ fielding_dissertation.pdf>.
[REST] Fielding、R。、「Architectural Styles and the Design of Network-based Software Architectures」、Ph.D。カリフォルニア大学アーバイン校の論文、2000年、<http://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf>。
[RFC0020] Cerf, V., "ASCII format for network interchange", RFC 20, October 1969.
[RFC0020] Cerf、V。、「ネットワーク交換用のASCII形式」、RFC 20、1969年10月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC0792] Postel、J。、「インターネット制御メッセージプロトコル」、STD 5、RFC 792、1981年9月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、1981年9月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P。、「ドメイン名-実装と仕様」、STD 13、RFC 1035、1987年11月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264] Rosenberg、J。およびH. Schulzrinne、「オファー/アンサーモデルとセッション記述プロトコル（SDP）」、RFC 3264、2002年6月。
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[RFC3280] Housley、R.、Polk、W.、Ford、W。、およびD. Solo、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile」、RFC 3280、2002年4月。
[RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, "Advanced Sockets Application Program Interface (API) for IPv6", RFC 3542, May 2003.
[RFC3542] Stevens、W.、Thomas、M.、Nordmark、E.、and T. Jinmei、 "Advanced Sockets Application Program Interface（API）for IPv6"、RFC 3542、May 2003。
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G. Fairhurst, "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, July 2004.
[RFC3828] Larzon、L-A。、Degermark、M.、Pink、S.、Jonsson、L-E。、およびG. Fairhurst、「The Lightweight User Datagram Protocol（UDP-Lite）」、RFC 3828、2004年7月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086] Eastlake、D.、Schiller、J。、およびS. Crocker、「Randomness Requirements for Security」、BCP 106、RFC 4086、2005年6月。
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443]コンタ、A。、ディアリング、S。、およびM.グプタ、「インターネットプロトコルバージョン6（IPv6）仕様のインターネットコントロールメッセージプロトコル（ICMPv6）」、RFC 4443、2006年3月。
[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)", RFC 4492, May 2006.
[RFC4492] Blake-Wilson、S.、Bolyard、N.、Gupta、V.、Hawk、C。、およびB. Moeller、「Elliptic Curve Cryptography（ECC）Cipher Suites for Transport Layer Security（TLS）」、RFC 4492 、2006年5月。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.
[RFC4821] Mathis、M。およびJ. Heffner、「Packetization Layer Path MTU Discovery」、RFC 4821、2007年3月。
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, September 2007.
[RFC4944]モンテネグロ、G。、クシャルナガル、N。、ホイ、J。、およびD.キュラー、「IEEE 802.15.4ネットワーク上のIPv6パケットの送信」、RFC 4944、2007年9月。
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, November 2008.
[RFC5405] Eggert、L。およびG. Fairhurst、「アプリケーション設計者のためのユニキャストUDP使用ガイドライン」、BCP 145、RFC 5405、2008年11月。
[RFC5489] Badra, M. and I. Hajjeh, "ECDHE_PSK Cipher Suites for Transport Layer Security (TLS)", RFC 5489, March 2009.
[RFC5489] Badra、M。およびI. Hajjeh、「トランスポート層セキュリティ（TLS）のECDHE_PSK暗号スイート」、RFC 5489、2009年3月。
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, February 2011.
[RFC6090] McGrew、D.、Igoe、K。、およびM. Salter、「Fundamental Elliptic Curve Cryptography Algorithms」、RFC 6090、2011年2月。
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011.
[RFC6120] Saint-Andre、P。、「Extensible Messaging and Presence Protocol（XMPP）：Core」、RFC 6120、2011年3月。
[RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, September 2011.
[RFC6282] Hui、J。およびP. Thubert、「IEEE 802.15.4ベースのネットワーク上のIPv6データグラムの圧縮形式」、RFC 6282、2011年9月。
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, August 2011.
[RFC6335]綿、M。、エガート、L。、タッチ、J。、ウェスターランド、M。、およびS.チェシャー、「サービス名とトランスポートプロトコルのポート番号レジストリの管理のためのInternet Assigned Numbers Authority（IANA）手順"、BCP 165、RFC 6335、2011年8月。
[RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for Transport Layer Security (TLS)", RFC 6655, July 2012.
[RFC6655] McGrew、D.およびD. Bailey、「AES-CCM Cipher Suites for Transport Layer Security（TLS）」、RFC 6655、2012年7月。
[RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC 6936, April 2013.
[RFC6936] Fairhurst、G。およびM. Westerlund、「ゼロチェックサムを使用したIPv6 UDPデータグラムの使用に関する適用性声明」、RFC 6936、2013年4月。
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, June 2013.
[RFC6960] Santesson、S.、Myers、M.、Ankney、R.、Malpani、A.、Galperin、S.、and C. Adams、 "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol-OCSP"、RFC 6960、2013年6月。
[RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) Multiple Certificate Status Request Extension", RFC 6961, June 2013.
[RFC6961] Pettersen、Y。、「トランスポート層セキュリティ（TLS）複数の証明書ステータス要求拡張」、RFC 6961、2013年6月。
[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, March 2014.
[RFC7159]ブレイ、T。、「JavaScript Object Notation（JSON）データ交換フォーマット」、RFC 7159、2014年3月。
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, May 2014.
[RFC7228] Bormann、C.、Ersue、M.、and A. Keranen、 "Terminology for Constrained-Node Networks"、RFC 7228、May 2014。
[RTO-CONSIDER] Allman, M., "Retransmission Timeout Considerations", Work in Progress, May 2012.
[RTO-CONSIDER]オールマンM.、「再送信タイムアウトの考慮事項」、作業中、2012年5月。
[W3CXMLSEC] Wenning, R., "Report of the XML Security PAG", W3C XML Security PAG, October 2012, <http://www.w3.org/2011/xmlsec-pag/pagreport.html>.
[W3CXMLSEC] Wenning、R。、「Report of the XML Security PAG」、W3C XML Security PAG、2012年10月、<http://www.w3.org/2011/xmlsec-pag/pagreport.html>。
This section gives a number of short examples with message flows for GET requests. These examples demonstrate the basic operation, the operation in the presence of retransmissions, and multicast.
このセクションでは、GETリクエストのメッセージフローの短い例をいくつか示します。これらの例は、基本的な操作、再送信がある場合の操作、およびマルチキャストを示しています。
Figure 16 shows a basic GET request causing a piggybacked response: The client sends a Confirmable GET request for the resource coap://server/temperature to the server with a Message ID of 0x7d34. The request includes one Uri-Path Option (Delta 0 + 11 = 11, Length 11, Value "temperature"); the Token is left empty. This request is a total of 16 bytes long. A 2.05 (Content) response is returned in the Acknowledgement message that acknowledges the Confirmable request, echoing both the Message ID 0x7d34 and the empty Token value. The response includes a Payload of "22.3 C" and is 11 bytes long.
図16は、ピギーバック応答を引き起こす基本的なGET要求を示しています。クライアントは、リソースcoap：// server / temperatureの確認可能なGET要求をメッセージID 0x7d34でサーバーに送信します。リクエストには1つのUri-Pathオプションが含まれます（デルタ0 + 11 = 11、長さ11、値 "温度"）。トークンは空のままです。このリクエストの長さは合計16バイトです。メッセージID 0x7d34と空のトークン値の両方をエコーして、確認可能要求を確認する2.05（コンテンツ）応答が確認メッセージで返されます。応答には「22.3 C」のペイロードが含まれ、長さは11バイトです。
Client Server
| |
| |
+----->| Header: GET (T=CON, Code=0.01, MID=0x7d34)
| GET | Uri-Path: "temperature"
| |
| |
|<-----+ Header: 2.05 Content (T=ACK, Code=2.05, MID=0x7d34)
| 2.05 | Payload: "22.3 C"
| |
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 0 | 0 | GET=1 | MID=0x7d34 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 11 | 11 | "temperature" (11 B) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 2 | 0 | 2.05=69 | MID=0x7d34 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1| "22.3 C" (6 B) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: Confirmable Request; Piggybacked Response
図16：確認可能なリクエスト。ピギーバックされた応答
Figure 17 shows a similar example, but with the inclusion of an non-empty Token (Value 0x20) in the request and the response, increasing the sizes to 17 and 12 bytes, respectively.
図17は同様の例を示していますが、要求と応答に空でないトークン（値0x20）が含まれ、サイズがそれぞれ17バイトと12バイトに増えています。
Client Server
| |
| |
+----->| Header: GET (T=CON, Code=0.01, MID=0x7d35)
| GET | Token: 0x20
| | Uri-Path: "temperature"
| |
| |
|<-----+ Header: 2.05 Content (T=ACK, Code=2.05, MID=0x7d35)
| 2.05 | Token: 0x20
| | Payload: "22.3 C"
| |
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 0 | 1 | GET=1 | MID=0x7d35 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 11 | 11 | "temperature" (11 B) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 2 | 1 | 2.05=69 | MID=0x7d35 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1| "22.3 C" (6 B) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: Confirmable Request; Piggybacked Response
図17：確認可能なリクエスト。ピギーバックされた応答
In Figure 18, the Confirmable GET request is lost. After ACK_TIMEOUT seconds, the client retransmits the request, resulting in a piggybacked response as in the previous example.
図18では、確認可能なGET要求が失われています。 ACK_TIMEOUT秒後、クライアントはリクエストを再送信し、前の例のようにピギーバックされた応答になります。
Client Server
| |
| |
+----X | Header: GET (T=CON, Code=0.01, MID=0x7d36)
| GET | Token: 0x31
| | Uri-Path: "temperature"
TIMEOUT |
| |
+----->| Header: GET (T=CON, Code=0.01, MID=0x7d36)
| GET | Token: 0x31
| | Uri-Path: "temperature"
| |
| |
|<-----+ Header: 2.05 Content (T=ACK, Code=2.05, MID=0x7d36)
| 2.05 | Token: 0x31
| | Payload: "22.3 C"
| |
Figure 18: Confirmable Request (Retransmitted); Piggybacked Response In Figure 19, the first Acknowledgement message from the server to the client is lost. After ACK_TIMEOUT seconds, the client retransmits the request.
図18：確認可能なリクエスト（再送信）ピギーバック応答図19では、サーバーからクライアントへの最初の確認応答メッセージが失われています。 ACK_TIMEOUT秒後、クライアントはリクエストを再送信します。
Client Server
| |
| |
+----->| Header: GET (T=CON, Code=0.01, MID=0x7d37)
| GET | Token: 0x42
| | Uri-Path: "temperature"
| |
| |
| X----+ Header: 2.05 Content (T=ACK, Code=2.05, MID=0x7d37)
| 2.05 | Token: 0x42
| | Payload: "22.3 C"
TIMEOUT |
| |
+----->| Header: GET (T=CON, Code=0.01, MID=0x7d37)
| GET | Token: 0x42
| | Uri-Path: "temperature"
| |
| |
|<-----+ Header: 2.05 Content (T=ACK, Code=2.05, MID=0x7d37)
| 2.05 | Token: 0x42
| | Payload: "22.3 C"
| |
Figure 19: Confirmable Request; Piggybacked Response (Retransmitted) In Figure 20, the server acknowledges the Confirmable request and sends a 2.05 (Content) response separately in a Confirmable message. Note that the Acknowledgement message and the Confirmable response do not necessarily arrive in the same order as they were sent. The client acknowledges the Confirmable response.
図19：確認可能なリクエスト。 Piggybacked Response（Retransmitted）図20では、サーバーが確認可能要求を確認し、2.05（コンテンツ）応答を確認可能メッセージで個別に送信します。確認メッセージと確認可能応答は、送信されたときと同じ順序で到着するとは限りません。クライアントは確認応答を確認します。
Client Server
| |
| |
+----->| Header: GET (T=CON, Code=0.01, MID=0x7d38)
| GET | Token: 0x53
| | Uri-Path: "temperature"
| |
| |
|<- - -+ Header: (T=ACK, Code=0.00, MID=0x7d38)
| |
| |
|<-----+ Header: 2.05 Content (T=CON, Code=2.05, MID=0xad7b)
| 2.05 | Token: 0x53
| | Payload: "22.3 C"
| |
| |
+- - ->| Header: (T=ACK, Code=0.00, MID=0xad7b)
| |
Figure 20: Confirmable Request; Separate Response
図20：確認可能なリクエスト。個別の応答
Figure 21 shows an example where the client loses its state (e.g., crashes and is rebooted) right after sending a Confirmable request, so the separate response arriving some time later comes unexpected. In this case, the client rejects the Confirmable response with a Reset message. Note that the unexpected ACK is silently ignored.
図21は、Confirmableリクエストを送信した直後にクライアントがその状態を失う（クラッシュして再起動するなど）ため、後で到着する個別の応答が予期しないものになる例を示しています。この場合、クライアントはリセット可能なメッセージで確認可能な応答を拒否します。予期しないACKは黙って無視されることに注意してください。
Client Server
| |
| |
+----->| Header: GET (T=CON, Code=0.01, MID=0x7d39)
| GET | Token: 0x64
| | Uri-Path: "temperature"
CRASH |
| |
|<- - -+ Header: (T=ACK, Code=0.00, MID=0x7d39)
| |
| |
|<-----+ Header: 2.05 Content (T=CON, Code=2.05, MID=0xad7c)
| 2.05 | Token: 0x64
| | Payload: "22.3 C"
| |
| |
+- - ->| Header: (T=RST, Code=0.00, MID=0xad7c)
| |
Figure 21: Confirmable Request; Separate Response (Unexpected)
図21：確認可能なリクエスト。個別の応答（予期しない）
Figure 22 shows a basic GET request where the request and the response are Non-confirmable, so both may be lost without notice.
図22は、要求と応答が確認できないため、通知なしに両方が失われる可能性がある基本的なGET要求を示しています。
Client Server
| |
| |
+----->| Header: GET (T=NON, Code=0.01, MID=0x7d40)
| GET | Token: 0x75
| | Uri-Path: "temperature"
| |
| |
|<-----+ Header: 2.05 Content (T=NON, Code=2.05, MID=0xad7d)
| 2.05 | Token: 0x75
| | Payload: "22.3 C"
| |
Figure 22: Non-confirmable Request; Non-confirmable Response
図22：確認できないリクエスト。確認できない応答
In Figure 23, the client sends a Non-confirmable GET request to a multicast address: all nodes in link-local scope. There are 3 servers on the link: A, B and C. Servers A and B have a matching resource, therefore they send back a Non-confirmable 2.05 (Content) response. The response sent by B is lost. C does not have matching response, therefore it sends a Non-confirmable 4.04 (Not Found) response.
図23では、クライアントは確認不可能なGET要求をマルチキャストアドレス（リンクローカルスコープのすべてのノード）に送信します。リンクには3つのサーバーがあります。A、B、Cです。サーバーAとBには一致するリソースがあるため、確認できない2.05（コンテンツ）応答を返します。 Bから送信された応答は失われます。 Cには一致する応答がないため、確認不可能な4.04（Not Found）応答を送信します。
Client ff02::1 A B C
| | | | |
| | | | |
+------>| | | | Header: GET (T=NON, Code=0.01, MID=0x7d41)
| GET | | | | Token: 0x86
| | | | Uri-Path: "temperature"
| | | |
| | | |
|<------------+ | | Header: 2.05 (T=NON, Code=2.05, MID=0x60b1)
| 2.05 | | | Token: 0x86
| | | | Payload: "22.3 C"
| | | |
| | | |
| X------------+ | Header: 2.05 (T=NON, Code=2.05, MID=0x01a0)
| 2.05 | | | Token: 0x86
| | | | Payload: "20.9 C"
| | | |
| | | |
|<------------------+ Header: 4.04 (T=NON, Code=4.04, MID=0x952a)
| 4.04 | | | Token: 0x86
| | | |
Figure 23: Non-confirmable Request (Multicast); Non-confirmable Response
図23：確認できない要求（マルチキャスト）確認できない応答
The following examples demonstrate different sets of Uri options, and the result after constructing an URI from them. In addition to the options, Section 6.5 refers to the destination IP address and port, but not all paths of the algorithm cause the destination IP address and port to be included in the URI.
次の例は、さまざまなUriオプションのセットと、それらからURIを構築した後の結果を示しています。オプションに加えて、セクション6.5は宛先IPアドレスとポートを参照していますが、アルゴリズムのすべてのパスが宛先IPアドレスとポートをURIに含めるわけではありません。
o Input:
o 入力：
Destination IP Address = [2001:db8::2:1]
Destination UDP Port = 5683
Output:
出力：
coap://[2001:db8::2:1]/
o Input:
o 入力：
Destination IP Address = [2001:db8::2:1]
Destination UDP Port = 5683
Uri-Host = "example.net"
Output:
出力：
coap://example.net/
o Input:
o 入力：
Destination IP Address = [2001:db8::2:1]
Destination UDP Port = 5683
Uri-Host = "example.net"
Uri-Path = ".well-known"
Uri-Path = "core"
Output:
出力：
coap://example.net/.well-known/core
o Input:
o 入力：
Destination IP Address = [2001:db8::2:1]
Destination UDP Port = 5683
Uri-Host = "xn--18j4d.example"
Uri-Path = the string composed of the Unicode characters U+3053
U+3093 U+306b U+3061 U+306f, usually represented in UTF-8 as
E38193E38293E381ABE381A1E381AF hexadecimal
Output:
出力：
coap://xn--18j4d.example/
%E3%81%93%E3%82%93%E3%81%AB%E3%81%A1%E3%81%AF
(The line break has been inserted for readability; it is not part of the URI.)
（改行は読みやすくするために挿入されています。URIの一部ではありません。）
o Input:
o 入力：
Destination IP Address = 198.51.100.1
Destination UDP Port = 61616
Uri-Path = ""
Uri-Path = "/"
Uri-Path = ""
Uri-Path = ""
Uri-Query = "//"
Uri-Query = "?&"
Output:
出力：
coap://198.51.100.1:61616//%2F//?%2F%2F&?%26
Authors' Addresses
著者のアドレス
Zach Shelby ARM 150 Rose Orchard San Jose, CA 95134 USA
Zach Shelby ARM 150 Rose Orchard San Jose、CA 95134 USA
Phone: +1-408-203-9434
EMail: zach.shelby@arm.com
Klaus Hartke Universitaet Bremen TZI Postfach 330440 Bremen D-28359 Germany
Klaus Hartke Universitaet Bremen TZI PO Box 330440ブレーメンD-28359ドイツ
Phone: +49-421-218-63905
EMail: hartke@tzi.org
Carsten Bormann Universitaet Bremen TZI Postfach 330440 Bremen D-28359 Germany
Carsten Bormann Universitaet Bremen TZI PO Box 330440ブレーメンD-28359ドイツ
Phone: +49-421-218-63921
EMail: cabo@tzi.org