idnits 2.17.1 draft-ietf-core-etch-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 08, 2016) is 2903 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCthis' is mentioned on line 583, but not defined == Unused Reference: 'RFC5226' is defined on line 626, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-21) exists of draft-ietf-core-block-19 == Outdated reference: A later version (-11) exists of draft-vanderstok-core-comi-09 == Outdated reference: A later version (-08) exists of draft-hartke-core-apps-03 == Outdated reference: A later version (-02) exists of draft-snell-search-method-00 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 core P. van der Stok 3 Internet-Draft Consultant 4 Intended status: Standards Track C. Bormann 5 Expires: November 9, 2016 Universitaet Bremen TZI 6 A. Sehgal 7 Consultant 8 May 08, 2016 10 Patch and Fetch Methods for Constrained Application Protocol (CoAP) 11 draft-ietf-core-etch-00 13 Abstract 15 The existing Constrained Application Protocol (CoAP) methods only 16 allow access to a complete resource. This does not permit 17 applications to access parts of a resource. In case of resources 18 with larger or complex data, or in situations where a resource 19 continuity is required, replacing or requesting the whole resource is 20 undesirable. Several applications using CoAP will need to perform 21 partial resource accesses. 23 Similar to HTTP, the existing Constrained Application Protocol (CoAP) 24 GET method only allows the specification of a URI and request 25 parameters in CoAP options, not the transfer of a request payload 26 detailing the request. This leads to some applications to using POST 27 where actually a cacheable, idempotent, safe request is desired. 29 Again similar to HTTP, the existing Constrained Application Protocol 30 (CoAP) PUT method only allows to replace a complete resource. This 31 also leads applications to use POST where actually a cacheable, 32 possibly idempotent request is desired. 34 This specification adds new CoAP methods, FETCH, to perform the 35 equivalent of a GET with a request body; and the twin methods PATCH 36 and iPATCH, to modify parts of an existing CoAP resource. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on November 9, 2016. 55 Copyright Notice 57 Copyright (c) 2016 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 1.1. FETCH . . . . . . . . . . . . . . . . . . . . . . . . . . 3 74 1.2. PATCH and iPATCH . . . . . . . . . . . . . . . . . . . . 4 75 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 4 76 1.4. Terminology and Acronyms . . . . . . . . . . . . . . . . 4 77 2. FETCH Method . . . . . . . . . . . . . . . . . . . . . . . . 4 78 2.1. The Content-Format Option . . . . . . . . . . . . . . . . 6 79 2.2. Working with Observe . . . . . . . . . . . . . . . . . . 6 80 2.3. Working with Block . . . . . . . . . . . . . . . . . . . 6 81 2.4. FETCH discussion . . . . . . . . . . . . . . . . . . . . 6 82 3. PATCH and iPATCH Methods . . . . . . . . . . . . . . . . . . 6 83 3.1. Simple Examples for PATCH and iPATCH . . . . . . . . . . 8 84 3.2. Response Codes . . . . . . . . . . . . . . . . . . . . . 10 85 3.3. Option Numbers . . . . . . . . . . . . . . . . . . . . . 10 86 3.4. Error Handling . . . . . . . . . . . . . . . . . . . . . 10 87 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 12 88 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 89 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 90 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 91 8. Change log . . . . . . . . . . . . . . . . . . . . . . . . . 14 92 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 93 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 94 9.2. Informative References . . . . . . . . . . . . . . . . . 15 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 97 1. Introduction 99 This specification defines the new Constrained Application Protocol 100 (CoAP) [RFC7252] methods, FETCH, PATCH and iPATCH, which are used to 101 access and update parts of a resource. 103 1.1. FETCH 105 The CoAP GET method [RFC7252] is used to obtain the representation of 106 a resource, where the resource is specified by a URI and additional 107 request parameters can additionally shape the representation. This 108 has been modelled after the HTTP GET operation and the REST model in 109 general. 111 In HTTP, a resource is often used to search for information, and 112 existing systems varyingly use the HTTP GET and POST methods to 113 perform a search. Often a POST method is used for the sole reason 114 that a larger set of parameters to the search can be supplied in the 115 request body than can comfortably transferred in the URI with a GET 116 request. The draft [I-D.snell-search-method] proposes a SEARCH 117 method that is similar to GET in most properties but enables sending 118 a request body as with POST. The FETCH method defined in the present 119 specification is inspired by [I-D.snell-search-method], which updates 120 the definition and semantics of the HTTP SEARCH request method 121 previously defined by [RFC5323]. However, there is no intention to 122 limit FETCH to search-type operations, and the resulting properties 123 may not be the same as those of HTTP SEARCH. 125 A major problem with GET is that the information that controls the 126 request needs to be bundled up in some unspecified way into the URI. 127 Using the request body for this information has a number of 128 advantages: 130 o The client can specify a media type (and a content encoding), 131 enabling the server to unambiguously interpret the request 132 parameters in the context of that media type. Also, the request 133 body is not limited by the character set limitations of URIs, 134 enabling a more natural (and more efficient) representation of 135 certain domain-specific parameters. 137 o The request parameters are not limited by the maximum size of the 138 URI. In HTTP, that is a problem as the practical limit for this 139 size varies. In CoAP, another problem is that the block-wise 140 transfer is not available for transferring large URI options in 141 multiple rounds. 143 As an alternative to using GET, many implementations make use of the 144 POST method to perform extended requests, even if they are 145 semantically idempotent, safe, and even cacheable, to be able to pass 146 along the input parameters within the request payload as opposed to 147 using the request URI. 149 The FETCH method provides a solution that spans the gap between the 150 use of GET and POST. As with POST, the input to the FETCH operation 151 is passed along within the payload of the request rather than as part 152 of the request URI. Unlike POST, however the semantics of the FETCH 153 method are more specifically defined. 155 1.2. PATCH and iPATCH 157 PATCH is also specified for HTTP in [RFC5789]. Most of the 158 motivation for PATCH described in [RFC5789] also applies here. iPATCH 159 is the idempotent version of PATCH. 161 The PUT method exists to overwrite a resource with completely new 162 contents, and cannot be used to perform partial changes. When using 163 PUT for partial changes, proxies and caches, and even clients and 164 servers, may get confused as to the result of the operation. PATCH 165 was not adopted in an early design stage of CoAP, however, it has 166 become necessary with the arrival of applications that require 167 partial updates to resources (e.g. [I-D.vanderstok-core-comi]). 168 Using PATCH avoids transferring all data associated with a resource 169 in case of modifications, thereby not burdening the constrained 170 communication medium. 172 This document relies on knowledge of the PATCH specification for HTTP 173 [RFC5789]. This document provides extracts from [RFC5789] to make 174 independent reading possible. 176 1.3. Requirements Language 178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 180 "OPTIONAL" in this document are to be interpreted as described in 181 [RFC2119]. 183 1.4. Terminology and Acronyms 185 This document uses terminology defined in [RFC5789] and [RFC7252]. 187 2. FETCH Method 189 The CoAP FETCH method is used to obtain a representation of a 190 resource, giving a number of request parameters. Unlike the CoAP GET 191 method, which requests that a server return a representation of the 192 resource identified by the effective request URI (as defined by 194 [RFC7252]), the FETCH method is used by a client to ask the server to 195 produce a representation as described by the request parameters 196 (including the request options and the payload) based on the resource 197 specified by the effective request URI. The payload returned in 198 response to a FETCH cannot be assumed to be a complete representation 199 of the resource identified by the effective request URI. 201 Together with the request options, the body of the request (which may 202 be constructed from multiple payloads using the block protocol 203 [I-D.ietf-core-block]) defines the request parameters. 204 Implementations MAY use a request body of any content type with the 205 FETCH method; it is outside the scope of this document how 206 information about admissible content types is obtained by the client 207 (although we can hint that form relations ([I-D.hartke-core-apps]) 208 might be a preferred way). 210 FETCH requests are both safe and idempotent with regards to the 211 resource identified by the request URI. That is, the performance of 212 a fetch is not intended to alter the state of the targeted resource. 213 (However, while processing a search request, a server can be expected 214 to allocate computing and memory resources or even create additional 215 server resources through which the response to the search can be 216 retrieved.) 218 A successful response to a FETCH request is expected to provide some 219 indication as to the final disposition of the requested operation. 220 If a successful response includes a body payload, the payload is 221 expected to describe the results of the FETCH operation. 223 Depending on the response code as defined by [RFC7252], the response 224 to a FETCH request is cacheable; the request body is part of the 225 cache key. Specifically, 2.05 "Content" response codes, the 226 responses for which are cacheable, are a usual way to respond to a 227 FETCH request. (Note that this aspect differs markedly from 228 [I-D.snell-search-method].) (Note also that caches that cannot use 229 the request payload as part of the cache key will not be able to 230 cache responses to FETCH requests at all.) The Max-Age option in the 231 response has equivalent semantics to its use in a GET. 233 The semantics of the FETCH method change to a "conditional FETCH" if 234 the request message includes an If-Match, or If-None-Match option 235 ([RFC7252]). A conditional FETCH requests that the query be 236 performed only under the circumstances described by the conditional 237 option(s). It is important to note, however, that such conditions 238 are evaluated against the state of the target resource itself as 239 opposed to the results of the FETCH operation. 241 TODO This needs some additional text on what an ETag on a FETCH 242 result means. 244 2.1. The Content-Format Option 246 A FETCH request MUST include a Content-Format option to specify the 247 media type and content encoding of the request body. 249 2.2. Working with Observe 251 The Observe option [RFC7641] can be used with a FETCH request as it 252 can be used with a GET request. 254 2.3. Working with Block 256 The Block1 option [I-D.ietf-core-block] can be used with a FETCH 257 request as it would be used with a POST request; the Block2 option 258 can then be used as with GET or POST. 260 2.4. FETCH discussion 262 One property of FETCH that may be non-obvious is that a FETCH request 263 cannot be generated from a link alone, but also needs a way to 264 generate the request payload. Again, form relations 265 ([I-D.hartke-core-apps]) may be able to fill parts of this gap. 267 3. PATCH and iPATCH Methods 269 The PATCH and iPATCH methods request that a set of changes described 270 in the request payload is applied to the target resource of the 271 request. The set of changes is represented in a format identified by 272 a media type. If the Request-URI does not point to an existing 273 resource, the server MAY create a new resource with that URI, 274 depending on the patch document type (whether it can logically modify 275 a null resource) and permissions, etc. Creation of a new resource 276 would result in a 2.01 (Created) Response Code dependent of the patch 277 document type. 279 Restrictions to a PATCH or iPATCH request can be made by including 280 the If-Match or If-None-Match options in the request (see 281 Section 5.10.8.1 and 5.10.8.2 of [RFC7252]). If the resource could 282 not be created or modified, then an appropriate Error Response Code 283 SHOULD be sent. 285 The difference between the PUT and PATCH requests is extensively 286 documented in [RFC5789]. 288 The PATCH method is not safe and not idempotent, as with the HTTP 289 PATCH method specified in [RFC5789]. 291 The iPATCH method is not safe but idempotent, as with the CoAP PUT 292 method specified in [RFC7252], Section 5.8.3. 294 A client can mark a request as idempotent by using the iPATCH method 295 instead of the PATCH method. This is the only difference between the 296 two. The indication of idempotence may enable the server to keep 297 less state about the interaction; some constrained servers may only 298 implement the iPATCH variant for this reason. 300 PATCH and iPATCH are both atomic. The server MUST apply the entire 301 set of changes atomically and never provide a partially modified 302 representation to a concurrently executed GET request. Given the 303 constrained nature of the servers, most servers will only execute 304 CoAP requests consecutively, thus preventing a concurrent partial 305 overlapping of request modifications. Resuming, modifications MUST 306 NOT be applied to the server state when an error occurs or only a 307 partial execution is possible on the resources present in the server. 309 The atomicity applies to a single server. When a PATCH or iPATCH 310 request is multicast to a set of servers, each server can either 311 execute all required modifications or not. It is not required that 312 all servers execute all modifications or none. An Atomic Commit 313 protocol that provides multiple server atomicity is out of scope. 315 A PATCH or iPATCH response can invalidate a cache as with the PUT 316 response. Caching behaviour as function of the successful (2.xx) 317 response codes for PATCH or iPATCH are: 319 o A 2.01 (Created) response invalidates any cache entry for the 320 resource indicated by the Location-* Options; the payload is a 321 representation of the action result. 323 o A 2.04 (Changed) response invalidates any cache entry for the 324 target resource; the payload is a representation of the action 325 result. 327 There is no guarantee that a resource can be modified with PATCH or 328 iPATCH. Servers MUST ensure that a received PATCH body is 329 appropriate for the type of resource identified by the target 330 resource of the request. 332 When a request is intended to effect a partial update of a given 333 resource, clients cannot use PUT while supplying just the update, but 334 are free to use PATCH or iPATCH. 336 3.1. Simple Examples for PATCH and iPATCH 338 The example is taken over from [RFC6902], which specifies a JSON 339 notation for PATCH operations. A resource located at 340 coap://www.example.com/object contains a target JSON document. 342 JSON document original state: 343 { 344 "x-coord": 256, 345 "y-coord": 45", 346 "foo": ["bar","baz"] 347 } 349 REQ: iPATCH CoAP://www.example.com/object 350 Content-Format: application/json-patch+json 351 [ 352 { "op":"replace", "path":"x-coord", "value":45} 353 ] 355 RET: CoAP 2.04 Changed 357 JSON document final state: 358 { 359 "x-coord": 45, 360 "y-coord": 45, 361 "foo": ["bar","baz"] 362 } 364 This example illustrates use of an idempotent modification to the 365 x-coord member of the existing resource "object". The 2.04 (Changed) 366 response code is conform with the CoAP PUT method. 368 The same example using the Content-Format application/merge- 369 patch+json from [RFC7396] looks like: 371 JSON document original state: 372 { 373 "x-coord": 256, 374 "y-coord": 45", 375 "foo": ["bar","baz"] 376 } 378 REQ: iPATCH CoAP://www.example.com/object 379 Content-Format: 52 (application/merge-patch+json) 380 { "x-coord":45} 382 RET: CoAP 2.04 Changed 384 JSON document final state: 385 { 386 "x-coord": 45, 387 "y-coord": 45, 388 "foo": ["bar","baz"] 389 } 391 The examples show the use of the iPATCH method, but the use of the 392 PATCH method would have led to the same result. Below a non- 393 idempotent modification is shown. Because the action is non- 394 idempotent, iPATCH returns an error, while PATCH executes the action. 396 JSON document original state: 397 { 398 "x-coord": 256, 399 "y-coord": 45", 400 "foo": ["bar","baz"] 401 } 403 REQ: iPATCH CoAP://www.example.com/object 404 Content-Format: 51 (application/json-patch+json) 405 [ 406 { "op":"add","path":"foo/1","value":"bar"} 407 ] 408 RET: CoAP 4.12 Precondition Failed 410 JSON document final state is unchanged 412 REQ: PATCH CoAP://www.example.com/object 413 Content-Format: 51 (application/json-patch+json) 414 [ 415 { "op":"add","path":"foo/1","value":"bar"} 416 ] 417 RET: CoAP 2.04 Changed 419 JSON document final state: 420 { 421 "x-coord": 45, 422 "y-coord": 45, 423 "foo": ["bar","bar","baz"] 424 } 426 3.2. Response Codes 428 PATCH and iPATCH for CoAP adopt the response codes as specified in 429 sections 5.9 and 12.1.2 of [RFC7252]. 431 3.3. Option Numbers 433 PATCH and iPATCH for CoAP adopt the option numbers as specified in 434 sections 5.10 and 12.2 of [RFC7252]. 436 3.4. Error Handling 438 A PATCH or iPATCH request may fail under certain known conditions. 439 These situations should be dealt with as expressed below. 441 Malformed PATCH or iPATCH payload: If a server determines that the 442 payload provided with a PATCH or iPATCH request is not properly 443 formatted, it can return a 4.00 (Bad Request) CoAP error. The 444 definition of a malformed payload depends upon the CoAP Content- 445 Format specified with the request. 447 Unsupported PATCH or iPATCH payload: In case a client sends payload 448 that is inappropriate for the resource identified by the Request- 449 URI, the server can return a 4.15 (Unsupported Content-Format) 450 CoAP error. The server can determine if the payload is supported 451 by checking the CoAP Content-Format specified with the request. 453 Unprocessable request: This situation occurs when the payload of a 454 PATCH request is determined as valid, i.e. well-formed and 455 supported, however, the server is unable to or incapable of 456 processing the request. The server can return a 4.22 457 (Unprocessable Entity) CoAP error. More specific scenarios might 458 include situations when: 460 * the server has insufficient computing resources to complete the 461 request successfully -- 4.13 (Request Entity Too Large) CoAP 462 Response Code (see below), 464 * the resource specified in the request becomes invalid by 465 applying the payload -- 4.09 (Conflict) CoAP Response Code (see 466 below)), 468 In case there are more specific errors that provide more insight 469 into the problem, then those should be used. 471 Resource not found: The 4.04 (Not Found) error should be returned in 472 case the payload of a PATCH request cannot be applied to a non- 473 existent resource. 475 Failed precondition: In case the client uses the conditional If- 476 Match or If-None-Match option to define a precondition for the 477 PATCH request, and that precondition fails, then the server can 478 return the 4.12 (Precondition Failed) CoAP error. 480 Request too large: If the payload of the PATCH request is larger 481 than a CoAP server can process, then it can return the 4.13 482 (Request Entity Too Large) CoAP error. 484 Conflicting state: If the modification specified by a PATCH or 485 iPATCH request causes the resource to enter an inconsistent state 486 that the server cannot resolve, the server can return the 4.09 487 (Conflict) CoAP response. The server SHOULD generate a payload 488 that includes enough information for a user to recognize the 489 source of the conflict. The server MAY return the actual resource 490 state to provide the client with the means to create a new 491 consistent resource state. Such a situation might be encountered 492 when a structural modification is applied to a configuration data- 493 store, but the structures being modified do not exist. 495 Concurrent modification: Resource constrained devices might need to 496 process requests in the order they are received. In case requests 497 are received concurrently to modify the same resource but they 498 cannot be queued, the server can return a 5.03 (Service 499 unavailable) CoAP response code. 501 Conflict handling failure: If the modification implies the 502 reservation of resources or the waiting on conditions to become 503 true, leading to a too long request execution time, the server can 504 return 5.03 (service unavailable) response code. 506 It is possible that other error situations, not mentioned here, are 507 encountered by a CoAP server while processing the PATCH request. In 508 these situations other appropriate CoAP status codes can also be 509 returned. 511 4. Discussion 513 Adding three new methods to CoAP's existing four may seem like a 514 major change. However, both FETCH and the two PATCH variants fit 515 well into the REST paradigm and have been anticipated on the HTTP 516 side. Adding both a non-idempotent and an idempotent PATCH variant 517 allows to keep interoperability with HTTP's PATCH method as well as 518 the use/indication of an idempotent PATCH if that is possible, saving 519 significant effort on the server side. 521 Interestingly, the three new methods fit into the old table of 522 methods with a surprising similarity in the idempotence and safety 523 attributes: 525 +------+--------+------+--------+------+------------+ 526 | Code | Name | Code | Name | safe | idempotent | 527 +------+--------+------+--------+------+------------+ 528 | 0.01 | GET | 0.05 | FETCH | yes | yes | 529 | 0.02 | POST | 0.06 | PATCH | no | no | 530 | 0.03 | PUT | 0.07 | iPATCH | no | yes | 531 | 0.04 | DELETE | | | no | yes | 532 +------+--------+------+--------+------+------------+ 534 5. Security Considerations 536 This section analyses the possible threats to the CoAP FETCH and 537 PATCH or iPATCH methods. It is meant to inform protocol and 538 application developers about the security limitations of CoAP FETCH 539 and PATCH or iPATCH as described in this document. 541 The FETCH method is subject to the same general security 542 considerations as all CoAP methods as described in [RFC7252]. 544 The security consideration of section 15 of [RFC2616], section 11 of 545 [RFC7252], and section 5 of [RFC5789] also apply. 547 The security considerations for PATCH or iPATCH are nearly identical 548 to the security considerations for PUT ([RFC7252]). The mechanisms 549 used for PUT can be used for PATCH or iPATCH as well. 551 PATCH or iPATCH are secured following the CoAP recommendations as 552 specified in section 9 of [RFC7252]. When additional security 553 techniques are standardized for CoAP, PATCH or iPATCH can also be 554 (and need to be) secured by those new techniques. 556 6. IANA Considerations 558 IANA is requested to add the following entries to the sub-registry 559 "CoAP Method Codes": 561 +------+--------+-----------+ 562 | Code | Name | Reference | 563 +------+--------+-----------+ 564 | 0.05 | FETCH | [RFCthis] | 565 | 0.06 | PATCH | [RFCthis] | 566 | 0.07 | iPATCH | [RFCthis] | 567 +------+--------+-----------+ 569 The FETCH method is idempotent and safe, and it returns the same 570 response codes that GET can return, plus 4.15 "Unsupported Content- 571 Format" with the same semantics as with POST. 573 The PATCH method is neither idempotent nor safe. It returns the same 574 response codes that POST can return, plus 4.09 "Conflict" with the 575 semantics specified in Section 3.4. 577 IANA is requested to add the following code to the sub-registry "CoAP 578 response codes": 580 +------+----------+-----------+ 581 | Code | Name | Reference | 582 +------+----------+-----------+ 583 | 4.09 | Conflict | [RFCthis] | 584 +------+----------+-----------+ 586 IANA is requested to add entries to the sub-registry "CoAP Content- 587 Formats", within the "CoRE Parameters" registry: 589 +------------------------------+----------+----+-----------+ 590 | Media Type | Encoding | ID | Reference | 591 +------------------------------+----------+----+-----------+ 592 | application/json-patch+json | | 51 | [RFC6902] | 593 | application/merge-patch+json | | 52 | [RFC7396] | 594 +------------------------------+----------+----+-----------+ 596 7. Acknowledgements 598 Klaus Hartke has pointed out some essential differences between CoAP 599 and HTTP concerning PATCH, and found a number of problems in an 600 earlier version of Section 2. We are grateful for discussions with 601 Christian Amsuss, Timothy Carey, Paul Duffy, Kovatsch Matthias, 602 Michel Veillette, Michael Verschoor, Thomas Watteyne, and Gengyu Wei. 604 8. Change log 606 When published as a RFC, this section needs to be removed. 608 Version 00 is a composition from draft-vanderstok-core-patch-03 and 609 draft-bormann-core-coap-fetch-00 and replaces these two drafts. 611 9. References 613 9.1. Normative References 615 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 616 Requirement Levels", BCP 14, RFC 2119, 617 DOI 10.17487/RFC2119, March 1997, 618 . 620 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 621 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 622 Transfer Protocol -- HTTP/1.1", RFC 2616, 623 DOI 10.17487/RFC2616, June 1999, 624 . 626 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 627 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 628 DOI 10.17487/RFC5226, May 2008, 629 . 631 [RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP", 632 RFC 5789, DOI 10.17487/RFC5789, March 2010, 633 . 635 [RFC6902] Bryan, P., Ed. and M. Nottingham, Ed., "JavaScript Object 636 Notation (JSON) Patch", RFC 6902, DOI 10.17487/RFC6902, 637 April 2013, . 639 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 640 Application Protocol (CoAP)", RFC 7252, 641 DOI 10.17487/RFC7252, June 2014, 642 . 644 [RFC7396] Hoffman, P. and J. Snell, "JSON Merge Patch", RFC 7396, 645 DOI 10.17487/RFC7396, October 2014, 646 . 648 [RFC7641] Hartke, K., "Observing Resources in the Constrained 649 Application Protocol (CoAP)", RFC 7641, 650 DOI 10.17487/RFC7641, September 2015, 651 . 653 [I-D.ietf-core-block] 654 Bormann, C. and Z. Shelby, "Block-wise transfers in CoAP", 655 draft-ietf-core-block-19 (work in progress), March 2016. 657 9.2. Informative References 659 [RFC5323] Reschke, J., Ed., Reddy, S., Davis, J., and A. Babich, 660 "Web Distributed Authoring and Versioning (WebDAV) 661 SEARCH", RFC 5323, DOI 10.17487/RFC5323, November 2008, 662 . 664 [I-D.vanderstok-core-comi] 665 Stok, P. and A. Bierman, "CoAP Management Interface", 666 draft-vanderstok-core-comi-09 (work in progress), March 667 2016. 669 [I-D.hartke-core-apps] 670 Hartke, K., "CoRE Application Descriptions", draft-hartke- 671 core-apps-03 (work in progress), February 2016. 673 [I-D.snell-search-method] 674 Reschke, J., Malhotra, A., and J. Snell, "HTTP SEARCH 675 Method", draft-snell-search-method-00 (work in progress), 676 April 2015. 678 Authors' Addresses 679 Peter van der Stok 680 Consultant 682 Email: consultancy@vanderstok.org 684 Carsten Bormann 685 Universitaet Bremen TZI 686 Postfach 330440 687 Bremen D-28359 688 Germany 690 Phone: +49-421-218-63921 691 Email: cabo@tzi.org 693 Anuj Sehgal 694 Consultant 696 Email: anuj@iurs.org