CoAP Extensions for Asynchronous Task Resources
draft-li-coap-task-resources-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Linzhe Li , Yong Cui | ||
| Last updated | 2026-07-21 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-li-coap-task-resources-01
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.
</tasks/89>;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,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
<https://www.rfc-editor.org/rfc/rfc6690>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/rfc/rfc7252>.
[RFC7641] Hartke, K., "Observing Resources in the Constrained
Application Protocol (CoAP)", RFC 7641,
DOI 10.17487/RFC7641, September 2015,
<https://www.rfc-editor.org/rfc/rfc7641>.
[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,
<https://www.rfc-editor.org/rfc/rfc8132>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[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, <https://www.rfc-editor.org/rfc/rfc8610>.
[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,
<https://www.rfc-editor.org/rfc/rfc8710>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/rfc/rfc8949>.
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, <https://datatracker.ietf.org/doc/html/draft-
ietf-core-conditional-attributes-13>.
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]