[要約] RFC 8132は、CoAPにおけるPATCHとFETCHメソッドの仕様を定めたものです。このRFCの目的は、CoAPプロトコルを使用してリソースの部分的な更新と取得をサポートすることです。
Internet Engineering Task Force (IETF) P. van der Stok
Request for Comments: 8132 Consultant
Category: Standards Track C. Bormann
ISSN: 2070-1721 Universitaet Bremen TZI
A. Sehgal
NAVOMI, Inc.
April 2017
PATCH and FETCH Methods for the Constrained Application Protocol (CoAP)
制約付きアプリケーションプロトコル（CoAP）のPATCHおよびFETCHメソッド
Abstract
概要
The methods defined in RFC 7252 for the Constrained Application Protocol (CoAP) only allow access to a complete resource, not to parts of a resource. In case of resources with larger or complex data, or in situations where resource continuity is required, replacing or requesting the whole resource is undesirable. Several applications using CoAP need to access parts of the resources.
制約付きアプリケーションプロトコル（CoAP）についてRFC 7252で定義されているメソッドは、リソースの一部ではなく、完全なリソースへのアクセスのみを許可します。より大きなデータや複雑なデータを含むリソースの場合、またはリソースの継続性が必要な状況では、リソース全体を置換または要求することは望ましくありません。 CoAPを使用するいくつかのアプリケーションは、リソースの一部にアクセスする必要があります。
This specification defines the new CoAP methods, FETCH, PATCH, and iPATCH, which are used to access and update parts of a resource.
この仕様は、新しいCoAPメソッドであるFETCH、PATCH、およびiPATCHを定義します。これらは、リソースの一部にアクセスして更新するために使用されます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8132.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8132で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. FETCH . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. PATCH and iPATCH . . . . . . . . . . . . . . . . . . . . 4
1.3. Requirements Language . . . . . . . . . . . . . . . . . . 5
1.4. Terminology and Acronyms . . . . . . . . . . . . . . . . 5
2. FETCH Method . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Response Codes . . . . . . . . . . . . . . . . . . . . . 6
2.2. Error Handling . . . . . . . . . . . . . . . . . . . . . 6
2.3. Option Numbers . . . . . . . . . . . . . . . . . . . . . 7
2.3.1. The Content-Format Option . . . . . . . . . . . . . . 7
2.3.2. The ETag Option . . . . . . . . . . . . . . . . . . . 8
2.4. Working with Observe . . . . . . . . . . . . . . . . . . 8
2.5. Working with Block . . . . . . . . . . . . . . . . . . . 8
2.6. Building FETCH Requests . . . . . . . . . . . . . . . . . 8
2.7. A Simple Example for FETCH . . . . . . . . . . . . . . . 8
3. PATCH and iPATCH Methods . . . . . . . . . . . . . . . . . . 9
3.1. Simple Examples for PATCH and iPATCH . . . . . . . . . . 12
3.2. Response Codes . . . . . . . . . . . . . . . . . . . . . 14
3.3. Option Numbers . . . . . . . . . . . . . . . . . . . . . 14
3.4. Error Handling . . . . . . . . . . . . . . . . . . . . . 15
4. The New Set of CoAP Methods . . . . . . . . . . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1. Normative References . . . . . . . . . . . . . . . . . . 19
7.2. Informative References . . . . . . . . . . . . . . . . . 19
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
Similar to HTTP, the GET method defined in [RFC7252] for the Constrained Application Protocol (CoAP) only allows the specification of a URI and request parameters in CoAP options, not the transfer of a request payload detailing the request. This leads some applications to use POST where a cacheable, idempotent, safe request is actually desired.
HTTPと同様に、[RFC7252]で定義されているConstrained Application Protocol（CoAP）のGETメソッドは、CoAPオプションでのURIと要求パラメーターの指定のみを許可し、要求の詳細を示す要求ペイロードの転送は許可しません。これにより、一部のアプリケーションは、キャッシュ可能でべき等で安全な要求が実際に必要な場合にPOSTを使用するようになります。
Again, similar to the original specification of HTTP, the PUT method defined in [RFC7252] only allows a complete resource to be replaced. This also leads applications to use POST where a cacheable, possibly idempotent request is actually desired.
この場合も、元のHTTPの仕様と同様に、[RFC7252]で定義されているPUTメソッドでは、完全なリソースのみを置き換えることができます。これにより、アプリケーションは、キャッシュ可能な、場合によってはべき等の要求が実際に必要な場合にPOSTを使用するようになります。
The present specification adds new CoAP methods: FETCH, to perform the equivalent of a GET with a request body; and the twin methods, PATCH and iPATCH, to modify parts of a CoAP resource.
現在の仕様では、新しいCoAPメソッドであるFETCHが追加され、GETと同等のリクエストボディが実行されます。 CoAPリソースの一部を変更するための2つの方法、PATCHとiPATCH。
The CoAP GET method [RFC7252] is used to obtain the representation of a resource, where the resource is specified by a URI and additional request parameters can also shape the representation. This has been modeled after the HTTP GET operation and the REST model in general.
CoAP GETメソッド[RFC7252]は、リソースの表現を取得するために使用されます。リソースはURIで指定され、追加のリクエストパラメータも表現を形成できます。これは、HTTP GET操作とRESTモデル一般をモデルにしています。
In HTTP, a resource is often used to search for information, and existing systems varyingly use the HTTP GET and POST methods to perform a search. Often, a POST method is used solely so that a larger set of parameters to the search can be supplied in the request body than can comfortably be transferred in the URI with a GET request. [HTTP-SEARCH] proposes a SEARCH method that is similar to GET in most properties but enables sending a request body, as is done with POST. The FETCH method defined in the present specification is inspired by [HTTP-SEARCH], which updates the definition and semantics of the HTTP SEARCH request method previously defined by [RFC5323]. However, there is no intention to limit FETCH to search-type operations, and the resulting properties may not be the same as those of HTTP SEARCH.
HTTPでは、多くの場合、リソースは情報の検索に使用され、既存のシステムはさまざまな方法でHTTP GETおよびPOSTメソッドを使用して検索を実行します。多くの場合、POSTメソッドは単独で使用されるため、GETリクエストを使用してURIで転送するよりも、検索へのより多くのパラメーターセットをリクエストの本文で提供できます。 [HTTP-SEARCH]は、ほとんどのプロパティでGETと同様のSEARCHメソッドを提案しますが、POSTの場合と同様に、リクエスト本文を送信できます。本明細書で定義されているFETCHメソッドは、[RFC5323]で以前に定義されたHTTP SEARCHリクエストメソッドの定義とセマンティクスを更新する[HTTP-SEARCH]に触発されています。ただし、FETCHを検索タイプの操作に限定する意図はなく、結果のプロパティはHTTP SEARCHのプロパティと同じではない場合があります。
A major problem with GET is that the information that controls the request needs to be bundled up in some unspecified way into the URI. Using the request body for this information has a number of advantages:
GETの主な問題は、リクエストを制御する情報を、不特定の方法でURIにバンドルする必要があることです。この情報にリクエスト本文を使用すると、いくつかの利点があります。
o The client can specify a media type (and a content coding) that enables the server to unambiguously interpret the request parameters in the context of that media type. Also, the request body is not limited by the character set limitations of URIs, which enables a more natural (and more efficient) representation of certain domain-specific parameters.
o クライアントは、サーバーがそのメディアタイプのコンテキストで要求パラメーターを明確に解釈できるようにするメディアタイプ（およびコンテンツコーディング）を指定できます。また、リクエストの本文はURIの文字セット制限によって制限されないため、特定のドメイン固有のパラメータをより自然に（かつより効率的に）表現できます。
o The request parameters are not limited by the maximum size of the URI. In HTTP, that is a problem, as the practical limit for this size varies. In CoAP, another problem is that the block-wise transfer is not available for transferring large URI options in multiple rounds.
o 要求パラメーターは、URIの最大サイズによって制限されません。 HTTPでは、このサイズの実際の制限が異なるため、これは問題です。 CoAPでは、別の問題として、ブロック単位の転送が複数のラウンドで大きなURIオプションを転送するために利用できないということがあります。
As an alternative to using GET, many implementations make use of the POST method to perform extended requests (even if they are semantically idempotent, safe, and even cacheable) to be able to pass along the input parameters within the request payload as opposed to using the request URI.
GETを使用する代わりに、多くの実装では、POSTメソッドを使用して（意味的にべき等で安全で、キャッシュ可能であっても）拡張リクエストを実行して、使用するのではなく、リクエストペイロード内の入力パラメーターを渡すことができます。リクエストURI。
The FETCH method provides a solution that spans the gap between the use of GET and POST. As with POST, the input to the FETCH operation is passed along within the payload of the request rather than as part of the request URI. Unlike POST, however, the semantics of the FETCH method are more specifically defined.
FETCHメソッドは、GETとPOSTの使用の間のギャップにまたがるソリューションを提供します。 POSTと同様に、FETCH操作への入力は、要求URIの一部としてではなく、要求のペイロード内で渡されます。ただし、POSTとは異なり、FETCHメソッドのセマンティクスはより具体的に定義されています。
PATCH is also specified for HTTP in [RFC5789]. Most of the motivation for PATCH described in [RFC5789] also applies here. iPATCH is the idempotent version of PATCH.
[RFC5789]では、PATCHもHTTPに対して指定されています。 [RFC5789]で説明されているPATCHの動機のほとんどは、ここでも当てはまります。 iPATCHは、PATCHのべき等バージョンです。
The PUT method exists to overwrite a resource with completely new contents and cannot be used to perform partial changes. When using PUT for partial changes, proxies and caches, and even clients and servers, may get confused as to the result of the operation. PATCH was not adopted in an early design stage of CoAP; however, it has become necessary with the arrival of applications that require partial updates to resources (e.g., [COAP-MGMNT]). Using PATCH avoids transferring all data associated with a resource in case of modifications, thereby not burdening the constrained communication medium.
PUTメソッドは、完全に新しいコンテンツでリソースを上書きするために存在し、部分的な変更の実行には使用できません。部分的な変更にPUTを使用すると、プロキシとキャッシュ、さらにはクライアントとサーバーでさえ、操作の結果に関して混乱する可能性があります。 PAPCHはCoAPの初期設計段階では採用されませんでした。ただし、リソースの部分的な更新を必要とするアプリケーション（[COAP-MGMNT]など）の登場により、その必要性が高まっています。 PATCHを使用すると、変更があった場合にリソースに関連付けられているすべてのデータが転送されるのを回避できるため、制約のある通信媒体に負担がかかりません。
This document relies on knowledge of the PATCH specification for HTTP [RFC5789]. This document provides extracts from [RFC5789] to make independent reading possible.
このドキュメントは、HTTP [RFC5789]のPATCH仕様の知識に依存しています。このドキュメントは、[RFC5789]からの抜粋を提供して、独立した読み取りを可能にします。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこの文書の "は、[RFC2119]で説明されているように解釈されます。
This document uses terminology defined in [RFC5789] and [RFC7252].
このドキュメントでは、[RFC5789]と[RFC7252]で定義されている用語を使用しています。
Specifically, it uses the terms "safe" and "idempotent" as defined in Section 5.1 of [RFC7252]. (Further discussion of safe and idempotent methods can now be found in Sections 4.2.1 and 4.2.2 of [RFC7231], respectively; the implications of idempotence of methods on server implementations are also discussed in Section 4.5 of [RFC7252].)
具体的には、[RFC7252]のセクション5.1で定義されている「安全」および「べき等」という用語を使用します。 （安全なメソッドとべき等メソッドの詳細については、[RFC7231]のセクション4.2.1と4.2.2にそれぞれ記載されています。サーバー実装におけるメソッドのべき等性の影響については、[RFC7252]のセクション4.5でも説明しています。）
The CoAP FETCH method is used to obtain a representation of a resource, specified by a number of request parameters. Unlike the CoAP GET method, which requests that a server return a representation of the resource identified by the effective request URI (as defined by [RFC7252]), the FETCH method is used by a client to ask the server to produce a representation as described by the request parameters (including the request options and the payload) based on the resource specified by the effective request URI. The payload returned in response to a FETCH cannot be assumed to be a complete representation of the resource identified by the effective request URI, i.e., it cannot be used by a cache as a payload to be returned by a GET request.
CoAP FETCHメソッドは、いくつかの要求パラメーターで指定されたリソースの表現を取得するために使用されます。サーバーが有効なリクエストURI（[RFC7252]で定義されている）で識別されるリソースの表現を返すように要求するCoAP GETメソッドとは異なり、FETCHメソッドはクライアントによって使用され、説明のとおり表現を生成するようサーバーに要求します。有効なリクエストURIで指定されたリソースに基づくリクエストパラメータ（リクエストオプションとペイロードを含む）。 FETCHへの応答として返されるペイロードは、有効な要求URIによって識別されるリソースの完全な表現であるとは想定できません。つまり、GET要求によって返されるペイロードとしてキャッシュで使用することはできません。
Together with the request options, the body of the request (which may be constructed from multiple payloads using the block protocol [RFC7959]) defines the request parameters. With the FETCH method, implementations may submit a request body of any media type that is defined with the semantics of selecting information from a resource in such a FETCH request; it is outside the scope of this document how information about media types admissible for the specific resource is obtained by the client (although we can hint that form relations [CORE-APP] might be a preferred way). It is RECOMMENDED that any discovery method that allows a client to find out that the server supports FETCH also provides information regarding what FETCH payload media types are applicable.
リクエストオプションとともに、リクエストの本文（ブロックプロトコル[RFC7959]を使用して複数のペイロードから構築される場合があります）はリクエストパラメータを定義します。 FETCHメソッドを使用すると、実装は、そのようなFETCH要求内のリソースから情報を選択するセマンティクスで定義された任意のメディアタイプの要求本文を送信できます。特定のリソースに許可されるメディアタイプに関する情報がクライアントによってどのように取得されるかは、このドキュメントの範囲外です（ただし、フォームの関係[CORE-APP]が推奨される方法である可能性があることを示唆できます）。クライアントがサーバーがFETCHをサポートしていることを確認できるようにするすべての検出方法でも、適用可能なFETCHペイロードメディアタイプに関する情報を提供することをお勧めします。
FETCH requests are both safe and idempotent with regards to the resource identified by the request URI. That is, the performance of a FETCH is not intended to alter the state of the targeted resource. (However, while processing a FETCH request, a server can be expected to allocate computing and memory resources or even create additional server resources through which the response to the search can be retrieved.)
FETCHリクエストは、リクエストURIで識別されるリソースに関して安全かつべき等です。つまり、FETCHのパフォーマンスは、対象となるリソースの状態を変更することを目的としていません。 （ただし、FETCH要求を処理している間、サーバーはコンピューティングリソースとメモリリソースを割り当てるか、検索に対する応答を取得できる追加のサーバーリソースを作成することさえ期待できます。）
A successful response to a FETCH request is expected to provide some indication as to the final disposition of the requested operation. If a successful response includes a body payload, the payload is expected to describe the results of the FETCH operation.
FETCH要求に対する応答が成功すると、要求された操作の最終的な処理に関する何らかの指示が提供されることが期待されます。成功した応答に本文のペイロードが含まれている場合、ペイロードにはFETCH操作の結果が記述されていることが期待されます。
Depending on the response code as defined by [RFC7252], the response to a FETCH request is cacheable; the request body is part of the cache key. Specifically, 2.05 (Content) response codes (the responses for which are cacheable) are a typical way to respond to a FETCH request. (Note that this aspect differs markedly from [HTTP-SEARCH] and also that caches that cannot use the request payload as part of the cache key will not be able to cache responses to FETCH requests at all.) The Max-Age option in the response has equivalent semantics to its use in a GET.
[RFC7252]で定義されている応答コードに応じて、FETCH要求への応答はキャッシュ可能です。リクエストボディはキャッシュキーの一部です。具体的には、2.05（コンテンツ）応答コード（キャッシュ可能な応答）は、FETCH要求に応答する一般的な方法です。 （この側面は[HTTP-SEARCH]とは著しく異なります。また、リクエストペイロードをキャッシュキーの一部として使用できないキャッシュは、FETCHリクエストへの応答をまったくキャッシュできません。）Max-Ageオプション応答には、GETでの使用と同等のセマンティクスがあります。
The semantics of the FETCH method change to a "conditional FETCH" if the request message includes an If-Match or If-None-Match option [RFC7252]. A conditional FETCH requests that the query be performed only under the circumstances described by the conditional option(s). It is important to note, however, that such conditions are evaluated against the state of the target resource itself as opposed to the results of the FETCH operation.
要求メッセージにIf-MatchまたはIf-None-Matchオプションが含まれている場合、FETCHメソッドのセマンティクスは「条件付きFETCH」に変わります[RFC7252]。条件付きFETCHは、条件付きオプションで記述された状況でのみクエリを実行するように要求します。ただし、このような条件は、FETCH操作の結果ではなく、ターゲットリソース自体の状態に対して評価されることに注意してください。
FETCH for CoAP adopts the response codes as specified in Sections 5.9 and 12.1.2 of [RFC7252] as well as the additional response codes mentioned in Section 2.2.
CoAPのFETCHは、[RFC7252]のセクション5.9および12.1.2で指定されている応答コード、およびセクション2.2で言及されている追加の応答コードを採用しています。
A FETCH request may fail under certain known conditions. Beyond the conditions already defined in [RFC7252] for GET, noteworthy ones are:
既知の特定の条件下では、FETCH要求が失敗する場合があります。 [RFC7252]でGETに対してすでに定義されている条件を超えて、注目すべき条件は次のとおりです。
Malformed FETCH payload: If a server determines that the payload provided with a FETCH request is not properly formatted, it can return a 4.00 (Bad Request) CoAP error. The definition of a malformed payload depends upon the CoAP Content-Format specified with the request.
不正なFETCHペイロード：FETCHリクエストで提供されたペイロードが適切にフォーマットされていないとサーバーが判断した場合、4.00（Bad Request）CoAPエラーを返すことがあります。不正なペイロードの定義は、リクエストで指定されたCoAP Content-Formatによって異なります。
Unsupported FETCH payload: In case a client sends a payload that is inappropriate for the resource identified by the Request-URI, the server can return a 4.15 (Unsupported Content-Format) CoAP error. The server can determine if the payload is supported by checking the CoAP Content-Format specified with the request.
サポートされていないFETCHペイロード：クライアントがRequest-URIで識別されるリソースに不適切なペイロードを送信した場合、サーバーは4.15（サポートされていないContent-Format）CoAPエラーを返すことがあります。サーバーは、リクエストで指定されたCoAP Content-Formatをチェックすることにより、ペイロードがサポートされているかどうかを判断できます。
Unprocessable request: This situation occurs when the payload of a FETCH request is determined to be valid (i.e., well-formed and supported) but the server is unable to or is incapable of processing the request. The server can return a 4.22 (Unprocessable Entity) CoAP error. In situations when the server has insufficient computing resources to complete the request successfully, it can return a 4.13 (Request Entity Too Large) CoAP error (see also below). If there are more specific errors that provide additional insight into the problem, then those should be used.
処理不能な要求：この状況は、FETCH要求のペイロードが有効である（つまり、整形式でサポートされている）と判断されたが、サーバーが要求を処理できない、または処理できない場合に発生します。サーバーは4.22（Unprocessable Entity）CoAPエラーを返すことがあります。サーバーのコンピューティングリソースが不十分でリクエストを正常に完了できない状況では、4.13（リクエストエンティティが大きすぎる）CoAPエラーを返すことがあります（以下も参照）。問題に対する追加の洞察を提供するより具体的なエラーがある場合は、それらを使用する必要があります。
Request too large: If the payload of the FETCH request is larger than a CoAP server can process, then it can return the 4.13 (Request Entity Too Large) CoAP error.
リクエストが大きすぎる：FETCHリクエストのペイロードがCoAPサーバーが処理できるサイズより大きい場合、4.13（Request Entity Too Large）CoAPエラーが返されることがあります。
It is possible that other error situations not mentioned here are encountered by a CoAP server while processing the FETCH request. In these situations, other appropriate CoAP response codes can also be returned.
ここに記載されていない他のエラー状況が、FETCH要求の処理中にCoAPサーバーで発生する可能性があります。これらの状況では、他の適切なCoAP応答コードも返される可能性があります。
FETCH for CoAP adopts the option numbers as specified in Sections 5.10 and 12.2 of [RFC7252].
CoAPのFETCHは、[RFC7252]のセクション5.10および12.2で指定されているオプション番号を採用します。
Generally, options defined for GET act in an analogous way for FETCH. Two specific cases are called out in the rest of this section.
一般に、GETに定義されたオプションは、FETCHと同様に機能します。このセクションの残りの部分では、2つの特定のケースが呼び出されます。
A FETCH request MUST include a Content-Format option (see Section 5.10.3 of [RFC7252]) to specify the media type and content coding of the request body. (Typically, the media type will have been specifically designed to specify details for a selection or a search on a resource.)
FETCHリクエストには、リクエスト本文のメディアタイプとコンテンツコーディングを指定するContent-Formatオプション（[RFC7252]のセクション5.10.3を参照）を含める必要があります。 （通常、メディアタイプは、リソースの選択または検索の詳細を指定するように特別に設計されています。）
The ETag option on a FETCH result has the same semantics as defined in Section 5.10.6 of [RFC7252]. In particular, its use as a response option describes the "tagged representation", which for FETCH is the same as the "selected representation". The FETCH payload is input to that selection process and therefore needs to be part of the cache key. Similarly, the use of ETag as a request option can elicit a 2.03 (Valid) response if the representation associated with the ETag would still be selected by the FETCH request (including its payload).
FETCH結果のETagオプションは、[RFC7252]のセクション5.10.6で定義されているものと同じセマンティクスを持っています。特に、応答オプションとしてのその使用は、「タグ付き表現」を説明します。これは、FETCHの場合、「選択された表現」と同じです。 FETCHペイロードはその選択プロセスに入力されるため、キャッシュキーの一部である必要があります。同様に、ETagを要求オプションとして使用すると、FETCH要求（ペイロードを含む）によってETagに関連付けられた表現が引き続き選択される場合、2.03（有効）応答を引き出すことができます。
The Observe option [RFC7641] can be used with a FETCH request as it can be used with a GET request.
Observeオプション[RFC7641]は、GETリクエストで使用できるため、FETCHリクエストでも使用できます。
The Block1 option [RFC7959] can be used with a FETCH request as it would be used with a POST request; the Block2 option can then be used as it would with GET or POST.
Block1オプション[RFC7959]は、POSTリクエストで使用されるのと同じように、FETCHリクエストでも使用できます。その後、Block2オプションは、GETまたはPOSTの場合と同様に使用できます。
One property of FETCH that may be non-obvious is that a FETCH request cannot be generated from a link alone; the client also needs a way to generate the request payload. Again, form relations [CORE-APP] may be able to fill parts of this gap.
自明ではない可能性のあるFETCHの1つの特性は、FETCH要求をリンクのみから生成できないことです。クライアントには、要求ペイロードを生成する方法も必要です。繰り返しになりますが、フォームの関係[CORE-APP]は、このギャップの一部を埋めることができる場合があります。
The FETCH method needs a media type for its payload (as expressed by the Content-Format request option) that specifies the search query in similar detail as is shown for the PATCH payload in the PATCH example in Section 3.1. ([HTTP-SEARCH] invents a "text/query" format based on some hypothetical SQL dialect for its examples.)
FETCHメソッドには、ペイロードのメディアタイプが必要です（Content-Formatリクエストオプションで表される）。これは、セクション3.1のPATCHの例のPATCHペイロードに示されているのと同様の詳細で検索クエリを指定します。 （[HTTP-SEARCH]は、その例として架空のSQL方言に基づく「テキスト/クエリ」フォーマットを発明します。）
The example below illustrates retrieval of a subset of a JSON [RFC7159] object (the same object as used in Section 3.1). Using a hypothetical media type "application/example-map-keys+json" (with a Content-Format ID of NNN, which is not defined as this is just an example), the client specifies the items in the object that it wants: it supplies a JSON array that gives the map keys for these items. A resource located at <coap://www.example.com/object> can be represented by a JSON document that we will consider as the target of the FETCH. The client wants to learn the contents of the single map key "foo" within this target:
以下の例は、JSON [RFC7159]オブジェクト（セクション3.1で使用したものと同じオブジェクト）のサブセットの取得を示しています。架空のメディアタイプ「application / example-map-keys + json」（これは単なる例であるため定義されていないNNNのコンテンツ形式IDを使用）を使用して、クライアントは必要なオブジェクト内のアイテムを指定します。これらの項目のマップキーを提供するJSON配列を提供します。 <coap：//www.example.com/object>にあるリソースは、FETCHのターゲットと見なすJSONドキュメントで表すことができます。クライアントは、このターゲット内の単一のマップキー「foo」の内容を学習したいと考えています。
{
"x-coord": 256,
"y-coord": 45,
"foo": ["bar","baz"]
}
FETCH Example: JSON Document Returned by GET
FETCHの例：GETによって返されるJSONドキュメント
The example FETCH request specifies a single top-level member desired by giving its map key as the sole element of the "example-map-keys" payload:
FETCHリクエストの例では、「example-map-keys」ペイロードの唯一の要素としてマップキーを指定することで、必要な単一のトップレベルメンバーを指定しています。
FETCH CoAP://www.example.com/object
Content-Format: NNN (application/example-map-keys+json)
Accept: application/json
[
"foo"
]
FETCH Example: Request
FETCHの例：リクエスト
The server returns a subset document with just the selected member:
サーバーは、選択されたメンバーのみを含むサブセットドキュメントを返します。
2.05 Content
Content-Format: 50 (application/json)
{
"foo": ["bar","baz"]
}
FETCH Example: Response with Subset JSON Document
FETCHの例：サブセットJSONドキュメントを含む応答
By the logic of this example, the requester could have entered more than one map key into the request payload array and would have received a more complete subset of the top-level JSON object that is representing the resource.
この例のロジックにより、リクエスターは複数のマップキーをリクエストペイロードアレイに入力でき、リソースを表す最上位のJSONオブジェクトのより完全なサブセットを受信できます。
The PATCH and iPATCH methods request that a set of changes described in the request payload be applied to the target resource of the request. The set of changes is represented in a format identified by a media type. If the Request-URI does not point to an existing resource, the server MAY create a new resource with that URI, depending on the PATCH document type (whether it can logically modify a null resource) and permissions, as well as other conditions such as the degree of control the server gives clients in creating new entries in its URI space (see also Section 3.4). Creation of a new resource would result in a 2.01 (Created) response code dependent on the PATCH document type.
PATCHおよびiPATCHメソッドは、リクエストペイロードに記述されている一連の変更がリクエストのターゲットリソースに適用されることをリクエストします。変更のセットは、メディアタイプによって識別される形式で表されます。 Request-URIが既存のリソースを指していない場合、サーバーは、PATCHドキュメントタイプ（nullリソースを論理的に変更できるかどうか）と権限、およびその他の条件に応じて、そのURIで新しいリソースを作成できます（MAY）。サーバーがそのURIスペースに新しいエントリを作成する際にサーバーに与える制御の程度（セクション3.4も参照）。新しいリソースを作成すると、PATCHドキュメントタイプに応じて2.01（Created）応答コードが生成されます。
Restrictions to a PATCH or iPATCH request can be made by including the If-Match or If-None-Match options in the request (see Sections 5.10.8.1 and 5.10.8.2 of [RFC7252]). If the resource could not be created or modified, then an appropriate error response code SHOULD be sent.
PATCHまたはiPATCHリクエストに対する制限は、リクエストにIf-MatchまたはIf-None-Matchオプションを含めることで行うことができます（[RFC7252]のセクション5.10.8.1および5.10.8.2を参照）。リソースを作成または変更できなかった場合は、適切なエラー応答コードを送信する必要があります（SHOULD）。
The difference between the PUT and PATCH requests is documented in [RFC5789]. When a request is intended to effect a partial update of a given resource, clients cannot use PUT while supplying just the update, but they might be able to use PATCH or iPATCH.
PUTとPATCHリクエストの違いは[RFC5789]に文書化されています。リクエストが特定のリソースの部分的な更新を行うことを目的としている場合、クライアントは更新のみを提供している間はPUTを使用できませんが、PATCHまたはiPATCHを使用できる場合があります。
The PATCH method is "not safe" and "not idempotent", as is the HTTP PATCH method specified in [RFC5789].
[RFC5789]で指定されているHTTP PATCHメソッドと同様に、PATCHメソッドは「安全ではなく」「べき等ではありません」。
The iPATCH method is not safe but idempotent, as with the CoAP PUT method specified in Section 5.8.3 of [RFC7252].
[RFC7252]のセクション5.8.3で指定されているCoAP PUTメソッドと同様に、iPATCHメソッドは安全ではありませんがべき等です。
A client can mark a request as idempotent by using the iPATCH method instead of the PATCH method. This is the only difference between the two. The indication of idempotence may enable the server to keep less state about the interaction; some constrained servers may only implement the iPATCH variant for this reason.
クライアントは、PATCHメソッドの代わりにiPATCHメソッドを使用して、要求をべき等としてマークできます。これが2つの唯一の違いです。べき等の指標により、サーバーはインタラクションについての状態を維持できなくなります。このため、一部の制約付きサーバーはiPATCHバリアントのみを実装する場合があります。
PATCH and iPATCH are both atomic. The server MUST apply the entire set of changes atomically and never provide a partially modified representation to a concurrently executed GET request. Given the constrained nature of the servers, most servers will only execute CoAP requests consecutively, thus preventing a concurrent partial overlapping of request modifications. In other words, modifications MUST NOT be applied to the server state when an error occurs or when only a partial execution is possible on the resources present in the server.
PATCHとiPATCHはどちらもアトミックです。サーバーは変更のセット全体をアトミックに適用しなければならず、同時に実行されたGETリクエストに部分的に変更された表現を提供してはなりません。サーバーの制約された性質を考えると、ほとんどのサーバーはCoAP要求を連続して実行するだけなので、要求の変更が同時に部分的にオーバーラップするのを防ぎます。言い換えると、エラーが発生したとき、またはサーバーに存在するリソースで部分的な実行しかできないときに、変更をサーバーの状態に適用してはなりません（MUST NOT）。
The atomicity applies to a single server. When a PATCH or iPATCH request is multicast to a set of servers, each server can either execute all required modifications or not. It is not required that all servers execute all modifications or none. An Atomic Commit protocol that provides multiple server atomicity is out of scope.
原子性は単一のサーバーに適用されます。 PATCH要求またはiPATCH要求がサーバーのセットにマルチキャストされる場合、各サーバーは必要なすべての変更を実行することも、しないこともできます。すべてのサーバーがすべての変更を実行するか、まったく実行する必要はありません。複数のサーバーの原子性を提供するAtomic Commitプロトコルは範囲外です。
A PATCH or iPATCH response can invalidate a cache in a similar manner to the PUT response. For the successful (2.xx) response codes, PATCH or iPATCH have the following caching behavior:
PATCHまたはiPATCH応答は、PUT応答と同様の方法でキャッシュを無効にすることができます。成功した（2.xx）応答コードの場合、PATCHまたはiPATCHには次のキャッシュ動作があります。
o A 2.01 (Created) response invalidates any cache entry for the resource indicated by the Location-* options; the payload is a representation of the action result.
o 2.01（Created）応答は、Location- *オプションで示されたリソースのキャッシュエントリを無効にします。ペイロードはアクション結果の表現です。
o A 2.04 (Changed) response invalidates any cache entry for the target resource; the payload is a representation of the action result.
o 2.04（変更）応答は、ターゲットリソースのキャッシュエントリを無効にします。ペイロードはアクション結果の表現です。
There is no guarantee that a resource can be modified with PATCH or iPATCH. Servers MUST ensure that a received PATCH body is appropriate for the type of resource identified by the target resource of the request.
リソースがPATCHまたはiPATCHで変更できるという保証はありません。サーバーは、受信したPATCHボディが、リクエストのターゲットリソースによって識別されるリソースのタイプに適していることを確認する必要があります。
It is RECOMMENDED that any discovery method that allows a client to find out that the server supports one of PATCH and iPATCH also provide information regarding what PATCH payload media types are applicable and which of the two methods are implemented by the server for each of these media types.
サーバーがPATCHおよびiPATCHのいずれかをサポートしていることをクライアントが確認できるようにするすべての検出方法は、適用可能なPATCHペイロードメディアタイプと、これらの各メディアに対してサーバーが実装する2つの方法のどちらに関する情報も提供することをお勧めします。タイプ。
Servers that do not rely on the idempotence of iPATCH can easily support both PATCH and iPATCH, and it is RECOMMENDED they do so. This is inexpensive to do, as, for iPATCH, there is no requirement on the server to check that the client's intention that the request be idempotent is fulfilled (although there is diagnostic value in that check, so a less-constrained implementation may want to perform it).
iPATCHのべき等に依存しないサーバーは、PATCHとiPATCHの両方を簡単にサポートできます。そうすることをお勧めします。これは安価に実行できます。iPATCHでは、要求がべき等であるというクライアントの意図が満たされていることをサーバーがチェックする必要がないためです（そのチェックには診断値があるため、制約の少ない実装では、それを実行します）。
The example is taken over from [RFC6902], which specifies a JSON notation for PATCH operations. A resource located at <coap://www.example.com/object> contains a target JSON document.
この例は、PATCH操作のJSON表記を指定する[RFC6902]から引き継がれています。 <coap：//www.example.com/object>にあるリソースには、ターゲットJSONドキュメントが含まれています。
JSON document original state:
{
"x-coord": 256,
"y-coord": 45,
"foo": ["bar","baz"]
}
REQ: iPATCH CoAP://www.example.com/object
Content-Format: 51 (application/json-patch+json)
[
{ "op":"replace", "path":"x-coord", "value":45}
]
RET: CoAP 2.04 Changed
RET：CoAP 2.04が変更されました
JSON document final state:
{
"x-coord": 45,
"y-coord": 45,
"foo": ["bar","baz"]
}
This example illustrates use of an idempotent modification to the x-coord member of the existing resource "object". The 2.04 (Changed) response code conforms with the CoAP PUT method.
この例は、既存のリソース「オブジェクト」のx-coordメンバーに対するべき等の変更の使用を示しています。 2.04（変更）応答コードは、CoAP PUTメソッドに準拠しています。
The same example using the Content-Format application/merge-patch+json from [RFC7396] looks like the following:
[RFC7396]のContent-Format application / merge-patch + jsonを使用した同じ例は、次のようになります。
JSON document original state:
{
"x-coord": 256,
"y-coord": 45,
"foo": ["bar","baz"]
}
REQ: iPATCH CoAP://www.example.com/object
Content-Format: 52 (application/merge-patch+json)
{ "x-coord":45}
RET: CoAP 2.04 Changed
RET：CoAP 2.04が変更されました
JSON document final state:
{
"x-coord": 45,
"y-coord": 45,
"foo": ["bar","baz"]
}
The examples show the use of the iPATCH method, but the use of the PATCH method would have led to the same result. Below, a non-idempotent modification is shown. Because the action is non-idempotent, iPATCH returns an error, while PATCH executes the action.
例ではiPATCHメソッドの使用を示していますが、PATCHメソッドを使用しても同じ結果になります。以下に、べき等でない変更を示します。アクションはべき等ではないため、iPATCHはエラーを返し、PATCHはアクションを実行します。
JSON document original state:
{
"x-coord": 256,
"y-coord": 45,
"foo": ["bar","baz"]
}
REQ: iPATCH CoAP://www.example.com/object
Content-Format: 51 (application/json-patch+json)
[
{ "op":"add","path":"foo/1","value":"bar"}
]
RET: CoAP 4.00 Bad Request
Diagnostic payload: Patch format not idempotent
JSON document final state is unchanged
JSONドキュメントの最終状態は変更されていません
REQ: PATCH CoAP://www.example.com/object
Content-Format: 51 (application/json-patch+json)
[
{ "op":"add","path":"foo/1","value":"bar"}
]
RET: CoAP 2.04 Changed
JSON document final state:
{
"x-coord": 45,
"y-coord": 45,
"foo": ["bar","bar","baz"]
}
PATCH and iPATCH for CoAP adopt the response codes as specified in Sections 5.9 and 12.1.2 of [RFC7252] and add 4.09 (Conflict) and 4.22 (Unprocessable Entity) with the semantics specified in Section 3.4 of the present specification.
CoAPのPATCHおよびiPATCHは、[RFC7252]のセクション5.9および12.1.2で指定された応答コードを採用し、本仕様のセクション3.4で指定されたセマンティクスで4.09（競合）および4.22（処理不能エンティティ）を追加します。
PATCH and iPATCH for CoAP adopt the option numbers as specified in Sections 5.10 and 12.2 of [RFC7252].
CoAPのPATCHおよびiPATCHは、[RFC7252]のセクション5.10および12.2で指定されているオプション番号を採用します。
A PATCH or iPATCH request may fail under certain known conditions. These situations should be dealt with as expressed below.
特定の既知の条件下では、PATCHまたはiPATCHリクエストが失敗する場合があります。これらの状況は、次のように対処する必要があります。
Malformed PATCH or iPATCH payload: If a server determines that the payload provided with a PATCH or iPATCH request is not properly formatted, it can return a 4.00 (Bad Request) CoAP error. The definition of a malformed payload depends upon the CoAP Content-Format specified with the request.
不正なPATCHまたはiPATCHペイロード：PATCHまたはiPATCHリクエストで提供されたペイロードが適切にフォーマットされていないとサーバーが判断した場合、4.00（Bad Request）CoAPエラーが返されることがあります。不正なペイロードの定義は、リクエストで指定されたCoAP Content-Formatによって異なります。
Unsupported PATCH or iPATCH payload: In case a client sends a payload that is inappropriate for the resource identified by the Request-URI, the server can return a 4.15 (Unsupported Content-Format) CoAP error. The server can determine if the payload is supported by checking the CoAP Content-Format specified with the request.
サポートされていないPATCHまたはiPATCHペイロード：クライアントがRequest-URIで識別されたリソースに不適切なペイロードを送信した場合、サーバーは4.15（サポートされていないContent-Format）CoAPエラーを返すことがあります。サーバーは、リクエストで指定されたCoAP Content-Formatをチェックすることにより、ペイロードがサポートされているかどうかを判断できます。
Unprocessable request: This situation occurs when the payload of a PATCH request is determined to be valid (i.e., well-formed and supported) but the server is unable to or is incapable of processing the request. The server can return a 4.22 (Unprocessable Entity) CoAP error. More specific scenarios might include situations such as:
処理できないリクエスト：この状況は、PATCHリクエストのペイロードが有効である（つまり、整形式でサポートされている）と判断されたが、サーバーがリクエストを処理できない、または処理できない場合に発生します。サーバーは4.22（Unprocessable Entity）CoAPエラーを返すことがあります。より具体的なシナリオには、次のような状況が含まれる場合があります。
* the server has insufficient computing resources to complete the request successfully -- 4.13 (Request Entity Too Large) CoAP response code (see below); or
* サーバーに十分なコンピューティングリソースがないため、リクエストを正常に完了できません。4.13（リクエストエンティティが大きすぎます）CoAP応答コード（下記参照）。または
* the resource specified in the request becomes invalid by applying the payload -- 4.09 (Conflict) CoAP response code (see "Conflicting state" below)).
* ペイロードを適用することにより、リクエストで指定されたリソースが無効になります-4.09（競合）CoAP応答コード（以下の「競合状態」を参照）。
In case there are more specific errors that provide additional insight into the problem, then those should be used.
問題に対する追加の洞察を提供するより具体的なエラーがある場合は、それらを使用する必要があります。
Resource not found: The 4.04 (Not Found) error should be returned if the payload of a PATCH request cannot be applied to a non-existent resource.
リソースが見つからない：PATCHリクエストのペイロードを存在しないリソースに適用できない場合、4.04（Not Found）エラーが返されます。
Failed precondition: In case the client uses the conditional If-Match or If-None-Match option to define a precondition for the PATCH request, and that precondition fails, then the server can return the 4.12 (Precondition Failed) CoAP error.
失敗した前提条件：クライアントが条件付きのIf-MatchオプションまたはIf-None-Matchオプションを使用してPATCHリクエストの前提条件を定義し、その前提条件が失敗した場合、サーバーは4.12（Precondition Failed）CoAPエラーを返すことがあります。
Request too large: If the payload of the PATCH request is larger than a CoAP server can process, then it can return the 4.13 (Request Entity Too Large) CoAP error.
リクエストが大きすぎる：PATCHリクエストのペイロードがCoAPサーバーが処理できるサイズより大きい場合、4.13（Request Entity Too Large）CoAPエラーが返されることがあります。
Conflicting state: If the modification specified by a PATCH or iPATCH request causes the resource to enter an inconsistent state that the server cannot resolve, the server can return the 4.09 (Conflict) CoAP response. The server SHOULD generate a payload that includes enough information for a user to recognize the source of the conflict. The server MAY return the actual resource state to provide the client with the means to create a new consistent resource state. Such a situation might be encountered when a structural modification is applied to a configuration data store but the structures being modified do not exist.
競合状態：PATCHまたはiPATCH要求で指定された変更により、リソースがサーバーで解決できない不整合な状態になる場合、サーバーは4.09（競合）CoAP応答を返すことがあります。サーバーは、ユーザーが競合の原因を認識するのに十分な情報を含むペイロードを生成する必要があります（SHOULD）。サーバーは、クライアントに新しい一貫したリソース状態を作成する手段を提供するために、実際のリソース状態を返す場合があります。このような状況は、構造変更が構成データストアに適用されたが、変更されている構造が存在しない場合に発生する可能性があります。
Concurrent modification: Resource-constrained devices might need to process requests in the order they are received. In case requests are received concurrently to modify the same resource but they cannot be queued, the server can return a 5.03 (Service Unavailable) CoAP response code.
同時変更：リソースに制約のあるデバイスは、受信した順に要求を処理する必要がある場合があります。同じリソースを変更する要求が同時に受信されても、それらをキューに入れることができない場合、サーバーは5.03（Service Unavailable）CoAP応答コードを返すことができます。
Conflict handling failure: If the modification implies the reservation of resources or the wait time for conditions to become true leads to a too-long request execution time, the server can return a 5.03 (Service Unavailable) response code.
競合処理の失敗：変更がリソースの予約を意味するか、条件がtrueになるまでの待機時間が原因で要求の実行時間が長すぎる場合、サーバーは5.03（Service Unavailable）応答コードを返すことがあります。
It is possible that other error situations not mentioned here are encountered by a CoAP server while processing the PATCH request. In these situations, other appropriate CoAP status codes can also be returned.
ここに記載されていない他のエラー状況が、PATCH要求の処理中にCoAPサーバーで発生する可能性があります。これらの状況では、他の適切なCoAPステータスコードも返されます。
Adding three new methods to CoAP's existing four may seem like a major change. However, FETCH and the two PATCH variants fit well into the REST paradigm and have been anticipated on the HTTP side. Adding both a non-idempotent and an idempotent PATCH variant allows interoperability with HTTP's PATCH method to be kept and allows the use/indication of an idempotent PATCH when that is possible, which saves significant effort on the server side.
CoAPの既存の4つに3つの新しいメソッドを追加することは、大きな変更のように思えるかもしれません。ただし、FETCHと2つのPATCHバリアントはRESTパラダイムにうまく適合し、HTTP側で期待されています。非べき等とべき等の両方のPATCHバリアントを追加すると、HTTPのPATCHメソッドとの相互運用性が維持され、可能であればべき等PATCHの使用/表示が可能になるため、サーバー側の大幅な労力を節約できます。
Interestingly, the three new methods fit into the old table of methods with a surprising similarity in the idempotence and safety attributes:
興味深いことに、3つの新しいメソッドは、べき等性と安全性の属性が驚くほど類似している古いメソッドの表に適合します。
+------+--------+------+--------+------+------------+
| Code | Name | Code | Name | safe | idempotent |
+------+--------+------+--------+------+------------+
| 0.01 | GET | 0.05 | FETCH | yes | yes |
| 0.02 | POST | 0.06 | PATCH | no | no |
| 0.03 | PUT | 0.07 | iPATCH | no | yes |
| 0.04 | DELETE | | | no | yes |
+------+--------+------+--------+------+------------+
This section analyzes the possible threats to the CoAP FETCH and PATCH or iPATCH methods. It is meant to inform protocol and application developers about the security limitations of CoAP FETCH and PATCH or iPATCH as described in this document.
このセクションでは、CoAP FETCHおよびPATCHまたはiPATCHメソッドに対する潜在的な脅威を分析します。このドキュメントで説明されているように、CoAP FETCHおよびPATCHまたはiPATCHのセキュリティ制限についてプロトコルおよびアプリケーション開発者に通知することを目的としています。
The FETCH method is subject to the same general security considerations as all CoAP methods as described in Section 11 of [RFC7252]. Specifically, the security considerations for FETCH are closest to those of GET, except that the FETCH request carries a payload that may need additional protection. The payload of a FETCH request may reveal more detailed information about the specific portions of a resource of interest to the requester than a GET request for the entire resource would; this may mean that confidentiality protection of the request by Datagram Transport Layer Security (DTLS) or other means is needed for FETCH where it wouldn't be needed for GET.
[RFC7252]のセクション11で説明されているように、FETCHメソッドはすべてのCoAPメソッドと同じ一般的なセキュリティの考慮事項に従います。具体的には、FETCHのセキュリティに関する考慮事項は、GETCHのセキュリティに関する考慮事項に最も近いものです。ただし、FETCH要求には、追加の保護が必要なペイロードが含まれています。 FETCHリクエストのペイロードは、リソース全体のGETリクエストよりも、リクエスタにとって関心のあるリソースの特定の部分に関するより詳細な情報を明らかにする場合があります。これは、データグラムトランスポート層セキュリティ（DTLS）またはその他の手段による要求の機密保護が、GETには必要ないFETCHに必要であることを意味する場合があります。
The PATCH and iPATCH methods are subject to the same general security considerations as all CoAP methods as described in Section 11 of [RFC7252]. The specific security considerations for PATCH or iPATCH are nearly identical to the security considerations for PUT [RFC7252]; the security considerations of Section 5 of [RFC5789] also apply to PATCH and iPATCH. Specifically, there is likely to be a need for authorizing requests (possibly through access control and/or authentication) and for ensuring that data is not corrupted through transport errors or through accidental overwrites. The mechanisms used for PUT can be used for PATCH or iPATCH as well.
[RFC7252]のセクション11で説明されているように、PATCHメソッドとiPATCHメソッドには、すべてのCoAPメソッドと同じ一般的なセキュリティ上の考慮事項があります。 PATCHまたはiPATCHの具体的なセキュリティの考慮事項は、PUT [RFC7252]のセキュリティの考慮事項とほぼ同じです。 [RFC5789]のセクション5のセキュリティに関する考慮事項は、PATCHとiPATCHにも適用されます。具体的には、リクエストを承認し（場合によってはアクセス制御や認証を介して）、トランスポートエラーや偶発的な上書きによってデータが破損しないようにする必要があります。 PUTに使用されるメカニズムは、PATCHまたはiPATCHにも使用できます。
The new methods defined in the present specification are secured following the CoAP recommendations for the existing methods as specified in Section 9 of [RFC7252]. When additional security techniques are standardized for CoAP (e.g., Object Security), these techniques are then also available for securing the new methods.
本仕様書で定義されている新しいメソッドは、[RFC7252]のセクション9で指定されている既存のメソッドのCoAP推奨に従って保護されています。 CoAP用に追加のセキュリティ技術（オブジェクトセキュリティなど）が標準化されている場合、これらの技術は新しい方法を保護するためにも利用できます。
IANA has added the following entries to the subregistry "CoAP Method Codes":
IANAは、サブレジストリ「CoAPメソッドコード」に次のエントリを追加しました。
+------+--------+-----------+
| Code | Name | Reference |
+------+--------+-----------+
| 0.05 | FETCH | RFC 8132 |
| 0.06 | PATCH | RFC 8132 |
| 0.07 | iPATCH | RFC 8132 |
+------+--------+-----------+
The FETCH method is idempotent and safe, and it returns the same response codes that GET can return, plus 4.13 (Request Entity Too Large), 4.15 (Unsupported Content-Format), and 4.22 (Unprocessable Entity) with the semantics specified in Section 2.2.
FETCHメソッドはべき等で安全であり、GETが返すことができるのと同じ応答コードに加えて、セクション2.2で指定されているセマンティクスを持つ4.13（リクエストエンティティが大きすぎる）、4.15（サポートされていないコンテンツ形式）、および4.22（処理できないエンティティ）を返します。 。
The PATCH method is neither idempotent nor safe. It returns the same response codes that POST can return, plus 4.09 (Conflict) and 4.22 (Unprocessable Entity) with the semantics specified in Section 3.4.
PATCHメソッドは、べき等でも安全でもありません。これは、POSTが返すことができるのと同じ応答コードに加えて、セクション3.4で指定されているセマンティクスで4.09（競合）および4.22（処理できないエンティティ）を返します。
The iPATCH method is identical to the PATCH method, except that it is idempotent.
iPATCHメソッドは、べき等であることを除いて、PATCHメソッドと同じです。
IANA has added the following code to the subregistry "CoAP Response Codes":
IANAは、サブレジストリ「CoAP応答コード」に次のコードを追加しました。
+------+----------------------+-----------+
| Code | Name | Reference |
+------+----------------------+-----------+
| 4.09 | Conflict | RFC 8132 |
| 4.22 | Unprocessable Entity | RFC 8132 |
+------+----------------------+-----------+
IANA has added entries to the subregistry "CoAP Content-Formats":
IANAはサブレジストリ「CoAP Content-Formats」にエントリを追加しました。
+------------------------------+----------------+----+-----------+
| Media Type | Content Coding | ID | Reference |
+------------------------------+----------------+----+-----------+
| application/json-patch+json | identity | 51 | [RFC6902] |
| application/merge-patch+json | identity | 52 | [RFC7396] |
+------------------------------+----------------+----+-----------+
[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>。
[RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP", RFC 5789, DOI 10.17487/RFC5789, March 2010, <http://www.rfc-editor.org/info/rfc5789>.
[RFC5789] Dusseault、L.およびJ. Snell、「PATCH Method for HTTP」、RFC 5789、DOI 10.17487 / RFC5789、2010年3月、<http://www.rfc-editor.org/info/rfc5789>。
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <http://www.rfc-editor.org/info/rfc7231>.
[RFC7231]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Semantics and Content」、RFC 7231、DOI 10.17487 / RFC7231、2014年6月、<http://www.rfc-editor.org/info/rfc7231 >。
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <http://www.rfc-editor.org/info/rfc7252>.
[RFC7252] Shelby、Z.、Hartke、K。、およびC. Bormann、「The Constrained Application Protocol（CoAP）」、RFC 7252、DOI 10.17487 / RFC7252、2014年6月、<http：//www.rfc-editor。 org / info / rfc7252>。
[RFC7641] Hartke, K., "Observing Resources in the Constrained Application Protocol (CoAP)", RFC 7641, DOI 10.17487/RFC7641, September 2015, <http://www.rfc-editor.org/info/rfc7641>.
[RFC7641] Hartke、K。、「Observing Resources in the Constrained Application Protocol（CoAP）」、RFC 7641、DOI 10.17487 / RFC7641、2015年9月、<http://www.rfc-editor.org/info/rfc7641>。
[RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in the Constrained Application Protocol (CoAP)", RFC 7959, DOI 10.17487/RFC7959, August 2016, <http://www.rfc-editor.org/info/rfc7959>.
[RFC7959] Bormann、C.およびZ. Shelby、Ed。、「Block-Wise Transfers in the Constrained Application Protocol（CoAP）」、RFC 7959、DOI 10.17487 / RFC7959、2016年8月、<http：//www.rfc- editor.org/info/rfc7959>。
[RFC5323] Reschke, J., Ed., Reddy, S., Davis, J., and A. Babich, "Web Distributed Authoring and Versioning (WebDAV) SEARCH", RFC 5323, DOI 10.17487/RFC5323, November 2008, <http://www.rfc-editor.org/info/rfc5323>.
[RFC5323] Reschke、J.、Ed。、Reddy、S.、Davis、J.、and A. Babich、 "Web Distributed Authoring and Versioning（WebDAV）SEARCH"、RFC 5323、DOI 10.17487 / RFC5323、November 2008、< http://www.rfc-editor.org/info/rfc5323>。
[RFC6902] Bryan, P., Ed. and M. Nottingham, Ed., "JavaScript Object Notation (JSON) Patch", RFC 6902, DOI 10.17487/RFC6902, April 2013, <http://www.rfc-editor.org/info/rfc6902>.
[RFC6902]ブライアン、P。、エド。 M.ノッティンガム編、「JavaScript Object Notation（JSON）Patch」、RFC 6902、DOI 10.17487 / RFC6902、2013年4月、<http://www.rfc-editor.org/info/rfc6902>。
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, <http://www.rfc-editor.org/info/rfc7159>.
[RFC7159]ブレイ、T。、編、「JavaScript Object Notation（JSON）データ交換フォーマット」、RFC 7159、DOI 10.17487 / RFC7159、2014年3月、<http://www.rfc-editor.org/info/ rfc7159>。
[RFC7396] Hoffman, P. and J. Snell, "JSON Merge Patch", RFC 7396, DOI 10.17487/RFC7396, October 2014, <http://www.rfc-editor.org/info/rfc7396>.
[RFC7396] Hoffman、P。およびJ. Snell、「JSON Merge Patch」、RFC 7396、DOI 10.17487 / RFC7396、2014年10月、<http://www.rfc-editor.org/info/rfc7396>。
[COAP-MGMNT] Stok, P., Bierman, A., Veillette, M., and A. Pelov, "CoAP Management Interface", Work in Progress, draft-ietf-core-comi-00, January 2017.
[COAP-MGMNT] Stok、P.、Bierman、A.、Veillette、M。、およびA. Pelov、「CoAP Management Interface」、Work in Progress、draft-ietf-core-comi-00、2017年1月。
[CORE-APP] Hartke, K., "CoRE Application Descriptions", Work in Progress, draft-hartke-core-apps-07, February 2017.
[CORE-APP] Hartke、K。、「CoRE Application Descriptions」、Work in Progress、draft-hartke-core-apps-07、2017年2月。
[HTTP-SEARCH] Reschke, J., Malhotra, A., and J. Snell, "HTTP SEARCH Method", Work in Progress, draft-snell-search-method-00, April 2015.
[HTTP-SEARCH] Reschke、J.、Malhotra、A。、およびJ. Snell、「HTTP SEARCH Method」、Work in Progress、draft-snell-search-method-00、2015年4月。
Acknowledgements
謝辞
Klaus Hartke has pointed out some essential differences between CoAP and HTTP concerning PATCH and found a number of problems in an earlier draft version of Section 2. We are grateful for discussions with Christian Amsuss, Andy Bierman, Timothy Carey, Paul Duffy, Matthias Kovatsch, Michel Veillette, Michael Verschoor, Thomas Watteyne, and Gengyu Wei. Christian Groves provided detailed comments during the Working Group Last Call, and Christer Holmberg's Gen-ART review provided some further editorial improvement. Further Last Call reviews were provided by Sheng Jiang and Phillip Hallam-Baker. As usual, the IESG had some very good reviews, and we would like to specifically call out those by Alexey Melnikov (responsible AD) and Alissa Cooper.
Klaus Hartkeは、PATCHに関するCoAPとHTTPの本質的な違いを指摘し、セクション2の以前のドラフトバージョンにいくつかの問題を発見しました。ChristianAmsuss、Andy Bierman、Timothy Carey、Paul Duffy、Matthias Kovatsch、ミシェルヴェイレット、マイケルヴェルシュアー、トーマスワッテイン、ゲンギュウェイ。クリスチャングローブスは、ワーキンググループのラストコール中に詳細なコメントを提供し、クリスターホルムバーグのGen-ARTレビューは、さらに編集上の改善を提供しました。さらにラストコールのレビューは、Sheng JiangおよびPhillip Hallam-Bakerによって提供されました。いつものように、IESGには非常に優れたレビューがいくつかありました。具体的には、アレクセイメルニコフ（責任あるAD）とアリッサクーパーによるレビューを呼びたいと思います。
Authors' Addresses
著者のアドレス
Peter van der Stok Consultant
Peter van der Stokコンサルタント
Email: consultancy@vanderstok.org
Carsten Bormann Universitaet Bremen TZI Postfach 330440 Bremen D-28359 Germany
Carsten Bormann Universitaet Bremen TZI PO Box 330440ブレーメンD-28359ドイツ
Phone: +49-421-218-63921
Email: cabo@tzi.org
Anuj Sehgal NAVOMI, Inc.
Anuj Sehgal Navami、これ。
Email: anuj.sehgal@navomi.com