[要約] RFC 7967は、CoAPオプションの1つである"No Server Response"についての仕様を提供しています。このオプションは、CoAPクライアントがサーバからの応答を受け取らない場合の動作を定義しています。目的は、ネットワークの信頼性を向上させ、クライアントとサーバ間の通信の効率を向上させることです。
Independent Submission A. Bhattacharyya
Request for Comments: 7967 S. Bandyopadhyay
Category: Informational A. Pal
ISSN: 2070-1721 T. Bose
Tata Consultancy Services Ltd.
August 2016
Constrained Application Protocol (CoAP) Option for No Server Response
サーバー応答がないための制約付きアプリケーションプロトコル（CoAP）オプション
Abstract
概要
There can be machine-to-machine (M2M) scenarios where server responses to client requests are redundant. This kind of open-loop exchange (with no response path from the server to the client) may be desired to minimize resource consumption in constrained systems while updating many resources simultaneously or performing high-frequency updates. CoAP already provides Non-confirmable (NON) messages that are not acknowledged by the recipient. However, the request/response semantics still require the server to respond with a status code indicating "the result of the attempt to understand and satisfy the request", per RFC 7252.
クライアントの要求に対するサーバーの応答が冗長になるマシンツーマシン（M2M）のシナリオが存在する可能性があります。この種の開ループ交換（サーバーからクライアントへの応答パスなし）は、同時に多くのリソースを更新したり、高頻度の更新を実行しながら、制約されたシステムでのリソース消費を最小限に抑えるために望ましい場合があります。 CoAPは、受信者によって確認されない確認不可能な（NON）メッセージをすでに提供しています。ただし、要求/応答のセマンティクスでは、RFC 7252に従って、サーバーが「要求を理解して満足する試みの結果」を示すステータスコードで応答する必要があります。
This specification introduces a CoAP option called 'No-Response'. Using this option, the client can explicitly express to the server its disinterest in all responses against the particular request. This option also provides granular control to enable expression of disinterest to a particular response class or a combination of response classes. The server MAY decide to suppress the response by not transmitting it back to the client according to the value of the No-Response option in the request. This option may be effective for both unicast and multicast requests. This document also discusses a few examples of applications that benefit from this option.
この仕様では、「No-Response」と呼ばれるCoAPオプションが導入されています。このオプションを使用すると、クライアントは、特定の要求に対するすべての応答に対する関心がないことをサーバーに明示的に表現できます。このオプションは、特定の応答クラスまたは応答クラスの組み合わせに対する無関心の表現を可能にするきめ細かい制御も提供します。サーバーは、リクエストのNo-Responseオプションの値に従って、クライアントに応答を送信しないことで、応答を抑制することを決定してもよい（MAY）。このオプションは、ユニキャストとマルチキャストの両方のリクエストに有効です。このドキュメントでは、このオプションを利用するアプリケーションのいくつかの例についても説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7967.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7967で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Potential Benefits .........................................4
1.2. Terminology ................................................4
2. Option Definition ...............................................5
2.1. Granular Control over Response Suppression .................5
2.2. Method-Specific Applicability Considerations ...............8
3. Miscellaneous Aspects ...........................................9
3.1. Reusing Tokens .............................................9
3.2. Taking Care of Congestion Control and Server-Side
Flow Control ..............................................10
3.3. Considerations regarding Caching of Responses .............11
3.4. Handling the No-Response Option for a HTTP-to-CoAP
Reverse Proxy .............................................11
4. Application Scenarios ..........................................12
4.1. Frequent Update of Geolocation from Vehicles to
Backend Server ............................................12
4.1.1. Using No-Response with PUT .........................13
4.1.2. Using No-Response with POST ........................14
4.1.2.1. POST Updating a Fixed Target Resource .....14
4.1.2.2. POST Updating through Query String ........15
4.2. Multicasting Actuation Command from a Handheld Device
to a Group of Appliances ..................................15
4.2.1. Using Granular Response Suppression ................16
5. IANA Considerations ............................................16
6. Security Considerations ........................................16
7. References .....................................................16
7.1. Normative References ......................................16
7.2. Informative References ....................................17
Acknowledgments ...................................................18
Authors' Addresses ................................................18
This specification defines a new option for the Constrained Application Protocol (CoAP) [RFC7252] called 'No-Response'. This option enables clients to explicitly express their disinterest in receiving responses back from the server. The disinterest can be expressed at the granularity of response classes (e.g., 2.xx) or a combination of classes (e.g., 2.xx and 5.xx). By default, this option indicates interest in all response classes. The server MAY decide to suppress the response by not transmitting it back to the client according to the value of the No-Response option in the request.
この仕様は、「No-Response」と呼ばれる制約付きアプリケーションプロトコル（CoAP）[RFC7252]の新しいオプションを定義します。このオプションを使用すると、クライアントはサーバーからの応答を受信することに関心がないことを明示的に表現できます。非関心は、応答クラス（2.xxなど）の粒度またはクラスの組み合わせ（2.xxおよび5.xxなど）で表現できます。デフォルトでは、このオプションはすべての応答クラスに関心があることを示します。サーバーは、リクエストのNo-Responseオプションの値に従って、クライアントに応答を送信しないことで、応答を抑制することを決定してもよい（MAY）。
Along with the technical details, this document presents some practical application scenarios that highlight the usefulness of this option. [ITS-LIGHT] and [CoAP-ADAPT] contain the background research for this document.
このドキュメントでは、技術的な詳細とともに、このオプションの有用性を強調するいくつかの実用的なアプリケーションシナリオを紹介します。 [ITS-LIGHT]および[CoAP-ADAPT]には、このドキュメントの背景研究が含まれています。
In this document, when it is mentioned that a request from a client is with No-Response, the intended meaning is that the client expresses its disinterest for all or some selected classes of responses.
このドキュメントでは、クライアントからの要求がNo-Responseであると述べられている場合、意図された意味は、クライアントがすべてまたは一部の選択されたクラスの応答に対する無関心を表すことです。
The use of the No-Response option should be driven by typical application requirements and, particularly, characteristics of the information to be updated. If this option is opportunistically used in a fitting M2M application, then the concerned system may benefit in the following aspects. (However, note that this option is elective, and servers can simply ignore the preference expressed by the client.)
No-Responseオプションの使用は、典型的なアプリケーション要件、特に更新される情報の特性によって推進されるべきです。このオプションが日和見的に適切なM2Mアプリケーションで使用されている場合、関係するシステムは次の点でメリットがあります。 （ただし、このオプションは選択的であり、サーバーはクライアントによって表現された設定を単に無視できることに注意してください。）
* Reduction in network congestion due to effective reduction of the overall traffic.
* トラフィック全体の効果的な削減によるネットワークの輻輳の削減。
* Reduction in server-side load by relieving the server from responding to requests for which responses are not necessary.
* 応答が不要な要求へのサーバーの応答を軽減することによるサーバー側の負荷の削減。
* Reduction in battery consumption at the constrained endpoint(s).
* 制約されたエンドポイントでのバッテリー消費の削減。
* Reduction in overall communication cost.
* 全体的な通信コストの削減。
The terms used in this document are in conformance with those defined in [RFC7252].
このドキュメントで使用されている用語は、[RFC7252]で定義されている用語に準拠しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
The properties of the No-Response option are given in Table 1. In this table, the C, U, N, and R columns indicate the properties Critical, Unsafe, NoCacheKey, and Repeatable, respectively.
No-Responseオプションのプロパティを表1に示します。この表では、C、U、N、およびR列は、それぞれCritical、Unsafe、NoCacheKey、およびRepeatableのプロパティを示しています。
+--------+---+---+---+---+-------------+--------+--------+---------+
| Number | C | U | N | R | Name | Format | Length | Default |
+--------+---+---+---+---+-------------+--------+--------+---------+
| 258 | | X | - | | No-Response | uint | 0-1 | 0 |
+--------+---+---+---+---+-------------+--------+--------+---------+
Table 1: Option Properties
表1：オプションプロパティ
This option is a request option. It is elective and not repeatable. This option is Unsafe-to-Forward, as the intermediary MUST know how to interpret this option. Otherwise, the intermediary (without knowledge about the special unidirectional nature of the request) would wait for responses.
このオプションは要求オプションです。選択科目であり、再現性はありません。仲介者はこのオプションを解釈する方法を知っている必要があるため、このオプションは安全ではありません。そうでない場合、仲介者は（要求の特別な単方向性についての知識がなければ）応答を待ちます。
Note: Since CoAP maintains a clear separation between the request/response and the message sub-layer, this option does not have any dependency on the type of message (Confirmable/Non-confirmable). So, even the absence of a message sub-layer (e.g., CoAP over TCP [CoAP-TCP-TLS]) should have no effect on the interpretation of this option. However, considering the CoAP-over-UDP scenario [RFC7252], NON messages are best suited to this option because of the expected benefits. Using No-Response with NON messages gets rid of any kind of reverse traffic, and the interaction becomes completely open loop.
注：CoAPは要求/応答とメッセージサブレイヤーを明確に分離しているため、このオプションはメッセージのタイプ（確認可能/確認不可能）に依存しません。そのため、メッセージサブレイヤー（CoAP over TCP [CoAP-TCP-TLS]など）がなくても、このオプションの解釈に影響はありません。ただし、CoAP-over-UDPシナリオ[RFC7252]を考慮すると、期待される利点のため、NONメッセージはこのオプションに最適です。 NONメッセージでNo-Responseを使用すると、あらゆる種類のリバーストラフィックが取り除かれ、対話は完全にオープンループになります。
Using this option with CON requests may not serve the desired purpose if piggybacked responses are triggered. But, if the server responds with a separate response (which, perhaps, the client does not care about), then this option can be useful. Suppressing the separate response reduces traffic by one additional CoAP message in this case.
このオプションをCONリクエストで使用しても、ピギーバックされた応答がトリガーされた場合、目的を果たせない可能性があります。ただし、サーバーが個別の応答で応答する場合（おそらく、クライアントは気にしない）、このオプションは便利です。この場合、個別の応答を抑制すると、1つの追加のCoAPメッセージによってトラフィックが削減されます。
This option contains values to indicate disinterest in all or a particular class or combination of classes of responses as described in Section 2.1.
このオプションには、セクション2.1で説明されているように、すべてまたは特定のクラス、または応答のクラスの組み合わせにおける無関心を示す値が含まれています。
This option enables granular control over response suppression by allowing the client to express its disinterest in a typical class or combination of classes of responses. For example, a client may explicitly tell the receiver that no response is required unless something 'bad' happens and a response of class 4.xx or 5.xx is to be fed back to the client. No response of the class 2.xx is required in such case.
このオプションを使用すると、クライアントが典型的なクラスまたは応答のクラスの組み合わせに関心がないことを表現できるため、応答抑制をきめ細かく制御できます。たとえば、クライアントは、何か「悪い」ことが起こり、クラス4.xxまたは5.xxの応答がクライアントにフィードバックされる場合を除いて、応答は不要であることを受信者に明示的に通知する場合があります。そのような場合、クラス2.xxの応答は必要ありません。
Note: Section 2.7 of [RFC7390] describes a scheme where a server in the multicast group may decide on its own to suppress responses for group communication with granular control. The client does not have any knowledge about that. However, on the other hand, the No-Response option enables the client to explicitly inform the servers about its disinterest in responses. Such explicit control on the client side may be helpful for debugging network resources. An example scenario is described in Section 4.2.1.
注：[RFC7390]のセクション2.7は、マルチキャストグループ内のサーバーが独自に決定して、きめ細かい制御でグループ通信の応答を抑制する方法を説明しています。クライアントはそのことについて何も知りません。ただし、その一方で、No-Responseオプションを使用すると、クライアントはサーバーが応答に関心がないことをサーバーに明示的に通知できます。クライアント側でのこのような明示的な制御は、ネットワークリソースのデバッグに役立つ場合があります。シナリオ例については、4.2.1項で説明します。
The server MUST send back responses of the classes for which the client has not expressed any disinterest. There may be instances where a server, on its own, decides to suppress responses. An example is suppression of responses by multicast servers as described in Section 2.7 of [RFC7390]. If such a server receives a request with a No-Response option showing 'interest' in specific response classes (i.e., not expressing disinterest for these options), then any default behavior of suppressing responses, if present, MUST be overridden to deliver those responses that are of interest to the client.
サーバーは、クライアントが無関心を表明していないクラスの応答を返送しなければなりません（MUST）。サーバー自体が応答を抑制することを決定する場合があります。 [RFC7390]のセクション2.7で説明されているように、マルチキャストサーバーによる応答の抑制がその例です。そのようなサーバーが特定の応答クラスで「関心」を示す無応答オプション付きの要求を受信した場合（つまり、これらのオプションに無関心を表していない場合）、応答を抑制するデフォルトの動作は、存在する場合、オーバーライドしてそれらの応答を配信する必要があります。それはクライアントにとって興味深いものです。
So, for example, suppose a multicast server suppresses all responses by default and receives a request with a No-Response option expressing disinterest in 2.xx (success) responses only. Note that the option value naturally expresses interest in error responses 4.xx and 5.xx in this case. Thus, the server must send back a response if the concerned request caused an error.
したがって、たとえば、マルチキャストサーバーがデフォルトですべての応答を抑制し、2.xx（成功）応答のみに関心がないことを表すNo-Responseオプションを含む要求を受信するとします。この場合、オプション値はエラー応答4.xxおよび5.xxへの関心を自然に表すことに注意してください。したがって、関連する要求がエラーを引き起こした場合、サーバーは応答を返送する必要があります。
The option value is defined as a bit map (Table 2) to achieve granular suppression. Its length can be 0 bytes (empty) or 1 byte.
オプション値は、詳細な抑制を実現するためのビットマップ（表2）として定義されます。その長さは0バイト（空）または1バイトです。
+-------+-----------------------+-----------------------------------+
| Value | Binary Representation | Description |
+-------+-----------------------+-----------------------------------+
| 0 | <empty> | Interested in all responses. |
+-------+-----------------------+-----------------------------------+
| 2 | 00000010 | Not interested in 2.xx responses. |
+-------+-----------------------+-----------------------------------+
| 8 | 00001000 | Not interested in 4.xx responses. |
+-------+-----------------------+-----------------------------------+
| 16 | 00010000 | Not interested in 5.xx responses. |
+-------+-----------------------+-----------------------------------+
Table 2: Option Values
表2：オプション値
The conventions used in deciding the option values are:
オプション値の決定に使用される規則は次のとおりです。
1. To suppress an individual class: Set bit number (n-1) starting from the least significant bit (bit number 0) to suppress all responses belonging to class n.xx. So,
1. 個々のクラスを抑制するには：最下位ビット（ビット番号0）から始まるビット番号（n-1）を設定して、クラスn.xxに属するすべての応答を抑制します。そう、
option value to suppress n.xx class = 2**(n-1)
2. To suppress a combination of classes: Set each corresponding bit according to point 1 above. Example: The option value will be 18 (binary: 00010010) to suppress both 2.xx and 5.xx responses. This is essentially bitwise OR of the corresponding individual values for suppressing 2.xx and 5.xx. The "CoAP Response Codes" registry (see Section 12.1.2 of [RFC7252]) defines 2.xx, 4.xx, and 5.xx responses. So, an option value of 26 (binary: 00011010) will request to suppress all response codes defined in [RFC7252].
2. クラスの組み合わせを抑制するには：上記のポイント1に従って、対応する各ビットを設定します。例：2.xxと5.xxの両方の応答を抑制するために、オプション値は18（バイナリ：00010010）になります。これは基本的に、2.xxおよび5.xxを抑制するための対応する個々の値のビット単位のORです。 「CoAP Response Codes」レジストリ（[RFC7252]のセクション12.1.2を参照）は、2.xx、4.xx、および5.xx応答を定義します。したがって、オプション値26（バイナリ：00011010）は、[RFC7252]で定義されているすべての応答コードを抑制するように要求します。
Note: When No-Response is used with value 26 in a request, the client endpoint SHOULD cease listening to response(s) to the particular request. On the other hand, showing interest in at least one class of response means that the client endpoint can no longer completely cease listening activity and must be configured to listen during some application specific time-out period for the particular request. The client endpoint never knows whether the present request will be a success or a failure. Thus, for example, if the client decides to open up the response for errors (4.xx and 5.xx), then it has to wait for the entire time-out period -- even for the instances where the request is successful (and the server is not supposed to send back a response). Note that in this context there may be situations when the response to errors might get lost. In such a situation, the client would wait during the time-out period but would not receive any response. However, this should not give the client the impression that the request was necessarily successful. In other words, in this case, the client cannot distinguish between response suppression and message loss. The application designer needs to tackle this situation. For example, while performing frequent updates, the client may strategically interweave requests without No-Response option into a series of requests with No-Response to check periodically that things are fine at the server end and the server is actively responding.
注：No-Responseがリクエストで値26とともに使用される場合、クライアントエンドポイントは、特定のリクエストへのレスポンスのリスニングを中止する必要があります（SHOULD）。一方、少なくとも1つのクラスの応答に関心を示すと、クライアントエンドポイントはリスニングアクティビティを完全に停止できなくなり、特定のリクエストのアプリケーション固有のタイムアウト期間中にリッスンするように設定する必要があります。クライアントエンドポイントは、現在の要求が成功するか失敗するかを決して知りません。したがって、たとえば、クライアントがエラー（4.xxおよび5.xx）に対する応答を開くことを決定した場合、要求が成功したインスタンスであっても、タイムアウト期間全体を待機する必要があります（サーバーは応答を返すことは想定されていません）。このコンテキストでは、エラーへの応答が失われる場合があることに注意してください。このような状況では、クライアントはタイムアウト期間中待機しますが、応答を受け取りません。ただし、これは、要求が必ず成功したという印象をクライアントに与えるべきではありません。つまり、この場合、クライアントは応答抑制とメッセージ損失を区別できません。アプリケーション設計者は、この状況に取り組む必要があります。たとえば、頻繁な更新を実行している間、クライアントは無応答オプションのないリクエストを戦略的に織り交ぜて無応答の一連のリクエストとし、サーバーエンドで問題がないこととサーバーがアクティブに応答していることを定期的にチェックします。
The following table provides a ready reference on the possible applicability of this option with four REST methods. This table is for the type of possible interactions foreseen at the time of preparing this specification. The key words from RFC 2119 such as "SHOULD NOT", etc., deliberately have not been used in this table because it only contains suggestions.
次の表は、4つのRESTメソッドを使用したこのオプションの適用可能性に関するすぐに参照できるものです。この表は、この仕様の作成時に予測される可能性のある相互作用のタイプを示しています。 「SHOULD NOT」などのRFC 2119のキーワードは、提案だけが含まれているため、この表では意図的に使用されていません。
+-------------+----------------------------------------------------+
| Method Name | Remarks on Applicability |
+-------------+----------------------------------------------------+
| | This should not be used with a conventional GET |
| | request when the client requests the contents |
| | of a resource. However, this option may be useful |
| | for exceptional cases where GET requests have side |
| GET | effects. For instance, the proactive cancellation |
| | procedure for observing a request [RFC7641] |
| | requires a client to issue a GET request with the |
| | Observe option set to 1 ('deregister'). If it is |
| | more efficient to use this deregistration instead |
| | of reactive cancellation (rejecting the next |
| | notification with RST), the client MAY express its |
| | disinterest in the response to such a GET request. |
+-------------+----------------------------------------------------+
| | Suitable for frequent updates (particularly in NON |
| | messages) on existing resources. Might not be |
| | useful when PUT is used to create a new resource, |
| | as it may be important for the client to know that |
| PUT | the resource creation was actually successful in |
| | order to carry out future actions. Also, it may be|
| | important to ensure that a resource was actually |
| | created rather than updating an existing resource. |
+-------------+----------------------------------------------------+
| | If POST is used to update a target resource, |
| | then No-Response can be used in the same manner as |
| | in PUT. This option may also be useful while |
| POST | updating through query strings rather than updating|
| | a fixed target resource (see Section 4.1.2.2 for an|
| | example). |
+-------------+----------------------------------------------------+
| | Deletion is usually a permanent action. If the |
| DELETE | client wants to ensure that the deletion request |
| | was properly executed, then this option should not |
| | be used with the request. |
+-------------+----------------------------------------------------+
Table 3: Suggested Applicability of No-Response with REST Methods
表3：RESTメソッドでの無応答の推奨される適用性
This section further describes important implementation aspects worth considering while using the No-Response option. The following discussion contains guidelines and requirements (derived by combining [RFC7252], [RFC7390], and [RFC5405]) for the application developer.
このセクションでは、応答なしオプションを使用する際に検討する価値のある重要な実装の側面についてさらに説明します。以下の説明には、アプリケーション開発者向けのガイドラインと要件（[RFC7252]、[RFC7390]、および[RFC5405]を組み合わせることによって派生）が含まれています。
Tokens provide a matching criteria between a request and the corresponding response. The life of a Token starts when it is assigned to a request and ends when the final matching response is received. Then, the Token can again be reused. However, a request with No-Response typically does not have any guaranteed response path. So, the client has to decide on its own about when it can retire a Token that has been used in an earlier request so that the Token can be reused in a future request. Since the No-Response option is 'elective', a server that has not implemented this option will respond back. This leads to the following two scenarios:
トークンは、要求と対応する応答の間の一致基準を提供します。トークンの存続期間は、要求に割り当てられたときに始まり、最後に一致する応答を受け取ったときに終了します。その後、トークンを再利用できます。ただし、通常、応答なしのリクエストには、応答パスが保証されていません。そのため、クライアントは、以前のリクエストで使用されたトークンをいつリタイアできるかを自分で決め、将来のリクエストでトークンを再利用できるようにする必要があります。応答なしオプションは「選択的」であるため、このオプションを実装していないサーバーは応答します。これにより、次の2つのシナリオが発生します。
The first scenario is when the client is never going to care about any response coming back or about relating the response to the original request. In that case, it MAY reuse the Token value at liberty.
最初のシナリオは、クライアントが返される応答について、または応答を元の要求に関連付けることについてまったく気にしない場合です。その場合、それは自由にトークン値を再利用するかもしれません。
However, as a second scenario, let us consider that the client sends two requests where the first request is with No-Response and the second request (with the same Token) is without No-Response. In this case, a delayed response to the first one can be interpreted as a response to the second request (client needs a response in the second case) if the time interval between using the same Token is not long enough. This creates a problem in the request-response semantics.
ただし、2番目のシナリオとして、クライアントが2つの要求を送信し、最初の要求が無応答で、2番目の要求（同じトークンを使用）が無応答の場合を考えてみましょう。この場合、同じトークンを使用する時間間隔が十分に長くない場合、最初の応答に対する遅延応答は、2番目の要求に対する応答（クライアントは2番目の場合には応答が必要）として解釈できます。これにより、要求と応答のセマンティクスに問題が生じます。
The most ideal solution would be to always use a unique Token for requests with No-Response. But if a client wants to reuse a Token, then in most practical cases the client implementation SHOULD implement an application-specific reuse time after which it can reuse the Token. A minimum reuse time for Tokens with a similar expression as in Section 2.5 of [RFC7390] SHOULD be used:
最も理想的なソリューションは、応答なしのリクエストに対して常に一意のトークンを使用することです。ただし、クライアントがトークンを再利用したい場合、ほとんどの実際的なケースでは、クライアント実装は、アプリケーション固有の再利用時間を実装してから、トークンを再利用できるようにする必要があります。 [RFC7390]のセクション2.5と同様の表現を持つトークンの最小再利用時間を使用する必要があります。
TOKEN_REUSE_TIME = NON_LIFETIME + MAX_SERVER_RESPONSE_DELAY + MAX_LATENCY
TOKEN_REUSE_TIME = NON_LIFETIME + MAX_SERVER_RESPONSE_DELAY + MAX_LATENCY
NON_LIFETIME and MAX_LATENCY are defined in Section 4.8.2 of [RFC7252]. MAX_SERVER_RESPONSE_DELAY has the same interpretation as in Section 2.5 of [RFC7390] for a multicast request. For a unicast request, since the message is sent to only one server, MAX_SERVER_RESPONSE_DELAY means the expected maximum response delay from the particular server to that client that sent the request. For multicast requests, MAX_SERVER_RESPONSE_DELAY has the same interpretation as in Section 2.5 of [RFC7390]. So, for multicast it is the expected maximum server response delay "over all servers that the client can send a multicast request to", per [RFC7390]. This response delay for a given server includes its specific Leisure period; where Leisure is defined in Section 8.2 of [RFC7252]. In general, the Leisure for a server may not be known to the client. A lower bound for Leisure, lb_Leisure, is defined in [RFC7252], but not an upper bound as is needed in this case. Therefore, the upper bound can be estimated by taking N (N>>1) times the lower bound lb_Leisure:
NON_LIFETIMEおよびMAX_LATENCYは、[RFC7252]のセクション4.8.2で定義されています。 MAX_SERVER_RESPONSE_DELAYの解釈は、マルチキャストリクエストの[RFC7390]のセクション2.5と同じです。ユニキャスト要求の場合、メッセージは1つのサーバーにのみ送信されるため、MAX_SERVER_RESPONSE_DELAYは、特定のサーバーから要求を送信したクライアントへの予想最大応答遅延を意味します。マルチキャストリクエストの場合、MAX_SERVER_RESPONSE_DELAYの解釈は[RFC7390]のセクション2.5と同じです。したがって、マルチキャストの場合、[RFC7390]に従って、「クライアントがマルチキャスト要求を送信できるすべてのサーバーにわたって」予想される最大サーバー応答遅延になります。特定のサーバーのこの応答遅延には、特定のレジャー期間が含まれます。ここで、レジャーは[RFC7252]のセクション8.2で定義されています。一般に、サーバーのレジャーはクライアントに知られていない場合があります。レジャーの下限であるlb_Leisureは[RFC7252]で定義されていますが、この場合必要な上限はありません。したがって、上限は、下限lb_LeisureのN（N >> 1）倍を取ることで推定できます。
lb_Leisure = S * G / R
where S = estimated response size G = group size estimate R = data transfer rate
ここで、S =推定応答サイズG =グループサイズ推定R =データ転送速度
Any estimate of MAX_SERVER_RESPONSE_DELAY MUST be larger than DEFAULT_LEISURE, as defined in [RFC7252].
[RFC7252]で定義されているように、MAX_SERVER_RESPONSE_DELAYの推定値はすべてDEFAULT_LEISUREより大きくなければなりません（MUST）。
Note: If it is not possible for the client to get a reasonable estimate of the MAX_SERVER_RESPONSE_DELAY, then the client, to be safe, SHOULD use a unique Token for each stream of messages.
注：クライアントがMAX_SERVER_RESPONSE_DELAYの妥当な見積もりを取得できない場合、クライアントは安全であるため、メッセージのストリームごとに一意のトークンを使用する必要があります（SHOULD）。
This section provides guidelines for basic congestion control. Better congestion control mechanisms can be designed as future work.
このセクションでは、基本的な輻輳制御のガイドラインを示します。より良い輻輳制御メカニズムは、将来の作業として設計できます。
If this option is used with NON messages, then the interaction becomes completely open loop. The absence of any feedback from the server-end affects congestion-control mechanisms. In this case, the communication pattern maps to the scenario where the application cannot maintain an RTT estimate as described in Section 3.1.2 of [RFC5405]. Hence, per [RFC5405], a 3-second interval is suggested as the minimum interval between successive updates, and it is suggested to use an even less aggressive rate when possible. However, in case of a higher rate of updates, the application MUST have some knowledge about the channel, and an application developer MUST interweave occasional closed-loop exchanges (e.g., NON messages without No-Response, or CON messages) to get an RTT estimate between the endpoints.
このオプションをNONメッセージで使用すると、相互作用は完全に開ループになります。サーバー側からのフィードバックがないと、輻輳制御メカニズムに影響します。この場合、通信パターンは、[RFC5405]のセクション3.1.2で説明されているように、アプリケーションがRTT見積もりを維持できないシナリオにマッピングされます。したがって、[RFC5405]によれば、3秒間隔が連続する更新間の最小間隔として提案されており、可能な場合はさらに攻撃的なレートを使用することが提案されています。ただし、より高い更新率の場合、アプリケーションはチャネルについてある程度の知識を持っている必要があり、アプリケーション開発者はRTTを取得するために、時折の閉ループ交換（たとえば、応答なしのNONメッセージ、またはCONメッセージ）を織り込む必要があります。エンドポイント間の推定。
Interweaving requests without No-Response is a MUST in case of an aggressive request rate for applications where server-side flow control is necessary. For example, as proposed in [CoAP-PUBSUB], a
サーバー側のフロー制御が必要なアプリケーションの要求レートが非常に高い場合、No-Responseのないリクエストを織り交ぜることは必須です。たとえば、[CoAP-PUBSUB]で提案されているように、
broker MAY return 4.29 (Too Many Requests) in order to request a client to slow down the request rate. Interweaving requests without No-Response allows the client to listen to such a response.
ブローカーはクライアントにリクエストレートを下げるようにリクエストするために4.29（Too Many Requests）を返す場合があります。応答なしのリクエストを織り交ぜることで、クライアントはそのような応答を聞くことができます。
The cacheability of CoAP responses does not depend on the request method, but it depends on the Response Code. The No-Response option does not lead to any impact on cacheability of responses. If a request containing No-Response triggers a cacheable response, then the response MUST be cached. However, the response MAY not be transmitted considering the value of the No-Response option in the request.
CoAP応答のキャッシュ可能性は要求メソッドに依存しませんが、応答コードに依存します。 No-Responseオプションは、応答のキャッシュ可能性に影響を与えません。 No-Responseを含むリクエストがキャッシュ可能な応答をトリガーする場合、応答はキャッシュされなければなりません（MUST）。ただし、リクエストのNo-Responseオプションの値を考慮して、応答が送信されない場合があります。
For example, if a request with No-Response triggers a cacheable response of 4.xx class with Max-Age not equal to 0, then the response must be cached. The cache will return the response to subsequent similar requests without No-Response as long as the Max-Age has not elapsed.
たとえば、No-Responseを含むリクエストが、Max-Ageが0以外の4.xxクラスのキャッシュ可能なレスポンスをトリガーする場合、レスポンスをキャッシュする必要があります。 Max-Ageが経過していない限り、キャッシュは、No-Responseなしで後続の同様のリクエストへの応答を返します。
A HTTP-to-CoAP reverse proxy MAY translate an incoming HTTP request to a corresponding CoAP request indicating that no response is required (showing disinterest in all classes of responses) based on some application-specific requirement. In this case, it is RECOMMENDED that the reverse proxy generate an HTTP response with status code 204 (No Content) when such response is allowed. The generated response is sent after the proxy has successfully sent out the CoAP request.
HTTP-to-CoAPリバースプロキシは、アプリケーション固有の要件に基づいて、応答が不要であることを示す対応するCoAP要求にHTTP応答を変換する場合があります（すべてのクラスの応答に関心がないことを示す）。この場合、そのような応答が許可されているときに、リバースプロキシがステータスコード204（コンテンツなし）のHTTP応答を生成することをお勧めします。生成された応答は、プロキシがCoAP要求を正常に送信した後に送信されます。
If the reverse proxy applies No-Response for one or more classes of responses, it will wait for responses up to an application-specific maximum time (T_max) before responding to the HTTP side. If a response of a desired class is received within T_max, then the response gets translated to HTTP as defined in [HTTP-to-CoAP]. However, if the proxy does not receive any response within T_max, it is RECOMMENDED that the reverse Proxy send an HTTP response with status code 204 (No Content) when allowed for the specific HTTP request method.
リバースプロキシが1つ以上の応答クラスに応答なしを適用する場合、HTTP側に応答する前に、アプリケーション固有の最大時間（T_max）まで応答を待機します。 T_max内で目的のクラスの応答を受信した場合、その応答は[HTTP-to-CoAP]で定義されているようにHTTPに変換されます。ただし、プロキシがT_max以内に応答を受信しない場合、リバースプロキシは、特定のHTTP要求メソッドで許可されている場合、ステータスコード204（コンテンツなし）のHTTP応答を送信することをお勧めします。
This section describes some examples of application scenarios that may potentially benefit from the use of the No-Response option.
このセクションでは、No-Responseオプションを使用することでメリットが得られる可能性のあるアプリケーションシナリオの例について説明します。
Let us consider an intelligent traffic system (ITS) consisting of vehicles equipped with a sensor gateway comprising sensors like GPS and accelerometer sensors. The sensor gateway acts as a CoAP client. It connects to the Internet using a low-bandwidth cellular connection (e.g., General Packet Radio Service (GPRS)). The GPS coordinates of the vehicle are periodically updated to the backend server.
GPSや加速度センサーなどのセンサーで構成されるセンサーゲートウェイを備えた車両で構成されるインテリジェント交通システム（ITS）について考えてみましょう。センサーゲートウェイはCoAPクライアントとして機能します。低帯域幅のセルラー接続を使用してインターネットに接続します（例：General Packet Radio Service（GPRS））。車両のGPS座標は、バックエンドサーバーに対して定期的に更新されます。
While performing frequent location updates, retransmitting (through the CoAP CON mechanism) a location coordinate that the vehicle has already left is not efficient as it adds redundant traffic to the network. Therefore, the updates are done using NON messages. However, given the huge number of vehicles updating frequently, the NON exchange will also trigger a huge number of responses from the backend. Thus, the cumulative load on the network will be quite significant. Also, the client in this case may not be interested in getting responses to location update requests for a location it has already passed and when the next location update is imminent.
頻繁な位置更新を実行している間、車両がすでに残した位置座標を（CoAP CONメカニズムを介して）再送信すると、ネットワークに冗長なトラフィックが追加されるため、効率的ではありません。したがって、更新はNONメッセージを使用して行われます。ただし、膨大な数の車両が頻繁に更新される場合、NON交換はバックエンドからの膨大な数の応答もトリガーします。したがって、ネットワークの累積負荷は非常に大きくなります。また、この場合のクライアントは、すでに通過した場所の次の場所の更新が差し迫っているときに、場所の更新要求に対する応答を取得することに関心がない可能性があります。
On the contrary, if the client endpoints on the vehicles explicitly declare that they do not need any status response back from the server, then load will be reduced significantly. The assumption is that the high rate of updates will compensate for the stray losses in geolocation reports.
逆に、車両のクライアントエンドポイントがサーバーからのステータス応答を必要としないことを明示的に宣言すると、負荷が大幅に軽減されます。更新の頻度が高いと、地理位置情報レポートの浮遊損失が補われると想定されています。
Note: It may be argued that the above example application can also be implemented using the Observe option [RFC7641] with NON notifications. But, in practice, implementing with Observe would require lot of bookkeeping at the data collection endpoint at the backend (observer). The observer needs to maintain all the observe relationships with each vehicle. The data collection endpoint may be unable to know all its data sources beforehand. The client endpoints at vehicles may go offline or come back online randomly. In the case of Observe, the onus is always on the data collection endpoint to establish an observe relationship with each data source. On the other hand, implementation will be much simpler if initiating is left to the data source to carry out updates using the No-Response option. Another way of looking at it is that the implementation choice depends on where there is interest to initiate the update. In an Observe scenario, the interest is expressed by the data consumer. In contrast, the classic update case applies when the interest is from the data producer. The No-Response option makes classic updates consume even less resources.
注：上記のサンプルアプリケーションは、NON通知でObserveオプション[RFC7641]を使用して実装することもできます。ただし、実際には、Observeを使用して実装するには、バックエンド（オブザーバー）のデータ収集エンドポイントで多くの簿記が必要になります。オブザーバーは、各車両とのすべての監視関係を維持する必要があります。データ収集エンドポイントは、すべてのデータソースを事前に知ることができない場合があります。車両のクライアントエンドポイントがオフラインになるか、ランダムにオンラインに戻ることがあります。監視の場合、責任は常にデータ収集エンドポイントにあり、各データソースとの監視関係を確立します。一方、No-Responseオプションを使用して更新を実行するのをデータソースに任せると、実装がはるかに簡単になります。別の見方をすると、実装の選択は、更新を開始する必要がある場所に依存するということです。観察シナリオでは、関心はデータ利用者によって表現されます。対照的に、従来の更新ケースは、データプロデューサーからの関心がある場合に適用されます。応答なしオプションを使用すると、従来の更新で消費されるリソースがさらに少なくなります。
The following subsections illustrate some sample exchanges based on the application described above.
以下のサブセクションでは、上記のアプリケーションに基づくいくつかのサンプル交換について説明します。
Each vehicle is assigned a dedicated resource "vehicle-stat-<n>", where <n> can be any string uniquely identifying the vehicle. The update requests are sent using NON messages. The No-Response option causes the server not to respond back.
各車両には専用のリソース「vehicle-stat- <n>」が割り当てられます。<n>は、車両を一意に識別する任意の文字列です。更新リクエストはNONメッセージを使用して送信されます。 No-Responseオプションは、サーバーが応答しないようにします。
Client Server
| |
| |
+----->| Header: PUT (T=NON, Code=0.03, MID=0x7d38)
| PUT | Token: 0x53
| | Uri-Path: "vehicle-stat-00"
| | Content Type: text/plain
| | No-Response: 26
| | Payload:
| | "VehID=00&RouteID=DN47&Lat=22.5658745&Long=88.4107966667&
| | Time=2013-01-13T11:24:31"
| |
[No response from the server. Next update in 20 s.]
| |
+----->| Header: PUT (T=NON, Code=0.03, MID=0x7d39)
| PUT | Token: 0x54
| | Uri-Path: "vehicle-stat-00"
| | Content Type: text/plain
| | No-Response: 26
| | Payload:
| | "VehID=00&RouteID=DN47&Lat=22.5649015&Long=88.4103511667&
| | Time=2013-01-13T11:24:51"
Figure 1: Example of Unreliable Update with No-Response Option Using PUT
図1：PUTを使用した無応答オプションによる信頼できない更新の例
In this case, POST acts the same way as PUT. The exchanges are the same as above. The updated values are carried as payload of POST as shown in Figure 2.
この場合、POSTはPUTと同じように機能します。交換は上記と同じです。図2に示すように、更新された値はPOSTのペイロードとして伝達されます。
Client Server
| |
| |
+----->| Header: POST (T=NON, Code=0.02, MID=0x7d38)
| POST | Token: 0x53
| | Uri-Path: "vehicle-stat-00"
| | Content Type: text/plain
| | No-Response: 26
| | Payload:
| | "VehID=00&RouteID=DN47&Lat=22.5658745&Long=88.4107966667&
| | Time=2013-01-13T11:24:31"
| |
[No response from the server. Next update in 20 s.]
| |
+----->| Header: POST (T=NON, Code=0.02, MID=0x7d39)
| POST | Token: 0x54
| | Uri-Path: "vehicle-stat-00"
| | Content Type: text/plain
| | No-Response: 26
| | Payload:
| | "VehID=00&RouteID=DN47&Lat=22.5649015&Long=88.4103511667&
| | Time=2013-01-13T11:24:51"
Figure 2: Example of Unreliable Update with No-Response Option Using POST as the Update Method
図2：POSTを更新メソッドとして使用する無応答オプションを使用した信頼性の低い更新の例
It may be possible that the backend infrastructure deploys a dedicated database to store the location updates. In such a case, the client can update through a POST by sending a query string in the URI. The query string contains the name/value pairs for each update. No-Response can be used in the same manner as for updating fixed resources. The scenario is depicted in Figure 3.
バックエンドインフラストラクチャが、場所の更新を保存するための専用データベースを展開する可能性があります。このような場合、クライアントはURIでクエリ文字列を送信することにより、POSTを通じて更新できます。クエリ文字列には、各更新の名前と値のペアが含まれています。応答なしは、固定リソースの更新と同じ方法で使用できます。このシナリオを図3に示します。
Client Server
| |
| |
+----->| Header: POST (T=NON, Code=0.02, MID=0x7d38)
| POST | Token: 0x53
| | Uri-Path: "updateOrInsertInfo"
| | Uri-Query: "VehID=00"
| | Uri-Query: "RouteID=DN47"
| | Uri-Query: "Lat=22.5658745"
| | Uri-Query: "Long=88.4107966667"
| | Uri-Query: "Time=2013-01-13T11:24:31"
| | No-Response: 26
| |
[No response from the server. Next update in 20 s.]
| |
+----->| Header: POST (T=NON, Code=0.02, MID=0x7d39)
| POST | Token: 0x54
| | Uri-Path: "updateOrInsertInfo"
| | Uri-Query: "VehID=00"
| | Uri-Query: "RouteID=DN47"
| | Uri-Query: "Lat=22.5649015"
| | Uri-Query: "Long=88.4103511667"
| | Uri-Query: "Time=2013-01-13T11:24:51"
| | No-Response: 26
| |
Figure 3: Example of Unreliable Update with No-Response Option Using POST with a Query String to Insert Update Information into the Backend Database
図3：クエリ文字列を含むPOSTを使用して更新情報をバックエンドデータベースに挿入する無応答オプションを使用した信頼性の低い更新の例
4.2. Multicasting Actuation Command from a Handheld Device to a Group of Appliances
4.2. ハンドヘルドデバイスからアプライアンスのグループへのアクチュエーションコマンドのマルチキャスト
A handheld device (e.g., a smart phone) may be programmed to act as an IP-enabled switch to remotely operate on one or more IP-enabled appliances. For example, a multicast request to switch on/off all the lights of a building can be sent. In this case, the IP switch application can use the No-Response option in a NON request message to reduce the traffic generated due to simultaneous CoAP responses from all the lights.
ハンドヘルドデバイス（例えば、スマートフォン）は、１つ以上のＩＰ対応機器上で遠隔操作するためのＩＰ対応スイッチとして機能するようにプログラムされてもよい。たとえば、建物のすべての照明のオン/オフを切り替えるマルチキャスト要求を送信できます。この場合、IPスイッチアプリケーションは、NON要求メッセージのNo-Responseオプションを使用して、すべてのライトからの同時CoAP応答によって生成されるトラフィックを削減できます。
Thus, No-Response helps in reducing overall communication cost and the probability of network congestion in this case.
したがって、No-Responseは、全体的な通信コストとこの場合のネットワーク輻輳の可能性を減らすのに役立ちます。
The IP switch application may optionally use granular response suppression such that the error responses are not suppressed. In that case, the lights that could not execute the request would respond back and be readily identified. Thus, explicit suppression of option classes by the multicast client may be useful to debug the network and the application.
IPスイッチアプリケーションは、エラー応答が抑制されないように、オプションで詳細な応答抑制を使用できます。その場合、要求を実行できなかったライトが応答し、簡単に識別されます。したがって、マルチキャストクライアントによるオプションクラスの明示的な抑制は、ネットワークとアプリケーションのデバッグに役立つ場合があります。
The IANA had previously assigned number 284 to this option in the "CoAP Option Numbers" registry. IANA has updated this as shown below:
IANAは、以前に「CoAPオプション番号」レジストリでこのオプションに番号284を割り当てていました。 IANAはこれを以下のように更新しました。
+--------+--------------+-------------+
| Number | Name | Reference |
+--------+--------------+-------------+
| 258 | No-Response | RFC 7967 |
+--------+--------------+-------------+
The No-Response option defined in this document presents no security considerations beyond those in Section 11 of the base CoAP specification [RFC7252].
このドキュメントで定義されているNo-Responseオプションは、ベースCoAP仕様[RFC7252]のセクション11にあるものを超えるセキュリティ上の考慮事項を提示していません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <http://www.rfc-editor.org/info/rfc7252>.
[RFC7252] Shelby、Z.、Hartke、K。、およびC. Bormann、「The Constrained Application Protocol（CoAP）」、RFC 7252、DOI 10.17487 / RFC7252、2014年6月、<http：//www.rfc-editor。 org / info / rfc7252>。
[CoAP-ADAPT] Bandyopadhyay, S., Bhattacharyya, A., and A. Pal, "Adapting protocol characteristics of CoAP using sensed indication for vehicular analytics", 11th ACM Conference on Embedded Networked Sensor Systems (SenSys '13), DOI 10.1145/2517351.2517422, November 2013.
[CoAP-ADAPT] Bandyopadhyay、S.、Bhattacharyya、A。、およびA. Pal、「車両分析用の検出された表示を使用したCoAPのプロトコル特性の適応」、第11回組み込みネットワークセンサーシステムに関するACM会議（SenSys '13）、DOI 10.1145 /2517351.2517422、2013年11月。
[CoAP-PUBSUB] Koster, M., Keranen, A., and J. Jimenez, "Publish-Subscribe Broker for the Constrained Application Protocol (CoAP)", Work in Progress, draft-koster-core-coap-pubsub-05, July 2016.
[CoAP-PUBSUB]コスター、M。、ケラネン、A。、およびJ.ヒメネス、「制約付きアプリケーションプロトコル（CoAP）のパブリッシュ-サブスクライブブローカー」、作業中、draft-koster-core-coap-pubsub-05 、2016年7月。
[CoAP-TCP-TLS] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets", Work in Progress, draft-ietf-core-coap-tcp-tls-04, August 2016.
[CoAP-TCP-TLS] Bormann、C.、Lemay、S.、Tschofenig、H.、Hartke、K.、Silverajan、B.、and B. Raymor、Ed。、 "CoAP（Constrained Application Protocol）over TCP、 TLS、およびWebSockets」、Work in Progress、draft-ietf-core-coap-tcp-tls-04、2016年8月。
[HTTP-to-CoAP] Castellani, A., Loreto, S., Rahman, A., Fossati, T., and E. Dijk, "Guidelines for HTTP-to-CoAP Mapping Implementations", Work in Progress, draft-ietf-core-http-mapping-13, July 2016.
[HTTP-to-CoAP] Castellani、A.、Loreto、S.、Rahman、A.、Fossati、T。、およびE. Dijk、「HTTP-to-CoAPマッピング実装のガイドライン」、作業中、ドラフト- ietf-core-http-mapping-13、2016年7月。
[ITS-LIGHT] Bhattacharyya, A., Bandyopadhyay, S., and A. Pal, "ITS-light: Adaptive lightweight scheme to resource optimize intelligent transportation tracking system (ITS) - Customizing CoAP for opportunistic optimization", 10th International Conference on Mobile and Ubiquitous Systems: Computing, Networking and Services (MobiQuitous 2013), DOI 10.1007/978-3-319-11569-6_58, December 2013.
[ITS-LIGHT] Bhattacharyya、A.、Bandyopadhyay、S。、およびA. Pal、「ITS-light：Adaptive Lightweight Scheme to Resource Optimization Intelligent Transportation Tracking System（ITS）-Customizing CoAP for Opportunistic Optimization」、第10回国際会議モバイルおよびユビキタスシステム：コンピューティング、ネットワーキング、およびサービス（MobiQuitous 2013）、DOI 10.1007 / 978-3-319-11569-6_58、2013年12月。
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, DOI 10.17487/RFC5405, November 2008, <http://www.rfc-editor.org/info/rfc5405>.
[RFC5405] Eggert、L。およびG. Fairhurst、「アプリケーション設計者のためのユニキャストUDP使用ガイドライン」、BCP 145、RFC 5405、DOI 10.17487 / RFC5405、2008年11月、<http://www.rfc-editor.org/info / rfc5405>。
[RFC7390] Rahman, A., Ed., and E. Dijk, Ed., "Group Communication for the Constrained Application Protocol (CoAP)", RFC 7390, DOI 10.17487/RFC7390, October 2014, <http://www.rfc-editor.org/info/rfc7390>.
[RFC7390] Rahman、A.、Ed。およびE. Dijk、Ed。、「Group Communication for the Constrained Application Protocol（CoAP）」、RFC 7390、DOI 10.17487 / RFC7390、2014年10月、<http：// www。 rfc-editor.org/info/rfc7390>。
[RFC7641] Hartke, K., "Observing Resources in the Constrained Application Protocol (CoAP)", RFC 7641, DOI 10.17487/RFC7641, September 2015, <http://www.rfc-editor.org/info/rfc7641>.
[RFC7641] Hartke、K。、「Observing Resources in the Constrained Application Protocol（CoAP）」、RFC 7641、DOI 10.17487 / RFC7641、2015年9月、<http://www.rfc-editor.org/info/rfc7641>。
Acknowledgments
謝辞
Thanks to Carsten Bormann, Matthias Kovatsch, Esko Dijk, Bert Greevenbosch, Akbar Rahman, and Klaus Hartke for their valuable input.
Carsten Bormann、Matthias Kovatsch、Esko Dijk、Bert Greevenbosch、Akbar Rahman、Klaus Hartkeの貴重な情報に感謝します。
Authors' Addresses
著者のアドレス
Abhijan Bhattacharyya Tata Consultancy Services Ltd. Kolkata, India
遠征Bhattacharya Tata Consultancy Services LTD。コルカタ、インド
Email: abhijan.bhattacharyya@tcs.com
Soma Bandyopadhyay Tata Consultancy Services Ltd. Kolkata, India
Soma Bandyopadhyay Tata Consultancy Services Ltd.コルカタ、インド
Email: soma.bandyopadhyay@tcs.com
Arpan Pal Tata Consultancy Services Ltd. Kolkata, India
Arpan Pal Tata Consultancy Services Ltd.コルカタ、インド
Email: arpan.pal@tcs.com
Tulika Bose Tata Consultancy Services Ltd. Kolkata, India
Tulika Bose Tata Consultancy Services Ltd.コルカタ、インド
Email: tulika.bose@tcs.com