CoRE L. Li Internet-Draft Zhongguancun Laboratory Intended status: Standards Track Y. Cui Expires: 23 January 2027 Tsinghua University 22 July 2026 CoAP Extensions for Asynchronous Task Resources draft-li-coap-task-resources-01 Abstract Many operations on constrained devices cannot complete within a single CoAP request and response exchange. Examples include firmware installation, diagnostic procedures, commissioning, calibration, and physical actuation. This document defines a common lifecycle model for representing such operations as addressable CoAP Task Resources. It specifies task creation, state monitoring, discovery, cancellation, terminal-state retention, and eventual removal. It also defines a four-part request payload model, identified by the existing CoAP Content-Format Option, for carrying resource operations together with task execution controls. No new CoAP Option is defined. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 23 January 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Li & Cui Expires 23 January 2027 [Page 1] Internet-Draft CoAP Task Resources July 2026 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Task Lifecycle . . . . . . . . . . . . . . . . . . . . . . . 4 5. Task Request Payload . . . . . . . . . . . . . . . . . . . . 6 5.1. Content-Format . . . . . . . . . . . . . . . . . . . . . 6 5.2. Four-Part Payload . . . . . . . . . . . . . . . . . . . . 6 5.3. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 8 5.4. Resource Operations . . . . . . . . . . . . . . . . . . . 9 5.5. Task Execution Controls . . . . . . . . . . . . . . . . . 9 5.6. Example . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Task-Resource Mapping . . . . . . . . . . . . . . . . . . . . 10 6.1. Creation . . . . . . . . . . . . . . . . . . . . . . . . 10 6.2. Methods on a Task Resource . . . . . . . . . . . . . . . 11 6.3. Cancellation Resource . . . . . . . . . . . . . . . . . . 12 7. Task Status Subresources . . . . . . . . . . . . . . . . . . 12 8. Conditional Observation . . . . . . . . . . . . . . . . . . . 13 9. Task Discovery . . . . . . . . . . . . . . . . . . . . . . . 13 10. Task Status Payload . . . . . . . . . . . . . . . . . . . . . 14 11. Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . 15 12. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 16 13. Security Considerations . . . . . . . . . . . . . . . . . . . 17 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 14.1. Task Request Content-Format . . . . . . . . . . . . . . 17 14.2. Interface Description Registration . . . . . . . . . . . 17 15. Implementation Considerations . . . . . . . . . . . . . . . . 18 16. Changes from draft-li-coap-task-resources-00 . . . . . . . . 18 17. Normative References . . . . . . . . . . . . . . . . . . . . 18 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Li & Cui Expires 23 January 2027 [Page 2] Internet-Draft CoAP Task Resources July 2026 1. Introduction A CoAP request [RFC7252] normally produces a response describing the immediate result of applying a method to a resource. Some operations, however, continue after the request has been accepted. A firmware installation may download an image, verify it, install it, and reboot the device. A diagnostic operation may run multiple tests and retain a report. Commissioning and physical actuation may wait for external events or take a substantial amount of time. Applications commonly represent these operations using implementation-specific job identifiers, state fields, polling endpoints, or Observe notifications. Although these mechanisms can work within one application, they do not provide a reusable contract for generic CoAP clients. In particular: * a client has no common state vocabulary for determining whether an operation is pending, active, completed, failed, aborted, or rejected; * a lost creation response or a client restart can leave an outstanding task undiscoverable; * progress alone cannot reliably identify terminal failure or cancellation; * cancellation is often confused with removal of the resource representing the operation; * resource-operation semantics and task-execution controls are often carried in application-specific CoAP Options or payloads. The primary contribution of this document is a common lifecycle for asynchronous Task Resources. A Task Initiator submits an operation using POST. When the Executor accepts the operation for asynchronous processing, it creates a Task Resource and returns the location of that resource. The Task Initiator subsequently retrieves or observes the Task Resource, updates permitted task parameters, or requests cancellation through a cancellation resource using existing CoAP methods. 2. Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Li & Cui Expires 23 January 2027 [Page 3] Internet-Draft CoAP Task Resources July 2026 Task Initiator: A CoAP client that requests an operation that may be processed asynchronously. Executor: A CoAP server that accepts, executes, and reports the operation. Task Resource: A CoAP resource representing one accepted operation. It exposes task state and MAY expose progress, estimated completion time, diagnostics, and per-resource results. Task Request: The four-part payload defined in Section 5. It contains resource-operation content and task-execution content. Resource Operation: One application operation on a target resource, carried in the Resource content part of a Task Request. Terminal State: COMPLETED, FAILED, ABORTED, or REJECTED. 3. Scope This document specifies: * a common Task Resource lifecycle and state vocabulary; * task creation, retrieval, observation, update, and cancellation behavior; * discovery using CoRE Link Format interface descriptions; * a four-part Task Request payload identified by Content-Format; This document does not change the base CoAP message layer, token processing, retransmission behavior, or proxy behavior. It defines no new CoAP Option. 4. Task Lifecycle A Task Resource represents an operation accepted for asynchronous processing. Its state follows the state machine below. Li & Cui Expires 23 January 2027 [Page 4] Internet-Draft CoAP Task Resources July 2026 +---------+ Dynamic admission fails | PENDING | -------------------------> [ REJECTED ] +---------+ | | Waiting for activate v +---------+ cancellation | PENDING | -------------------------> [ ABORTED ] +---------+ | | Accepted for execution v +---------+ Cancellation | ACTIVE | -------------------------> [ ABORTED ] +---------+ | | Execution finishes v +--------------+ | Successful? | -- Yes ---------------> [ COMPLETED ] +--------------+ | | No v [ FAILED ] Figure 1: Task Lifecycle The states are: PENDING: A Task Resource exists, but execution has not started. ACTIVE: The operation is executing. COMPLETED: The operation completed successfully. FAILED: Execution terminated without successful completion. ABORTED: Execution was canceled before completion. REJECTED: The Task Resource was created and remained PENDING, but a dynamic admission decision made before execution determined that the operation could not be started under the current runtime conditions. Examples include insufficient currently available processing capacity, memory, storage, energy, execution slots, or excessive device load. REJECTED MUST NOT be used for an unsupported task type, malformed payload, unsupported execution control, authorization failure, or failure of a profile-specific Li & Cui Expires 23 January 2027 [Page 5] Internet-Draft CoAP Task Resources July 2026 security or safety requirement. Such failures are detected before Task Resource creation, reported using an appropriate 4.xx response, and do not produce REJECTED. A resource or load failure that occurs after the task becomes ACTIVE produces FAILED rather than REJECTED. An Executor SHOULD keep a terminal Task Resource available long enough for the Task Initiator to retrieve its final state. Retention time is deployment specific. Where possible, the Executor SHOULD indicate how long the Task Resource is expected to remain available. The applicable application profile defines how this indication is conveyed; this document does not define a retention Option or a new retention field. After the retention period expires, the Executor MAY remove the Task Resource. Subsequent requests to the removed URI SHOULD receive 4.04 (Not Found). 5. Task Request Payload 5.1. Content-Format A Task Request MUST include the CoAP Content-Format Option with value 62, identifying application/multipart-core as defined by [RFC8710]. This document does not define or register a new Content-Format. The payload contains exactly two multipart-core parts. The first part carries the Resource representation, and the second part carries the Task representation. Because each multipart-core part consists of a Content-Format identifier followed by a byte string or null, the complete Task Request is encoded as a four-element CBOR array. An Executor that does not support Content-Format 62 for Task Requests MUST respond with 4.15 (Unsupported Content-Format). 5.2. Four-Part Payload A Task Request contains four ordered logical parts: Li & Cui Expires 23 January 2027 [Page 6] Internet-Draft CoAP Task Resources July 2026 +======+================+==========================================+ | Part | Name | Content | +======+================+==========================================+ | 1 | Resource | The registered CoAP Content-Format | | | Content-Format | identifier for Part 2 | +------+----------------+------------------------------------------+ | 2 | Resource | A byte string containing resources and | | | representation | values to be operated on | +------+----------------+------------------------------------------+ | 3 | Task Content- | The registered CoAP Content-Format | | | Format | identifier for Part 4 | +------+----------------+------------------------------------------+ | 4 | Task | A byte string containing task controls, | | | representation | or null when no Task content is supplied | +------+----------------+------------------------------------------+ Table 1 The parts have the following semantics: 1. The first element is the registered CoAP Content-Format identifier of the Resource representation carried in the second element. An application profile selects this value. For example, the value is 60 when the Resource representation uses application/cbor. 2. The second element is a non-empty CBOR byte string containing exactly one Resource representation encoded according to the first element. 3. The third element is the registered CoAP Content-Format identifier of the Task representation carried in the fourth element. This document uses 60 (application/cbor) for the Task- Content map defined below. 4. The fourth element is a CBOR byte string containing exactly one Task-Content map encoded using application/cbor. It MAY be null when the request carries no execution mode or profile-specific task parameters. The values in the first and third elements identify the embedded representations; they are not format-version numbers. In particular, the outer value 62 MUST NOT be repeated in either position unless the corresponding embedded representation is itself another application/ multipart-core representation. Li & Cui Expires 23 January 2027 [Page 7] Internet-Draft CoAP Task Resources July 2026 5.3. Encoding The complete Task Request has the following CDDL structure, using the multipart-core rules from [RFC8710]: Task-Request = [ resource-content-format: content-format, resource-representation: bstr, task-content-format: 60, task-representation: bstr / null ] content-format = 0..65535 Task-Content = { ? 1 => execution-mode, ? 2 => profile-parameters } execution-mode = atomic / sequential atomic = 1 sequential = 2 profile-parameters = { * int => any } The byte string in resource-representation MUST be interpreted according to resource-content-format and the applicable application profile. The byte string in task-representation, when present, MUST contain exactly one well-formed CBOR data item matching Task-Content; no bytes may remain after that item is decoded. The outer multipart-core array, the Task-Content map, and CBOR Resource representations defined by an application profile SHOULD use the deterministic encoding requirements in Section 4.2.1 of [RFC8949]. Indefinite-length items MUST NOT be used in the outer array or Task-Content map. A receiver MUST reject the complete Task Request with 4.00 (Bad Request) if: * the outer array does not contain exactly four elements; * the first or third element is not an unsigned integer; * the Resource representation is absent, null, or empty; * the fourth element is neither a byte string nor null; Li & Cui Expires 23 January 2027 [Page 8] Internet-Draft CoAP Task Resources July 2026 * the third element is not 60 when the fourth element is a byte string; or * an embedded representation is malformed according to its Content- Format. The Executor MUST NOT apply any Resource Operation from a malformed Task Request. If Content-Format 62 is supported but an embedded Content-Format is not supported for the applicable profile, the Executor MUST respond with 4.15 (Unsupported Content-Format). 5.4. Resource Operations The Resource content part identifies target resources and the content to be applied to them. Every target MUST be within the authorization scope of the request. An application profile MUST define how resources are identified, how operation order is represented, and which value types and operations are permitted. The representation is profile-defined because firmware management, diagnostics, commissioning, and actuation differ. A profile SHOULD reuse an existing resource representation where possible and MUST specify how its contents are applied. 5.5. Task Execution Controls The Task content part can carry these execution modes: atomic (1): The Resource Operations form one atomic unit. The Executor MUST either apply all operations successfully or leave all targets unchanged. An Executor that does not support this guarantee for the requested task type or Resource Operations MUST reject the request with 4.22 (Unprocessable Entity) and MUST NOT create a Task Resource. An Executor that supports the guarantee but cannot admit the created task because of current runtime resource availability follows the dynamic admission procedure in Section 4 and transitions the Task Resource to REJECTED. sequential (2): The Executor applies Resource Operations in the order expressed by the Resource content part. The application profile defines whether execution stops after the first failed operation. Task-Status SHOULD include per-operation results when more than one operation was attempted. For more than one Resource Operation, Task content MUST state the requested execution mode unless equivalent semantics are defined by the application profile. For one operation, the mode MAY be omitted. Li & Cui Expires 23 January 2027 [Page 9] Internet-Draft CoAP Task Resources July 2026 Task controls are interpreted only by the Task Initiator and Executor. Intermediaries are not required to understand the representation. Profiles MAY instead define equivalent semantics through collection or interface behavior. 5.6. Example The following example uses multipart-core diagnostic notation. The Resource representation and Task representation both use Content- Format 60 (application/cbor). The example Resource representation h'A101F5' is a profile-defined CBOR map, while h'A10102' encodes the Task-Content map {1: 2}, requesting sequential execution. POST /operations Content-Format: 62 [ 60, h'A101F5', 60, h'A10102' ] The complete encoded payload for this example is: 84 18 3C 43 A1 01 F5 18 3C 43 A1 01 02 If the same request carries no Task content, the fourth element is null: [ 60, h'A101F5', 60, null ] 6. Task-Resource Mapping 6.1. Creation A Task Initiator submits a Task Request using POST to an operation- submission resource or task collection identified by the application profile. POST is used because processing the request creates a distinct Task Resource whose URI is returned by the Executor. This document does not use PATCH or iPATCH to submit a Task Request: those methods apply changes to the resource identified by the request URI, whereas Task Request submission creates a separate Task Resource. Li & Cui Expires 23 January 2027 [Page 10] Internet-Draft CoAP Task Resources July 2026 If the Executor accepts the operation for asynchronous processing, it MUST create a Task Resource and return 2.01 (Created). The response MUST include one or more Location-Path Options identifying the Task Resource. This specification does not use Location-Query to identify a Task Resource. Location is the sole protocol mechanism defined here for returning the Task Resource URI. A client MUST NOT depend on a separate task- link Option. Before returning 2.01 (Created), the Executor MUST complete pre- creation validation. This validation MUST include the Task Request structure and embedded representations, support for the requested task type and Resource Operations, support for the requested execution controls, authorization for every target, and all profile- specific security and safety requirements. If pre-creation validation fails, the Executor MUST return an appropriate 4.xx response and MUST NOT create a Task Resource. After creating the Task Resource and while it remains PENDING, the Executor MAY perform dynamic admission based on runtime conditions that can vary after creation. These conditions include currently available processing capacity, memory, storage, energy, execution slots, and device load. If dynamic admission determines that the operation cannot be started, the Executor MUST transition the Task Resource to REJECTED. The Executor MUST NOT use REJECTED for a condition that was required to be checked during pre-creation validation. 6.2. Methods on a Task Resource GET: Retrieves Task-Status or another selected representation. A Task Resource MAY be observable using CoAP Observe [RFC7641]. FETCH: Retrieves selected task-state information when supported by the profile. PATCH and iPATCH [RFC8132]: Update mutable task parameters when permitted by the profile. An update MUST NOT change the identity of the represented operation. DELETE: Requests removal of the Task Resource, consistently with [RFC7252]. The Executor MUST NOT interpret DELETE as a cancellation request. If deletion is permitted and succeeds, the Executor SHOULD return 2.02 (Deleted), and the Task Resource URI is no longer available. An Executor SHOULD reject deletion of a PENDING or ACTIVE task with 4.09 (Conflict) unless an application profile explicitly permits removal while execution continues. Li & Cui Expires 23 January 2027 [Page 11] Internet-Draft CoAP Task Resources July 2026 An Executor MAY remove a terminal Task Resource automatically after its retention period. Explicit DELETE and automatic retention expiry have the same resource-removal semantics. 6.3. Cancellation Resource An Executor that supports cancellation MUST expose a cancellation resource associated with each cancellable Task Resource. The cancellation resource is identified by appending the single path segment cancel to the Task Resource URI. For example, if the Task Resource URI is /tasks/89, the cancellation resource URI is /tasks/89/cancel. {Task-Resource-URI}/cancel The Task Initiator requests cancellation by sending POST to this resource. If cancellation is not supported for the Task Resource, the Executor MUST return 4.04 (Not Found) or 4.05 (Method Not Allowed), as applicable. If the task is PENDING or ACTIVE and cancellation succeeds, the Executor SHOULD return 2.04 (Changed) and transition the Task Resource to ABORTED. The Task Resource remains available during its retention period so clients can retrieve the terminal state. If the task is already terminal, the Executor SHOULD return 4.09 (Conflict), unless the application profile defines cancellation as idempotent and permits a success response. Refusal to cancel because stopping the underlying operation would be unsafe SHOULD also use an appropriate error response and MUST NOT change the current task state. 7. Task Status Subresources An Executor MAY expose subordinate resources identified by appending the corresponding path segment to the Task Resource URI: {Task-Resource-URI}/state {Task-Resource-URI}/progress {Task-Resource-URI}/eta For example, if the Task Resource URI is /tasks/89, the state subresource URI is /tasks/89/state. /state contains the numeric state value defined in Section 10. /progress contains an unsigned integer from 0 to 100. /eta contains estimated seconds to completion. Li & Cui Expires 23 January 2027 [Page 12] Internet-Draft CoAP Task Resources July 2026 Successful responses from /state, /progress, and /eta MUST include Content-Format 60 (application/cbor). Each response payload MUST contain exactly one CBOR unsigned integer. For /state, the integer is one of the state values defined in Section 10. For /progress, it is in the range 0 to 100. For /eta, it is the estimated number of seconds to completion. A client MUST determine terminal status using /state or the state field of a Task-Status representation. Progress is informational. FAILED, ABORTED, and REJECTED are not required to report progress 100. 8. Conditional Observation Task-state and task-progress resources MAY support Conditional Query Parameters defined by [I-D.ietf-core-conditional-attributes]. This reduces Observe traffic without defining task-specific query parameters. For example: GET /tasks/89/progress?c.st=20&c.pmin=5&c.pmax=60 Observe: 0 A client needing every transition SHOULD observe /state without a step condition. Conditional reporting MUST NOT make terminal state permanently unavailable. 9. Task Discovery Task Resources SHOULD be discoverable using CoRE Link Format [RFC6690] and its interface description mechanism. This document defines no new discovery protocol. ;if="core.task" A client can request Task Resources using: GET /.well-known/core?if=core.task Subject to authorization and privacy policy, retained terminal Task Resources SHOULD remain discoverable during retention. This permits a restarted client to recover outstanding or recently completed tasks. Executors MUST NOT expose task existence, target paths, status, or diagnostics to unauthorized clients through discovery. Li & Cui Expires 23 January 2027 [Page 13] Internet-Draft CoAP Task Resources July 2026 10. Task Status Payload Task-Status is encoded using CBOR [RFC8949] and described using CDDL [RFC8610]. A response carrying a Task-Status representation MUST include Content-Format 60 (application/cbor). Task-Status = { 1 => task-state, ; task state ? 2 => progress, ; progress percentage ? 3 => uint, ; estimated seconds to completion ? 4 => tstr, ; diagnostic text ? 5 => [ + Sub-Result ] ; per-resource-operation result } task-state = 0..5 progress = 0..100 coap-response-code = 0..255 Sub-Result = { 1 => tstr, ; target resource path 2 => coap-response-code ; CoAP response code } The state values are: +=======+===========+ | Value | State | +=======+===========+ | 0 | PENDING | +-------+-----------+ | 1 | ACTIVE | +-------+-----------+ | 2 | COMPLETED | +-------+-----------+ | 3 | FAILED | +-------+-----------+ | 4 | ABORTED | +-------+-----------+ | 5 | REJECTED | +-------+-----------+ Table 2 The compound representation is used when a client needs complete state in one response. Task Status Subresources SHOULD return only the corresponding individual task-status value. A client MUST determine terminal status from state, not progress. Li & Cui Expires 23 January 2027 [Page 14] Internet-Draft CoAP Task Resources July 2026 A Task-Status representation containing a state or progress value outside the ranges defined above is malformed. The response code in a Sub-Result is the 8-bit CoAP Code value. An Executor MUST NOT generate an unassigned or reserved CoAP response code in a Sub- Result. 11. Workflow The scalar state payloads in the following exchanges are shown in CBOR diagnostic notation. Responses carrying these payloads use Content-Format 60 (application/cbor). Task Initiator Executor | | | POST /operations | | Content-Format: 62 | | Payload: four-part Task Request | | 1=Resource CF; 2=Resource bytes; | | 3=Task CF; 4=Task bytes | |---------------------------------------->| | | | 2.01 Created | | Location-Path: "tasks" | | Location-Path: "89" | |<----------------------------------------| | | | GET /tasks/89/state | | Observe: 0 | |---------------------------------------->| | | | 2.05 Content | | Content-Format: 60 | | Payload: 1 (ACTIVE) | |<----------------------------------------| | | | 2.05 Content | | Content-Format: 60 | | Payload: 2 (COMPLETED) | |<----------------------------------------| Failure, cancellation, or rejection produces FAILED, ABORTED, or REJECTED rather than relying on progress reaching 100. Cancellation, when needed, uses a separate interaction: Li & Cui Expires 23 January 2027 [Page 15] Internet-Draft CoAP Task Resources July 2026 Task Initiator Executor | | | POST /tasks/89/cancel | |---------------------------------------->| | | | 2.04 Changed | |<----------------------------------------| | | | GET /tasks/89/state | |---------------------------------------->| | | | 2.05 Content | | Content-Format: 60 | | Payload: 4 (ABORTED) | |<----------------------------------------| 12. Error Handling The Executor MUST reject a request before creating a Task Resource when: * the Task Request structure or an embedded representation is malformed; * the requested task type, Resource Operation, or execution control is not supported; * a target or operation is not allowed; * authorization for any target fails; * a profile-specific security or safety requirement is not satisfied. 4.15 (Unsupported Content-Format) is used when the media type is unsupported. 4.00 (Bad Request) is used when the multipart-core structure or an embedded representation is malformed. 4.22 (Unprocessable Entity) is used when a syntactically valid request asks for semantics that the Executor cannot provide, including an unsupported execution guarantee. Authorization errors use the code required by the security profile. Insufficient runtime resources or excessive device load discovered during dynamic admission after Task Resource creation are reported using REJECTED. Once a task becomes ACTIVE, inability to continue execution is reported using FAILED and optional diagnostics and Sub-Result fields. Li & Cui Expires 23 January 2027 [Page 16] Internet-Draft CoAP Task Resources July 2026 13. Security Considerations Task Requests can change multiple resources and initiate long-running physical or administrative operations. The Executor MUST authorize the complete request, including every target and requested execution control, before creating a Task Resource. Atomic execution can require buffering, rollback state, or durable storage. The Executor MUST reject atomic mode unless it can preserve all-or-nothing behavior across relevant failures. Profiles SHOULD define whether this includes power loss and reboot. Attackers can create expensive tasks to exhaust processing, storage, bandwidth, or energy. Executors SHOULD apply admission control, authorization, quotas, request-size limits, task-count limits, and retention limits. Discovery and Task-Status can expose operational history, target paths, and diagnostics. Access MUST be protected according to application policy. Task Requests remain end-to-end application data. A proxy can recognize Content-Format 62 as application/multipart-core without understanding the application semantics of the two embedded representations. Such a proxy is not expected to inspect Task- Content or enforce execution controls. Deployments requiring confidentiality or integrity across intermediaries SHOULD use an appropriate end-to-end security mechanism. Cancellation can be safety-sensitive. The Executor MUST authorize POST to the cancellation resource and MAY reject it when stopping the underlying operation would be unsafe. DELETE authorization is separate and controls removal of the Task Resource, not cancellation of the underlying operation. 14. IANA Considerations 14.1. Task Request Content-Format This document uses the existing application/multipart-core CoAP Content-Format (ID 62) registered by [RFC8710]. It requests no new media type or CoAP Content-Format identifier. 14.2. Interface Description Registration IANA is requested to register: Value: core.task Li & Cui Expires 23 January 2027 [Page 17] Internet-Draft CoAP Task Resources July 2026 Description: CoAP Task Resource for an asynchronous or long-running operation. Reference: This document. 15. Implementation Considerations An Executor can persist Task Resource state independently from the execution engine. Persisting state, request identity, and final result allows recovery after reboot and reduces duplicate work after application retries. Profiles should define limits on Resource Operations, request size, execution modes, mutable task fields, and retention. They should also define how a client correlates a retry with an existing task when duplication is unsafe. 16. Changes from draft-li-coap-task-resources-00 * Removed the Batch-Control and Progress-Link CoAP Options. * Made Location the sole mechanism for returning the Task Resource URI. * Added a four-part Task Request payload identified using Content- Format. * Encoded the four elements using the existing application/ multipart-core Content-Format (ID 62), with one Resource representation and one Task representation. * Moved atomic and sequential controls into Task content. * Updated examples, error handling, proxy behavior, and security text. * Separated cancellation from deletion: POST to the cancel subresource of a Task Resource requests cancellation, while DELETE removes the Task Resource. * Distinguished pre-creation validation from post-creation dynamic admission and clarified the use of REJECTED. * Constrained Task-Status state, progress, and CoAP response-code values in CDDL. 17. Normative References Li & Cui Expires 23 January 2027 [Page 18] Internet-Draft CoAP Task Resources July 2026 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, . [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, . [RFC7641] Hartke, K., "Observing Resources in the Constrained Application Protocol (CoAP)", RFC 7641, DOI 10.17487/RFC7641, September 2015, . [RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and FETCH Methods for the Constrained Application Protocol (CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, . [RFC8710] Fossati, T., Hartke, K., and C. Bormann, "Multipart Content-Format for the Constrained Application Protocol (CoAP)", RFC 8710, DOI 10.17487/RFC8710, February 2020, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, . Li & Cui Expires 23 January 2027 [Page 19] Internet-Draft CoAP Task Resources July 2026 [I-D.ietf-core-conditional-attributes] Silverajan, B., Koster, M., and A. Soloway, "Conditional Query Parameters for CoAP Observe", Work in Progress, Internet-Draft, draft-ietf-core-conditional-attributes-13, 6 July 2026, . Appendix A. Acknowledgments The authors thank CoRE Working Group participants who reviewed earlier versions and encouraged the document to focus on the reusable task lifecycle, reuse existing discovery and observation mechanisms, and avoid unnecessary CoAP Options. Authors' Addresses Linzhe Li Zhongguancun Laboratory Beijing 100094 China Email: lilz@zgclab.edu.cn Yong Cui Tsinghua University Beijing, 100084 China Email: cuiyong@tsinghua.edu.cn URI: http://www.cuiyong.net/ Li & Cui Expires 23 January 2027 [Page 20]