[要約] RFC 8323は、CoAP（制約されたアプリケーションプロトコル）をTCP、TLS、およびWebSockets上で使用するための仕様です。このRFCの目的は、CoAPをこれらのプロトコル上で使用することにより、制約のあるデバイス間での効率的な通信を可能にすることです。
Internet Engineering Task Force (IETF) C. Bormann
Request for Comments: 8323 Universitaet Bremen TZI
Updates: 7641, 7959 S. Lemay
Category: Standards Track Zebra Technologies
ISSN: 2070-1721 H. Tschofenig
ARM Ltd.
K. Hartke
Universitaet Bremen TZI
B. Silverajan
Tampere University of Technology
B. Raymor, Ed.
February 2018
CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets
TCP、TLS、およびWebSockets上のCoAP（制約付きアプリケーションプロトコル）
Abstract
概要
The Constrained Application Protocol (CoAP), although inspired by HTTP, was designed to use UDP instead of TCP. The message layer of CoAP over UDP includes support for reliable delivery, simple congestion control, and flow control.
制約付きアプリケーションプロトコル（CoAP）は、HTTPから着想を得ていますが、TCPではなくUDPを使用するように設計されています。 CoAP over UDPのメッセージ層には、信頼性の高い配信、単純な輻輳制御、およびフロー制御のサポートが含まれています。
Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or Transport Layer Security (TLS). This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports. It also formally updates RFC 7641 for use with these transports and RFC 7959 to enable the use of larger messages over a reliable transport.
一部の環境では、TCPやトランスポート層セキュリティ（TLS）などの信頼性の高いトランスポートを介して伝送されるCoAPの可用性が役立ちます。このドキュメントでは、CoAP over TCP、TLS、およびWebSocketsトランスポートを使用するために必要な変更の概要を説明します。また、これらのトランスポートおよびRFC 7959で使用するためにRFC 7641を正式に更新し、信頼性の高いトランスポートでより大きなメッセージを使用できるようにします。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8323.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8323で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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トラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
2. Conventions and Terminology .....................................6
3. CoAP over TCP ...................................................7
3.1. Messaging Model ............................................7
3.2. Message Format .............................................9
3.3. Message Transmission ......................................11
3.4. Connection Health .........................................12
4. CoAP over WebSockets ...........................................13
4.1. Opening Handshake .........................................15
4.2. Message Format ............................................15
4.3. Message Transmission ......................................16
4.4. Connection Health .........................................17
5. Signaling ......................................................17
5.1. Signaling Codes ...........................................17
5.2. Signaling Option Numbers ..................................18
5.3. Capabilities and Settings Messages (CSMs) .................18
5.4. Ping and Pong Messages ....................................20
5.5. Release Messages ..........................................21
5.6. Abort Messages ............................................23
5.7. Signaling Examples ........................................24
6. Block-Wise Transfer and Reliable Transports ....................25
6.1. Example: GET with BERT Blocks .............................27
6.2. Example: PUT with BERT Blocks .............................27
7. Observing Resources over Reliable Transports ...................28
7.1. Notifications and Reordering ..............................28
7.2. Transmission and Acknowledgments ..........................28
7.3. Freshness .................................................28
7.4. Cancellation ..............................................29
8. CoAP over Reliable Transport URIs ..............................29
8.1. coap+tcp URI Scheme .......................................30
8.2. coaps+tcp URI Scheme ......................................31
8.3. coap+ws URI Scheme ........................................32
8.4. coaps+ws URI Scheme .......................................33
8.5. Uri-Host and Uri-Port Options .............................33
8.6. Decomposing URIs into Options .............................34
8.7. Composing URIs from Options ...............................35
9. Securing CoAP ..................................................35
9.1. TLS Binding for CoAP over TCP .............................36
9.2. TLS Usage for CoAP over WebSockets ........................37
10. Security Considerations .......................................37
10.1. Signaling Messages .......................................37
11. IANA Considerations ...........................................38
11.1. Signaling Codes ..........................................38
11.2. CoAP Signaling Option Numbers Registry ...................38
11.3. Service Name and Port Number Registration ................40
11.4. Secure Service Name and Port Number Registration .........40
11.5. URI Scheme Registration ..................................41
11.6. Well-Known URI Suffix Registration .......................43
11.7. ALPN Protocol Identifier .................................44
11.8. WebSocket Subprotocol Registration .......................44
11.9. CoAP Option Numbers Registry .............................44
12. References ....................................................45
12.1. Normative References .....................................45
12.2. Informative References ...................................47
Appendix A. Examples of CoAP over WebSockets ......................49
Acknowledgments ...................................................52
Contributors ......................................................52
Authors' Addresses ................................................53
The Constrained Application Protocol (CoAP) [RFC7252] was designed for Internet of Things (IoT) deployments, assuming that UDP [RFC768] can be used unimpeded as can the Datagram Transport Layer Security (DTLS) protocol [RFC6347] over UDP. The use of CoAP over UDP is focused on simplicity, has a low code footprint, and has a small over-the-wire message size.
制約付きアプリケーションプロトコル（CoAP）[RFC7252]は、UDP [RFC768]がUDPを介したデータグラムトランスポート層セキュリティ（DTLS）プロトコル[RFC6347]と同様に妨げられることなく使用できると想定して、モノのインターネット（IoT）の導入向けに設計されました。 CoAP over UDPの使用は単純さに重点が置かれており、コードフットプリントが低く、有線メッセージサイズが小さいです。
The primary reason for introducing CoAP over TCP [RFC793] and TLS [RFC5246] is that some networks do not forward UDP packets. Complete blocking of UDP happens in between about 2% and 4% of terrestrial access networks, according to [EK2016]. UDP impairment is especially concentrated in enterprise networks and networks in geographic regions with otherwise challenged connectivity. Some networks also rate-limit UDP traffic, as reported in [BK2015], and deployment investigations related to the standardization of Quick UDP Internet Connections (QUIC) revealed numbers around 0.3% [SW2016].
CoAP over TCP [RFC793]およびTLS [RFC5246]を導入する主な理由は、一部のネットワークがUDPパケットを転送しないためです。 [EK2016]によれば、UDPの完全なブロックは、地上アクセスネットワークの約2〜4％で発生します。 UDP障害は、特にエンタープライズネットワークと、他の方法では接続が困難な地理的領域のネットワークに集中しています。 [BK2015]で報告されているように、一部のネットワークはUDPトラフィックもレート制限し、Quick UDP Internet Connections（QUIC）の標準化に関連する導入調査では、約0.3％の数値が明らかになりました[SW2016]。
The introduction of CoAP over TCP also leads to some additional effects that may be desirable in a specific deployment:
CoAP over TCPの導入は、特定の展開で望ましいかもしれないいくつかの追加の効果にもつながります。
o Where NATs are present along the communication path, CoAP over TCP leads to different NAT traversal behavior than CoAP over UDP. NATs often calculate expiration timers based on the transport-layer protocol being used by application protocols. Many NATs maintain TCP-based NAT bindings for longer periods based on the assumption that a transport-layer protocol, such as TCP, offers additional information about the session lifecycle. UDP, on the other hand, does not provide such information to a NAT and timeouts tend to be much shorter [HomeGateway]. According to [HomeGateway], the mean for TCP and UDP NAT binding timeouts is 386 minutes (TCP) and 160 seconds (UDP). Shorter timeout values require keepalive messages to be sent more frequently. Hence, the use of CoAP over TCP requires less-frequent transmission of keepalive messages.
o NATが通信パスに沿って存在する場合、CoAP over TCPは、CoAP over UDPとは異なるNATトラバーサル動作を引き起こします。 NATは多くの場合、アプリケーションプロトコルで使用されているトランスポート層プロトコルに基づいて有効期限タイマーを計算します。多くのNATは、TCPなどのトランスポート層プロトコルがセッションのライフサイクルに関する追加情報を提供するとの想定に基づいて、TCPベースのNATバインディングを長期間維持します。一方、UDPはそのような情報をNATに提供せず、タイムアウトははるかに短くなる傾向があります[HomeGateway]。 [HomeGateway]によると、TCPおよびUDP NATバインディングタイムアウトの平均は386分（TCP）および160秒（UDP）です。タイムアウト値を短くすると、キープアライブメッセージをより頻繁に送信する必要があります。したがって、CoAP over TCPを使用するには、キープアライブメッセージの送信頻度を減らす必要があります。
o TCP utilizes mechanisms for congestion control and flow control that are more sophisticated than the default mechanisms provided by CoAP over UDP; these TCP mechanisms are useful for the transfer of larger payloads. (However, work is ongoing to add advanced congestion control to CoAP over UDP as well; see [CoCoA].)
o TCPは、CoAP over UDPによって提供されるデフォルトのメカニズムよりも高度な輻輳制御およびフロー制御のメカニズムを利用します。これらのTCPメカニズムは、より大きなペイロードの転送に役立ちます。 （ただし、CoAP over UDPにも高度な輻輳制御を追加する作業が進行中です。[CoCoA]を参照してください。）
Note that the use of CoAP over UDP (and CoAP over DTLS over UDP) is still the recommended transport for use in constrained node networks, particularly when used in concert with block-wise transfer. CoAP over TCP is applicable for those cases where the networking infrastructure leaves no other choice. The use of CoAP over TCP leads to a larger code size, more round trips, increased RAM requirements, and larger packet sizes. Developers implementing CoAP over TCP are encouraged to consult [TCP-in-IoT] for guidance on low-footprint TCP implementations for IoT devices.
CoAP over UDP（およびCoAP over DTLS over UDP）の使用は、特にブロック単位の転送と組み合わせて使用する場合、制約付きノードネットワークでの使用に推奨されるトランスポートであることに注意してください。 CoAP over TCPは、ネットワークインフラストラクチャが他に選択肢を残さない場合に適用できます。 CoAP over TCPを使用すると、コードサイズが大きくなり、ラウンドトリップが多くなり、RAM要件が増加し、パケットサイズが大きくなります。 CoAP over TCPを実装する開発者は、IoTデバイス用の設置面積の小さいTCP実装のガイダンスについて[TCP-in-IoT]を参照することをお勧めします。
Standards based on CoAP, such as Lightweight Machine to Machine [LWM2M], currently use CoAP over UDP as a transport; adding support for CoAP over TCP enables them to address the issues above for specific deployments and to protect investments in existing CoAP implementations and deployments.
Lightweight Machine to Machine [LWM2M]などのCoAPに基づく標準では、現在、CoAP over UDPをトランスポートとして使用しています。 CoAP over TCPのサポートを追加することで、特定の展開に関する上記の問題に対処し、既存のCoAPの実装と展開への投資を保護できます。
Although HTTP/2 could also potentially address the need for enterprise firewall traversal, there would be additional costs and delays introduced by such a transition from CoAP to HTTP/2. Currently, there are also fewer HTTP/2 implementations available for constrained devices in comparison to CoAP. Since CoAP also supports group communication using IP-layer multicast and unreliable communication, IoT devices would have to support HTTP/2 in addition to CoAP.
HTTP / 2はエンタープライズファイアウォールトラバーサルのニーズにも対応できる可能性がありますが、CoAPからHTTP / 2へのこのような移行により、追加のコストと遅延が発生します。現在、CoAPと比較して、制約されたデバイスで使用できるHTTP / 2実装も少なくなっています。 CoAPはIPレイヤーマルチキャストを使用したグループ通信と信頼性の低い通信もサポートしているため、IoTデバイスはCoAPに加えてHTTP / 2をサポートする必要があります。
Furthermore, CoAP may be integrated into a web environment where the front end uses CoAP over UDP from IoT devices to a cloud infrastructure and then CoAP over TCP between the back-end services. A TCP-to-UDP gateway can be used at the cloud boundary to communicate with the UDP-based IoT device.
さらに、CoAPは、フロントエンドがIoTデバイスからクラウドインフラストラクチャへのUDP上のCoAPを使用し、バックエンドサービス間でTCP上のCoAPを使用するWeb環境に統合できます。 TCP-to-UDPゲートウェイをクラウド境界で使用して、UDPベースのIoTデバイスと通信できます。
Finally, CoAP applications running inside a web browser may be without access to connectivity other than HTTP. In this case, the WebSocket Protocol [RFC6455] may be used to transport CoAP requests and responses, as opposed to cross-proxying them via HTTP to an HTTP-to-CoAP cross-proxy. This preserves the functionality of CoAP without translation -- in particular, the Observe Option [RFC7641].
最後に、Webブラウザー内で実行されているCoAPアプリケーションは、HTTP以外の接続にアクセスできない場合があります。この場合、WebSocketプロトコル[RFC6455]を使用して、CoAP要求と応答をHTTP経由でHTTPからCoAPへのクロスプロキシにクロスプロキシするのではなく、転送することができます。これにより、変換なしでCoAPの機能が保持されます。特に、監視オプション[RFC7641]が保持されます。
To address the above-mentioned deployment requirements, this document defines how to transport CoAP over TCP, CoAP over TLS, and CoAP over WebSockets. For these cases, the reliability offered by the transport protocol subsumes the reliability functions of the message layer used for CoAP over UDP. (Note that for both a reliable transport and the message layer for CoAP over UDP, the reliability offered is per transport hop: where proxies -- see Sections 5.7 and 10 of [RFC7252] -- are involved, that layer's reliability function does not extend end to end.) Figure 1 illustrates the layering:
上記の導入要件に対処するために、このドキュメントでは、CoAP over TCP、CoAP over TLS、およびCoAP over WebSocketsを転送する方法を定義します。これらの場合、トランスポートプロトコルによって提供される信頼性は、CoAP over UDPに使用されるメッセージレイヤーの信頼性機能を包括します。 （CoAP over UDPの信頼性の高いトランスポートとメッセージレイヤーの両方について、提供される信頼性はトランスポートホップごとです：プロキシ（[RFC7252]のセクション5.7および10を参照）が関係する場合、そのレイヤーの信頼性機能は拡張されません。エンドツーエンド。）図1は、階層化を示しています。
+--------------------------------+
| Application |
+--------------------------------+
+--------------------------------+
| Requests/Responses/Signaling | CoAP (RFC 7252) / This Document
|--------------------------------|
| Message Framing | This Document
+--------------------------------+
| Reliable Transport |
+--------------------------------+
Figure 1: Layering of CoAP over Reliable Transports
図1：信頼できるトランスポート上のCoAPの階層化
This document specifies how to access resources using CoAP requests and responses over the TCP, TLS, and WebSocket protocols. This allows connectivity-limited applications to obtain end-to-end CoAP connectivity either (1) by communicating CoAP directly with a CoAP server accessible over a TCP, TLS, or WebSocket connection or (2) via a CoAP intermediary that proxies CoAP requests and responses between different transports, such as between WebSockets and UDP.
このドキュメントでは、TCP、TLS、およびWebSocketプロトコルを介してCoAP要求と応答を使用してリソースにアクセスする方法を指定します。これにより、接続が制限されたアプリケーションは、（1）TCP、TLS、またはWebSocket接続を介してアクセス可能なCoAPサーバーとCoAPを直接通信することによって、または（2）CoAP要求をプロキシするCoAP仲介を介して、エンドツーエンドのCoAP接続を取得できます。 WebSocketsとUDPの間など、異なるトランスポート間の応答。
Section 7 updates [RFC7641] ("Observing Resources in the Constrained Application Protocol (CoAP)") for use with CoAP over reliable transports. [RFC7641] is an extension to CoAP that enables CoAP clients to "observe" a resource on a CoAP server. (The CoAP client retrieves a representation of a resource and registers to be notified by the CoAP server when the representation is updated.)
セクション7は、信頼できるトランスポート上でCoAPを使用するために[RFC7641]（ "Constrained Application Protocol（CoAP）のリソースの監視"）を更新します。 [RFC7641]はCoAPの拡張機能であり、CoAPクライアントがCoAPサーバー上のリソースを「監視」できるようにします。 （CoAPクライアントは、リソースの表現を取得し、表現が更新されたときにCoAPサーバーから通知を受けるように登録します。）
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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
This document assumes that readers are familiar with the terms and concepts that are used in [RFC6455], [RFC7252], [RFC7641], and [RFC7959].
このドキュメントは、読者が[RFC6455]、[RFC7252]、[RFC7641]、および[RFC7959]で使用される用語と概念に精通していることを前提としています。
The term "reliable transport" is used only to refer to transport protocols, such as TCP, that provide reliable and ordered delivery of a byte stream.
「信頼性の高いトランスポート」という用語は、バイトストリームの信頼性の高い順序付けられた配信を提供するTCPなどのトランスポートプロトコルを指す場合にのみ使用されます。
Block-wise Extension for Reliable Transport (BERT): Extends [RFC7959] to enable the use of larger messages over a reliable transport.
信頼性の高いトランスポートのブロック単位の拡張（BERT）：[RFC7959]を拡張して、信頼性の高いトランスポートを介してより大きなメッセージを使用できるようにします。
BERT Option: A Block1 or Block2 option that includes an SZX (block size) value of 7.
BERTオプション：7のSZX（ブロックサイズ）値を含むBlock1またはBlock2オプション。
BERT Block: The payload of a CoAP message that is affected by a BERT Option in descriptive usage (see Section 2.1 of [RFC7959]).
BERTブロック：記述的な使用においてBERTオプションの影響を受けるCoAPメッセージのペイロード（[RFC7959]のセクション2.1を参照）。
Transport Connection: Underlying reliable byte-stream connection, as directly provided by TCP or indirectly provided via TLS or WebSockets.
トランスポート接続：TCPによって直接提供されるか、TLSまたはWebSocketを介して間接的に提供される、基になる信頼性の高いバイトストリーム接続。
Connection: Transport Connection, unless explicitly qualified otherwise.
接続：特に明記されていない限り、トランスポート接続。
Connection Initiator: The peer that opens a Transport Connection, i.e., the TCP active opener, TLS client, or WebSocket client.
接続イニシエーター：トランスポート接続を開くピア、つまり、TCPアクティブオープナー、TLSクライアント、またはWebSocketクライアント。
Connection Acceptor: The peer that accepts the Transport Connection opened by the other peer, i.e., the TCP passive opener, TLS server, or WebSocket server.
接続アクセプター：TCPパッシブオープナー、TLSサーバー、またはWebSocketサーバーなど、他のピアによって開かれたトランスポート接続を受け入れるピア。
The request/response interaction model of CoAP over TCP is the same as CoAP over UDP. The primary differences are in the message layer. The message layer of CoAP over UDP supports optional reliability by defining four types of messages: Confirmable, Non-confirmable, Acknowledgment, and Reset. In addition, messages include a Message ID to relate Acknowledgments to Confirmable messages and to detect duplicate messages.
CoAP over TCPの要求/応答対話モデルは、CoAP over UDPと同じです。主な違いはメッセージ層にあります。 CoAP over UDPのメッセージ層は、確認可能、確認不可能、確認応答、およびリセットの4種類のメッセージを定義することにより、オプションの信頼性をサポートします。さらに、メッセージには確認応答を確認可能なメッセージに関連付け、重複メッセージを検出するためのメッセージIDが含まれています。
Management of the transport connections is left to the application, i.e., the present specification does not describe how an application decides to open a connection or to reopen another one in the presence of failures (or what it would deem to be a failure; see also Section 5.4). In particular, the Connection Initiator need not be the client of the first request placed on the connection. Some implementations will want to implement dynamic connection management similar to the technique described in Section 6 of [RFC7230] for HTTP: opening a connection when the first client request is ready to be sent, reusing that connection for subsequent messages until no more messages are sent for a certain time period and no requests are outstanding (possibly with a configurable idle time), and then starting a release process (orderly shutdown) (see Section 5.5). In implementations of this kind, connection releases or aborts may not be indicated as errors to the application but may simply be handled by automatic reconnection once the need arises again. Other implementations may be based on configured connections that are kept open continuously and lead to management system notifications on release or abort. The protocol defined in the present specification is intended to work with either model (or other, application-specific connection management models).
トランスポート接続の管理はアプリケーションに委ねられます。つまり、この仕様では、障害（または障害と見なされるもの）が存在する場合に、アプリケーションが接続を開く、または別の接続を開くことを決定する方法については説明していません。セクション5.4）。特に、接続イニシエーターは、接続に配置された最初の要求のクライアントである必要はありません。一部の実装では、HTTPの[RFC7230]のセクション6で説明されている手法と同様の動的接続管理を実装する必要があります。最初のクライアント要求を送信する準備ができたときに接続を開き、メッセージが送信されなくなるまで後続のメッセージにその接続を再利用します一定の期間、未解決のリクエストがない（アイドル時間が設定可能である可能性があります）後、リリースプロセスを開始します（通常のシャットダウン）（セクション5.5を参照）。この種類の実装では、接続の解放または中止はアプリケーションへのエラーとして示されず、必要が再び発生したときに自動再接続によって単に処理される場合があります。他の実装は、継続的に開いたままにされ、解放または中止の管理システム通知につながる構成された接続に基づく場合があります。本明細書で定義されているプロトコルは、いずれかのモデル（または他のアプリケーション固有の接続管理モデル）で機能することを目的としています。
Conceptually, CoAP over TCP replaces most of the message layer of CoAP over UDP with a framing mechanism on top of the byte stream provided by TCP/TLS, conveying the length information for each message that, on datagram transports, is provided by the UDP/DTLS datagram layer.
概念的には、CoAP over TCPは、CoAP over UDPのほとんどのメッセージレイヤーをTCP / TLSによって提供されるバイトストリーム上のフレーミングメカニズムに置き換え、データグラムトランスポート上でUDP /によって提供される各メッセージの長さ情報を伝達します。 DTLSデータグラム層。
TCP ensures reliable message transmission, so the message layer of CoAP over TCP is not required to support Acknowledgment messages or to detect duplicate messages. As a result, both the Type and Message ID fields are no longer required and are removed from the message format for CoAP over TCP.
TCPは信頼性のあるメッセージ送信を保証するため、CoAP over TCPのメッセージ層は、確認応答メッセージのサポートや重複メッセージの検出に必要ありません。その結果、タイプフィールドとメッセージIDフィールドの両方が不要になり、CoAP over TCPのメッセージフォーマットから削除されました。
Figure 2 illustrates the difference between CoAP over UDP and CoAP over reliable transports. The removed Type and Message ID fields are indicated by dashes.
図2は、CoAP over UDPとCoAP over信任転送の違いを示しています。削除されたタイプおよびメッセージIDフィールドはダッシュで示されます。
CoAP Client CoAP Server CoAP Client CoAP Server
| | | |
| CON [0xbc90] | | (-------) [------] |
| GET /temperature | | GET /temperature |
| (Token 0x71) | | (Token 0x71) |
+------------------->| +------------------->|
| | | |
| ACK [0xbc90] | | (-------) [------] |
| 2.05 Content | | 2.05 Content |
| (Token 0x71) | | (Token 0x71) |
| "22.5 C" | | "22.5 C" |
|<-------------------+ |<-------------------+
| | | |
CoAP over UDP CoAP over reliable transports
信頼できるトランスポート上のCoAP over UDP CoAP
Figure 2: Comparison between CoAP over Unreliable Transports and CoAP over Reliable Transports
図2：CoAP over Unliliable TransportsとCoAP over Reliable Transportsの比較
The CoAP message format defined in [RFC7252], as shown in Figure 3, relies on the datagram transport (UDP, or DTLS over UDP) for keeping the individual messages separate and for providing length information.
[RFC7252]で定義されているCoAPメッセージフォーマットは、図3に示すように、個々のメッセージを個別に保持し、長さ情報を提供するために、データグラム転送（UDPまたはDTLS over UDP）に依存しています。
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 3: CoAP Message Format as Defined in RFC 7252
図3：RFC 7252で定義されているCoAPメッセージフォーマット
The message format for CoAP over TCP is very similar to the format specified for CoAP over UDP. The differences are as follows:
CoAP over TCPのメッセージフォーマットは、CoAP over UDPに指定されたフォーマットとよく似ています。違いは次のとおりです。
o Since the underlying TCP connection provides retransmissions and deduplication, there is no need for the reliability mechanisms provided by CoAP over UDP. The Type (T) and Message ID fields in the CoAP message header are elided.
o 基礎となるTCP接続は再送信と重複排除を提供するため、CoAP over UDPによって提供される信頼性メカニズムは必要ありません。 CoAPメッセージヘッダーのタイプ（T）およびメッセージIDフィールドは省略されています。
o The Version (Vers) field is elided as well. In contrast to the message format of CoAP over UDP, the message format for CoAP over TCP does not include a version number. CoAP is defined in [RFC7252] with a version number of 1. At this time, there is no known reason to support version numbers different from 1. If version negotiation needs to be addressed in the future, Capabilities and Settings Messages (CSMs) (see Section 5.3) have been specifically designed to enable such a potential feature.
o バージョン（Vers）フィールドも省略されます。 CoAP over UDPのメッセージフォーマットとは異なり、CoAP over TCPのメッセージフォーマットにはバージョン番号が含まれていません。 CoAPは[RFC7252]でバージョン番号1で定義されています。現時点では、1とは異なるバージョン番号をサポートする既知の理由はありません。将来バージョンネゴシエーションに対処する必要がある場合は、機能と設定メッセージ（CSM）（セクション5.3を参照）は、このような潜在的な機能を有効にするように特別に設計されています。
o In a stream-oriented transport protocol such as TCP, a form of message delimitation is needed. For this purpose, CoAP over TCP introduces a length field with variable size. Figure 4 shows the adjusted CoAP message format with a modified structure for the fixed header (first 4 bytes of the header for CoAP over UDP), which includes the length information of variable size.
o TCPなどのストリーム指向のトランスポートプロトコルでは、ある形式のメッセージ区切りが必要です。この目的のために、CoAP over TCPでは、可変サイズの長さフィールドが導入されています。図4は、可変ヘッダーの長さ情報を含む、固定ヘッダー（CoAP over UDPのヘッダーの最初の4バイト）の構造が変更された調整済み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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Len | TKL | Extended Length (if any, as chosen by Len) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Token (if any, TKL bytes) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1| Payload (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: CoAP Frame for Reliable Transports
図4：信頼性の高いトランスポートのCoAPフレーム
Length (Len): 4-bit unsigned integer. A value between 0 and 12 inclusive indicates the length of the message in bytes, starting with the first bit of the Options field. Three values are reserved for special constructs:
長さ（Len）：4ビットの符号なし整数。 0から12までの値は、オプションフィールドの最初のビットから始まるメッセージの長さをバイトで示します。 3つの値は、特別な構成のために予約されています。
13: An 8-bit unsigned integer (Extended Length) follows the initial byte and indicates the length of options/payload minus 13.
13：8ビットの符号なし整数（拡張長）は最初のバイトに続き、オプション/ペイロードの長さから13を引いた長さを示します。
14: A 16-bit unsigned integer (Extended Length) in network byte order follows the initial byte and indicates the length of options/payload minus 269.
14：ネットワークバイトオーダーの16ビット符号なし整数（拡張長）は、最初のバイトに続き、オプション/ペイロードの長さから269を引いたものを示します。
15: A 32-bit unsigned integer (Extended Length) in network byte order follows the initial byte and indicates the length of options/payload minus 65805.
15：ネットワークバイトオーダーの32ビット符号なし整数（拡張長）は、最初のバイトの後に続き、オプション/ペイロードの長さから65805を引いた値を示します。
The encoding of the Length field is modeled after the Option Length field of the CoAP Options (see Section 3.1 of [RFC7252]).
長さフィールドのエンコーディングは、CoAPオプションのオプション長さフィールドをモデルにしています（[RFC7252]のセクション3.1を参照）。
For simplicity, a Payload Marker (0xFF) is shown in Figure 4; the Payload Marker indicates the start of the optional payload and is absent for zero-length payloads (see Section 3 of [RFC7252]). (If present, the Payload Marker is included in the message length, which counts from the start of the Options field to the end of the Payload field.) For example, a CoAP message just containing a 2.03 code with the Token 7f and no options or payload is encoded as shown in Figure 5.
簡単にするために、ペイロードマーカー（0xFF）を図4に示します。ペイロードマーカーは、オプションのペイロードの開始を示し、長さがゼロのペイロードにはありません（[RFC7252]のセクション3を参照）。 （存在する場合、ペイロードマーカーはメッセージの長さに含まれ、オプションフィールドの先頭からペイロードフィールドの末尾までカウントされます。）たとえば、トークン7fを含む2.03コードのみを含み、オプションがないCoAPメッセージまたはペイロードは、図5に示すようにエンコードされます。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x01 | 0x43 | 0x7f |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Len = 0 ------> 0x01
TKL = 1 ___/
Code = 2.03 --> 0x43
Token = 0x7f
Figure 5: CoAP Message with No Options or Payload
図5：オプションまたはペイロードのないCoAPメッセージ
The semantics of the other CoAP header fields are left unchanged.
他のCoAPヘッダーフィールドのセマンティクスは変更されません。
Once a Transport Connection is established, each endpoint MUST send a CSM (see Section 5.3) as its first message on the connection. This message establishes the initial settings and capabilities for the endpoint, such as maximum message size or support for block-wise transfers. The absence of options in the CSM indicates that base values are assumed.
トランスポート接続が確立されると、各エンドポイントは接続の最初のメッセージとしてCSM（セクション5.3を参照）を送信する必要があります。このメッセージは、最大メッセージサイズやブロック単位の転送のサポートなど、エンドポイントの初期設定と機能を確立します。 CSMにオプションがないことは、ベース値が想定されていることを示しています。
To avoid a deadlock, the Connection Initiator MUST NOT wait for the Connection Acceptor to send its initial CSM before sending its own initial CSM. Conversely, the Connection Acceptor MAY wait for the Connection Initiator to send its initial CSM before sending its own initial CSM.
デッドロックを回避するために、接続イニシエーターは、独自の初期CSMを送信する前に、接続アクセプターが初期CSMを送信するのを待機してはなりません（MUST NOT）。逆に、接続アクセプターは、独自の初期CSMを送信する前に、接続イニシエーターが初期CSMを送信するのを待つ場合があります。
To avoid unnecessary latency, a Connection Initiator MAY send additional messages after its initial CSM without waiting to receive the Connection Acceptor's CSM; however, it is important to note that the Connection Acceptor's CSM might indicate capabilities that impact how the Connection Initiator is expected to communicate with the Connection Acceptor. For example, the Connection Acceptor's CSM could indicate a Max-Message-Size Option (see Section 5.3.1) that is smaller than the base value (1152) in order to limit both buffering requirements and head-of-line blocking.
不必要な待ち時間を回避するために、接続イニシエーターは、接続アクセプターのCSMの受信を待たずに、最初のCSMの後に追加のメッセージを送信できます（MAY）。ただし、接続アクセプターのCSMは、接続イニシエーターが接続アクセプターと通信することが期待される方法に影響を与える機能を示す可能性があることに注意することが重要です。たとえば、バッファリング要件と行頭ブロッキングの両方を制限するために、接続アクセプターのCSMは、ベース値（1152）よりも小さいMax-Message-Sizeオプション（セクション5.3.1を参照）を示すことができます。
Endpoints MUST treat a missing or invalid CSM as a connection error and abort the connection (see Section 5.6).
エンドポイントは、欠落または無効なCSMを接続エラーとして扱い、接続を中止する必要があります（セクション5.6を参照）。
CoAP requests and responses are exchanged asynchronously over the Transport Connection. A CoAP client can send multiple requests without waiting for a response, and the CoAP server can return responses in any order. Responses MUST be returned over the same connection as the originating request. Each concurrent request is differentiated by its Token, which is scoped locally to the connection.
CoAP要求と応答は、トランスポート接続を介して非同期で交換されます。 CoAPクライアントは応答を待たずに複数の要求を送信でき、CoAPサーバーは任意の順序で応答を返すことができます。応答は、元の要求と同じ接続を介して返される必要があります。各同時要求は、ローカルで接続をスコープとするトークンによって区別されます。
The Transport Connection is bidirectional, so requests can be sent by both the entity that established the connection (Connection Initiator) and the remote host (Connection Acceptor). If one side does not implement a CoAP server, an error response MUST be returned for all CoAP requests from the other side. The simplest approach is to always return 5.01 (Not Implemented). A more elaborate mock server could also return 4.xx responses such as 4.04 (Not Found) or 4.02 (Bad Option) where appropriate.
トランスポート接続は双方向であるため、接続を確立したエンティティ（接続イニシエーター）とリモートホスト（接続アクセプター）の両方から要求を送信できます。一方がCoAPサーバーを実装していない場合、他方からのすべてのCoAP要求に対してエラー応答を返さなければなりません（MUST）。最も単純なアプローチは、常に5.01（未実装）を返すことです。より複雑なモックサーバーは、必要に応じて、4.04（Not Found）や4.02（Bad Option）などの4.xx応答を返すこともできます。
Retransmission and deduplication of messages are provided by TCP.
メッセージの再送信と重複排除はTCPによって提供されます。
Empty messages (Code 0.00) can always be sent and MUST be ignored by the recipient. This provides a basic keepalive function that can refresh NAT bindings.
空のメッセージ（コード0.00）は常に送信でき、受信者は無視する必要があります。これにより、NATバインディングを更新できる基本的なキープアライブ機能が提供されます。
If a CoAP client does not receive any response for some time after sending a CoAP request (or, similarly, when a client observes a resource and it does not receive any notification for some time), it can send a CoAP Ping Signaling message (see Section 5.4) to test the Transport Connection and verify that the CoAP server is responsive.
CoAPクライアントがCoAP要求を送信してからしばらくの間応答を受信しない場合（または、同様に、クライアントがリソースを監視し、しばらくの間通知を受信しない場合）は、CoAP Pingシグナリングメッセージを送信できます（を参照）セクション5.4）トランスポート接続をテストし、CoAPサーバーが応答することを確認します。
When the underlying Transport Connection is closed or reset, the signaling state and any observation state (see Section 7.4) associated with the connection are removed. Messages that are in flight may or may not be lost.
基になるトランスポート接続が閉じられるかリセットされると、その接続に関連付けられている信号状態と監視状態（7.4項を参照）が削除されます。処理中のメッセージは失われる場合と失われない場合があります。
CoAP over WebSockets is intentionally similar to CoAP over TCP; therefore, this section only specifies the differences between the transports.
CoAP over WebSocketsは、意図的にCoAP over TCPに似ています。したがって、このセクションでは、トランスポート間の違いのみを指定します。
CoAP over WebSockets can be used in a number of configurations. The most basic configuration is a CoAP client retrieving or updating a CoAP resource located on a CoAP server that exposes a WebSocket endpoint (see Figure 6). The CoAP client acts as the WebSocket client, establishes a WebSocket connection, and sends a CoAP request, to which the CoAP server returns a CoAP response. The WebSocket connection can be used for any number of requests.
CoAP over WebSocketsは、さまざまな構成で使用できます。最も基本的な構成は、WebSocketエンドポイントを公開するCoAPサーバーにあるCoAPリソースを取得または更新するCoAPクライアントです（図6を参照）。 CoAPクライアントはWebSocketクライアントとして機能し、WebSocket接続を確立し、CoAPリクエストを送信します。CoAPリクエストには、CoAPサーバーがCoAP応答を返します。 WebSocket接続は、任意の数の要求に使用できます。
___________ ___________
| | | |
| _|___ requests ___|_ |
| CoAP / \ \ -------------> / / \ CoAP |
| Client \__/__/ <------------- \__\__/ Server |
| | responses | |
|___________| |___________|
WebSocket =============> WebSocket
Client Connection Server
Figure 6: CoAP Client (WebSocket Client) Accesses CoAP Server (WebSocket Server)
図6：CoAPクライアント（WebSocketクライアント）がCoAPサーバー（WebSocketサーバー）にアクセスする
The challenge with this configuration is how to identify a resource in the namespace of the CoAP server. When the WebSocket Protocol is used by a dedicated client directly (i.e., not from a web page through a web browser), the client can connect to any WebSocket endpoint. Sections 8.3 and 8.4 define new URI schemes that enable the client to identify both a WebSocket endpoint and the path and query of the CoAP resource within that endpoint.
この構成の課題は、CoAPサーバーの名前空間でリソースを識別する方法です。専用クライアントがWebSocketプロトコルを直接（つまり、WebブラウザからではなくWebページから）使用する場合、クライアントは任意のWebSocketエンドポイントに接続できます。セクション8.3および8.4は、クライアントがWebSocketエンドポイントとそのエンドポイント内のCoAPリソースのパスとクエリの両方を識別できるようにする新しいURIスキームを定義します。
Another possible configuration is to set up a CoAP forward proxy at the WebSocket endpoint. Depending on what transports are available to the proxy, it could forward the request to a CoAP server with a CoAP UDP endpoint (Figure 7), an SMS endpoint (a.k.a. mobile phone), or even another WebSocket endpoint. The CoAP client specifies the resource to be updated or retrieved in the Proxy-Uri Option.
別の可能な構成は、WebSocketエンドポイントでCoAPフォワードプロキシをセットアップすることです。プロキシで使用できるトランスポートによっては、CoAP UDPエンドポイント（図7）、SMSエンドポイント（別名、携帯電話）、または別のWebSocketエンドポイントを使用して、リクエストをCoAPサーバーに転送できます。 CoAPクライアントは、Proxy-Uriオプションで更新または取得するリソースを指定します。
___________ ___________ ___________
| | | | | |
| _|___ ___|_ _|___ ___|_ |
| CoAP / \ \ ---> / / \ CoAP / \ \ ---> / / \ CoAP |
| Client \__/__/ <--- \__\__/ Proxy \__/__/ <--- \__\__/ Server |
| | | | | |
|___________| |___________| |___________|
WebSocket ===> WebSocket UDP UDP
Client Server Client Server
Figure 7: CoAP Client (WebSocket Client) Accesses CoAP Server (UDP Server) via a CoAP Proxy (WebSocket Server / UDP Client)
図7：CoAPクライアント（WebSocketクライアント）は、CoAPプロキシ（WebSocketサーバー/ UDPクライアント）を介してCoAPサーバー（UDPサーバー）にアクセスします
A third possible configuration is a CoAP server running inside a web browser (Figure 8). The web browser initially connects to a WebSocket endpoint and is then reachable through the WebSocket server. When no connection exists, the CoAP server is unreachable. Because the WebSocket server is the only way to reach the CoAP server, the CoAP proxy should be a reverse-proxy.
3番目に可能な構成は、Webブラウザー内で実行されるCoAPサーバーです（図8）。 Webブラウザーは最初にWebSocketエンドポイントに接続し、その後WebSocketサーバーを介して到達可能です。接続が存在しない場合、CoAPサーバーに到達できません。 WebSocketサーバーがCoAPサーバーに到達する唯一の方法であるため、CoAPプロキシはリバースプロキシである必要があります。
___________ ___________ ___________
| | | | | |
| _|___ ___|_ _|___ ___|_ |
| CoAP / \ \ ---> / / \ CoAP / / \ ---> / \ \ CoAP |
| Client \__/__/ <--- \__\__/ Proxy \__\__/ <--- \__/__/ Server |
| | | | | |
|___________| |___________| |___________|
UDP UDP WebSocket <=== WebSocket
Client Server Server Client
Figure 8: CoAP Client (UDP Client) Accesses CoAP Server (WebSocket Client) via a CoAP Proxy (UDP Server / WebSocket Server)
図8：CoAPクライアント（UDPクライアント）はCoAPプロキシ（UDPサーバー/ WebSocketサーバー）を介してCoAPサーバー（WebSocketクライアント）にアクセスします
Further configurations are possible, including those where a WebSocket connection is established through an HTTP proxy.
HTTPプロキシを介してWebSocket接続が確立されるものを含む、さらなる構成が可能です。
Before CoAP requests and responses are exchanged, a WebSocket connection is established as defined in Section 4 of [RFC6455]. Figure 9 shows an example.
CoAPリクエストとレスポンスが交換される前に、[RFC6455]のセクション4で定義されているようにWebSocket接続が確立されます。図9に例を示します。
The WebSocket client MUST include the subprotocol name "coap" in the list of protocols; this indicates support for the protocol defined in this document.
WebSocketクライアントは、プロトコルのリストにサブプロトコル名「coap」を含める必要があります。これは、このドキュメントで定義されているプロトコルのサポートを示しています。
The WebSocket client includes the hostname of the WebSocket server in the Host header field of its handshake as per [RFC6455]. The Host header field also indicates the default value of the Uri-Host Option in requests from the WebSocket client to the WebSocket server.
WebSocketクライアントは、[RFC6455]に従って、ハンドシェイクのHostヘッダーフィールドにWebSocketサーバーのホスト名を含めます。 Hostヘッダーフィールドは、WebSocketクライアントからWebSocketサーバーへのリクエストのUri-Hostオプションのデフォルト値も示します。
GET /.well-known/coap HTTP/1.1
Host: example.org
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Protocol: coap
Sec-WebSocket-Version: 13
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: coap
Figure 9: Example of an Opening Handshake
図9：オープニングハンドシェイクの例
Once a WebSocket connection is established, CoAP requests and responses can be exchanged as WebSocket messages. Since CoAP uses a binary message format, the messages are transmitted in binary data frames as specified in Sections 5 and 6 of [RFC6455].
WebSocket接続が確立されると、CoAP要求と応答をWebSocketメッセージとして交換できます。 CoAPはバイナリメッセージ形式を使用するため、[RFC6455]のセクション5および6で指定されているように、メッセージはバイナリデータフレームで送信されます。
The message format shown in Figure 10 is the same as the message format for CoAP over TCP (see Section 3.2), with one change: the Length (Len) field MUST be set to zero, because the WebSocket frame contains the length.
図10に示すメッセージ形式は、CoAP over TCPのメッセージ形式（セクション3.2を参照）と同じですが、WebSocketフレームには長さが含まれているため、長さ（Len）フィールドをゼロに設定する必要があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Len=0 | TKL | Code | Token (TKL bytes) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1| Payload (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: CoAP Message Format over WebSockets
図10：WebSockets上のCoAPメッセージフォーマット
As with CoAP over TCP, the message format for CoAP over WebSockets eliminates the Version field defined in CoAP over UDP. If CoAP version negotiation is required in the future, CoAP over WebSockets can address the requirement by defining a new subprotocol identifier that is negotiated during the opening handshake.
CoAP over TCPと同様に、CoAP over WebSocketsのメッセージ形式では、CoAP over UDPで定義されたバージョンフィールドが削除されます。 CoAPバージョンネゴシエーションが将来必要になる場合、CoAP over WebSocketsは、開始ハンドシェイク中にネゴシエートされる新しいサブプロトコル識別子を定義することにより、要件に対処できます。
Requests and responses can be fragmented as specified in Section 5.4 of [RFC6455], though typically they are sent unfragmented, as they tend to be small and fully buffered before transmission. The WebSocket Protocol does not provide means for multiplexing. If it is not desirable for a large message to monopolize the connection, requests and responses can be transferred in a block-wise fashion as defined in [RFC7959].
リクエストとレスポンスは、[RFC6455]のセクション5.4で指定されているようにフラグメント化できますが、送信前に小さく、完全にバッファリングされる傾向があるため、通常はフラグメント化されずに送信されます。 WebSocketプロトコルは多重化の手段を提供しません。大きなメッセージが接続を独占することが望ましくない場合は、[RFC7959]で定義されているように、要求と応答をブロック単位で転送できます。
As with CoAP over TCP, each endpoint MUST send a CSM (see Section 5.3) as its first message on the WebSocket connection.
CoAP over TCPと同様に、各エンドポイントはWebSocket接続の最初のメッセージとしてCSM（セクション5.3を参照）を送信する必要があります。
CoAP requests and responses are exchanged asynchronously over the WebSocket connection. A CoAP client can send multiple requests without waiting for a response, and the CoAP server can return responses in any order. Responses MUST be returned over the same connection as the originating request. Each concurrent request is differentiated by its Token, which is scoped locally to the connection.
CoAP要求と応答は、WebSocket接続を介して非同期的に交換されます。 CoAPクライアントは応答を待たずに複数の要求を送信でき、CoAPサーバーは任意の順序で応答を返すことができます。応答は、元の要求と同じ接続を介して返される必要があります。各同時要求は、ローカルで接続をスコープとするトークンによって区別されます。
The connection is bidirectional, so requests can be sent by both the entity that established the connection and the remote host.
接続は双方向であるため、接続を確立したエンティティとリモートホストの両方から要求を送信できます。
As with CoAP over TCP, retransmission and deduplication of messages are provided by the WebSocket Protocol. CoAP over WebSockets therefore does not make a distinction between Confirmable messages and Non-confirmable messages and does not provide Acknowledgment or Reset messages.
CoAP over TCPと同様に、メッセージの再送信と重複排除はWebSocketプロトコルによって提供されます。したがって、CoAP over WebSocketsは、確認可能なメッセージと確認不可能なメッセージを区別せず、確認またはリセットメッセージを提供しません。
As with CoAP over TCP, a CoAP client can test the health of the connection for CoAP over WebSockets by sending a CoAP Ping Signaling message (Section 5.4). To ensure that redundant maintenance traffic is not transmitted, WebSocket Ping and unsolicited Pong frames (Section 5.5 of [RFC6455]) SHOULD NOT be used.
CoAP over TCPと同様に、CoAPクライアントは、CoAP Pingシグナリングメッセージを送信することにより、CoAP over WebSocketsの接続の状態をテストできます（セクション5.4）。冗長なメンテナンストラフィックが送信されないようにするために、WebSocket Pingおよび非送信請求Pongフレーム（[RFC6455]のセクション5.5）は使用しないでください。
Signaling messages are specifically introduced only for CoAP over reliable transports to allow peers to:
シグナリングメッセージは、ピアが次のことを行えるように、信頼できるトランスポート上のCoAPに対してのみ導入されます。
o Learn related characteristics, such as maximum message size for the connection.
o 接続の最大メッセージサイズなど、関連する特性を学習します。
o Shut down the connection in an orderly fashion.
o 正しい方法で接続をシャットダウンします。
o Provide diagnostic information when terminating a connection in response to a serious error condition.
o 深刻なエラー状態に対応して接続を終了するときに、診断情報を提供します。
Signaling is a third basic kind of message in CoAP, after requests and responses. Signaling messages share a common structure with the existing CoAP messages. There are a code, a Token, options, and an optional payload.
シグナリングは、要求と応答の後の、CoAPの3番目の基本的なメッセージです。シグナリングメッセージは、既存のCoAPメッセージと共通の構造を共有します。コード、トークン、オプション、およびオプションのペイロードがあります。
(See Section 3 of [RFC7252] for the overall structure of the message format, option format, and option value formats.)
（メッセージ形式、オプション形式、オプション値形式の全体的な構造については、[RFC7252]のセクション3をご覧ください）。
A code in the 7.00-7.31 range indicates a Signaling message. Values in this range are assigned by the "CoAP Signaling Codes" subregistry (see Section 11.1).
7.00〜7.31の範囲のコードは、シグナリングメッセージを示します。この範囲の値は、「CoAP Signaling Codes」サブレジストリによって割り当てられます（セクション11.1を参照）。
For each message, there are a sender and a peer receiving the message.
メッセージごとに、送信者とメッセージを受信するピアがあります。
Payloads in Signaling messages are diagnostic payloads as defined in Section 5.5.2 of [RFC7252], unless otherwise defined by a Signaling message option.
シグナリングメッセージのペイロードは、[RFC7252]のセクション5.5.2で定義されている診断ペイロードです。ただし、シグナリングメッセージオプションで別途定義されている場合を除きます。
Option Numbers for Signaling messages are specific to the message code. They do not share the number space with CoAP options for request/response messages or with Signaling messages using other codes.
シグナリングメッセージのオプション番号は、メッセージコードに固有です。これらは、要求/応答メッセージのCoAPオプションまたは他のコードを使用したシグナリングメッセージと番号スペースを共有しません。
Option Numbers are assigned by the "CoAP Signaling Option Numbers" subregistry (see Section 11.2).
オプション番号は、「CoAPシグナリングオプション番号」サブレジストリによって割り当てられます（セクション11.2を参照）。
Signaling Options are elective or critical as defined in Section 5.4.1 of [RFC7252]. If a Signaling Option is critical and not understood by the receiver, it MUST abort the connection (see Section 5.6). If the option is understood but cannot be processed, the option documents the behavior.
[RFC7252]のセクション5.4.1で定義されているように、シグナリングオプションは選択的または重要です。シグナリングオプションが重要であり、レシーバーが理解できない場合は、接続を中止する必要があります（セクション5.6を参照）。オプションは理解されているが処理できない場合、オプションは動作を文書化します。
CSMs are used for two purposes:
CSMは次の2つの目的で使用されます。
o Each capability option indicates one capability of the sender to the recipient.
o 各機能オプションは、送信者の1つの機能を受信者に示します。
o Each setting option indicates a setting that will be applied by the sender.
o 各設定オプションは、送信者によって適用される設定を示します。
One CSM MUST be sent by each endpoint at the start of the Transport Connection. Additional CSMs MAY be sent at any other time by either endpoint over the lifetime of the connection.
トランスポート接続の開始時に、各エンドポイントから1つのCSMを送信する必要があります。追加のCSMは、接続の存続期間中、いずれかのエンドポイントによっていつでも送信できます（MAY）。
Both capability options and setting options are cumulative. A CSM does not invalidate a previously sent capability indication or setting even if it is not repeated. A capability message without any option is a no-operation (and can be used as such). An option that is sent might override a previous value for the same option. The option defines how to handle this case if needed.
機能オプションと設定オプションの両方が累積されます。 CSMは、繰り返されなくても、以前に送信された機能の表示または設定を無効にしません。オプションのない機能メッセージは操作なしです（そのように使用できます）。送信されるオプションは、同じオプションの以前の値をオーバーライドする場合があります。オプションは、必要に応じてこのケースを処理する方法を定義します。
Base values are listed below for CSM options. These are the values for the capability and settings before any CSMs send a modified value.
CSMオプションの基本値を以下に示します。これらは、CSMが変更された値を送信する前の機能と設定の値です。
These are not default values (as defined in Section 5.4.4 in [RFC7252]) for the option. Default values apply on a per-message basis and are thus reset when the value is not present in a given CSM.
これらは、オプションのデフォルト値（[RFC7252]のセクション5.4.4で定義）ではありません。デフォルト値はメッセージごとに適用されるため、特定のCSMに値が存在しない場合はリセットされます。
CSMs are indicated by the 7.01 (CSM) code; see Table 1 (Section 11.1).
CSMは7.01（CSM）コードで示されます。表1（セクション11.1）を参照してください。
The sender can use the elective Max-Message-Size Option to indicate the maximum size of a message in bytes that it can receive. The message size indicated includes the entire message, starting from the first byte of the message header and ending at the end of the message payload.
送信者は、選択可能なMax-Message-Sizeオプションを使用して、受信できるメッセージの最大サイズをバイト単位で示すことができます。示されているメッセージサイズには、メッセージヘッダーの最初のバイトから始まり、メッセージペイロードの最後で終わるメッセージ全体が含まれます。
(Note that there is no relationship of the message size to the overall request or response body size that may be achievable in block-wise transfer. For example, the exchange depicted in Figure 13 (Section 6.1) can be performed if the CoAP client indicates a value of around 6000 bytes for the Max-Message-Size Option, even though the total body size transferred to the client is 3072 + 5120 + 4711 = 12903 bytes.)
（ブロックサイズの転送で達成できる可能性のある、全体の要求または応答本文のサイズに対するメッセージサイズの関係はないことに注意してください。たとえば、図13（セクション6.1）に示す交換は、CoAPクライアントがMax-Message-Sizeオプションの値は約6000バイトですが、クライアントに転送される本文の合計サイズは3072 + 5120 + 4711 = 12903バイトです。）
+---+---+---+---------+------------------+--------+--------+--------+
| # | C | R | Applies | Name | Format | Length | Base |
| | | | to | | | | Value |
+---+---+---+---------+------------------+--------+--------+--------+
| 2 | | | CSM | Max-Message-Size | uint | 0-4 | 1152 |
+---+---+---+---------+------------------+--------+--------+--------+
C=Critical, R=Repeatable
C =クリティカル、R =繰り返し可能
As per Section 4.6 of [RFC7252], the base value (and the value used when this option is not implemented) is 1152.
[RFC7252]のセクション4.6によると、ベース値（およびこのオプションが実装されていない場合に使用される値）は1152です。
The active value of the Max-Message-Size Option is replaced each time the option is sent with a modified value. Its starting value is its base value.
Max-Message-Sizeオプションのアクティブな値は、オプションが変更された値で送信されるたびに置き換えられます。その開始値はそのベース値です。
+---+---+---+---------+------------------+--------+--------+--------+
| # | C | R | Applies | Name | Format | Length | Base |
| | | | to | | | | Value |
+---+---+---+---------+------------------+--------+--------+--------+
| 4 | | | CSM | Block-Wise- | empty | 0 | (none) |
| | | | | Transfer | | | |
+---+---+---+---------+------------------+--------+--------+--------+
C=Critical, R=Repeatable
C =クリティカル、R =繰り返し可能
A sender can use the elective Block-Wise-Transfer Option to indicate that it supports the block-wise transfer protocol [RFC7959].
送信者は、選択的なBlock-Wise-Transferオプションを使用して、ブロック単位の転送プロトコル[RFC7959]をサポートしていることを示すことができます。
If the option is not given, the peer has no information about whether block-wise transfers are supported by the sender or not. An implementation wishing to offer block-wise transfers to its peer therefore needs to indicate so via the Block-Wise-Transfer Option.
このオプションが指定されていない場合、ピアは、ブロック単位の転送が送信者によってサポートされているかどうかについての情報を持っていません。したがって、ピアにブロック単位の転送を提供することを希望する実装は、Block-Wise-Transferオプションを介してそれを示す必要があります。
If a Max-Message-Size Option is indicated with a value that is greater than 1152 (in the same CSM or a different CSM), the Block-Wise-Transfer Option also indicates support for BERT (see Section 6). Subsequently, if the Max-Message-Size Option is indicated with a value equal to or less than 1152, BERT support is no longer indicated. (Note that the indication of BERT support does not oblige either peer to actually choose to make use of BERT.)
Max-Message-Sizeオプションが1152より大きい値で（同じCSMまたは異なるCSMで）示されている場合、Block-Wise-TransferオプションはBERTのサポートも示しています（セクション6を参照）。その後、Max-Message-Sizeオプションが1152以下の値で示される場合、BERTサポートは示されなくなります。 （BERTサポートの表示は、どちらのピアにもBERTを使用することを実際に選択するように強制するものではないことに注意してください。）
Implementation note: When indicating a value of the Max-Message-Size Option with an intention to enable BERT, the indicating implementation may want to (1) choose a particular BERT block size it wants to encourage and (2) add a delta for the header and any options that may also need to be included in the message with a BERT block of that size. Section 4.6 of [RFC7252] adds 128 bytes to a maximum block size of 1024 to arrive at a default message size of 1152. A BERT-enabled implementation may want to indicate a BERT block size of 2048 or a higher multiple of 1024 and at the same time be more generous with the size of the header and options added (say, 256 or 512). However, adding 1024 or more to the base BERT block size may encourage the peer implementation to vary the BERT block size based on the size of the options included; this type of scenario might make it harder to establish interoperability.
実装に関するメモ：BERTを有効にする目的でMax-Message-Sizeオプションの値を示す場合、その示す実装では、（1）推奨する特定のBERTブロックサイズを選択し、（2）デルタを追加する必要があります。ヘッダーと、そのサイズのBERTブロックを持つメッセージに含める必要があるオプション。 [RFC7252]のセクション4.6は、最大ブロックサイズ1024に128バイトを追加して、デフォルトのメッセージサイズ1152に到達します。BERT対応の実装では、2048またはそれ以上の1024のBERTブロックサイズと、同時に、ヘッダーのサイズと追加されたオプション（たとえば、256または512）により寛大になります。ただし、ベースのBERTブロックサイズに1024以上を追加すると、ピアの実装で、含まれているオプションのサイズに基づいてBERTブロックサイズを変更するようになる場合があります。このタイプのシナリオでは、相互運用性の確立が困難になる可能性があります。
In CoAP over reliable transports, Empty messages (Code 0.00) can always be sent and MUST be ignored by the recipient. This provides a basic keepalive function. In contrast, Ping and Pong messages are a bidirectional exchange.
信頼できるトランスポート上のCoAPでは、空のメッセージ（コード0.00）を常に送信でき、受信者は無視する必要があります。これにより、基本的なキープアライブ機能が提供されます。対照的に、PingメッセージとPongメッセージは双方向の交換です。
Upon receipt of a Ping message, the receiver MUST return a Pong message with an identical Token in response. Unless the Ping carries an option with delaying semantics such as the Custody Option, it SHOULD respond as soon as practical. As with all Signaling messages, the recipient of a Ping or Pong message MUST ignore elective options it does not understand.
Pingメッセージを受信すると、受信者は応答として同一のトークンを含むPongメッセージを返さなければなりません（MUST）。 PingがCustody Optionなどのセマンティクスを遅延させるオプションを運んでいない限り、Pingはできるだけ早く応答する必要があります。すべてのシグナリングメッセージと同様に、PingまたはPongメッセージの受信者は、理解できない選択オプションを無視する必要があります。
Ping and Pong messages are indicated by the 7.02 code (Ping) and the 7.03 code (Pong).
PingおよびPongメッセージは、7.02コード（Ping）および7.03コード（Pong）で示されます。
Note that, as with similar mechanisms defined in [RFC6455] and [RFC7540], the present specification does not define any specific maximum time that the sender of a Ping message has to allow when waiting for a Pong reply. Any limitations on patience for this reply are a matter of the application making use of these messages, as is any approach to recover from a failure to respond in time.
[RFC6455]と[RFC7540]で定義されている同様のメカニズムと同様に、この仕様では、Pingメッセージの送信者がPong応答を待つときに許可する必要がある特定の最大時間を定義していません。この応答に対する忍耐力の制限は、これらのメッセージを利用するアプリケーションの問題であり、応答の失敗から回復するためのあらゆるアプローチと同様です。
+---+---+---+----------+----------------+--------+--------+---------+
| # | C | R | Applies | Name | Format | Length | Base |
| | | | to | | | | Value |
+---+---+---+----------+----------------+--------+--------+---------+
| 2 | | | Ping, | Custody | empty | 0 | (none) |
| | | | Pong | | | | |
+---+---+---+----------+----------------+--------+--------+---------+
C=Critical, R=Repeatable
C =クリティカル、R =繰り返し可能
When responding to a Ping message, the receiver can include an elective Custody Option in the Pong message. This option indicates that the application has processed all the request/response messages received prior to the Ping message on the current connection. (Note that there is no definition of specific application semantics for "processed", but there is an expectation that the receiver of a Pong message with a Custody Option should be able to free buffers based on this indication.)
Pingメッセージに応答するとき、受信者はPongメッセージに選択的保管オプションを含めることができます。このオプションは、現在の接続でPingメッセージの前に受信したすべての要求/応答メッセージをアプリケーションが処理したことを示します。 （「処理済み」の特定のアプリケーションセマンティクスの定義はありませんが、カストディオプションを使用したPongメッセージの受信者は、この指示に基づいてバッファーを解放できるはずであることに注意してください。）
A sender can also include an elective Custody Option in a Ping message to explicitly request the inclusion of an elective Custody Option in the corresponding Pong message. In that case, the receiver SHOULD delay its Pong message until it finishes processing all the request/response messages received prior to the Ping message on the current connection.
送信者は、Pingメッセージに選択的カストディオプションを含めて、対応するPongメッセージに選択的カストディオプションを含めることを明示的に要求することもできます。その場合、受信者は、現在の接続でPingメッセージの前に受信したすべての要求/応答メッセージの処理が完了するまで、そのPongメッセージを遅延させる必要があります（SHOULD）。
A Release message indicates that the sender does not want to continue maintaining the Transport Connection and opts for an orderly shutdown, but wants to leave it to the peer to actually start closing the connection. The details are in the options. A diagnostic payload (see Section 5.5.2 of [RFC7252]) MAY be included.
リリースメッセージは、送信者がトランスポート接続の維持を継続せず、通常のシャットダウンを選択することを示しますが、ピアにそのまま残して、実際に接続のクローズを開始することを望みます。詳細はオプションにあります。診断ペイロード（[RFC7252]のセクション5.5.2を参照）が含まれる場合があります。
A peer will normally respond to a Release message by closing the Transport Connection. (In case that does not happen, the sender of the release may want to implement a timeout mechanism if getting rid of the connection is actually important to it.) Messages may be in flight or responses outstanding when the sender decides to send a Release message (which is one reason the sender had decided to wait before closing the connection). The peer responding to the Release message SHOULD delay the closing of the connection until it has responded to all requests received by it before the Release message. It also MAY wait for the responses to its own requests.
ピアは通常、トランスポート接続を閉じることにより、解放メッセージに応答します。 （それが起こらない場合、リリースの送信者は、接続を取り除くことが実際に重要である場合、タイムアウトメカニズムを実装する必要があります。）送信者がリリースメッセージを送信することを決定したときに、メッセージが処理中または応答が未解決である可能性があります。 （これは、送信者が接続を閉じる前に待機することを決定した理由の1つです）。解放メッセージに応答するピアは、解放メッセージの前に受信したすべての要求に応答するまで、接続のクローズを遅らせる必要があります（SHOULD）。また、自身の要求への応答を待つ場合もあります。
It is NOT RECOMMENDED for the sender of a Release message to continue sending requests on the connection it already indicated to be released: the peer might close the connection at any time and miss those requests. The peer is not obligated to check for this condition, though.
リリースメッセージの送信者が、解放するようにすでに示している接続で要求を送信し続けることはお勧めしません。ピアはいつでも接続を閉じて、それらの要求を見逃す可能性があります。ただし、ピアはこの状態をチェックする義務はありません。
Release messages are indicated by the 7.04 code (Release).
リリースメッセージは7.04コード（リリース）で示されます。
Release messages can indicate one or more reasons using elective options. The following options are defined:
リリースメッセージは、選択オプションを使用している1つ以上の理由を示している場合があります。以下のオプションが定義されています。
+---+---+---+---------+------------------+--------+--------+--------+
| # | C | R | Applies | Name | Format | Length | Base |
| | | | to | | | | Value |
+---+---+---+---------+------------------+--------+--------+--------+
| 2 | | x | Release | Alternative- | string | 1-255 | (none) |
| | | | | Address | | | |
+---+---+---+---------+------------------+--------+--------+--------+
C=Critical, R=Repeatable
C =クリティカル、R =繰り返し可能
The elective Alternative-Address Option requests the peer to instead open a connection of the same scheme as the present connection to the alternative transport address given. Its value is in the form "authority" as defined in Section 3.2 of [RFC3986]. (Existing state related to the connection is not transferred from the present connection to the new connection.) The Alternative-Address Option is a repeatable option as defined in Section 5.4.5 of [RFC7252]. When multiple occurrences of the option are included, the peer can choose any of the alternative transport addresses.
選択的な代替アドレスオプションは、代わりに、指定された代替トランスポートアドレスへの現在の接続と同じスキームの接続を開くようにピアに要求します。その値は、[RFC3986]のセクション3.2で定義されている「authority」の形式です。 （接続に関連する既存の状態は、現在の接続から新しい接続に転送されません。）Alternative-Address Optionは、[RFC7252]のセクション5.4.5で定義されている繰り返し可能なオプションです。オプションの複数のオカレンスが含まれている場合、ピアは代替トランスポートアドレスのいずれかを選択できます。
+---+---+---+---------+-----------------+--------+--------+---------+
| # | C | R | Applies | Name | Format | Length | Base |
| | | | to | | | | Value |
+---+---+---+---------+-----------------+--------+--------+---------+
| 4 | | | Release | Hold-Off | uint | 0-3 | (none) |
+---+---+---+---------+-----------------+--------+--------+---------+
C=Critical, R=Repeatable
C =クリティカル、R =繰り返し可能
The elective Hold-Off Option indicates that the server is requesting that the peer not reconnect to it for the number of seconds given in the value.
選択的ホールドオフオプションは、値で指定された秒数の間、ピアがサーバーに再接続しないことをサーバーが要求していることを示します。
An Abort message indicates that the sender is unable to continue maintaining the Transport Connection and cannot even wait for an orderly release. The sender shuts down the connection immediately after the Abort message (and may or may not wait for a Release message, Abort message, or connection shutdown in the inverse direction). A diagnostic payload (see Section 5.5.2 of [RFC7252]) SHOULD be included in the Abort message. Messages may be in flight or responses outstanding when the sender decides to send an Abort message. The general expectation is that these will NOT be processed.
中止メッセージは、送信者がトランスポート接続の維持を継続できず、正常な解放を待つことさえできないことを示します。送信者は、Abortメッセージの直後に接続をシャットダウンします（Releaseメッセージ、Abortメッセージ、または逆方向の接続シャットダウンを待つ場合と待たない場合があります）。診断ペイロード（[RFC7252]のセクション5.5.2を参照）を中止メッセージに含める必要があります。送信者が中止メッセージを送信することを決定した場合、メッセージが処理中または応答が未解決である可能性があります。一般的な予想では、これらは処理されません。
Abort messages are indicated by the 7.05 code (Abort).
中止メッセージは、7.05コード（中止）で示されます。
Abort messages can indicate one or more reasons using elective options. The following option is defined:
中止メッセージは、選択オプションを使用している1つ以上の理由を示している場合があります。次のオプションが定義されています。
+---+---+---+---------+-----------------+--------+--------+---------+
| # | C | R | Applies | Name | Format | Length | Base |
| | | | to | | | | Value |
+---+---+---+---------+-----------------+--------+--------+---------+
| 2 | | | Abort | Bad-CSM-Option | uint | 0-2 | (none) |
+---+---+---+---------+-----------------+--------+--------+---------+
C=Critical, R=Repeatable
C =クリティカル、R =繰り返し可能
Bad-CSM-Option, which is elective, indicates that the sender is unable to process the CSM option identified by its Option Number, e.g., when it is critical and the Option Number is unknown by the sender, or when there is a parameter problem with the value of an elective option. More detailed information SHOULD be included as a diagnostic payload.
選択的であるBad-CSM-Optionは、送信者がオプション番号で識別されるCSMオプションを処理できないことを示します。たとえば、クリティカルでオプション番号が送信者に不明な場合、またはパラメーターの問題がある場合選択オプションの価値を持つ。より詳細な情報は、診断ペイロードとして含まれる必要があります。
For CoAP over UDP, messages that contain syntax violations are processed as message format errors. As described in Sections 4.2 and 4.3 of [RFC7252], such messages are rejected by sending a matching Reset message and otherwise ignoring the message.
CoAP over UDPの場合、構文違反を含むメッセージはメッセージ形式エラーとして処理されます。 [RFC7252]のセクション4.2および4.3で説明されているように、このようなメッセージは、一致するリセットメッセージを送信するか、メッセージを無視することで拒否されます。
For CoAP over reliable transports, the recipient rejects such messages by sending an Abort message and otherwise ignoring (not processing) the message. No specific Option has been defined for the Abort message in this case, as the details are best left to a diagnostic payload.
信頼性の高いトランスポートを介したCoAPの場合、受信者は中止メッセージを送信し、それ以外の場合はメッセージを無視（処理しない）することにより、そのようなメッセージを拒否します。この場合、詳細は診断ペイロードに任せるのが最適なので、Abortメッセージに特定のオプションは定義されていません。
An encoded example of a Ping message with a non-empty Token is shown in Figure 11.
空でないトークンを含むPingメッセージのエンコードされた例を図11に示します。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x01 | 0xe2 | 0x42 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Len = 0 -------> 0x01
TKL = 1 ___/
Code = 7.02 Ping --> 0xe2
Token = 0x42
Figure 11: Ping Message Example
図11：Pingメッセージの例
An encoded example of the corresponding Pong message is shown in Figure 12.
対応するPongメッセージのエンコードされた例を図12に示します。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x01 | 0xe3 | 0x42 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Len = 0 -------> 0x01
TKL = 1 ___/
Code = 7.03 Pong --> 0xe3
Token = 0x42
Figure 12: Pong Message Example
図12：Pongメッセージの例
The message size restrictions defined in Section 4.6 of [RFC7252] to avoid IP fragmentation are not necessary when CoAP is used over a reliable transport. While this suggests that the block-wise transfer protocol [RFC7959] is also no longer needed, it remains applicable for a number of cases:
IPフラグメンテーションを回避するために[RFC7252]のセクション4.6で定義されているメッセージサイズの制限は、CoAPが信頼できるトランスポートで使用される場合は不要です。これは、ブロック単位の転送プロトコル[RFC7959]も不要になったことを示唆していますが、多くの場合に引き続き適用できます。
o Large messages, such as firmware downloads, may cause undesired head-of-line blocking when a single transport connection is used.
o ファームウェアのダウンロードなどの大きなメッセージは、単一のトランスポート接続が使用されている場合、不要な行頭ブロッキングを引き起こす可能性があります。
o A UDP-to-TCP gateway may simply not have the context to convert a message with a Block Option into the equivalent exchange without any use of a Block Option (it would need to convert the entire block-wise exchange from start to end into a single exchange).
o UDP-to-TCPゲートウェイは、ブロックオプションを使用せずに、ブロックオプションを含むメッセージを同等の交換に変換するコンテキストを持たない場合があります（ブロック単位の交換全体を最初から最後に変換する必要があります）単一交換）。
BERT extends the block-wise transfer protocol to enable the use of larger messages over a reliable transport.
BERTは、ブロック単位の転送プロトコルを拡張して、信頼性の高いトランスポートでより大きなメッセージを使用できるようにします。
The use of this new extension is signaled by sending Block1 or Block2 Options with SZX == 7 (a "BERT Option"). SZX == 7 is a reserved value in [RFC7959].
この新しい拡張機能の使用は、SZX == 7（「BERTオプション」）でBlock1またはBlock2オプションを送信することによって通知されます。 SZX == 7は[RFC7959]で予約されている値です。
In control usage, a BERT Option is interpreted in the same way as the equivalent Option with SZX == 6, except that it also indicates the capability to process BERT blocks. As with the basic block-wise transfer protocol, the recipient of a CoAP request with a BERT Option in control usage is allowed to respond with a different SZX value, e.g., to send a non-BERT block instead.
コントロールの使用では、BERTオプションは、BERTブロックを処理する機能も示すことを除いて、SZX == 6の同等のオプションと同じように解釈されます。基本的なブロック単位の転送プロトコルと同様に、BERTオプションを制御用に使用するCoAP要求の受信者は、異なるSZX値で応答することができます。たとえば、代わりに非BERTブロックを送信できます。
In descriptive usage, a BERT Option is interpreted in the same way as the equivalent Option with SZX == 6, except that the payload is also allowed to contain multiple blocks. For non-final BERT blocks, the payload is always a multiple of 1024 bytes. For final BERT blocks, the payload is a multiple (possibly 0) of 1024 bytes plus a partial block of less than 1024 bytes.
説明的な使用法では、BERTオプションは、ペイロードに複数のブロックを含めることも許可されることを除いて、SZX == 6の同等のオプションと同じ方法で解釈されます。最終ではないBERTブロックの場合、ペイロードは常に1024バイトの倍数です。最後のBERTブロックの場合、ペイロードは1024バイトの倍数（おそらく0）に1024バイト未満の部分ブロックを加えたものです。
The recipient of a non-final BERT block (M=1) conceptually partitions the payload into a sequence of 1024-byte blocks and acts exactly as if it had received this sequence in conjunction with block numbers starting at, and sequentially increasing from, the block number given in the Block Option. In other words, the entire BERT block is positioned at the byte position that results from multiplying the block number by 1024. The position of further blocks to be transferred is indicated by incrementing the block number by the number of elements in this sequence (i.e., the size of the payload divided by 1024 bytes).
非最終BERTブロック（M = 1）の受信者は、概念的にペイロードを1024バイトのブロックのシーケンスに分割し、このシーケンスをブロック番号とともに開始して順次増加していくように、このシーケンスを受信したかのように動作します。ブロックオプションで指定されたブロック番号。言い換えると、BERTブロック全体が、ブロック番号に1024を掛けた結果のバイト位置に配置されます。転送される他のブロックの位置は、このシーケンスの要素数でブロック番号をインクリメントすることで示されます（つまり、ペイロードのサイズを1024バイトで除算したもの）。
As with SZX == 6, the recipient of a final BERT block (M=0) simply appends the payload at the byte position that is indicated by the block number multiplied by 1024.
SZX == 6と同様に、最後のBERTブロック（M = 0）の受信者は、ブロック番号に1024を掛けたバイト位置にペイロードを単純に追加します。
The following examples illustrate BERT Options. A value of SZX == 7 is labeled as "BERT" or as "BERT(nnn)" to indicate a payload of size nnn.
次の例は、BERTオプションを示しています。 SZX == 7の値は、「BERT」または「BERT（nnn）」としてラベル付けされ、サイズnnnのペイロードを示します。
In all these examples, a Block Option is decomposed to indicate the kind of Block Option (1 or 2) followed by a colon, the block number (NUM), the more bit (M), and the block size (2**(SZX + 4)) separated by slashes. For example, a Block2 Option value of 33 would be shown as 2:2/0/32), or a Block1 Option value of 59 would be shown as 1:3/1/128.
これらすべての例で、ブロックオプションは分解されて、ブロックオプションの種類（1または2）の後にコロン、ブロック番号（NUM）、ビット数（M）、およびブロックサイズ（2 **（ SZX + 4））スラッシュで区切られます。たとえば、Block2 Option値33は2：2/0/32）として表示され、Block1 Option値59は1：3/1/128として表示されます。
Figure 13 shows a GET request with a response that is split into three BERT blocks. The first response contains 3072 bytes of payload; the second, 5120; and the third, 4711. Note how the block number increments to move the position inside the response body forward.
図13は、3つのBERTブロックに分割された応答を伴うGET要求を示しています。最初の応答には3072バイトのペイロードが含まれます。 2番目の5120。 3番目の4711に注目してください。ブロック番号が増加して、応答本体内の位置が前に移動することに注意してください。
CoAP Client CoAP Server
| |
| GET, /status ------> |
| |
| <------ 2.05 Content, 2:0/1/BERT(3072) |
| |
| GET, /status, 2:3/0/BERT ------> |
| |
| <------ 2.05 Content, 2:3/1/BERT(5120) |
| |
| GET, /status, 2:8/0/BERT ------> |
| |
| <------ 2.05 Content, 2:8/0/BERT(4711) |
Figure 13: GET with BERT Blocks
図13：BERTブロックを使用したGET
Figure 14 demonstrates a PUT exchange with BERT blocks.
図14は、BERTブロックを使用したPUT交換を示しています。
CoAP Client CoAP Server
| |
| PUT, /options, 1:0/1/BERT(8192) ------> |
| |
| <------ 2.31 Continue, 1:0/1/BERT |
| |
| PUT, /options, 1:8/1/BERT(16384) ------> |
| |
| <------ 2.31 Continue, 1:8/1/BERT |
| |
| PUT, /options, 1:24/0/BERT(5683) ------> |
| |
| <------ 2.04 Changed, 1:24/0/BERT |
| |
Figure 14: PUT with BERT Blocks
図14：BERTブロックを使用したPUT
This section describes how the procedures defined in [RFC7641] for observing resources over CoAP are applied (and modified, as needed) for reliable transports. In this section, "client" and "server" refer to the CoAP client and CoAP server.
このセクションでは、[RFC7641]で定義された、CoAP経由でリソースを監視するための手順が、信頼性の高いトランスポートにどのように適用（および必要に応じて変更）されるかについて説明します。このセクションでは、「クライアント」と「サーバー」はCoAPクライアントとCoAPサーバーを指します。
When using the Observe Option [RFC7641] with CoAP over UDP, notifications from the server set the option value to an increasing sequence number for reordering detection on the client, since messages can arrive in a different order than they were sent. This sequence number is not required for CoAP over reliable transports, since TCP ensures reliable and ordered delivery of messages. The value of the Observe Option in 2.xx notifications MAY be empty on transmission and MUST be ignored on reception.
メッセージの送信順序とは異なる順序でメッセージが到着する可能性があるため、CoAP over UDPでObserve Option [RFC7641]を使用する場合、サーバーからの通知により、オプション値が増加するシーケンス番号に設定され、クライアントでの再順序付け検出が行われます。 TCPはメッセージの信頼性の高い順序付けられた配信を保証するため、このシーケンス番号は、信頼性の高いトランスポート上のCoAPには必要ありません。 2.xx通知の監視オプションの値は、送信時には空である場合があり、受信時には無視される必要があります。
Implementation note: This means that a proxy from a reordering transport to a reliable (in-order) transport (such as a UDP-to-TCP proxy) needs to process the Observe Option in notifications according to the rules in Section 3.4 of [RFC7641].
実装に関するメモ：これは、並べ替えトランスポートから信頼できる（順序正しい）トランスポート（UDPからTCPへのプロキシなど）へのプロキシは、[RFC7641のセクション3.4のルールに従って通知の監視オプションを処理する必要があることを意味します。 ]。
For CoAP over UDP, server notifications to the client can be Confirmable or Non-confirmable. A Confirmable message requires the client to respond with either an Acknowledgment message or a Reset message. An Acknowledgment message indicates that the client is alive and wishes to receive further notifications. A Reset message indicates that the client does not recognize the Token; this causes the server to remove the associated entry from the list of observers.
CoAP over UDPの場合、クライアントへのサーバー通知は、確認可能または確認不可能になります。確認可能なメッセージは、クライアントが確認メッセージまたはリセットメッセージのいずれかで応答することを要求します。確認メッセージは、クライアントが生きていて、さらに通知を受信したいことを示します。リセットメッセージは、クライアントがトークンを認識しないことを示します。これにより、サーバーは関連するエントリをオブザーバーのリストから削除します。
Since TCP eliminates the need for the message layer to support reliability, CoAP over reliable transports does not support Confirmable or Non-confirmable message types. All notifications are delivered reliably to the client with positive acknowledgment of receipt occurring at the TCP level. If the client does not recognize the Token in a notification, it MAY immediately abort the connection (see Section 5.6).
TCPはメッセージ層が信頼性をサポートする必要をなくすため、信頼性のあるトランスポート上のCoAPは確認可能または確認不可能なメッセージタイプをサポートしません。すべての通知は確実にクライアントに配信され、TCPレベルで発生する受信の肯定応答が含まれます。クライアントが通知でトークンを認識しない場合、クライアントは直ちに接続を中止することができます（セクション5.6を参照）。
For CoAP over UDP, if a client does not receive a notification for some time, it can send a new GET request with the same Token as the original request to re-register its interest in a resource and verify that the server is still responsive. For CoAP over reliable transports, it is more efficient to check the health of the connection (and all its active observations) by sending a single CoAP Ping Signaling message (Section 5.4) rather than individual requests to confirm each active observation. (Note that such a Ping/Pong only confirms a single hop: a proxy is not obligated or expected to react to a Ping by checking all its own registered interests or all the connections, if any, underlying them. A proxy MAY maintain its own schedule for confirming the interests that it relies on being registered toward the origin server; however, it is generally inadvisable for a proxy to generate a large number of outgoing checks based on a single incoming check.)
CoAP over UDPの場合、クライアントがしばらくの間通知を受信しない場合、クライアントは、元のリクエストと同じトークンを使用して新しいGETリクエストを送信し、リソースへの関心を再登録して、サーバーが引き続き応答することを確認できます。信頼性の高いトランスポートを介したCoAPの場合、各アクティブな監視を確認する個別のリクエストではなく、単一のCoAP Pingシグナリングメッセージ（セクション5.4）を送信することにより、接続（およびそのすべてのアクティブな監視）の状態をチェックする方が効率的です。 （そのようなPing / Pongは単一のホップのみを確認することに注意してください：プロキシは、そのすべての登録済みインタレストまたはそれらの基礎となるすべての接続をチェックすることにより、Pingに反応する義務がありません。オリジンサーバーへの登録に依存していることを確認するためのスケジュールを確認するためのスケジュール。ただし、プロキシが単一の着信チェックに基づいて多数の発信チェックを生成することはお勧めできません。）
For CoAP over UDP, a client that is no longer interested in receiving notifications can "forget" the observation and respond to the next notification from the server with a Reset message to cancel the observation.
CoAP over UDPの場合、通知の受信に不要になったクライアントは、監視を「忘れ」、サーバーからの次の通知にリセットメッセージで応答して、監視をキャンセルできます。
For CoAP over reliable transports, a client MUST explicitly deregister by issuing a GET request that has the Token field set to the Token of the observation to be canceled and includes an Observe Option with the value set to 1 (deregister).
信頼できるトランスポートを介したCoAPの場合、クライアントは、トークンフィールドがキャンセルされる監視のトークンに設定され、値が1に設定された監視オプションを含む（登録解除）GET要求を発行することによって明示的に登録解除する必要があります。
If the client observes one or more resources over a reliable transport, then the CoAP server (or intermediary in the role of the CoAP server) MUST remove all entries associated with the client endpoint from the lists of observers when the connection either times out or is closed.
クライアントが信頼性の高いトランスポートを介して1つ以上のリソースを監視する場合、CoAPサーバー（またはCoAPサーバーの役割の仲介者）は、接続がタイムアウトするか、接続が切断されたときに、クライアントエンドポイントに関連付けられたすべてのエントリをオブザーバーのリストから削除する必要があります。閉まっている。
CoAP over UDP [RFC7252] defines the "coap" and "coaps" URI schemes. This document introduces four additional URI schemes for identifying CoAP resources and providing a means of locating the resource:
CoAP over UDP [RFC7252]は、「coap」および「coaps」URIスキームを定義しています。このドキュメントでは、CoAPリソースを識別し、リソースを特定するための4つの追加URIスキームを紹介します。
o The "coap+tcp" URI scheme for CoAP over TCP.
o CoAP over TCPの「coap + tcp」URIスキーム。
o The "coaps+tcp" URI scheme for CoAP over TCP secured by TLS.
o TLSで保護されたCoAP over TCPの「coaps + tcp」URIスキーム。
o The "coap+ws" URI scheme for CoAP over WebSockets.
o CoSocket over WebSocketsの「coap + ws」URIスキーム。
o The "coaps+ws" URI scheme for CoAP over WebSockets secured by TLS.
o TLSで保護されたWebSockets上のCoAPの「coaps + ws」URIスキーム。
Resources made available via these schemes have no shared identity even if their resource identifiers indicate the same authority (the same host listening to the same TCP port). They are hosted in distinct namespaces because each URI scheme implies a distinct origin server.
これらのスキームを介して利用可能にされたリソースは、それらのリソース識別子が同じ機関（同じTCPポートをリッスンしている同じホスト）を示している場合でも、共有IDを持ちません。各URIスキームは異なる起点サーバーを意味するため、これらは異なる名前空間でホストされます。
In this section, the syntax for the URI schemes is specified using the Augmented Backus-Naur Form (ABNF) [RFC5234]. The definitions of "host", "port", "path-abempty", and "query" are adopted from [RFC3986].
このセクションでは、URIスキームの構文は、拡張バッカスナウアフォーム（ABNF）[RFC5234]を使用して指定されます。 「host」、「port」、「path-abempty」、および「query」の定義は、[RFC3986]から採用されています。
Section 8 ("Multicast CoAP") in [RFC7252] is not applicable to these schemes.
[RFC7252]のセクション8（「マルチキャストCoAP」）は、これらのスキームには適用されません。
As with the "coap" and "coaps" schemes defined in [RFC7252], all URI schemes defined in this section also support the path prefix "/.well-known/" as defined by [RFC5785] for "well-known locations" in the namespace of a host. This enables discovery as per Section 7 of [RFC7252].
[RFC7252]で定義されている「coap」および「coaps」スキームと同様に、このセクションで定義されているすべてのURIスキームは、[RFC5785]で「よく知られた場所」として定義されているパス接頭辞「/.well-known/」もサポートしています。ホストの名前空間。これにより、[RFC7252]のセクション7に基づく検出が可能になります。
The "coap+tcp" URI scheme identifies CoAP resources that are intended to be accessible using CoAP over TCP.
「coap + tcp」URIスキームは、CoAP over TCPを使用してアクセスできるようになっているCoAPリソースを識別します。
coap-tcp-URI = "coap+tcp:" "//" host [ ":" port ]
path-abempty [ "?" query ]
The syntax defined in Section 6.1 of [RFC7252] applies to this URI scheme, with the following change:
[RFC7252]のセクション6.1で定義されている構文は、このURIスキームに適用されますが、次の変更が加えられています。
o The port subcomponent indicates the TCP port at which the CoAP Connection Acceptor is located. (If it is empty or not given, then the default port 5683 is assumed, as with UDP.)
o ポートサブコンポーネントは、CoAP接続アクセプターが配置されているTCPポートを示します。 （それが空または指定されていない場合、UDPと同様に、デフォルトのポート5683が想定されます。）
Encoding considerations: The scheme encoding conforms to the encoding rules established for URIs in [RFC3986].
エンコーディングに関する考慮事項：スキームエンコーディングは、[RFC3986]でURIに対して確立されたエンコーディングルールに準拠しています。
Interoperability considerations: None.
相互運用性に関する考慮事項：なし。
Security considerations: See Section 11.1 of [RFC7252].
セキュリティに関する考慮事項：[RFC7252]のセクション11.1を参照してください。
The "coaps+tcp" URI scheme identifies CoAP resources that are intended to be accessible using CoAP over TCP secured with TLS.
「coaps + tcp」URIスキームは、TLSで保護されたCoAP over TCPを使用してアクセスできるようになっているCoAPリソースを識別します。
coaps-tcp-URI = "coaps+tcp:" "//" host [ ":" port ]
path-abempty [ "?" query ]
The syntax defined in Section 6.2 of [RFC7252] applies to this URI scheme, with the following changes:
[RFC7252]のセクション6.2で定義された構文は、このURIスキームに適用されますが、次の変更点があります。
o The port subcomponent indicates the TCP port at which the TLS server for the CoAP Connection Acceptor is located. If it is empty or not given, then the default port 5684 is assumed.
o ポートサブコンポーネントは、CoAP接続アクセプターのTLSサーバーが配置されているTCPポートを示します。空の場合または指定されていない場合は、デフォルトのポート5684が想定されます。
o If a TLS server does not support the Application-Layer Protocol Negotiation (ALPN) extension [RFC7301] or wishes to accommodate TLS clients that do not support ALPN, it MAY offer a coaps+tcp endpoint on TCP port 5684. This endpoint MAY also be ALPN enabled. A TLS server MAY offer coaps+tcp endpoints on ports other than TCP port 5684, which MUST be ALPN enabled.
o TLSサーバーがアプリケーション層プロトコルネゴシエーション（ALPN）拡張[RFC7301]をサポートしていない場合、またはALPNをサポートしていないTLSクライアントに対応したい場合は、TCPポート5684でcoaps + tcpエンドポイントを提供できます。このエンドポイントは、 ALPNが有効になっています。 TLSサーバーはTCPポート5684以外のポートでcoaps + tcpエンドポイントを提供してもよい（MAY）、ALPNを有効にする必要があります。
o For TCP ports other than port 5684, the TLS client MUST use the ALPN extension to advertise the "coap" protocol identifier (see Section 11.7) in the list of protocols in its ClientHello. If the TCP server selects and returns the "coap" protocol identifier using the ALPN extension in its ServerHello, then the connection succeeds. If the TLS server either does not negotiate the ALPN extension or returns a no_application_protocol alert, the TLS client MUST close the connection.
o ポート5684以外のTCPポートの場合、TLSクライアントは、ALPN拡張を使用して、ClientHelloのプロトコルのリストで「coap」プロトコル識別子（セクション11.7を参照）を通知する必要があります。 TCPサーバーがServerHelloのALPN拡張を使用して「coap」プロトコル識別子を選択して返す場合、接続は成功します。 TLSサーバーがALPN拡張をネゴシエートしないか、no_application_protocolアラートを返す場合、TLSクライアントは接続を閉じる必要があります。
o For TCP port 5684, a TLS client MAY use the ALPN extension to advertise the "coap" protocol identifier in the list of protocols in its ClientHello. If the TLS server selects and returns the "coap" protocol identifier using the ALPN extension in its ServerHello, then the connection succeeds. If the TLS server returns a no_application_protocol alert, then the TLS client MUST close the connection. If the TLS server does not negotiate the ALPN extension, then coaps+tcp is implicitly selected.
o TCPポート5684の場合、TLSクライアントは、ALPN拡張を使用して、ClientHelloのプロトコルのリストにある「coap」プロトコル識別子を通知できます（MAY）。 TLSサーバーがServerHelloのALPN拡張を使用して「coap」プロトコル識別子を選択して返す場合、接続は成功します。 TLSサーバーがno_application_protocolアラートを返す場合、TLSクライアントは接続を閉じる必要があります。 TLSサーバーがALPN拡張をネゴシエートしない場合、coaps + tcpが暗黙的に選択されます。
o For TCP port 5684, if the TLS client does not use the ALPN extension to negotiate the protocol, then coaps+tcp is implicitly selected.
o TCPポート5684の場合、TLSクライアントがプロトコルのネゴシエーションにALPN拡張を使用しない場合、coaps + tcpが暗黙的に選択されます。
Encoding considerations: The scheme encoding conforms to the encoding rules established for URIs in [RFC3986].
エンコーディングに関する考慮事項：スキームエンコーディングは、[RFC3986]でURIに対して確立されたエンコーディングルールに準拠しています。
Interoperability considerations: None.
相互運用性に関する考慮事項：なし。
Security considerations: See Section 11.1 of [RFC7252].
セキュリティに関する考慮事項：[RFC7252]のセクション11.1を参照してください。
The "coap+ws" URI scheme identifies CoAP resources that are intended to be accessible using CoAP over WebSockets.
「coap + ws」URIスキームは、CoAP over WebSocketsを使用してアクセスできるようになっているCoAPリソースを識別します。
coap-ws-URI = "coap+ws:" "//" host [ ":" port ]
path-abempty [ "?" query ]
The port subcomponent is OPTIONAL. The default is port 80.
ポートのサブコンポーネントはオプションです。デフォルトはポート80です。
The WebSocket endpoint is identified by a "ws" URI that is composed of the authority part of the "coap+ws" URI and the well-known path "/.well-known/coap" [RFC5785] [RFC8307]. Within the endpoint specified in a "coap+ws" URI, the path and query parts of the URI identify a resource that can be operated on by the methods defined by CoAP:
WebSocketエンドポイントは、「coap + ws」URIの権限部分と既知のパス「/.well-known/coap」[RFC5785] [RFC8307]で構成される「ws」URIによって識別されます。 「coap + ws」URIで指定されたエンドポイント内で、URIのパスとクエリ部分は、CoAPで定義されたメソッドで操作できるリソースを識別します。
coap+ws://example.org/sensors/temperature?u=Cel
\______ ______/\___________ ___________/
\/ \/
Uri-Path: "sensors"
ws://example.org/.well-known/coap Uri-Path: "temperature"
Uri-Query: "u=Cel"
Figure 15: The "coap+ws" URI Scheme
図15：「coap + ws」URIスキーム
Encoding considerations: The scheme encoding conforms to the encoding rules established for URIs in [RFC3986].
エンコーディングに関する考慮事項：スキームエンコーディングは、[RFC3986]でURIに対して確立されたエンコーディングルールに準拠しています。
Interoperability considerations: None.
相互運用性に関する考慮事項：なし。
Security considerations: See Section 11.1 of [RFC7252].
セキュリティに関する考慮事項：[RFC7252]のセクション11.1を参照してください。
The "coaps+ws" URI scheme identifies CoAP resources that are intended to be accessible using CoAP over WebSockets secured by TLS.
「coaps + ws」URIスキームは、TLSで保護されたWebSockets上のCoAPを使用してアクセスできるようになっているCoAPリソースを識別します。
coaps-ws-URI = "coaps+ws:" "//" host [ ":" port ]
path-abempty [ "?" query ]
The port subcomponent is OPTIONAL. The default is port 443.
ポートのサブコンポーネントはオプションです。デフォルトはポート443です。
The WebSocket endpoint is identified by a "wss" URI that is composed of the authority part of the "coaps+ws" URI and the well-known path "/.well-known/coap" [RFC5785] [RFC8307]. Within the endpoint specified in a "coaps+ws" URI, the path and query parts of the URI identify a resource that can be operated on by the methods defined by CoAP:
WebSocketエンドポイントは、「coaps + ws」URIの権限部分と既知のパス「/.well-known/coap」[RFC5785] [RFC8307]で構成される「wss」URIによって識別されます。 「coaps + ws」URIで指定されたエンドポイント内で、URIのパスとクエリ部分は、CoAPで定義されたメソッドで操作できるリソースを識別します。
coaps+ws://example.org/sensors/temperature?u=Cel
\______ ______/\___________ ___________/
\/ \/
Uri-Path: "sensors"
wss://example.org/.well-known/coap Uri-Path: "temperature"
Uri-Query: "u=Cel"
Figure 16: The "coaps+ws" URI Scheme
図16：「coaps + ws」URIスキーム
Encoding considerations: The scheme encoding conforms to the encoding rules established for URIs in [RFC3986].
エンコーディングに関する考慮事項：スキームエンコーディングは、[RFC3986]でURIに対して確立されたエンコーディングルールに準拠しています。
Interoperability considerations: None.
相互運用性に関する考慮事項：なし。
Security considerations: See Section 11.1 of [RFC7252].
セキュリティに関する考慮事項：[RFC7252]のセクション11.1を参照してください。
CoAP over reliable transports maintains the property from Section 5.10.1 of [RFC7252]:
信頼性の高いトランスポート上のCoAPは、[RFC7252]のセクション5.10.1の特性を維持します。
The default values for the Uri-Host and Uri-Port Options are sufficient for requests to most servers.
ほとんどのサーバーへの要求には、Uri-HostおよびUri-Portオプションのデフォルト値で十分です。
Unless otherwise noted, the default value of the Uri-Host Option is the IP literal representing the destination IP address of the request message. The default value of the Uri-Port Option is the destination TCP port.
特に明記されていない限り、Uri-Hostオプションのデフォルト値は、要求メッセージの宛先IPアドレスを表すIPリテラルです。 Uri-Portオプションのデフォルト値は、宛先TCPポートです。
For CoAP over TLS, these default values are the same, unless Server Name Indication (SNI) [RFC6066] is negotiated. In this case, the default value of the Uri-Host Option in requests from the TLS client to the TLS server is the SNI host.
CoAP over TLSの場合、サーバー名表示（SNI）[RFC6066]がネゴシエートされない限り、これらのデフォルト値は同じです。この場合、TLSクライアントからTLSサーバーへのリクエストのUri-Hostオプションのデフォルト値はSNIホストです。
For CoAP over WebSockets, the default value of the Uri-Host Option in requests from the WebSocket client to the WebSocket server is indicated by the Host header field from the WebSocket handshake.
CoAP over WebSocketsの場合、WebSocketクライアントからWebSocketサーバーへのリクエストのUri-Hostオプションのデフォルト値は、WebSocketハンドシェイクのHostヘッダーフィールドで示されます。
The steps are the same as those specified in Section 6.4 of [RFC7252], with minor changes:
手順は、[RFC7252]のセクション6.4で指定されている手順と同じですが、若干の変更があります。
This step from [RFC7252]:
[RFC7252]からのこのステップ：
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>コンポーネントがない場合、このアルゴリズムは失敗します。
is updated to:
更新：
3. If |url| does not have a <scheme> component whose value, when converted to ASCII lowercase, is "coap+tcp", "coaps+tcp", "coap+ws", or "coaps+ws", then fail this algorithm.
3. | url |の場合ASCII小文字に変換したときに値が「coap + tcp」、「coaps + tcp」、「coap + ws」、または「coaps + ws」である<scheme>コンポーネントがない場合、このアルゴリズムは失敗します。
This step from [RFC7252]:
[RFC7252]からのこのステップ：
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ポートオプションを含み、そのオプションの値を|ポート|にします。
is updated to:
更新：
7. If |port| does not equal the request's destination TCP port, include a Uri-Port Option and let that option's value be |port|.
7. | port |の場合リクエストの宛先TCPポートと等しくなく、URIポートオプションを含め、そのオプションの値を|ポート|にします。
The steps are the same as those specified in Section 6.5 of [RFC7252], with minor changes:
手順は、[RFC7252]のセクション6.5で指定されたものと同じですが、若干の変更があります。
This step from [RFC7252]:
[RFC7252]からのこのステップ：
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：//"です。
is updated to:
更新：
1. For CoAP over TCP, if the request is secured using TLS, let |url| be the string "coaps+tcp://". Otherwise, let |url| be the string "coap+tcp://". For CoAP over WebSockets, if the request is secured using TLS, let |url| be the string "coaps+ws://". Otherwise, let |url| be the string "coap+ws://".
1. CoAP over TCPの場合、要求がTLSを使用して保護されている場合は、| url |とします。文字列は "coaps + tcp：//"です。それ以外の場合は、| url |文字列は "coap + tcp：//"です。 CoAP over WebSocketsの場合、要求がTLSを使用して保護されている場合は、| url |文字列は "coaps + ws：//"です。それ以外の場合は、| url |文字列は "coap + ws：//"です。
This step from [RFC7252]:
[RFC7252]からのこのステップ：
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ポート。
is updated to:
更新：
4. If the request includes a Uri-Port Option, let |port| be that option's value. Otherwise, let |port| be the request's destination TCP port.
4. リクエストにURIポートオプションが含まれている場合は、| port |そのオプションの値である。それ以外の場合は、|ポート|リクエストの宛先TCPポートです。
"Security Challenges For the Internet Of Things" [SecurityChallenges] recommends the following:
「モノのインターネットのためのセキュリティの課題」[SecurityChallenges]は以下を推奨しています。
... it is essential that IoT protocol suites specify a mandatory to implement but optional to use security solution. This will ensure security is available in all implementations, but configurable to use when not necessary (e.g., in closed environment). ... even if those features stretch the capabilities of such devices.
... IoTプロトコルスイートでは、セキュリティソリューションを実装するために必須で、オプションで使用することを指定することが不可欠です。これにより、すべての実装でセキュリティが利用可能になりますが、必要でない場合（たとえば、閉じた環境）で使用するように構成できます。 ...それらの機能がそのようなデバイスの機能を拡張する場合でも。
A security solution MUST be implemented to protect CoAP over reliable transports and MUST be enabled by default. This document defines the TLS binding, but alternative solutions at different layers in the protocol stack MAY be used to protect CoAP over reliable transports when appropriate. Note that there is ongoing work to support a data-object-based security model for CoAP that is independent of transport (see [OSCORE]).
信頼できるトランスポートを介してCoAPを保護するためにセキュリティソリューションを実装する必要があり、デフォルトで有効にする必要があります。このドキュメントではTLSバインディングを定義していますが、プロトコルスタックのさまざまな層にある代替ソリューションを使用して、適切な場合に信頼性の高いトランスポートを介してCoAPを保護できます。トランスポートに依存しないCoAPのデータオブジェクトベースのセキュリティモデルをサポートするための作業が進行中であることに注意してください（[OSCORE]を参照）。
The TLS usage guidance in [RFC7925] applies, including the guidance about cipher suites in that document that are derived from the mandatory-to-implement cipher suites defined in [RFC7252].
[RFC7925]で定義された必須から実装までの暗号スイートから派生した、そのドキュメントの暗号スイートに関するガイダンスを含む、[RFC7925]のTLS使用ガイダンスが適用されます。
This guidance assumes implementation in a constrained device or for communication with a constrained device. However, CoAP over TCP/TLS has a wider applicability. It may, for example, be implemented on a gateway or on a device that is less constrained (such as a smart phone or a tablet), for communication with a peer that is likewise less constrained, or within a back-end environment that only communicates with constrained devices via proxies. As an exception to the previous paragraph, in this case, the recommendations in [RFC7525] are more appropriate.
このガイダンスでは、制約付きデバイスでの実装、または制約付きデバイスとの通信を想定しています。ただし、CoAP over TCP / TLSにはより広い適用範囲があります。たとえば、ゲートウェイや、制約の少ないデバイス（スマートフォンやタブレットなど）、同様に制約の少ないピアとの通信、またはバックエンド環境でのみ実装できます。プロキシ経由で制約されたデバイスと通信します。前の段落の例外として、この場合、[RFC7525]の推奨事項がより適切です。
Since the guidance offered in [RFC7925] differs from the guidance offered in [RFC7525] in terms of algorithms and credential types, it is assumed that an implementation of CoAP over TCP/TLS that needs to support both cases implements the recommendations offered by both specifications.
[RFC7925]で提供されるガイダンスは[RFC7525]で提供されるガイダンスとはアルゴリズムと資格情報の種類が異なるため、両方のケースをサポートする必要があるCoAP over TCP / TLSの実装は、両方の仕様で提供される推奨事項を実装すると想定されています。
During the provisioning phase, a CoAP device is provided with the security information that it needs, including keying materials, access control lists, and authorization servers. At the end of the provisioning phase, the device will be in one of four security modes:
プロビジョニングフェーズでは、CoAPデバイスに必要なセキュリティ情報（キー情報、アクセス制御リスト、承認サーバーなど）が提供されます。プロビジョニングフェーズの最後に、デバイスは次の4つのセキュリティモードのいずれかになります。
NoSec: TLS is disabled.
NoSec：TLSは無効です。
PreSharedKey: TLS is enabled. The guidance in Section 4.2 of [RFC7925] applies.
PreSharedKey：TLSが有効になっています。 [RFC7925]のセクション4.2のガイダンスが適用されます。
RawPublicKey: TLS is enabled. The guidance in Section 4.3 of [RFC7925] applies.
RawPublicKey：TLSが有効になっています。 [RFC7925]のセクション4.3のガイダンスが適用されます。
Certificate: TLS is enabled. The guidance in Section 4.4 of [RFC7925] applies.
証明書：TLSが有効になっています。 [RFC7925]のセクション4.4のガイダンスが適用されます。
The "NoSec" mode is optional to implement. The system simply sends the packets over normal TCP; this is indicated by the "coap+tcp" scheme and the TCP 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.
「NoSec」モードの実装はオプションです。システムは、通常のTCPを介してパケットを送信するだけです。これは、「coap + tcp」スキームとTCP CoAPデフォルトポートによって示されます。システムは、攻撃者がCoAPノードを使用してネットワークからパケットを送受信できないようにすることによってのみ保護されます。
"PreSharedKey", "RawPublicKey", or "Certificate" is mandatory to implement for the TLS binding, depending on the credential type used with the device. These security modes are achieved using TLS and are indicated by the "coaps+tcp" scheme and TLS-secured CoAP default port.
「PreSharedKey」、「RawPublicKey」、または「Certificate」は、デバイスで使用される資格情報の種類に応じて、TLSバインディングの実装に必須です。これらのセキュリティモードはTLSを使用して実現され、「coaps + tcp」スキームとTLSで保護されたCoAPデフォルトポートによって示されます。
A CoAP client requesting a resource identified by a "coaps+ws" URI negotiates a secure WebSocket connection to a WebSocket server endpoint with a "wss" URI. This is described in Section 8.4.
「coaps + ws」URIで識別されるリソースを要求するCoAPクライアントは、「wss」URIを使用してWebSocketサーバーエンドポイントへの安全なWebSocket接続をネゴシエートします。これはセクション8.4で説明されています。
The client MUST perform a TLS handshake after opening the connection to the server. The guidance in Section 4.1 of [RFC6455] applies. When a CoAP server exposes resources identified by a "coaps+ws" URI, the guidance in Section 4.4 of [RFC7925] applies towards mandatory-to-implement TLS functionality for certificates. For the server-side requirements for accepting incoming connections over an HTTPS (HTTP over TLS) port, the guidance in Section 4.2 of [RFC6455] applies.
クライアントは、サーバーへの接続を開いた後にTLSハンドシェイクを実行する必要があります。 [RFC6455]のセクション4.1のガイダンスが適用されます。 CoAPサーバーが「coaps + ws」URIで識別されるリソースを公開する場合、[RFC7925]のセクション4.4のガイダンスが、証明書の必須から実装へのTLS機能に適用されます。 HTTPS（HTTP over TLS）ポートを介した着信接続を受け入れるためのサーバー側の要件については、[RFC6455]のセクション4.2のガイダンスが適用されます。
Note that the guidance above formally inherits the mandatory-to-implement cipher suites defined in [RFC5246]. However, modern browsers usually implement cipher suites that are more recent; these cipher suites are then automatically picked up via the JavaScript WebSocket API. WebSocket servers that provide secure CoAP over WebSockets for the browser use case will need to follow the browser preferences and MUST follow [RFC7525].
上記のガイダンスは、[RFC5246]で定義されている必須から実装までの暗号スイートを正式に継承していることに注意してください。ただし、最近のブラウザーは通常、より新しい暗号スイートを実装しています。これらの暗号スイートは、JavaScript WebSocket APIを介して自動的に取得されます。ブラウザーの使用例にWebSocketを介した安全なCoAPを提供するWebSocketサーバーは、ブラウザーの設定に従う必要があり、[RFC7525]に従う必要があります。
The security considerations of [RFC7252] apply. For CoAP over WebSockets and CoAP over TLS-secured WebSockets, the security considerations of [RFC6455] also apply.
[RFC7252]のセキュリティに関する考慮事項が適用されます。 CoAP over WebSocketsおよびCoAP over TLSで保護されたWebSocketの場合、[RFC6455]のセキュリティに関する考慮事項も適用されます。
The guidance given by an Alternative-Address Option cannot be followed blindly. In particular, a peer MUST NOT assume that a successful connection to the Alternative-Address inherits all the security properties of the current connection.
Alternative-Address Optionによって提供されるガイダンスは、盲目的には従うことができません。特に、ピアは、Alternative-Addressへの正常な接続が現在の接続のすべてのセキュリティプロパティを継承すると想定してはなりません（MUST NOT）。
IANA has created a third subregistry for values of the Code field in the CoAP header (Section 12.1 of [RFC7252]). The name of this subregistry is "CoAP Signaling Codes".
IANAは、CoAPヘッダーのコードフィールドの値に対して3番目のサブレジストリを作成しました（[RFC7252]のセクション12.1）。このサブレジストリの名前は「CoAPシグナリングコード」です。
Each entry in the subregistry must include the Signaling Code in the range 7.00-7.31, its name, and a reference to its documentation.
サブレジストリの各エントリには、7.00〜7.31の範囲のシグナリングコードとその名前、およびそのドキュメントへの参照を含める必要があります。
Initial entries in this subregistry are as follows:
このサブレジストリの最初のエントリは次のとおりです。
+------+---------+-----------+
| Code | Name | Reference |
+------+---------+-----------+
| 7.01 | CSM | RFC 8323 |
| | | |
| 7.02 | Ping | RFC 8323 |
| | | |
| 7.03 | Pong | RFC 8323 |
| | | |
| 7.04 | Release | RFC 8323 |
| | | |
| 7.05 | Abort | RFC 8323 |
+------+---------+-----------+
Table 1: CoAP Signaling Codes
表1：CoAPシグナリングコード
All other Signaling Codes are Unassigned.
他のすべてのシグナリングコードは割り当てられていません。
The IANA policy for future additions to this subregistry is "IETF Review" or "IESG Approval" as described in [RFC8126].
このサブレジストリに将来追加されるIANAポリシーは、[RFC8126]で説明されている「IETFレビュー」または「IESG承認」です。
IANA has created a subregistry for Option Numbers used in CoAP Signaling Options within the "Constrained RESTful Environments (CoRE) Parameters" registry. The name of this subregistry is "CoAP Signaling Option Numbers".
IANAは、「制約付きRESTful環境（CoRE）パラメータ」レジストリ内のCoAPシグナリングオプションで使用されるオプション番号のサブレジストリを作成しました。このサブレジストリの名前は「CoAPシグナリングオプション番号」です。
Each entry in the subregistry must include one or more of the codes in the "CoAP Signaling Codes" subregistry (Section 11.1), the number for the Option, the name of the Option, and a reference to the Option's documentation.
サブレジストリの各エントリには、「CoAP Signaling Codes」サブレジストリの1つ以上のコード（セクション11.1）、オプションの番号、オプションの名前、およびオプションのドキュメントへの参照を含める必要があります。
Initial entries in this subregistry are as follows:
このサブレジストリの最初のエントリは次のとおりです。
+------------+--------+---------------------+-----------+
| Applies to | Number | Name | Reference |
+------------+--------+---------------------+-----------+
| 7.01 | 2 | Max-Message-Size | RFC 8323 |
| | | | |
| 7.01 | 4 | Block-Wise-Transfer | RFC 8323 |
| | | | |
| 7.02, 7.03 | 2 | Custody | RFC 8323 |
| | | | |
| 7.04 | 2 | Alternative-Address | RFC 8323 |
| | | | |
| 7.04 | 4 | Hold-Off | RFC 8323 |
| | | | |
| 7.05 | 2 | Bad-CSM-Option | RFC 8323 |
+------------+--------+---------------------+-----------+
Table 2: CoAP Signaling Option Codes
表2：CoAPシグナリングオプションコード
The IANA policy for future additions to this subregistry is based on number ranges for the option numbers, analogous to the policy defined in Section 12.2 of [RFC7252]. (The policy is analogous rather than identical because the structure of this subregistry includes an additional column ("Applies to"); however, the value of this column has no influence on the policy.)
このサブレジストリへの将来の追加に関するIANAポリシーは、[RFC7252]のセクション12.2で定義されているポリシーに類似した、オプション番号の番号範囲に基づいています。 （このサブレジストリの構造には追加の列（「適用先」）が含まれているため、ポリシーは同一ではなく類似しています。ただし、この列の値はポリシーに影響を与えません。）
The documentation for a Signaling Option Number should specify the semantics of an option with that number, including the following properties:
シグナリングオプション番号のドキュメントでは、次のプロパティを含む、その番号を持つオプションのセマンティクスを指定する必要があります。
o Whether the option is critical or elective, as determined by the Option Number.
o オプション番号によって決定される、オプションが重要であるか選択的であるか。
o Whether the option is repeatable.
o オプションが反復可能かどうか。
o The format and length of the option's value.
o オプションの値の形式と長さ。
o The base value for the option, if any.
o オプションのベース値（ある場合）。
IANA has assigned the port number 5683 and the service name "coap", in accordance with [RFC6335].
IANAは、[RFC6335]に従って、ポート番号5683とサービス名「coap」を割り当てました。
Service Name: coap
サービス名：coap
Transport Protocol: tcp
トランスポートプロトコル：tcp
Assignee:
IESG <iesg@ietf.org>
Contact:
IETF Chair <chair@ietf.org>
Description: Constrained Application Protocol (CoAP)
説明：制約付きアプリケーションプロトコル（CoAP）
Reference: RFC 8323
リファレンス：RFC 8323
Port Number: 5683
ポート番号：5683
IANA has assigned the port number 5684 and the service name "coaps", in accordance with [RFC6335]. The port number is to address the exceptional case of TLS implementations that do not support the ALPN extension [RFC7301].
IANAは、[RFC6335]に従って、ポート番号5684とサービス名「coaps」を割り当てました。ポート番号は、ALPN拡張[RFC7301]をサポートしないTLS実装の例外的なケースに対処するためのものです。
Service Name: coaps
サービス名：coaps
Transport Protocol: tcp
トランスポートプロトコル：tcp
Assignee:
IESG <iesg@ietf.org>
Contact:
IETF Chair <chair@ietf.org>
Description: Constrained Application Protocol (CoAP)
説明：制約付きアプリケーションプロトコル（CoAP）
Reference: [RFC7301], RFC 8323
参照：[RFC7301]、RFC 8323
Port Number: 5684
ポート番号：5684
URI schemes are registered within the "Uniform Resource Identifier (URI) Schemes" registry maintained at [IANA.uri-schemes].
URIスキームは、[IANA.uri-schemes]で管理されている「Uniform Resource Identifier（URI）Schemes」レジストリ内に登録されています。
Note: The following has been added as a note for each of the URI schemes defined in this document:
注：以下は、このドキュメントで定義されている各URIスキームのメモとして追加されています。
CoAP registers different URI schemes for accessing CoAP resources via different protocols. This approach runs counter to the WWW principle that a URI identifies a resource and that multiple URIs for identifying the same resource should be avoided <https://www.w3.org/TR/webarch/#avoid-uri-aliases>.
CoAPは、さまざまなプロトコルを介してCoAPリソースにアクセスするためのさまざまなURIスキームを登録します。このアプローチは、URIがリソースを識別し、同じリソースを識別するための複数のURIは回避する必要があるというWWWの原則に反します<https://www.w3.org/TR/webarch/#avoid-uri-aliases>。
This is not a problem for many of the usage scenarios envisioned for CoAP over reliable transports; additional URI schemes can be introduced to address additional usage scenarios (as being prepared, for example, in [Multi-Transport-URIs] and [CoAP-Alt-Transports]).
これは、信頼できるトランスポート上のCoAPで想定される多くの使用シナリオでは問題ではありません。追加のURIスキームを導入して、追加の使用シナリオに対処することができます（たとえば、[Multi-Transport-URIs]および[CoAP-Alt-Transports]で準備されている）。
IANA has registered the URI scheme "coap+tcp". This registration request complies with [RFC7595].
IANAはURIスキーム「coap + tcp」を登録しています。この登録要求は[RFC7595]に準拠しています。
Scheme name: coap+tcp
スキーム名：coap + tcp
Status: Permanent
ステータス：永久
Applications/protocols that use this scheme name: The scheme is used by CoAP endpoints to access CoAP resources using TCP.
このスキーム名を使用するアプリケーション/プロトコル：このスキームは、CoAPエンドポイントがTCPを使用してCoAPリソースにアクセスするために使用されます。
Contact:
IETF Chair <chair@ietf.org>
Change controller:
IESG <iesg@ietf.org>
Reference: Section 8.1 in RFC 8323
参照：RFC 8323のセクション8.1
IANA has registered the URI scheme "coaps+tcp". This registration request complies with [RFC7595].
IANAはURIスキーム「coaps + tcp」を登録しました。この登録要求は[RFC7595]に準拠しています。
Scheme name: coaps+tcp
スキーム名：coaps + tcp
Status: Permanent
ステータス：永久
Applications/protocols that use this scheme name: The scheme is used by CoAP endpoints to access CoAP resources using TLS.
このスキーム名を使用するアプリケーション/プロトコル：このスキームは、TLSを使用してCoAPリソースにアクセスするためにCoAPエンドポイントによって使用されます。
Contact:
IETF Chair <chair@ietf.org>
Change controller:
IESG <iesg@ietf.org>
Reference: Section 8.2 in RFC 8323
参照：RFC 8323のセクション8.2
IANA has registered the URI scheme "coap+ws". This registration request complies with [RFC7595].
IANAはURIスキーム「coap + ws」を登録しています。この登録要求は[RFC7595]に準拠しています。
Scheme name: coap+ws
スキーム名：coap + ws
Status: Permanent
ステータス：永久
Applications/protocols that use this scheme name: The scheme is used by CoAP endpoints to access CoAP resources using the WebSocket Protocol.
このスキーム名を使用するアプリケーション/プロトコル：このスキームは、WebSocketプロトコルを使用してCoAPリソースにアクセスするためにCoAPエンドポイントによって使用されます。
Contact:
IETF Chair <chair@ietf.org>
Change controller:
IESG <iesg@ietf.org>
Reference: Section 8.3 in RFC 8323
参照：RFC 8323のセクション8.3
IANA has registered the URI scheme "coaps+ws". This registration request complies with [RFC7595].
IANAはURIスキーム「coaps + ws」を登録しています。この登録要求は[RFC7595]に準拠しています。
Scheme name: coaps+ws
スキーム名：coaps + ws
Status: Permanent
ステータス：永久
Applications/protocols that use this scheme name: The scheme is used by CoAP endpoints to access CoAP resources using the WebSocket Protocol secured with TLS.
このスキーム名を使用するアプリケーション/プロトコル：このスキームは、TLSで保護されたWebSocketプロトコルを使用してCoAPリソースにアクセスするためにCoAPエンドポイントによって使用されます。
Contact:
IETF Chair <chair@ietf.org>
Change controller:
IESG <iesg@ietf.org>
References: Section 8.4 in RFC 8323
参考資料：RFC 8323のセクション8.4
IANA has registered "coap" in the "Well-Known URIs" registry. This registration request complies with [RFC5785].
IANAは「既知のURI」レジストリに「coap」を登録しました。この登録要求は[RFC5785]に準拠しています。
URI suffix: coap
うり すっふぃｘ： こあｐ
Change controller: IETF
コントローラの変更：IETF
Specification document(s): RFC 8323
仕様書：RFC 8323
Related information: None.
関連情報：なし。
IANA has assigned the following value in the "Application-Layer Protocol Negotiation (ALPN) Protocol IDs" registry created by [RFC7301]. The "coap" string identifies CoAP when used over TLS.
IANAは、[RFC7301]によって作成された "Application-Layer Protocol Negotiation（ALPN）Protocol IDs"レジストリに次の値を割り当てました。 「coap」文字列は、TLSを介して使用される場合にCoAPを識別します。
Protocol: CoAP
プロトコル：CoAP
Identification Sequence: 0x63 0x6f 0x61 0x70 ("coap")
識別シーケンス：0x63 0x6f 0x61 0x70（ "coap"）
Reference: RFC 8323
リファレンス：RFC 8323
IANA has registered the WebSocket CoAP subprotocol in the "WebSocket Subprotocol Name Registry":
IANAは、「WebSocketサブプロトコル名レジストリ」にWebSocket CoAPサブプロトコルを登録しました。
Subprotocol Identifier: coap
サブプロトコル識別子：coap
Subprotocol Common Name: Constrained Application Protocol (CoAP)
サブプロトコルの一般名：制約付きアプリケーションプロトコル（CoAP）
Subprotocol Definition: RFC 8323
サブプロトコル定義：RFC 8323
IANA has added this document as a reference for the following entries registered by [RFC7959] in the "CoAP Option Numbers" subregistry defined by [RFC7252]:
IANAは、[RFC7252]によって定義された「CoAP Option Numbers」サブレジストリの[RFC7959]によって登録された次のエントリの参照として、このドキュメントを追加しました。
+--------+--------+--------------------+
| Number | Name | Reference |
+--------+--------+--------------------+
| 23 | Block2 | RFC 7959, RFC 8323 |
| | | |
| 27 | Block1 | RFC 7959, RFC 8323 |
+--------+--------+--------------------+
Table 3: CoAP Option Numbers
表3：CoAPオプション番号
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <https://www.rfc-editor.org/info/rfc793>.
[RFC793] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、DOI 10.17487 / RFC0793、1981年9月、<https://www.rfc-editor.org/info/rfc793>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、DOI 10.17487 / RFC3986、2005年1月、<https：/ /www.rfc-editor.org/info/rfc3986>。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234] Crocker、D.、Ed。、およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<https：//www.rfc-editor .org / info / rfc5234>。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、DOI 10.17487 / RFC5246、2008年8月、<https://www.rfc-editor.org/info / rfc5246>。
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, DOI 10.17487/RFC5785, April 2010, <https://www.rfc-editor.org/info/rfc5785>.
[RFC5785]ノッティンガム、M。およびE.ハマーラハブ、「Defining Well-Known Uniform Resource Identifiers（URIs）」、RFC 5785、DOI 10.17487 / RFC5785、2010年4月、<https://www.rfc-editor.org / info / rfc5785>。
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, <https://www.rfc-editor.org/info/rfc6066>.
[RFC6066] Eastlake 3rd、D。、「Transport Layer Security（TLS）Extensions：Extension Definitions」、RFC 6066、DOI 10.17487 / RFC6066、2011年1月、<https://www.rfc-editor.org/info/rfc6066> 。
[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, DOI 10.17487/RFC6455, December 2011, <https://www.rfc-editor.org/info/rfc6455>.
[RFC6455] Fette、I。およびA. Melnikov、「The WebSocket Protocol」、RFC 6455、DOI 10.17487 / RFC6455、2011年12月、<https://www.rfc-editor.org/info/rfc6455>。
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <https://www.rfc-editor.org/info/rfc7252>.
[RFC7252] Shelby、Z.、Hartke、K。、およびC. Bormann、「The Constrained Application Protocol（CoAP）」、RFC 7252、DOI 10.17487 / RFC7252、2014年6月、<https：//www.rfc-editor。 org / info / rfc7252>。
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, July 2014, <https://www.rfc-editor.org/info/rfc7301>.
[RFC7301] Friedl、S.、Popov、A.、Langley、A。、およびE. Stephan、「Transport Layer Security（TLS）Application-Layer Protocol Negotiation Extension」、RFC 7301、DOI 10.17487 / RFC7301、2014年7月、< https://www.rfc-editor.org/info/rfc7301>。
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7525] Sheffer、Y.、Holz、R。、およびP. Saint-Andre、「Transport Layer Security（TLS）およびDatagram Transport Layer Security（DTLS）の安全な使用に関する推奨事項」、BCP 195、RFC 7525、DOI 10.17487 / RFC7525、2015年5月、<https://www.rfc-editor.org/info/rfc7525>。
[RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines and Registration Procedures for URI Schemes", BCP 35, RFC 7595, DOI 10.17487/RFC7595, June 2015, <https://www.rfc-editor.org/info/rfc7595>.
[RFC7595] Thaler、D.、Ed。、Hansen、T。、およびT. Hardie、「URIスキームのガイドラインと登録手順」、BCP 35、RFC 7595、DOI 10.17487 / RFC7595、2015年6月、<https：// www.rfc-editor.org/info/rfc7595>。
[RFC7641] Hartke, K., "Observing Resources in the Constrained Application Protocol (CoAP)", RFC 7641, DOI 10.17487/RFC7641, September 2015, <https://www.rfc-editor.org/info/rfc7641>.
[RFC7641] Hartke、K。、「Observing Resources in the Constrained Application Protocol（CoAP）」、RFC 7641、DOI 10.17487 / RFC7641、2015年9月、<https://www.rfc-editor.org/info/rfc7641>。
[RFC7925] Tschofenig, H., Ed., and T. Fossati, "Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) Profiles for the Internet of Things", RFC 7925, DOI 10.17487/RFC7925, July 2016, <https://www.rfc-editor.org/info/rfc7925>.
[RFC7925] Tschofenig、H.、Ed。、およびT. Fossati、「モノのインターネットのためのトランスポート層セキュリティ（TLS）/データグラムトランスポート層セキュリティ（DTLS）プロファイル」、RFC 7925、DOI 10.17487 / RFC7925、2016年7月、 <https://www.rfc-editor.org/info/rfc7925>。
[RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in the Constrained Application Protocol (CoAP)", RFC 7959, DOI 10.17487/RFC7959, August 2016, <https://www.rfc-editor.org/info/rfc7959>.
[RFC7959] Bormann、C.およびZ. Shelby、Ed。、「Block-Wise Transfers in the Constrained Application Protocol（CoAP）」、RFC 7959、DOI 10.17487 / RFC7959、2016年8月、<https：//www.rfc- editor.org/info/rfc7959>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]コットン、M。、レイバ、B。、およびT.ナルテン、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www .rfc-editor.org / info / rfc8126>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC8307] Bormann, C., "Well-Known URIs for the WebSocket Protocol", RFC 8307, DOI 10.17487/RFC8307, January 2018, <https://www.rfc-editor.org/info/rfc8307>.
[RFC8307] Bormann、C。、「WebSocketプロトコルの既知のURI」、RFC 8307、DOI 10.17487 / RFC8307、2018年1月、<https://www.rfc-editor.org/info/rfc8307>。
[BK2015] Byrne, C. and J. Kleberg, "Advisory Guidelines for UDP Deployment", Work in Progress, draft-byrne-opsec-udp-advisory-00, July 2015.
[BK2015] Byrne、C。およびJ. Kleberg、「UDP展開に関する勧告ガイドライン」、作業中、draft-byrne-opsec-udp-advisory-00、2015年7月。
[CoAP-Alt-Transports] Silverajan, B. and T. Savolainen, "CoAP Communication with Alternative Transports", Work in Progress, draft-silverajan-core-coap-alternative-transports-10, July 2017.
[CoAP-Alt-Transports] Silverajan、B。およびT. Savolainen、「代替トランスポートとのCoAP通信」、作業中、draft-silverajan-core-coap-alternative-transports-10、2017年7月。
[CoCoA] Bormann, C., Betzler, A., Gomez, C., and I. Demirkol, "CoAP Simple Congestion Control/Advanced", Work in Progress, draft-ietf-core-cocoa-02, October 2017.
[CoCoA] Bormann、C.、Betzler、A.、Gomez、C。、およびI. Demirkol、「CoAP Simple Congestion Control / Advanced」、Work in Progress、draft-ietf-core-cocoa-02、2017年10月。
[EK2016] Edeline, K., Kuehlewind, M., Trammell, B., Aben, E., and B. Donnet, "Using UDP for Internet Transport Evolution", arXiv preprint 1612.07816, December 2016, <https://arxiv.org/abs/1612.07816>.
[EK2016] Edeline、K.、Kuehlewind、M.、Trammell、B.、Aben、E。、およびB. Donnet、「UDPを使用したインターネットトランスポートエボリューション」、arXivプレプリント1612.07816、2016年12月、<https：// arxiv .org / abs / 1612.07816>。
[HomeGateway] Haetoenen, S., Nyrhinen, A., Eggert, L., Strowes, S., Sarolahti, P., and N. Kojo, "An experimental study of home gateway characteristics", Proceedings of the 10th ACM SIGCOMM conference on Internet measurement, DOI 10.1145/1879141.1879174, November 2010.
[HomeGateway] Haetoenen、S.、Nyrhinen、A.、Eggert、L.、Strowes、S.、Sarolahti、P.、and N. Kojo、「実験的ゲートウェイ特性の実験的研究」、第10回ACM SIGCOMM会議の議事録インターネット測定、DOI 10.1145 / 1879141.1879174、2010年11月。
[IANA.uri-schemes] IANA, "Uniform Resource Identifier (URI) Schemes", <https://www.iana.org/assignments/uri-schemes>.
[IANA.uri-schemes] IANA、「Uniform Resource Identifier（URI）Schemes」、<https://www.iana.org/assignments/uri-schemes>。
[LWM2M] Open Mobile Alliance, "Lightweight Machine to Machine Technical Specification Version 1.0", February 2017, <http://www.openmobilealliance.org/release/LightweightM2M/ V1_0-20170208-A/ OMA-TS-LightweightM2M-V1_0-20170208-A.pdf>.
[LWM2M] Open Mobile Alliance、「Lightweight Machine to Machine Technical Specification Version 1.0」、2017年2月、<http://www.openmobilealliance.org/release/LightweightM2M/ V1_0-20170208-A / OMA-TS-LightweightM2M-V1_0- 20170208-A.pdf>。
[Multi-Transport-URIs] Thaler, D., "Using URIs With Multiple Transport Stacks", Work in Progress, draft-thaler-appsawg-multi-transport-uris-01, July 2017.
[Multi-Transport-URIs] Thaler、D。、「複数のトランスポートスタックでのURIの使用」、作業中、draft-thaler-appsawg-multi-transport-uris-01、2017年7月。
[OSCORE] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, "Object Security for Constrained RESTful Environments (OSCORE)", Work in Progress, draft-ietf-core-object-security-08, January 2018.
[OSCORE] Selander、G.、Mattsson、J.、Palombini、F。、およびL. Seitz、「制約付きRESTful環境のオブジェクトセキュリティ（OSCORE）」、作業中、draft-ietf-core-object-security-08 、2018年1月。
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <https://www.rfc-editor.org/info/rfc768>.
[RFC768] Postel、J。、「User Datagram Protocol」、STD 6、RFC 768、DOI 10.17487 / RFC0768、1980年8月、<https://www.rfc-editor.org/info/rfc768>。
[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, DOI 10.17487/RFC6335, August 2011, <https://www.rfc-editor.org/info/rfc6335>.
[RFC6335]綿、M。、エガート、L。、タッチ、J。、ウェスターランド、M。、およびS.チェシャー、「サービス名とトランスポートプロトコルのポート番号レジストリの管理のためのInternet Assigned Numbers Authority（IANA）手順"、BCP 165、RFC 6335、DOI 10.17487 / RFC6335、2011年8月、<https://www.rfc-editor.org/info/rfc6335>。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security Version 1.2」、RFC 6347、DOI 10.17487 / RFC6347、2012年1月、<https://www.rfc-editor.org/info/rfc6347>。
[RFC7230] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>.
[RFC7230] Fielding、R.、Ed。、and J. Reschke、Ed。、 "Hypertext Transfer Protocol（HTTP / 1.1）：Message Syntax and Routing"、RFC 7230、DOI 10.17487 / RFC7230、June 2014、<https：/ /www.rfc-editor.org/info/rfc7230>。
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, May 2015, <https://www.rfc-editor.org/info/rfc7540>.
[RFC7540] Belshe、M.、Peon、R。、およびM. Thomson、編、「Hypertext Transfer Protocol Version 2（HTTP / 2）」、RFC 7540、DOI 10.17487 / RFC7540、2015年5月、<https：// www.rfc-editor.org/info/rfc7540>。
[SecurityChallenges] Polk, T. and S. Turner, "Security Challenges For the Internet Of Things", Interconnecting Smart Objects with the Internet / IAB Workshop, February 2011, <https://www.iab.org/wp-content/IAB-uploads/2011/03/ Turner.pdf>.
[SecurityChallenges] Polk、T.、S。ターナー、「モノのインターネットのためのセキュリティの課題」、スマートオブジェクトとインターネットの相互接続/ IABワークショップ、2011年2月、<https://www.iab.org/wp-content/ IAB-uploads / 2011/03 / Turner.pdf>。
[SW2016] Swett, I., "QUIC Deployment Experience @Google", IETF 96 Proceedings, Berlin, Germany, July 2016, <https://www.ietf.org/proceedings/96/slides/ slides-96-quic-3.pdf>.
[SW2016] Swett、I。、「QUIC Deployment Experience @Google」、IETF 96 Proceedings、ベルリン、ドイツ、2016年7月、<https://www.ietf.org/proceedings/96/slides/ slides-96-quic- 3.pdf>。
[TCP-in-IoT] Gomez, C., Crowcroft, J., and M. Scharf, "TCP Usage Guidance in the Internet of Things (IoT)", Work in Progress, draft-ietf-lwig-tcp-constrained-node-networks-01, October 2017.
[TCP-in-IoT] Gomez、C.、Crowcroft、J。、およびM. Scharf、「モノのインターネット（IoT）でのTCP使用ガイダンス」、作業中、draft-ietf-lwig-tcp-constrained- node-networks-01、2017年10月。
This appendix gives examples for the first two configurations discussed in Section 4.
この付録では、セクション4で説明した最初の2つの構成の例を示します。
An example of the process followed by a CoAP client to retrieve the representation of a resource identified by a "coap+ws" URI might be as follows. Figure 17 below illustrates the WebSocket and CoAP messages exchanged in detail.
「coap + ws」URIで識別されるリソースの表現を取得するためにCoAPクライアントが実行するプロセスの例は、次のようになります。以下の図17は、交換されるWebSocketおよびCoAPメッセージを詳細に示しています。
1. The CoAP client obtains the URI <coap+ws://example.org/sensors/temperature?u=Cel>, for example, from a resource representation that it retrieved previously.
1. CoAPクライアントは、たとえば、以前に取得したリソース表現から、URI <coap + ws：//example.org/sensors/temperature？u = Cel>を取得します。
2. The CoAP client establishes a WebSocket connection to the endpoint URI composed of the authority "example.org" and the well-known path "/.well-known/coap", <ws://example.org/.well-known/coap>.
2. CoAPクライアントは、オーソリティ "example.org"と既知のパス "/.well-known/coap"、<ws://example.org/.well-known/で構成されるエンドポイントURIへのWebSocket接続を確立します。コープ>。
3. CSMs (Section 5.3) are exchanged (not shown).
3. CSM（セクション5.3）が交換されます（表示されていません）。
4. The CoAP client sends a single-frame, masked, binary message containing a CoAP request. The request indicates the target resource with the Uri-Path ("sensors", "temperature") and Uri-Query ("u=Cel") Options.
4. CoAPクライアントは、CoAP要求を含む単一フレームのマスクされたバイナリメッセージを送信します。リクエストは、Uri-Path（「センサー」、「温度」）およびUri-Query（「u = Cel」）オプションを使用してターゲットリソースを示します。
5. The CoAP client waits for the server to return a response.
5. CoAPクライアントは、サーバーが応答を返すのを待ちます。
6. The CoAP client uses the connection for further requests, or the connection is closed.
6. CoAPクライアントは、以降の要求に接続を使用するか、接続が閉じられます。
CoAP CoAP Client Server (WebSocket (WebSocket Client) Server)
CoAP CoAPクライアントサーバー（WebSocket（WebSocketクライアント）サーバー）
| |
| |
+=========>| GET /.well-known/coap HTTP/1.1
| | Host: example.org
| | Upgrade: websocket
| | Connection: Upgrade
| | Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
| | Sec-WebSocket-Protocol: coap
| | Sec-WebSocket-Version: 13
| |
|<=========+ HTTP/1.1 101 Switching Protocols
| | Upgrade: websocket
| | Connection: Upgrade
| | Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
| | Sec-WebSocket-Protocol: coap
: :
:<-------->: Exchange of CSMs (not shown)
| |
+--------->| Binary frame (opcode=%x2, FIN=1, MASK=1)
| | +-------------------------+
| | | GET |
| | | Token: 0x53 |
| | | Uri-Path: "sensors" |
| | | Uri-Path: "temperature" |
| | | Uri-Query: "u=Cel" |
| | +-------------------------+
| |
|<---------+ Binary frame (opcode=%x2, FIN=1, MASK=0)
| | +-------------------------+
| | | 2.05 Content |
| | | Token: 0x53 |
| | | Payload: "22.3 Cel" |
| | +-------------------------+
: :
: :
+--------->| Close frame (opcode=%x8, FIN=1, MASK=1)
| |
|<---------+ Close frame (opcode=%x8, FIN=1, MASK=0)
| |
Figure 17: A CoAP Client Retrieves the Representation of a Resource Identified by a "coap+ws" URI
図17：CoAPクライアントが「coap + ws」URIで識別されるリソースの表現を取得する
Figure 18 shows how a CoAP client uses a CoAP forward proxy with a WebSocket endpoint to retrieve the representation of the resource "coap://[2001:db8::1]/". The use of the forward proxy and the address of the WebSocket endpoint are determined by the client from local configuration rules. The request URI is specified in the Proxy-Uri Option. Since the request URI uses the "coap" URI scheme, the proxy fulfills the request by issuing a Confirmable GET request over UDP to the CoAP server and returning the response over the WebSocket connection to the client.
図18は、CoAPクライアントがWebSocketエンドポイントでCoAPフォワードプロキシを使用して、リソース「coap：// [2001：db8 :: 1] /」の表現を取得する方法を示しています。フォワードプロキシの使用とWebSocketエンドポイントのアドレスは、クライアントがローカル構成ルールから決定します。リクエストURIはProxy-Uriオプションで指定されます。要求URIは「coap」URIスキームを使用するため、プロキシは、UDPを介して確認可能なGET要求をCoAPサーバーに発行し、WebSocket接続を介してクライアントに応答を返すことによって要求を満たします。
CoAP CoAP CoAP Client Proxy Server (WebSocket (WebSocket (UDP Client) Server) Endpoint)
CoAP CoAP CoAPクライアントプロキシサーバー（WebSocket（WebSocket（UDPクライアント）サーバー）エンドポイント）
| | |
+--------->| | Binary frame (opcode=%x2, FIN=1, MASK=1)
| | | +------------------------------------+
| | | | GET |
| | | | Token: 0x7d |
| | | | Proxy-Uri: "coap://[2001:db8::1]/" |
| | | +------------------------------------+
| | |
| +--------->| CoAP message (Ver=1, T=Con, MID=0x8f54)
| | | +------------------------------------+
| | | | GET |
| | | | Token: 0x0a15 |
| | | +------------------------------------+
| | |
| |<---------+ CoAP message (Ver=1, T=Ack, MID=0x8f54)
| | | +------------------------------------+
| | | | 2.05 Content |
| | | | Token: 0x0a15 |
| | | | Payload: "ready" |
| | | +------------------------------------+
| | |
|<---------+ | Binary frame (opcode=%x2, FIN=1, MASK=0)
| | | +------------------------------------+
| | | | 2.05 Content |
| | | | Token: 0x7d |
| | | | Payload: "ready" |
| | | +------------------------------------+
| | |
Figure 18: A CoAP Client Retrieves the Representation of a Resource Identified by a "coap" URI via a WebSocket-Enabled CoAP Proxy
図18：CoAPクライアントは、WebSocket対応のCoAPプロキシを介して、「coap」URIで識別されるリソースの表現を取得します
Acknowledgments
謝辞
We would like to thank Stephen Berard, Geoffrey Cristallo, Olivier Delaby, Esko Dijk, Christian Groves, Nadir Javed, Michael Koster, Achim Kraus, David Navarro, Szymon Sasin, Goeran Selander, Zach Shelby, Andrew Summers, Julien Vermillard, and Gengyu Wei for their feedback.
Stephen Berard、Geoffrey Cristallo、Olivier Delaby、Esko Dijk、Christian Groves、Nadir Javed、Michael Koster、Achim Kraus、David Navarro、Szymon Sasin、Goeran Selander、Zach Shelby、Andrew Summers、Julien Vermillard、Gengyu Weiに感謝します彼らのフィードバックのために。
Last Call reviews from Yoshifumi Nishida, Mark Nottingham, and Meral Shirazipour as well as several IESG reviewers provided extensive comments; from the IESG, we would like to specifically call out Ben Campbell, Mirja Kuehlewind, Eric Rescorla, Adam Roach, and the responsible AD Alexey Melnikov.
西田喜文、マークノッティンガム、およびMeral ShirazipourによるラストコールのレビューといくつかのIESGレビューアが広範なコメントを提供しました。 IESGからは、ベンキャンベル、ミルハキュールウィンド、エリックレスコーラ、アダムローチ、担当のADアレクセイメルニコフを具体的に呼びたいと思います。
Contributors
貢献者
Matthias Kovatsch Siemens AG Otto-Hahn-Ring 6 Munich D-81739 Germany
まってぃあｓ こゔぁｔｓｃｈ しえめんｓ あＧ おっとーはｈんーりんｇ ６ むにｃｈ Ｄー８１７３９ げｒまｎｙ
Phone: +49-173-5288856
Email: matthias.kovatsch@siemens.com
Teemu Savolainen Nokia Technologies Hatanpaan valtatie 30 Tampere FI-33100 Finland
Teemu Savolainen Nokia Technologies Hatanpa highway 30 Tampere FI-33100フィンランド
Email: teemu.savolainen@nokia.com
Valik Solorzano Barboza Zebra Technologies 820 W. Jackson Blvd. Suite 700 Chicago, IL 60607 United States of America
Valik Solorzano Barboza Zebra Technologies 820 W. Jackson Blvd. Suite 700 Chicago, IL 60607 United States of America
Phone: +1-847-634-6700
Email: vsolorzanobarboza@zebra.com
Authors' Addresses
著者のアドレス
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
Simon Lemay Zebra Technologies 820 W. Jackson Blvd. Suite 700 Chicago, IL 60607 United States of America
Simon Lemay Zebra Technologies 820 W. Jackson Blvd. Suite 700 Chicago、IL 60607アメリカ合衆国
Phone: +1-847-634-6700
Email: slemay@zebra.com
Hannes Tschofenig ARM Ltd. 110 Fulbourn Road Cambridge CB1 9NJ United Kingdom
Hannes Tschofenig ARM Ltd. 110 Fulbourn Road Cambridge CB1 9NJイギリス
Email: Hannes.tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
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 Bilhanan Silverajan Tampere University of Technology Korkeakoulunkatu 10 Tampere FI-33720 Finland
電話：+ 49-421-218-63905メール：hartke@tzi.org Bilhanan Silverajan Tampere University of Technology Korkeakoulunkatu 10 Tampere FI-33720フィンランド
Email: bilhanan.silverajan@tut.fi
Brian Raymor (editor)
ブライアン・レイモア（編集者）
Email: brianraymor@hotmail.com