[要約] RFC 7641は、CoAPでリソースを観測するための方法を提案しています。目的は、制約のある環境でのリソースの監視を可能にし、効率的なネットワークリソースの使用を促進することです。
Internet Engineering Task Force (IETF) K. Hartke
Request for Comments: 7641 Universitaet Bremen TZI
Category: Standards Track September 2015
ISSN: 2070-1721
Observing Resources in the Constrained Application Protocol (CoAP)
制約付きアプリケーションプロトコル（CoAP）でのリソースの監視
Abstract
概要
The Constrained Application Protocol (CoAP) is a RESTful application protocol for constrained nodes and networks. The state of a resource on a CoAP server can change over time. This document specifies a simple protocol extension for CoAP that enables CoAP clients to "observe" resources, i.e., to retrieve a representation of a resource and keep this representation updated by the server over a period of time. The protocol follows a best-effort approach for sending new representations to clients and provides eventual consistency between the state observed by each client and the actual resource state at the server.
制約付きアプリケーションプロトコル（CoAP）は、制約付きノードおよびネットワーク用のRESTfulアプリケーションプロトコルです。 CoAPサーバー上のリソースの状態は、時間の経過とともに変化する可能性があります。このドキュメントでは、CoAPクライアントがリソースを「監視」できるようにする、つまり、リソースの表現を取得し、この表現を一定期間サーバーが更新し続けることを可能にするCoAPの単純なプロトコル拡張を指定します。このプロトコルは、新しい表現をクライアントに送信するためのベストエフォートアプローチに従い、各クライアントによって監視された状態とサーバーでの実際のリソース状態との間に最終的な一貫性を提供します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7641.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7641で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 4
1.3. Consistency Model . . . . . . . . . . . . . . . . . . . . 6
1.4. Observable Resources . . . . . . . . . . . . . . . . . . 7
1.5. Requirements Notation . . . . . . . . . . . . . . . . . . 8
2. The Observe Option . . . . . . . . . . . . . . . . . . . . . 9
3. Client-Side Requirements . . . . . . . . . . . . . . . . . . 10
3.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Notifications . . . . . . . . . . . . . . . . . . . . . . 10
3.3. Caching . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4. Reordering . . . . . . . . . . . . . . . . . . . . . . . 12
3.5. Transmission . . . . . . . . . . . . . . . . . . . . . . 13
3.6. Cancellation . . . . . . . . . . . . . . . . . . . . . . 13
4. Server-Side Requirements . . . . . . . . . . . . . . . . . . 14
4.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2. Notifications . . . . . . . . . . . . . . . . . . . . . . 14
4.3. Caching . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.4. Reordering . . . . . . . . . . . . . . . . . . . . . . . 16
4.5. Transmission . . . . . . . . . . . . . . . . . . . . . . 17
5. Intermediaries . . . . . . . . . . . . . . . . . . . . . . . 20
6. Web Linking . . . . . . . . . . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . 22
9.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 24
A.1. Client/Server Examples . . . . . . . . . . . . . . . . . 24
A.2. Proxy Examples . . . . . . . . . . . . . . . . . . . . . 28
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 30
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 30
The Constrained Application Protocol (CoAP) [RFC7252] is intended to provide RESTful services [REST] not unlike HTTP [RFC7230] while reducing the complexity of implementation as well as the size of packets exchanged in order to make these services useful in a highly constrained network of themselves highly constrained nodes [RFC7228].
制約付きアプリケーションプロトコル（CoAP）[RFC7252]は、HTTP [RFC7230]とは異なり、RESTfulサービス[REST]を提供することを目的としていますが、これらのサービスを非常に制約のあるサービスで役立つように交換するパケットのサイズだけでなく、実装の複雑さも軽減します高度に制約されたノード自体のネットワーク[RFC7228]。
The model of REST is that of a client exchanging representations of resources with a server, where a representation captures the current or intended state of a resource. The server is the authority for representations of the resources in its namespace. A client interested in the state of a resource initiates a request to the server; the server then returns a response with a representation of the resource that is current at the time of the request.
RESTのモデルは、リソースの表現をサーバーと交換するクライアントのモデルで、表現はリソースの現在の状態または意図された状態をキャプチャします。サーバーは、そのネームスペース内のリソースの表現に対する権限です。リソースの状態に関心のあるクライアントは、サーバーへの要求を開始します。次に、サーバーは、要求時に最新であるリソースの表現を含む応答を返します。
This model does not work well when a client is interested in having a current representation of a resource over a period of time. Existing approaches from HTTP, such as repeated polling or HTTP long polling [RFC6202], generate significant complexity and/or overhead and thus are less applicable in a constrained environment.
このモデルは、クライアントが一定期間リソースの現在の表現を保持することに関心がある場合はうまく機能しません。繰り返しポーリングやHTTPロングポーリング[RFC6202]などのHTTPからの既存のアプローチは、かなりの複雑さやオーバーヘッドを生成するため、制約のある環境ではあまり適用できません。
The protocol specified in this document extends the CoAP core protocol with a mechanism for a CoAP client to "observe" a resource on a CoAP server: the client retrieves a representation of the resource and requests this representation be updated by the server as long as the client is interested in the resource.
このドキュメントで指定されているプロトコルは、CoAPコアプロトコルを拡張して、CoAPクライアントがCoAPサーバー上のリソースを「監視」するメカニズムを備えています。クライアントは、リソースの表現を取得し、サーバーがこの表現を更新するように要求します。クライアントはリソースに関心があります。
The protocol keeps the architectural properties of REST. It enables high scalability and efficiency through the support of caches and proxies. There is no intention, though, to solve the full set of problems that the existing HTTP solutions solve or to replace publish/subscribe networks that solve a much more general problem [RFC5989].
プロトコルはRESTのアーキテクチャプロパティを保持します。キャッシュとプロキシのサポートにより、高いスケーラビリティと効率を実現します。ただし、既存のHTTPソリューションが解決する問題の完全なセットを解決したり、より一般的な問題を解決するパブリッシュ/サブスクライブネットワークを置き換える意図はありません[RFC5989]。
The protocol is based on the well-known observer design pattern [GOF]. In this design pattern, components called "observers" register at a specific, known provider called the "subject" that they are interested in being notified whenever the subject undergoes a change in state. The subject is responsible for administering its list of registered observers. If multiple subjects are of interest to an observer, the observer must register separately for all of them.
このプロトコルは、よく知られているオブザーバーデザインパターン[GOF]に基づいています。この設計パターンでは、「オブザーバー」と呼ばれるコンポーネントは、「サブジェクト」と呼ばれる特定の既知のプロバイダーに登録され、サブジェクトの状態が変化するたびに通知を受けることに関心があります。被験者は、登録されたオブザーバーのリストを管理する責任があります。複数のサブジェクトがオブザーバーに関心がある場合、オブザーバーはそれらすべてに対して個別に登録する必要があります。
Observer Subject
| |
| Registration |
+------------------->|
| |
| Notification |
|<-------------------+
| |
| Notification |
|<-------------------+
| |
| Notification |
|<-------------------+
| |
Figure 1: The Observer Design Pattern
図1：オブザーバーの設計パターン
The observer design pattern is realized in CoAP as follows:
オブザーバーデザインパターンは、CoAPで次のように実現されます。
Subject: In the context of CoAP, the subject is a resource in the namespace of a CoAP server. The state of the resource can change over time, ranging from infrequent updates to continuous state transformations.
件名：CoAPのコンテキストでは、件名はCoAPサーバーのネームスペース内のリソースです。リソースの状態は、まれな更新から継続的な状態変換まで、時間の経過とともに変化する可能性があります。
Observer: An observer is a CoAP client that is interested in having a current representation of the resource at any given time.
オブザーバー：オブザーバーは、リソースの現在の表現を常に把握することに関心のあるCoAPクライアントです。
Registration: A client registers its interest in a resource by initiating an extended GET request to the server. In addition to returning a representation of the target resource, this request causes the server to add the client to the list of observers of the resource.
登録：クライアントは、サーバーへの拡張GET要求を開始することにより、リソースへの関心を登録します。ターゲットリソースの表現を返すことに加えて、このリクエストにより、サーバーはリソースのオブザーバーのリストにクライアントを追加します。
Notification: Whenever the state of a resource changes, the server notifies each client in the list of observers of the resource. Each notification is an additional CoAP response sent by the server in reply to the single extended GET request and includes a complete, updated representation of the new resource state.
通知：リソースの状態が変化するたびに、サーバーはリソースのオブザーバーのリストにある各クライアントに通知します。各通知は、単一の拡張GET要求に応答してサーバーから送信される追加のCoAP応答であり、新しいリソースの状態の完全で更新された表現が含まれます。
Figure 2 below shows an example of a CoAP client registering its interest in a resource and receiving three notifications: the first with the current state upon registration, and then two upon changes to the resource state. Both the registration request and the notifications are identified as such by the presence of the Observe Option defined in this document. In notifications, the Observe Option additionally provides a sequence number for reordering detection. All notifications carry the token specified by the client, so the client can easily correlate them to the request.
以下の図2は、リソースへの関心を登録し、3つの通知を受信するCoAPクライアントの例を示しています。1つは登録時の現在の状態、もう1つはリソース状態の変更時です。登録要求と通知の両方は、このドキュメントで定義されている監視オプションの存在によって識別されます。通知では、監視オプションにより、検出を並べ替えるためのシーケンス番号が追加で提供されます。すべての通知にはクライアントが指定したトークンが含まれているため、クライアントはそれらを要求に簡単に関連付けることができます。
Client Server
| |
| GET /temperature |
| Token: 0x4a | Registration
| Observe: 0 |
+------------------->|
| |
| 2.05 Content |
| Token: 0x4a | Notification of
| Observe: 12 | the current state
| Payload: 22.9 Cel |
|<-------------------+
| |
| 2.05 Content |
| Token: 0x4a | Notification upon
| Observe: 44 | a state change
| Payload: 22.8 Cel |
|<-------------------+
| |
| 2.05 Content |
| Token: 0x4a | Notification upon
| Observe: 60 | a state change
| Payload: 23.1 Cel |
|<-------------------+
| |
Figure 2: Observing a Resource in CoAP
図2：CoAPでのリソースの監視
Note: In this document, "Cel" stands for "degrees Celsius".
注：このドキュメントでは、「Cel」は「摂氏」を表します。
A client remains on the list of observers as long as the server can determine the client's continued interest in the resource. The server may send a notification in a confirmable CoAP message to request an acknowledgement from the client. When the client deregisters, rejects a notification, or the transmission of a notification times out after several transmission attempts, the client is considered no longer interested in the resource and is removed by the server from the list of observers.
サーバーがリソースに対するクライアントの継続的な関心を判別できる限り、クライアントはオブザーバーのリストに残ります。サーバーは、確認可能なCoAPメッセージで通知を送信して、クライアントからの確認応答を要求できます。クライアントが登録を解除するか、通知を拒否するか、数回の送信試行後に通知の送信がタイムアウトすると、クライアントはリソースに関心がないと見なされ、サーバーによってオブザーバーのリストから削除されます。
While a client is in the list of observers of a resource, the goal of the protocol is to keep the resource state observed by the client as closely in sync with the actual state at the server as possible.
クライアントがリソースのオブザーバーのリストに含まれている間、プロトコルの目標は、クライアントによって監視されるリソースの状態を、サーバーの実際の状態と可能な限り密接に同期させることです。
It cannot be avoided that the client and the server become out of sync at times: First, there is always some latency between the change of the resource state and the receipt of the notification. Second, CoAP messages with notifications can get lost, which will cause the client to assume an old state until it receives a new notification. And third, the server may erroneously come to the conclusion that the client is no longer interested in the resource, which will cause the server to stop sending notifications and the client to assume an old state until it eventually registers its interest again.
クライアントとサーバーが時々同期しなくなるのを避けることはできません。最初に、リソースの状態の変化と通知の受信の間に常にある程度の待ち時間があります。第2に、通知を含むCoAPメッセージが失われる可能性があり、これにより、クライアントは新しい通知を受信するまで古い状態を引き継ぐことになります。 3番目に、サーバーは誤ってクライアントがリソースに関心を持たなくなったと誤って判断する可能性があります。これにより、サーバーは通知の送信を停止し、クライアントが最終的に再び関心を登録するまで古い状態を引き継ぐことになります。
The protocol addresses this issue as follows:
プロトコルはこの問題に次のように対処します。
o It follows a best-effort approach for sending the current representation to the client after a state change: clients should see the new state after a state change as soon as possible, and they should see as many states as possible. This is limited by congestion control, however, so a client cannot rely on observing every single state that a resource might go through.
o これは、状態変更後に現在の表現をクライアントに送信するためのベストエフォートアプローチに従います。状態変更後、クライアントはできるだけ早く新しい状態を確認し、できるだけ多くの状態を確認する必要があります。ただし、これは輻輳制御によって制限されるため、クライアントは、リソースが通過する可能性があるすべての状態の監視に依存することはできません。
o It labels notifications with a maximum duration up to which it is acceptable for the observed state and the actual state to be out of sync. When the age of the notification received reaches this limit, the client cannot use the enclosed representation until it receives a new notification.
o 監視対象の状態と実際の状態が同期していないことが許容される最大期間で通知にラベルを付けます。受信した通知の経過時間がこの制限に達すると、クライアントは新しい通知を受信するまで囲まれた表現を使用できません。
o It is designed on the principle of eventual consistency: the protocol guarantees that if the resource does not undergo a new change in state, eventually all registered observers will have a current representation of the latest resource state.
o 結果整合性の原則に基づいて設計されています。プロトコルは、リソースの状態が変化しない場合、登録されたすべてのオブザーバーが最新のリソース状態の現在の表現を持つことを保証します。
A CoAP server is the authority for determining under what conditions resources change their state and thus when observers are notified of new resource states. The protocol does not offer explicit means for setting up triggers or thresholds; it is up to the server to expose observable resources that change their state in a way that is useful in the application context.
CoAPサーバーは、リソースが状態を変更する状況を決定するための権限であり、オブザーバーに新しいリソースの状態がいつ通知されるかを決定します。このプロトコルは、トリガーまたはしきい値を設定するための明示的な手段を提供しません。アプリケーションコンテキストで役立つように状態を変更する監視可能なリソースを公開するかどうかは、サーバーに依存します。
For example, a CoAP server with an attached temperature sensor could expose one or more of the following resources:
たとえば、温度センサーが接続されたCoAPサーバーは、次のリソースの1つ以上を公開する可能性があります。
o <coap://server/temperature>, which changes its state every few
seconds to a current reading of the temperature sensor;
o <coap://server/temperature/felt>, which changes its state to
"COLD" whenever the temperature reading drops below a certain pre-
configured threshold and to "WARM" whenever the reading exceeds a
second, slightly higher threshold;
o <coap://server/temperature/critical?above=42>, which changes its
state based on the client-specified parameter value either every
few seconds to the current temperature reading if the temperature
exceeds the threshold or to "OK" when the reading drops below;
o <coap://server/?query=select+avg(temperature)+from+Sensor.window: time(30sec)>, which accepts expressions of arbitrary complexity and changes its state accordingly.
o <coap：// server /？query = select + avg（temperature）+ from + Sensor.window：time（30sec）>。これは、任意の複雑さの式を受け入れ、それに応じてその状態を変更します。
Thus, by designing CoAP resources that change their state on certain conditions, it is possible to update the client only when these conditions occur instead of supplying it continuously with raw sensor data. By parameterizing resources, this is not limited to conditions defined by the server, but can be extended to arbitrarily complex queries specified by the client. The application designer therefore can choose exactly the right level of complexity for the application envisioned and devices involved and is not constrained to a "one size fits all" mechanism built into the protocol.
したがって、特定の条件で状態を変更するCoAPリソースを設計することにより、生のセンサーデータを継続的に提供する代わりに、これらの条件が発生した場合にのみクライアントを更新できます。リソースをパラメータ化することで、これはサーバーによって定義された条件に限定されず、クライアントによって指定された任意の複雑なクエリに拡張できます。したがって、アプリケーション設計者は、想定されるアプリケーションと関連するデバイスに適した複雑さのレベルを正確に選択でき、プロトコルに組み込まれた「1つのサイズですべてに適合する」メカニズムに制限されません。
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 RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
The Observe Option has the following properties. Its meaning depends on whether it is included in a GET request or in a response.
監視オプションには次のプロパティがあります。その意味は、GET要求に含まれるか、応答に含まれるかによって異なります。
+-----+---+---+---+---+---------+--------+--------+---------+
| No. | C | U | N | R | Name | Format | Length | Default |
+-----+---+---+---+---+---------+--------+--------+---------+
| 6 | | x | - | | Observe | uint | 0-3 B | (none) |
+-----+---+---+---+---+---------+--------+--------+---------+
C=Critical, U=Unsafe, N=No-Cache-Key, R=Repeatable
Table 1: The Observe Option
表1：監視オプション
When included in a GET request, the Observe Option extends the GET method so it does not only retrieve a current representation of the target resource, but also requests the server to add or remove an entry in the list of observers of the resource depending on the option value. The list entry consists of the client endpoint and the token specified by the client in the request. Possible values are:
GETリクエストに含まれている場合、監視オプションはGETメソッドを拡張するので、ターゲットリソースの現在の表現を取得するだけでなく、サーバーに応じてリソースのオブザーバーのリストにエントリを追加または削除するようサーバーに要求します。オプション値。リストエントリは、クライアントエンドポイントと、リクエストでクライアントによって指定されたトークンで構成されます。可能な値は次のとおりです。
0 (register) adds the entry to the list, if not present;
0（登録）は、存在しない場合、リストにエントリを追加します。
1 (deregister) removes the entry from the list, if present.
1（登録解除）は、存在する場合、リストからエントリーを削除します。
The Observe Option is not critical for processing the request. If the server is unwilling or unable to add a new entry to the list of observers, then the request falls back to a normal GET request and the response does not include the Observe Option.
監視オプションは、リクエストの処理には重要ではありません。サーバーがオブザーバーのリストに新しいエントリを追加したくない、または追加できない場合、要求は通常のGET要求にフォールバックし、応答には監視オプションが含まれません。
The Observe Option is not part of the Cache-Key: a cacheable response obtained with an Observe Option in the request can be used to satisfy a request without an Observe Option, and vice versa. When a stored response with an Observe Option is used to satisfy a normal GET request, the option MUST be removed before the response is returned.
Observe OptionはCache-Keyの一部ではありません。リクエスト内のObserve Optionで取得されたキャッシュ可能な応答を使用して、Observe Optionなしでリクエストを満たすことができます。逆も同様です。 Observe Optionで保存された応答を使用して通常のGET要求を満たす場合、応答が返される前にオプションを削除する必要があります。
When included in a response, the Observe Option identifies the message as a notification. This implies that a matching entry exists in the list of observers and that the server will notify the client of changes to the resource state. The option value is a sequence number for reordering detection (see Sections 3.4 and 4.4).
応答に含まれる場合、監視オプションはメッセージを通知として識別します。これは、一致するエントリがオブザーバーのリストに存在し、サーバーがリソース状態の変更をクライアントに通知することを意味します。オプション値は、再順序付け検出のシーケンス番号です（セクション3.4および4.4を参照）。
The value of the Observe Option is encoded as an unsigned integer in network byte order using a variable number of bytes ('uint' option format); see Section 3.2 of RFC 7252 [RFC7252].
Observe Optionの値は、可変バイト数（ 'uint'オプション形式）を使用して、ネットワークバイトオーダーの符号なし整数としてエンコードされます。 RFC 7252 [RFC7252]のセクション3.2をご覧ください。
A client registers its interest in a resource by issuing a GET request with an Observe Option set to 0 (register). If the server returns a 2.xx response that includes an Observe Option as well, the server has successfully added an entry with the client endpoint and request token to the list of observers of the target resource, and the client will be notified of changes to the resource state.
クライアントは、監視オプションを0（登録）に設定してGET要求を発行することにより、リソースへの関心を登録します。サーバーがObserve Optionも含む2.xx応答を返した場合、サーバーはクライアントエンドポイントとリクエストトークンを含むエントリをターゲットリソースのオブザーバーのリストに正常に追加しており、クライアントへの変更が通知されますリソースの状態。
Like a fresh response can be used to satisfy a request without contacting the server, the stream of updates resulting from one observation request can be used to satisfy another (observation or normal GET) request if the target resource is the same. A client MUST aggregate such requests and MUST NOT register more than once for the same target resource. The target resource is identified by all options in the request that are part of the Cache-Key. This includes, for example, the full request URI and the Accept Option.
新しい応答を使用してサーバーに接続せずに要求を満たすことができるように、1つの監視要求から生じる更新のストリームを使用して、ターゲットリソースが同じ場合、別の（監視または通常のGET）要求を満たすことができます。クライアントはそのようなリクエストを集約しなければならず（MUST）、同じターゲットリソースに対して複数回登録してはなりません（MUST NOT）。ターゲットリソースは、キャッシュキーの一部であるリクエスト内のすべてのオプションによって識別されます。これには、たとえば、完全なリクエストURIとAccept Optionが含まれます。
Notifications are additional responses sent by the server in reply to the single extended GET request that created the registration. Each notification includes the token specified by the client in the request. The only difference between a notification and a normal response is the presence of the Observe Option.
通知は、登録を作成した単一の拡張GET要求に応答してサーバーが送信する追加の応答です。各通知には、リクエストでクライアントによって指定されたトークンが含まれます。通知と通常の応答の唯一の違いは、監視オプションの存在です。
Notifications typically have a 2.05 (Content) response code. They include an Observe Option with a sequence number for reordering detection (see Section 3.4) and a payload in the same Content-Format as the initial response. If the client included one or more ETag Options in the GET request (see Section 3.3), notifications can have a 2.03 (Valid) response code rather than a 2.05 (Content) response code. Such notifications include an Observe Option with a sequence number but no payload.
通常、通知には2.05（コンテンツ）応答コードがあります。それらには、再順序付け検出のためのシーケンス番号（セクション3.4を参照）と最初の応答と同じContent-Formatのペイロードを持つObserve Optionが含まれています。クライアントがGETリクエストに1つ以上のETagオプションを含めた場合（セクション3.3を参照）、通知には2.05（コンテンツ）応答コードではなく2.03（有効）応答コードが含まれる場合があります。そのような通知には、ペイロードがなく、シーケンス番号が付いた監視オプションが含まれます。
In the event that the resource changes in a way that would cause a normal GET request at that time to return a non-2.xx response (for example, when the resource is deleted), the server sends a notification with an appropriate response code (such as 4.04 Not Found) and removes the client's entry from the list of observers of the resource. Non-2.xx responses do not include an Observe Option.
その時点で通常のGETリクエストが非2.xx応答を返すような方法でリソースが変更された場合（たとえば、リソースが削除された場合）、サーバーは適切な応答コードを含む通知を送信します（4.04 Not Foundなど）、リソースのオブザーバーのリストからクライアントのエントリを削除します。 2.xx以外の応答には、監視オプションは含まれません。
As notifications are just additional responses to a GET request, notifications partake in caching as defined in Section 5.6 of RFC 7252 [RFC7252]. Both the freshness model and the validation model are supported.
通知はGET要求に対する単なる追加の応答であるため、RFC 7252 [RFC7252]のセクション5.6で定義されているように、通知はキャッシングに参加します。鮮度モデルと検証モデルの両方がサポートされています。
A client MAY store a notification like a response in its cache and use a stored notification that is fresh without contacting the server. Like a response, a notification is considered fresh while its age is not greater than the value indicated by the Max-Age Option (and no newer notification/response has been received).
クライアントは、応答のような通知をキャッシュに格納し、サーバーに接続せずに新しい格納された通知を使用する場合があります。応答と同様に、通知は新しいと見なされますが、その経過時間はMax-Ageオプションで指定された値を超えません（新しい通知/応答は受信されません）。
The server will do its best to keep the resource state observed by the client as closely in sync with the actual state as possible. However, a client cannot rely on observing every single state that a resource might go through. For example, if the network is congested or the state changes more frequently than the network can handle, the server can skip notifications for any number of intermediate states.
サーバーは、クライアントが監視するリソースの状態を、実際の状態と可能な限り密接に同期させるように最善を尽くします。ただし、クライアントは、リソースが通過する可能性があるすべての状態の監視に依存することはできません。たとえば、ネットワークが混雑しているか、ネットワークが処理できるよりも頻繁に状態が変化する場合、サーバーは中間状態の通知をスキップできます。
The server uses the Max-Age Option to indicate an age up to which it is acceptable that the observed state and the actual state are inconsistent. If the age of the latest notification becomes greater than its indicated Max-Age, then the client MUST NOT assume that the enclosed representation reflects the actual resource state.
サーバーはMax-Age Optionを使用して、観測された状態と実際の状態が一致しないことが許容されるまでの経過時間を示します。最新の通知の経過時間が指定された最大経過時間よりも長くなる場合、クライアントは、囲まれた表現が実際のリソースの状態を反映していると想定してはなりません（MUST NOT）。
To make sure it has a current representation and/or to re-register its interest in a resource, a client MAY issue a new GET request with the same token as the original at any time. All options MUST be identical to those in the original request except for the set of ETag Options. It is RECOMMENDED that the client does not issue the request while it still has a fresh notification/response for the resource in its cache. Additionally, the client SHOULD at least wait for a random amount of time between 5 and 15 seconds after Max-Age expired to reduce collisions with other clients.
現在の表現であることを確認したり、リソースへの関心を再登録したりするために、クライアントはいつでも元のトークンと同じトークンを使用して新しいGETリクエストを発行できます（MAY）。 ETagオプションのセットを除いて、すべてのオプションは元のリクエストのオプションと同じである必要があります。キャッシュ内のリソースに対する新しい通知/応答がまだある間は、クライアントが要求を発行しないことをお勧めします。さらに、クライアントは、他のクライアントとの衝突を減らすために、Max-Ageの期限が切れた後、少なくとも5〜15秒のランダムな時間待機する必要があります。
When a client has one or more notifications stored in its cache for a resource, it can use the ETag Option in the GET request to give the server an opportunity to select a stored notification to be used.
クライアントが1つ以上の通知をリソースのキャッシュに保存している場合、GETリクエストのETagオプションを使用して、サーバーに使用する保存済み通知を選択する機会を与えることができます。
The client MAY include an ETag Option for each stored response that is applicable in the GET request. Whenever the observed resource changes to a representation identified by one of the ETag Options, the server can select a stored response by sending a 2.03 (Valid) notification with an appropriate ETag Option instead of a 2.05 (Content) notification.
クライアントは、GETリクエストで適用可能な保存された各応答のETagオプションを含めることができます。監視対象のリソースがETagオプションの1つで識別される表現に変化するたびに、サーバーは、2.05（コンテンツ）通知ではなく、適切なETagオプションを含む2.03（有効）通知を送信することで、保存された応答を選択できます。
A client implementation needs to keep all candidate responses in its cache until it is no longer interested in the target resource or it re-registers with a new set of entity tags.
クライアント実装は、ターゲットリソースに関心がなくなるか、新しいエンティティタグのセットに再登録するまで、すべての候補応答をキャッシュに保持する必要があります。
Messages with notifications can arrive in a different order than they were sent. Since the goal is to keep the observed state as closely in sync with the actual state as possible, a client MUST consider the notification that was sent most recently as the freshest, regardless of the order of arrival.
通知付きのメッセージは、送信された順序とは異なる順序で到着する場合があります。目的は、観測された状態を実際の状態と可能な限り密接に同期させることであるため、クライアントは、到着順序に関係なく、直近に送信された通知を最新のものと見なす必要があります。
To provide an order among notifications for the client, the server sets the value of the Observe Option in each notification to the 24 least significant bits of a strictly increasing sequence number. An incoming notification was sent more recently than the freshest notification so far when one of the following conditions is met:
クライアントに通知間の順序を提供するために、サーバーは各通知の監視オプションの値を、厳密に増加するシーケンス番号の最下位24ビットに設定します。次のいずれかの条件が満たされた場合、これまでに受信した通知が最新の通知よりも最近送信されました。
(V1 < V2 and V2 - V1 < 2^23) or
(V1 > V2 and V1 - V2 > 2^23) or
(T2 > T1 + 128 seconds)
where V1 is the value of the Observe Option in the freshest notification so far, V2 is the value of the Observe Option in the incoming notification, T1 is a client-local timestamp for the freshest notification so far, and T2 is a client-local timestamp for the incoming notification.
ここで、V1はこれまでの最新の通知の監視オプションの値、V2は受信通知の監視オプションの値、T1はこれまでの最新の通知のクライアントローカルタイムスタンプ、T2はクライアントローカルです。着信通知のタイムスタンプ。
Design Note: The first two conditions verify that V1 is less than V2 in 24-bit serial number arithmetic [RFC1982]. The third condition ensures that if the server is generating serial numbers based on a local clock, the time elapsed between the two incoming messages is not so large that the difference between V1 and V2 has become larger than the largest integer that it is meaningful to add to a 24-bit serial number; in other words, after 128 seconds have elapsed without any notification, a client does not need to check the sequence numbers to assume that an incoming notification was sent more recently than the freshest notification it has received so far.
デザインノート：最初の2つの条件は、24ビットのシリアル番号演算[RFC1982]でV1がV2より小さいことを確認します。 3番目の条件は、サーバーがローカルクロックに基づいてシリアル番号を生成している場合、2つの着信メッセージ間の経過時間がそれほど大きくないため、V1とV2の差が、追加する意味のある最大の整数よりも大きくなっていることを保証します24ビットのシリアル番号。つまり、通知なしで128秒が経過した後、クライアントはシーケンス番号をチェックする必要がなく、着信通知がこれまでに受信した最新の通知よりも最近送信されたと想定します。
The duration of 128 seconds was chosen as a nice round number greater than MAX_LATENCY (Section 4.8.2 of RFC 7252 [RFC7252]).
128秒の期間は、MAX_LATENCY（RFC 7252 [RFC7252]のセクション4.8.2）を超える適切なラウンド数として選択されました。
A notification can be confirmable or non-confirmable, i.e., it can be sent in a confirmable or a non-confirmable message. The message type used for a notification is independent of the type used for the request and of any previous notification.
通知は、確認可能または確認不可能にすることができます。つまり、確認可能または確認不能なメッセージで送信できます。通知に使用されるメッセージタイプは、リクエストに使用されるタイプや以前の通知から独立しています。
If a client does not recognize the token in a confirmable notification, it MUST NOT acknowledge the message and SHOULD reject it with a Reset message; otherwise, the client MUST acknowledge the message as usual. In the case of a non-confirmable notification, rejecting the message with a Reset message is OPTIONAL.
確認可能な通知でクライアントがトークンを認識しない場合、クライアントはメッセージを確認してはならず（MUST NOT）、リセットメッセージで拒否する必要があります（SHOULD）。それ以外の場合、クライアントは通常どおりメッセージを確認する必要があります。確認できない通知の場合、リセットメッセージでメッセージを拒否することはオプションです。
An acknowledgement message signals to the server that the client is alive and interested in receiving further notifications; if the server does not receive an acknowledgement in reply to a confirmable notification, it will assume that the client is no longer interested and will eventually remove the associated entry from the list of observers (Section 4.5).
確認メッセージは、クライアントが生存していて、さらに通知を受信することに関心があることをサーバーに通知します。サーバーが確認可能な通知に応答して確認応答を受信しない場合、クライアントは興味がないと見なし、最終的に関連するエントリをオブザーバーのリストから削除します（セクション4.5）。
A client that is no longer interested in receiving notifications for a resource can simply "forget" the observation. When the server then sends the next notification, the client will not recognize the token in the message and thus will return a Reset message. This causes the server to remove the associated entry from the list of observers. The entries in lists of observers are effectively "garbage collected" by the server.
リソースの通知を受信する必要がなくなったクライアントは、単に観察を「忘れる」だけです。その後、サーバーが次の通知を送信すると、クライアントはメッセージ内のトークンを認識しないため、リセットメッセージを返します。これにより、サーバーは関連するエントリをオブザーバーのリストから削除します。オブザーバーのリストのエントリは、サーバーによって事実上「ガベージコレクション」されます。
Implementation Note: Due to potential message loss, the Reset message may not reach the server. The client may therefore have to reject multiple notifications, each with one Reset message, until the server finally removes the associated entry from the list of observers and stops sending notifications.
実装上の注意：メッセージが失われる可能性があるため、リセットメッセージがサーバーに届かない場合があります。したがって、クライアントは、サーバーが最後に関連するエントリをオブザーバーのリストから削除して通知の送信を停止するまで、それぞれが1つのリセットメッセージを持つ複数の通知を拒否する必要がある場合があります。
In some circumstances, it may be desirable to cancel an observation and release the resources allocated by the server to it more eagerly. In this case, a client MAY explicitly deregister by issuing a GET request that has the Token field set to the token of the observation to be cancelled and includes an Observe Option with the value set to 1 (deregister). All other options MUST be identical to those in the registration request except for the set of ETag Options. When the server receives such a request, it will remove any matching entry from the list of observers and process the GET request as usual.
状況によっては、監視をキャンセルし、サーバーによって割り当てられたリソースをより積極的に解放することが望ましい場合があります。この場合、クライアントは、トークンフィールドがキャンセルされる監視のトークンに設定され、値が1（登録解除）に設定された監視オプションを含むGETリクエストを発行することにより、明示的に登録を解除できます（MAY）。 ETagオプションのセットを除いて、他のすべてのオプションは、登録リクエストのオプションと同じでなければなりません。サーバーがこのようなリクエストを受信すると、一致するエントリがオブザーバーのリストから削除され、通常どおりGETリクエストが処理されます。
A GET request with an Observe Option set to 0 (register) requests the server not only to return a current representation of the target resource, but also to add the client to the list of observers of that resource. Upon success, the server returns a current representation of the resource and MUST keep this representation updated (as described in Section 1.3) as long as the client is on the list of observers.
Observe Optionを0（登録）に設定したGET要求は、サーバーにターゲットリソースの現在の表現を返すだけでなく、そのリソースのオブザーバーのリストにクライアントを追加することも要求します。成功すると、サーバーはリソースの現在の表現を返し、クライアントがオブザーバーのリストにある限り、この表現を更新し続けなければなりません（セクション1.3で説明）。
The entry in the list of observers is keyed by the client endpoint and the token specified by the client in the request. If an entry with a matching endpoint/token pair is already present in the list (which, for example, happens when the client wishes to reinforce its interest in a resource), the server MUST NOT add a new entry but MUST replace or update the existing one.
オブザーバーのリストのエントリは、クライアントエンドポイントと、リクエストでクライアントによって指定されたトークンによってキーが付けられます。一致するエンドポイント/トークンのペアを持つエントリがリストにすでに存在する場合（たとえば、クライアントがリソースへの関心を強化したい場合に発生します）、サーバーは新しいエントリを追加してはならず（MUST）、既存のもの。
A server that is unable or unwilling to add a new entry to the list of observers of a resource MAY silently ignore the registration request and process the GET request as usual. The resulting response MUST NOT include an Observe Option, the absence of which signals to the client that it will not be notified of changes to the resource and, e.g., needs to poll the resource for its state instead.
リソースのオブザーバーのリストに新しいエントリを追加できない、または追加したくないサーバーは、登録要求を無視し、通常どおりGET要求を処理できます（MAY）。結果の応答には監視オプションを含めてはなりません。監視オプションがないと、リソースへの変更が通知されないことをクライアントに通知し、たとえば、代わりにリソースの状態をポーリングする必要があります。
If the Observe Option in a GET request is set to 1 (deregister), then the server MUST remove any existing entry with a matching endpoint/ token pair from the list of observers and process the GET request as usual. The resulting response MUST NOT include an Observe Option.
GETリクエストのObserve Optionが1（登録解除）に設定されている場合、サーバーは、一致するエンドポイント/トークンのペアを持つ既存のエントリをオブザーバーのリストから削除し、通常どおりGETリクエストを処理する必要があります。結果の応答には、監視オプションを含めることはできません。
A client is notified of changes to the resource state by additional responses sent by the server in reply to the GET request. Each such notification response (including the initial response) MUST echo the token specified by the client in the GET request. If there are multiple entries in the list of observers, the order in which the clients are notified is not defined; the server is free to use any method to determine the order.
クライアントは、GET要求への応答としてサーバーから送信される追加の応答によって、リソースの状態の変化を通知されます。そのような各通知応答（初期応答を含む）は、GET要求でクライアントによって指定されたトークンをエコーする必要があります。オブザーバのリストに複数のエントリがある場合、クライアントに通知される順序は定義されていません。サーバーは、任意の方法を使用して順序を決定できます。
A notification SHOULD have a 2.05 (Content) or 2.03 (Valid) response code. However, in the event that the state of a resource changes in a way that would cause a normal GET request at that time to return a non-2.xx response (for example, when the resource is deleted), the server SHOULD notify the client by sending a notification with an appropriate response code (such as 4.04 Not Found) and subsequently MUST remove the associated entry from the list of observers of the resource.
通知には、2.05（コンテンツ）または2.03（有効）応答コードが必要です（SHOULD）。ただし、リソースの状態がその時点で通常のGETリクエストが非2.xx応答を返すような方法で変化した場合（たとえば、リソースが削除された場合）、サーバーは通知する必要があります（SHOULD）クライアントは、適切な応答コード（4.04 Not Foundなど）を含む通知を送信し、その後、リソースのオブザーバーのリストから関連するエントリを削除する必要があります。
The Content-Format specified in a 2.xx notification MUST be the same as the one used in the initial response to the GET request. If the server is unable to continue sending notifications in this format, it SHOULD send a notification with a 4.06 (Not Acceptable) response code and subsequently MUST remove the associated entry from the list of observers of the resource.
2.xx通知で指定されたContent-Formatは、GET要求への初期応答で使用されたものと同じでなければなりません。サーバーがこの形式で通知を送信し続けることができない場合は、4.06（Not Acceptable）応答コードで通知を送信する必要があり（SHOULD）、その後、リソースのオブザーバーのリストから関連するエントリを削除する必要があります。
A 2.xx notification MUST include an Observe Option with a sequence number as specified in Section 4.4 below; a non-2.xx notification MUST NOT include an Observe Option.
2.xx通知には、以下のセクション4.4で指定されているシーケンス番号のある監視オプションを含める必要があります。 2.xx以外の通知には、監視オプションを含めることはできません。
As notifications are just additional responses sent by the server in reply to a GET request, they are subject to caching as defined in Section 5.6 of RFC 7252 [RFC7252].
通知は、GETリクエストへの応答としてサーバーから送信される単なる追加の応答であるため、RFC 7252 [RFC7252]のセクション5.6で定義されているように、キャッシュの対象になります。
After returning the initial response, the server MUST keep the resource state that is observed by the client as closely in sync with the actual resource state as possible.
初期応答を返した後、サーバーは、クライアントが監視するリソースの状態を、実際のリソースの状態と可能な限り密接に同期させなければなりません（MUST）。
Since becoming out of sync at times cannot be avoided, the server MUST indicate for each representation an age up to which it is acceptable that the observed state and the actual state are inconsistent. This age is application dependent and MUST be specified in notifications using the Max-Age Option.
時々同期が外れることは避けられないので、サーバーは各表現について、観察された状態と実際の状態が矛盾していることが許容されるまでの経過時間を示さなければなりません（MUST）。この年齢はアプリケーションによって異なり、Max-Ageオプションを使用して通知で指定する必要があります。
When the resource does not change and the client has a current representation, the server does not need to send a notification. However, if the client does not receive a notification, the client cannot tell if the observed state and the actual state are still in sync. Thus, when the age of the latest notification becomes greater than its indicated Max-Age, the client no longer has a usable representation of the resource state. The server MAY wish to prevent that by sending a new notification with the unchanged representation and a new Max-Age just before the Max-Age indicated earlier expires.
リソースが変更されず、クライアントに現在の表現がある場合、サーバーは通知を送信する必要はありません。ただし、クライアントが通知を受信しない場合、クライアントは監視された状態と実際の状態がまだ同期しているかどうかを判断できません。したがって、最新の通知の経過時間が指定されたMax-Ageよりも大きくなると、クライアントはリソースの状態の使用可能な表現を失います。サーバーは、以前のMax-Ageが期限切れになる直前に、変更されていない表現と新しいMax-Ageを含む新しい通知を送信することで、これを防止することができます。
A client can include a set of entity tags in its request using the ETag Option. When an observed resource changes its state and the origin server is about to send a 2.05 (Content) notification, then whenever that notification has an entity tag in the set of entity tags specified by the client, the server MAY send a 2.03 (Valid) response with an appropriate ETag Option instead.
クライアントは、ETagオプションを使用して、リクエストに一連のエンティティタグを含めることができます。監視対象のリソースの状態が変化し、配信元サーバーが2.05（コンテンツ）通知を送信しようとしている場合、その通知にクライアントによって指定されたエンティティタグのセットにエンティティタグが含まれている場合は常に、サーバーは2.03（有効）を送信できます（MAY）代わりに適切なETagオプションを使用して応答します。
Because messages can get reordered, the client needs a way to determine if a notification arrived later than a newer notification. For this purpose, the server MUST set the value of the Observe Option of each notification it sends to the 24 least significant bits of a strictly increasing sequence number. The sequence number MAY start at any value and MUST NOT increase so fast that it increases by more than 2^23 within less than 256 seconds.
メッセージは並べ替えられる可能性があるため、クライアントは、通知が新しい通知よりも後に到着したかどうかを判別する方法を必要とします。この目的のために、サーバーは、送信する各通知の監視オプションの値を、厳密に増加するシーケンス番号の最下位24ビットに設定する必要があります。シーケンス番号は任意の値で開始してもよい（MAY）ので、256秒未満で2 ^ 23以上増加するほど速く増加してはならない（MUST NOT）。
The sequence number selected for a notification MUST be greater than that of any preceding notification sent to the same client with the same token for the same resource. The value of the Observe Option MUST be current at the time of transmission; if a notification is retransmitted, the server MUST update the value of the option to the sequence number that is current at that time before retransmission.
通知用に選択されたシーケンス番号は、同じリソースの同じトークンを使用して同じクライアントに送信された前の通知のシーケンス番号よりも大きい必要があります。監視オプションの値は、送信時に最新である必要があります。通知が再送信される場合、サーバーはオプションの値を再送信前のその時点でのシーケンス番号に更新する必要があります。
Implementation Note: A simple implementation that satisfies the requirements is to obtain a timestamp from a local clock. The sequence number then is the timestamp in ticks, where 1 tick = (256 seconds)/(2^23) = 30.52 microseconds. It is not necessary that the clock reflects the current time/date.
実装上の注意：要件を満たす簡単な実装は、ローカルクロックからタイムスタンプを取得することです。シーケンス番号は、ティック単位のタイムスタンプです。1ティック=（256秒）/（2 ^ 23）= 30.52マイクロ秒です。クロックが現在の時刻/日付を反映している必要はありません。
Another valid implementation is to store a 24-bit unsigned integer variable per resource and increment this variable each time the resource undergoes a change of state (provided that the resource changes its state less than 2^23 times in the first 256 seconds after every state change). This removes the need to update the value of the Observe Option on retransmission when the resource state did not change.
別の有効な実装は、リソースごとに24ビットの符号なし整数変数を格納し、リソースの状態が変化するたびにこの変数をインクリメントすることです（ただし、リソースが状態を変更するのは、各状態の最初の256秒で2 ^ 23回未満です）。変化する）。これにより、リソースの状態が変化しなかった場合に、再送信時に監視オプションの値を更新する必要がなくなります。
Design Note: The choice of a 24-bit option value and a time span of 256 seconds theoretically allows for a notification rate of up to 65536 notifications per second. Constrained nodes often have rather imprecise clocks, though, and inaccuracies of the client and server side may cancel out or add in effect. Therefore, the maximum notification rate is reduced to 32768 notifications per second. This is still well beyond the highest known design objective of around 1 kHz (most CoAP applications will be several orders of magnitude below that) but allows total clock inaccuracies of up to -50/+100%.
デザインノート：24ビットのオプション値と256秒のタイムスパンを選択すると、理論的には1秒あたり最大65536通知の通知レートが可能になります。ただし、制約されたノードのクロックはかなり不正確であることが多く、クライアント側とサーバー側の不正確さが相殺されたり、実際に追加されたりする場合があります。したがって、最大通知レートは32768通知/秒に減少します。これは、既知の最も高い設計目標である1 kHzをはるかに上回っています（ほとんどのCoAPアプリケーションはその数桁下回ります）が、最大-50 / + 100％の合計クロック誤差を許容します。
A notification can be sent in a confirmable or a non-confirmable message. The message type used is typically application dependent and may be determined by the server for each notification individually.
通知は、確認可能なメッセージまたは確認できないメッセージで送信できます。使用されるメッセージタイプは、通常、アプリケーションに依存し、通知ごとにサーバーによって個別に決定されます。
For example, for resources that change in a somewhat predictable or regular fashion, notifications can be sent in non-confirmable messages; for resources that change infrequently, notifications can be sent in confirmable messages. The server can combine these two approaches depending on the frequency of state changes and the importance of individual notifications.
たとえば、ある程度予測可能または定期的に変化するリソースの場合、確認不可能なメッセージで通知を送信できます。頻繁に変更されないリソースの場合、確認可能なメッセージで通知を送信できます。サーバーは、状態変更の頻度と個々の通知の重要性に応じて、これら2つのアプローチを組み合わせることができます。
A server MAY choose to skip sending a notification if it knows that it will send another notification soon, for example, when the state of a resource is changing frequently. It also MAY choose to send more than one notification for the same resource state. However, above all, the server MUST ensure that a client in the list of observers of a resource eventually observes the latest state if the resource does not undergo a new change in state.
サーバーは、リソースの状態が頻繁に変化している場合など、別の通知をすぐに送信することがわかっている場合、通知の送信をスキップすることを選択できます。また、同じリソース状態に対して複数の通知を送信することを選択する場合もあります。ただし、何よりも、サーバーは、リソースの状態の新しい変化を受けない場合、リソースのオブザーバーのリストにあるクライアントが最終的に最新の状態を監視することを保証する必要があります。
For example, when state changes occur in bursts, the server can skip some notifications, send the notifications in non-confirmable messages, and make sure that the client observes the latest state change by repeating the last notification in a confirmable message when the burst is over.
たとえば、状態の変化がバーストで発生した場合、サーバーは一部の通知をスキップし、確認不可能なメッセージで通知を送信し、バーストが発生したときに確認可能なメッセージで最後の通知を繰り返すことにより、クライアントが最新の状態変化を確実に監視できるようにします以上。
The client's acknowledgement of a confirmable notification signals that the client is interested in receiving further notifications. If a client rejects a confirmable or non-confirmable notification with a Reset message, or if the last attempt to retransmit a confirmable notification times out, then the client is considered no longer interested and the server MUST remove the associated entry from the list of observers.
確認可能な通知のクライアントの確認は、クライアントがさらなる通知の受信に関心があることを示します。クライアントがリセットメッセージで確認可能または確認不可能な通知を拒否した場合、または確認可能な通知を再送信する最後の試行がタイムアウトした場合、クライアントは関心がないと見なされ、サーバーは関連するエントリをオブザーバーのリストから削除する必要があります。
Implementation Note: To properly process a Reset message that rejects a non-confirmable notification, a server needs to remember the message IDs of the non-confirmable notifications it sends. This may be challenging for a server with constrained resources. However, since Reset messages are transmitted unreliably, the client must be prepared in case the Reset messages are not received by the server. Thus, a server can always pretend that a Reset message rejecting a non-confirmable notification was lost.
実装上の注意：確認不可能な通知を拒否するリセットメッセージを適切に処理するには、サーバーは送信する確認不可能な通知のメッセージIDを記憶する必要があります。これは、リソースに制約があるサーバーにとっては困難な場合があります。ただし、リセットメッセージは確実に送信されないため、サーバーがリセットメッセージを受信しない場合に備えて、クライアントを準備する必要があります。したがって、サーバーは常に、確認できない通知を拒否するリセットメッセージが失われたと偽ることができます。
If a server does this, it could accelerate cancellation by sending the following notifications to that client in confirmable messages.
サーバーがこれを行う場合、確認可能なメッセージでそのクライアントに次の通知を送信することにより、キャンセルを加速できます。
A server that transmits notifications mostly in non-confirmable messages MUST send a notification in a confirmable message instead of a non-confirmable message at least every 24 hours. This prevents a client that went away or is no longer interested from remaining in the list of observers indefinitely.
ほとんどの場合確認不可能なメッセージで通知を送信するサーバーは、少なくとも24時間ごとに確認不可能なメッセージではなく確認可能なメッセージで通知を送信する必要があります。これにより、立ち去ったクライアントや興味がなくなったクライアントが無期限にオブザーバーのリストに残ることがなくなります。
Basic congestion control for CoAP is provided by the exponential back-off mechanism in Section 4.2 of RFC 7252 [RFC7252] and the limitations in Section 4.7 of RFC 7252 [RFC7252]. However, CoAP places the responsibility of congestion control for simple request/ response interactions only on the clients: rate-limiting request transmission implicitly controls the transmission of the responses. When a single request yields a potentially infinite number of notifications, additional responsibility needs to be placed on the server.
CoAPの基本的な輻輳制御は、RFC 7252 [RFC7252]のセクション4.2の指数バックオフメカニズムと、RFC 7252 [RFC7252]のセクション4.7の制限によって提供されます。ただし、CoAPは、単純な要求/応答対話の輻輳制御の責任をクライアントにのみ置きます。レート制限要求の送信は、応答の送信を暗黙的に制御します。単一の要求が潜在的に無限の数の通知を生成する場合、追加の責任がサーバーに課される必要があります。
In order not to cause congestion, servers MUST strictly limit the number of simultaneous outstanding notifications/responses that they transmit to a given client to NSTART (1 by default; see Section 4.7 of RFC 7252 [RFC7252]). An outstanding notification/response is either a confirmable message for which an acknowledgement has not yet been received and whose last retransmission attempt has not yet timed out or a non-confirmable message for which the waiting time that results from the following rate-limiting rules has not yet elapsed.
輻輳を引き起こさないために、サーバーは、特定のクライアントに送信する同時未解決通知/応答の数をNSTARTに厳密に制限する必要があります（デフォルトでは1。RFC7252 [RFC7252]のセクション4.7を参照）。未解決の通知/応答は、確認応答がまだ受信されておらず、最後の再送信の試行がまだタイムアウトしていない確認可能なメッセージ、または次のレート制限ルールに起因する待機時間のある確認不可能なメッセージのいずれかです。まだ経過していません。
The server SHOULD NOT send more than one non-confirmable notification per round-trip time (RTT) to a client on average. If the server cannot maintain an RTT estimate for a client, it SHOULD NOT send more than one non-confirmable notification every 3 seconds and SHOULD use an even less aggressive rate when possible (see also Section 3.1.2 of RFC 5405 [RFC5405]).
サーバーは、平均してラウンドトリップ時間（RTT）ごとに複数の確認不可能な通知をクライアントに送信してはなりません（SHOULD NOT）。サーバーがクライアントのRTT見積もりを維持できない場合は、3秒ごとに複数の確認不可能な通知を送信してはならず（SHOULD NOT）、可能な場合はさらに攻撃的なレートを使用する必要があります（RFC 5405 [RFC5405]のセクション3.1.2も参照）。 。
Further congestion control optimizations and considerations are expected in the future with advanced CoAP congestion control mechanisms.
高度なCoAP輻輳制御メカニズムにより、今後さらに輻輳制御の最適化と考慮事項が予想されます。
The state of an observed resource may change while the number of simultaneous outstanding notifications/responses to a client on the list of observers is greater than or equal to NSTART. In this case, the server cannot notify the client of the new resource state immediately but has to wait for an outstanding notification/response to complete first.
監視対象リソースの状態は、オブザーバーのリストにあるクライアントへの未解決の同時通知/応答の数がNSTART以上である間に変化する可能性があります。この場合、サーバーはクライアントに新しいリソースの状態をすぐに通知できませんが、未処理の通知/応答が最初に完了するのを待つ必要があります。
If there exists an outstanding notification/response that the server transmits to the client and that pertains to the changed resource, then it is desirable for the server to stop working towards getting the representation of the old resource state to the client and to start transmitting the current representation to the client instead, so the resource state observed by the client stays closer in sync with the actual state at the server.
サーバーがクライアントに送信し、変更されたリソースに関連する未解決の通知/応答が存在する場合、サーバーが古いリソースの状態の表現をクライアントに取得することに向けて動作を停止し、クライアントへの送信を開始することが望ましい代わりにクライアントへの現在の表現。したがって、クライアントによって監視されるリソースの状態は、サーバーでの実際の状態との同期を保ちます。
For this purpose, the server MAY optimize the transmission process by aborting the transmission of the old notification (but not before the current transmission attempt is completed) and starting a new transmission for the new notification (but with the retransmission timer and counter of the aborted transmission retained).
この目的のために、サーバーは古い通知の送信を中止することによって（ただし、現在の送信試行が完了する前ではなく）、新しい通知の新しい送信を開始することによって（ただし、再送信タイマーと中止されたカウンターを使用して）送信プロセスを最適化できます（MAY）。伝送が保持されます）。
In more detail, a server MAY supersede an outstanding transmission that pertains to an observation as follows:
より詳細には、サーバーは次のように観測に関連する未処理の送信に取って代わることができます：
1. Wait for the current (re)transmission attempt to be acknowledged, rejected, or to time out (confirmable transmission); or, wait for the waiting time to elapse or the transmission to be rejected (non-confirmable transmission).
1. 現在の（再）送信の試行が確認、拒否、またはタイムアウト（確認可能な送信）されるのを待ちます。または、待機時間が経過するか、送信が拒否される（確認できない送信）のを待ちます。
2. If the transmission is rejected or it was the last attempt to retransmit a notification, remove the associated entry from the list of observers of the observed resource.
2. 送信が拒否された場合、または通知を再送信する最後の試みであった場合は、監視対象リソースのオブザーバーのリストから関連するエントリを削除します。
3. If the entry is still in the list of observers, start to transmit a new notification with a representation of the current resource state. Should the resource have changed its state more than once in the meantime, the notifications for the intermediate states are silently skipped.
3. エントリがまだオブザーバーのリストにある場合は、現在のリソースの状態を表す新しい通知の送信を開始します。その間にリソースがその状態を2回以上変更した場合、中間状態の通知は通知なくスキップされます。
4. The new notification is transmitted with a new Message ID and the following transmission parameters: if the previous (re)transmission attempt timed out, retain its transmission parameters, increment the retransmission counter, and double the timeout; otherwise, initialize the transmission parameters as usual (see Section 4.2 of RFC 7252 [RFC7252]).
4. 新しい通知は、新しいメッセージIDと次の送信パラメーターで送信されます。前の（再）送信の試行がタイムアウトした場合、その送信パラメーターを保持し、再送信カウンターをインクリメントし、タイムアウトを2倍にします。それ以外の場合は、通常どおり送信パラメータを初期化します（RFC 7252 [RFC7252]のセクション4.2を参照）。
It is possible that the server later receives an acknowledgement for a confirmable notification that it superseded this way. Even though this does not signal consistency, it is valuable in that it signals the client's further interest in the resource. The server therefore should avoid inadvertently removing the associated entry from the list of observers.
サーバーが後で、この方法に取って代わったという確認可能な通知の確認を受け取る可能性があります。これは一貫性を示すものではありませんが、リソースに対するクライアントのさらなる関心を示すという点で価値があります。したがって、サーバーは、オブザーバーのリストから関連するエントリを誤って削除しないようにする必要があります。
A client may be interested in a resource in the namespace of a server that is reached through a chain of one or more CoAP intermediaries. In this case, the client registers its interest with the first intermediary towards the server, acting as if it was communicating with the server itself, as specified in Section 3. It is the task of this intermediary to provide the client with a current representation of the target resource and to keep the representation updated upon changes to the resource state, as specified in Section 4.
クライアントは、1つ以上のCoAP仲介者のチェーンを介して到達するサーバーのネームスペース内のリソースに関心がある場合があります。この場合、クライアントはサーバーへの最初の仲介者に関心を登録し、セクション3で指定されているように、サーバー自体と通信しているかのように動作します。この仲介者の役割は、クライアントに現在の表現を提供することです。ターゲットリソース。セクション4で指定されているように、リソースの状態が変化したときに表現を更新し続けるため。
To perform this task, the intermediary SHOULD make use of the protocol specified in this document, taking the role of the client and registering its own interest in the target resource with the next hop towards the server. If the response returned by the next hop doesn't include an Observe Option, the intermediary MAY resort to polling the next hop or MAY itself return a response without an Observe Option.
このタスクを実行するために、仲介者はこのドキュメントで指定されたプロトコルを利用して、クライアントの役割を果たし、サーバーへのネクストホップでターゲットリソースに自身の関心を登録する必要があります。ネクストホップから返された応答に監視オプションが含まれていない場合、仲介者はネクストホップのポーリングに頼るか、監視オプションなしで応答を返すことができます（MAY）。
The communication between each pair of hops is independent; each hop in the server role MUST determine individually how many notifications to send, of which message type, and so on. Each hop MUST generate its own values for the Observe Option in notifications and MUST set the value of the Max-Age Option according to the age of the local current representation.
ホップの各ペア間の通信は独立しています。サーバーロールの各ホップは、送信する通知の数、メッセージの種類などを個別に決定する必要があります。各ホップは、通知の監視オプションに独自の値を生成する必要があり、ローカルの現在の表現の経過時間に応じてMax-Ageオプションの値を設定する必要があります。
If two or more clients have registered their interest in a resource with an intermediary, the intermediary MUST register itself only once with the next hop and fan out the notifications it receives to all registered clients. This relieves the next hop from sending the same notifications multiple times and thus enables scalability.
2つ以上のクライアントが仲介者のリソースへの関心を登録している場合、仲介者は自身をネクストホップに一度だけ登録し、すべての登録済みクライアントに受信する通知をファンアウトする必要があります。これにより、ネクストホップが同じ通知を複数回送信することから解放され、スケーラビリティが実現します。
An intermediary is not required to act on behalf of a client to observe a resource; an intermediary MAY observe a resource, for example, just to keep its own cache up to date.
仲介者は、クライアントの代わりに行動してリソースを監視する必要はありません。仲介者は、たとえば、自身のキャッシュを最新の状態に保つために、リソースを監視できます（MAY）。
See Appendix A.2 for examples.
例については、付録A.2を参照してください。
A web link [RFC5988] to a resource accessible over CoAP (for example, in a link-format document [RFC6690]) MAY include the target attribute "obs".
CoAPを介してアクセス可能なリソースへのWebリンク[RFC5988]（たとえば、リンク形式のドキュメント[RFC6690]内）には、ターゲット属性「obs」を含めることができます（MAY）。
The "obs" attribute, when present, is a hint indicating that the destination of a link is useful for observation and thus, for example, should have a suitable graphical representation in a user interface. Note that this is only a hint; it is not a promise that the Observe Option can actually be used to perform the observation. A client may need to resort to polling the resource if the Observe Option is not returned in the response to the GET request.
「obs」属性は、存在する場合、リンクの宛先が観察に役立つことを示すヒントであり、したがって、たとえば、ユーザーインターフェイスに適切なグラフィック表現が必要です。これは単なるヒントであることに注意してください。観察オプションを実際に使用して観察を実行できるという保証はありません。 GETリクエストへの応答でObserve Optionが返されない場合、クライアントはリソースのポーリングに頼る必要があります。
A value MUST NOT be given for the "obs" attribute; any present value MUST be ignored by parsers. The "obs" attribute MUST NOT appear more than once in a given link-value; occurrences after the first MUST be ignored by parsers.
「obs」属性に値を指定してはなりません（MUST NOT）。現在の値はパーサーによって無視される必要があります。 「obs」属性は、特定のリンク値に複数回出現してはなりません（MUST NOT）。最初の後ろの出現はパーサーによって無視されなければなりません。
The security considerations in Section 11 of [RFC7252], the CoAP specification, apply.
[RFC7252]のセクション11、CoAP仕様のセキュリティに関する考慮事項が適用されます。
Observing resources can dramatically increase the negative effects of amplification attacks. That is, not only can notifications messages be much larger than the request message, but the nature of the protocol can cause a significant number of notifications to be generated. Without client authentication, a server therefore MUST strictly limit the number of notifications that it sends between receiving acknowledgements that confirm the actual interest of the client in the data; i.e., any notifications sent in non-confirmable messages MUST be interspersed with confirmable messages. Note that an attacker may still spoof the acknowledgements if the confirmable messages are sufficiently predictable.
リソースを観察すると、増幅攻撃の悪影響が劇的に増加する可能性があります。つまり、通知メッセージが要求メッセージよりもはるかに大きくなるだけでなく、プロトコルの性質により、大量の通知が生成される可能性があります。したがって、クライアント認証がない場合、サーバーは、データに対するクライアントの実際の関心を確認する確認応答を受信する間に送信する通知の数を厳密に制限する必要があります。つまり、確認不可能なメッセージで送信された通知には、確認可能なメッセージを挿入する必要があります。確認可能なメッセージが十分に予測可能である場合、攻撃者は依然として確認応答を偽装する可能性があることに注意してください。
The protocol follows a best-effort approach for keeping the state observed by a client and the actual resource state at a server in sync. This may have the client and the server become out of sync at times. Depending on the sensitivity of the observed resource, operating on an old state might be a security threat. The client therefore must be careful not to use a representation after its Max-Age expires, and the server must set the Max-Age Option to a sensible value.
このプロトコルは、クライアントが監視する状態とサーバーの実際のリソース状態を同期させるベストエフォートアプローチに従います。これにより、クライアントとサーバーが同期しなくなることがあります。観察されたリソースの機密性によっては、古い状態での操作がセキュリティ上の脅威になる場合があります。したがって、クライアントはMax-Ageの有効期限が切れた後に表現を使用しないように注意する必要があり、サーバーはMax-Age Optionを適切な値に設定する必要があります。
As with any protocol that creates state, attackers may attempt to exhaust the resources that the server has available for maintaining the list of observers for each resource. Servers may want to apply access controls to this creation of state. As degraded behavior, the server can always fall back to processing the request as a normal GET request (without an Observe Option) if it is unwilling or unable to add a client to the list of observers of a resource, including if system resources are exhausted or nearing exhaustion.
状態を作成する任意のプロトコルと同様に、攻撃者は、サーバーが各リソースのオブザーバーのリストを維持するために利用できるリソースを使い果たすことを試みる可能性があります。サーバーは、この状態の作成にアクセス制御を適用したい場合があります。低下した動作として、システムリソースが使い果たされているかどうかを含め、リソースのオブザーバーのリストにクライアントを追加したくない、またはできない場合、サーバーは常に通常のGETリクエスト（監視オプションなし）としてリクエストの処理にフォールバックできます。または消耗に近づいています。
Intermediaries must be careful to ensure that notifications cannot be employed to create a loop. A simple way to break any loops is to employ caches for forwarding notifications in intermediaries.
仲介者は、通知を使用してループを作成できないように注意する必要があります。ループを解消する簡単な方法は、中間で通知を転送するためにキャッシュを使用することです。
Resources can be observed over CoAP that is secured by Datagram Transport Layer Security (DTLS) using any of the security modes described in Section 9 of RFC 7252. The use of DTLS is indicated by the "coaps" URI scheme. All notifications resulting from a GET request with an Observe Option MUST be returned within the same epoch of the same connection as the request.
リソースは、RFC 7252のセクション9で説明されているセキュリティモードのいずれかを使用して、Datagram Transport Layer Security（DTLS）によって保護されたCoAPを介して監視できます。DTLSの使用は、「coaps」URIスキームで示されます。 Observe Optionを使用したGETリクエストの結果であるすべての通知は、リクエストと同じ接続の同じエポック内で返される必要があります。
The following entry has been added to the CoAP Option Numbers registry:
次のエントリがCoAPオプション番号レジストリに追加されました。
+--------+---------+-----------+
| Number | Name | Reference |
+--------+---------+-----------+
| 6 | Observe | RFC 7641 |
+--------+---------+-----------+
[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>。
[RFC5988] Nottingham, M., "Web Linking", RFC 5988, DOI 10.17487/RFC5988, October 2010, <http://www.rfc-editor.org/info/rfc5988>.
[RFC5988]ノッティンガム、M。、「Webリンク」、RFC 5988、DOI 10.17487 / RFC5988、2010年10月、<http://www.rfc-editor.org/info/rfc5988>。
[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>。
[GOF] Gamma, E., Helm, R., Johnson, R., and J. Vlissides, "Design Patterns: Elements of Reusable Object-Oriented Software", Addison-Wesley Professional Computing Series, 1994.
[GOF] Gamma、E.、Helm、R.、Johnson、R.、J。Vlissides、「設計パターン：再利用可能なオブジェクト指向ソフトウェアの要素」、Addison-Wesley Professional Computing Series、1994。
[REST] Fielding, R., "Architectural Styles and the Design of Network-based Software Architectures", Ph.D. Dissertation, University of California, Irvine, 2000, <http://www.ics.uci.edu/~fielding/pubs/dissertation/ fielding_dissertation.pdf>.
[REST] Fielding、R。、「Architectural Styles and the Design of Network-based Software Architectures」、Ph.D。カリフォルニア大学アーバイン校の論文、2000年、<http://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf>。
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, DOI 10.17487/RFC1982, August 1996, <http://www.rfc-editor.org/info/rfc1982>.
[RFC1982] Elz、R. and R. Bush、 "Serial Number Arithmetic"、RFC 1982、DOI 10.17487 / RFC1982、August 1996、<http://www.rfc-editor.org/info/rfc1982>。
[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>。
[RFC5989] Roach, A., "A SIP Event Package for Subscribing to Changes to an HTTP Resource", RFC 5989, DOI 10.17487/RFC5989, October 2010, <http://www.rfc-editor.org/info/rfc5989>.
[RFC5989] Roach、A。、「HTTPリソースへの変更をサブスクライブするためのSIPイベントパッケージ」、RFC 5989、DOI 10.17487 / RFC5989、2010年10月、<http://www.rfc-editor.org/info/rfc5989 >。
[RFC6202] Loreto, S., Saint-Andre, P., Salsano, S., and G. Wilkins, "Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP", RFC 6202, DOI 10.17487/RFC6202, April 2011, <http://www.rfc-editor.org/info/rfc6202>.
[RFC6202] Loreto、S.、Saint-Andre、P.、Salsano、S。、およびG. Wilkins、「双方向HTTPでのロングポーリングとストリーミングの使用に関する既知の問題とベストプラクティス」、RFC 6202、DOI 10.17487 / RFC6202、2011年4月、<http://www.rfc-editor.org/info/rfc6202>。
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, <http://www.rfc-editor.org/info/rfc6690>.
[RFC6690] Shelby、Z。、「Constrained RESTful Environments（CoRE）Link Format」、RFC 6690、DOI 10.17487 / RFC6690、2012年8月、<http://www.rfc-editor.org/info/rfc6690>。
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, <http://www.rfc-editor.org/info/rfc7228>.
[RFC7228] Bormann、C.、Ersue、M.、and A. Keranen、 "Terminology for Constrained-Node Networks"、RFC 7228、DOI 10.17487 / RFC7228、May 2014、<http://www.rfc-editor.org / info / rfc7228>。
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.
[RFC7230]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Message Syntax and Routing」、RFC 7230、DOI 10.17487 / RFC7230、2014年6月、<http://www.rfc-editor.org/info/ rfc7230>。
Observed CLIENT SERVER Actual
t State | | State
____________ | | ____________
1 | |
2 unknown | | 18.5 Cel
3 +----->| Header: GET 0x41011633
4 | GET | Token: 0x4a
5 | | Uri-Path: temperature
6 | | Observe: 0 (register)
7 | |
8 | |
9 ____________ |<-----+ Header: 2.05 0x61451633
10 | 2.05 | Token: 0x4a
11 18.5 Cel | | Observe: 9
12 | | Max-Age: 15
13 | | Payload: "18.5 Cel"
14 | |
15 | | ____________
16 ____________ |<-----+ Header: 2.05 0x51457b50
17 | 2.05 | 19.2 Cel Token: 0x4a
18 19.2 Cel | | Observe: 16
29 | | Max-Age: 15
20 | | Payload: "19.2 Cel"
21 | |
Figure 3: A Client Registers and Receives One Notification of the
Current State and One of a New State upon a State Change
Observed CLIENT SERVER Actual
t State | | State
____________ | | ____________
22 | |
23 19.2 Cel | | 19.2 Cel
24 | | ____________
25 | X----+ Header: 2.05 0x51457b51
26 | 2.05 | 19.7 Cel Token: 0x4a
27 | | Observe: 25
28 | | Max-Age: 15
29 | | Payload: "19.7 Cel"
30 | |
31 ____________ | |
32 | |
33 19.2 Cel | |
34 (stale) | |
35 | |
36 | |
37 | |
38 +----->| Header: GET 0x41011634
39 | GET | Token: 0xb2
40 | | Uri-Path: temperature
41 | | Observe: 0 (register)
42 | |
43 | |
44 ____________ |<-----+ Header: 2.05 0x61451634
45 | 2.05 | Token: 0xb2
46 19.7 Cel | | Observe: 44
47 | | Max-Age: 15
48 | | ETag: 0x78797a7a79
49 | | Payload: "19.7 Cel"
50 | |
Figure 4: The Client Re-registers after Max-Age Ends
図4：Max-Ageの終了後にクライアントが再登録する
Observed CLIENT SERVER Actual
t State | | State
____________ | | ____________
51 | |
52 19.7 Cel | | 19.7 Cel
53 | |
54 | | ____________
55 | crash
56 |
57 |
58 |
59 ____________ |
60 |
61 19.7 Cel |
62 (stale) |
63 | reboot____________
64 | |
65 | | 20.0 Cel
66 | |
67 +----->| Header: GET 0x41011635
68 | GET | Token: 0xf9
69 | | Uri-Path: temperature
70 | | Observe: 0 (register)
71 | | ETag: 0x78797a7a79
72 | |
73 | |
74 ____________ |<-----+ Header: 2.05 0x61451635
75 | 2.05 | Token: 0xf9
76 20.0 Cel | | Observe: 74
77 | | Max-Age: 15
78 | | Payload: "20.0 Cel"
79 | |
80 | | ____________
81 ____________ |<-----+ Header: 2.03 0x5143aa0c
82 | 2.03 | 19.7 Cel Token: 0xf9
83 19.7 Cel | | Observe: 81
84 | | ETag: 0x78797a7a79
85 | | Max-Age: 15
86 | |
Figure 5: The Client Re-registers and Gives the Server the Opportunity to Select a Stored Response
図5：クライアントが再登録し、サーバーに保存された応答を選択する機会を与える
Observed CLIENT SERVER Actual
t State | | State
____________ | | ____________
87 | |
88 19.7 Cel | | 19.7 Cel
89 | |
90 | | ____________
91 ____________ |<-----+ Header: 2.05 0x4145aa0f
92 | 2.05 | 19.3 Cel Token: 0xf9
93 19.3 Cel | | Observe: 91
94 | | Max-Age: 15
95 | | Payload: "19.3 Cel"
96 | |
97 | |
98 +- - ->| Header: 0x7000aa0f
99 | |
100 | |
101 | |
102 | | ____________
103 | |
104 | | 19.0 Cel
105 | |
106 ____________ | |
107 | |
108 19.3 Cel | |
109 (stale) | |
110 | |
Figure 6: The Client Rejects a Notification and Thereby Cancels the Observation
図6：クライアントは通知を拒否し、それによって観察をキャンセルします
CLIENT PROXY SERVER
| | |
| +----->| Header: GET 0x41015fb8
| | GET | Token: 0x1a
| | | Uri-Host: sensor.example
| | | Uri-Path: status
| | | Observe: 0 (register)
| | |
| |<-----+ Header: 2.05 0x61455fb8
| | 2.05 | Token: 0x1a
| | | Observe: 42
| | | Max-Age: 60
| | | Payload: "ready"
| | |
+----->| | Header: GET 0x41011633
| GET | | Token: 0x9a
| | | Proxy-Uri: coap://sensor.example/status
| | |
|<-----+ | Header: 2.05 0x61451633
| 2.05 | | Token: 0x9a
| | | Max-Age: 53
| | | Payload: "ready"
| | |
| |<-----+ Header: 2.05 0x514505fc0
| | 2.05 | Token: 0x1a
| | | Observe: 135
| | | Max-Age: 60
| | | Payload: "busy"
| | |
+----->| | Header: GET 0x41011634
| GET | | Token: 0x9b
| | | Proxy-Uri: coap://sensor.example/status
| | |
|<-----+ | Header: 2.05 0x61451634
| 2.05 | | Token: 0x9b
| | | Max-Age: 49
| | | Payload: "busy"
| | |
Figure 7: A Proxy Observes a Resource to Keep its Cache Up to Date
図7：プロキシがリソースを監視してキャッシュを最新の状態に保つ
CLIENT PROXY SERVER
| | |
+----->| | Header: GET 0x41011635
| GET | | Token: 0x6a
| | | Proxy-Uri: coap://sensor.example/status
| | | Observe: 0 (register)
| | |
|<- - -+ | Header: 0x60001635
| | |
| +----->| Header: GET 0x4101af90
| | GET | Token: 0xaa
| | | Uri-Host: sensor.example
| | | Uri-Path: status
| | | Observe: 0 (register)
| | |
| |<-----+ Header: 2.05 0x6145af90
| | 2.05 | Token: 0xaa
| | | Observe: 67
| | | Max-Age: 60
| | | Payload: "ready"
| | |
|<-----+ | Header: 2.05 0x4145af94
| 2.05 | | Token: 0x6a
| | | Observe: 17346
| | | Max-Age: 60
| | | Payload: "ready"
| | |
+- - ->| | Header: 0x6000af94
| | |
| |<-----+ Header: 2.05 0x51455a20
| | 2.05 | Token: 0xaa
| | | Observe: 157
| | | Max-Age: 60
| | | Payload: "busy"
| | |
|<-----+ | Header: 2.05 0x5145af9b
| 2.05 | | Token: 0x6a
| | | Observe: 17436
| | | Max-Age: 60
| | | Payload: "busy"
| | |
Figure 8: A Client Observes a Resource through a Proxy
図8：クライアントがプロキシを介してリソースを監視する
Acknowledgements
謝辞
Carsten Bormann was an original author of this document and is acknowledged for significant contribution to this document.
Carsten Bormannはこのドキュメントの原作者であり、このドキュメントへの多大な貢献により認められています。
Thanks to Daniele Alessandrelli, Jari Arkko, Peter A. Bigot, Angelo P. Castellani, Gilbert Clark, Esko Dijk, Thomas Fossati, Brian Frank, Bert Greevenbosch, Jeroen Hoebeke, Cullen Jennings, Matthias Kovatsch, Barry Leiba, Salvatore Loreto, Charles Palmer, Akbar Rahman, Zach Shelby, and Floris Van den Abeele for helpful comments and discussions that have shaped the document.
ダニエル・アレッサンドレリ、ヤリ・アルコ、ピーター・A・ビゴ、アンジェロ・P・カステラーニ、ギルバート・クラーク、エスコ・ダイク、トーマス・フォッサティ、ブライアン・フランク、バート・グリーベンボッシュ、イェローエン・ホーベケ、カレン・ジェニングス、マティアス・コヴァッチ、バリー・レイバ、シャルヴァトーレ・ロレトのおかげで、Akbar Rahman、Zach Shelby、およびFloris Van den Abeeleは、ドキュメントを形成した有益なコメントとディスカッションを求めています。
This work was supported in part by Klaus Tschira Foundation, Intel, Cisco, and Nokia.
この作品は、Klaus Tschira Foundation、Intel、Cisco、Nokiaによって部分的にサポートされました。
Author's Address
著者のアドレス
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