Subject: [core] Re: Request comments on draft-li-coap-task-resources-00
From: Esko Dijk <[email-masked]>
To: Linzhe Li <lilz=[email-masked]>, [email-masked]
Date: Thu, 23 Jul 2026 15:59:41 +0200
List-Id: "Constrained RESTful Environments (CoRE) Working Group list" <core.ietf.org>

Hi Linzhe,

I did see some similarity between the task lifecycle and PubSub. See: 
https://datatracker.ietf.org/doc/html/draft-ietf-core-coap-pubsub-21#name-topic-lifecycle

Although it's different, maybe good to check this for a comparison.

Overall a "task" could be a useful abstraction for RESTful systems 
(CoAP, also HTTP maybe).

best regards

Esko

On 7/3/26 05:36, Linzhe Li wrote:
>
> Hi ALL，
>
> We have prepared an individual draft that standardizes the abstraction 
> of asynchronous operations as CoAP task resources. Draft details are 
> as follows:
>
> CoAP Extensions for Asynchronous Task Resources
>
> draft-li-coap-task-resources-00
>
>
>     *Motivation：*Many CoAP deployments involve long-running operations
>     unfit for one request-response round trip, such as firmware
>     upgrade, diagnostics and automation tasks.
>
> Today these tasks are handled via proprietary methods: custom task 
> URIs in payloads, repeated resource polling, vendor-defined Observe 
> payloads or profile-specific state machines.
>
> These schemes only work within one profile, blocking 
> cross-device/cross-profile interoperability for standard CoAP clients, 
> gateways and management systems.
>
>
>     *Lightweight CoAP Task Resource Interaction Pattern Proposed in
>     the Draft:*
>
>      o
>
>         ●Upon receiving a request for an asynchronous operation, the
>         server creates a temporary task resource.
>
>      o
>
>         ●The response carries a link pointing to the task resource,
>         which can reuse Location-family options, optionally alongside
>         a dedicated Progress-Link option.
>
>      o
>
>         ●Clients may retrieve the task resource via GET or subscribe
>         to it via Observe to continuously monitor task status.
>
>      o
>
>         ●Where permitted by the upper-layer application profile,
>         clients can modify task configurations using PATCH/iPATCH or
>         cancel the task via DELETE.
>
>      o
>
>         ●Task status is described in a unified CBOR binary format with
>         standardized states: pending, active, completed, failed,
>         aborted, and rejected.
>
>      o
>
>         ●Subresources reporting numeric task states and progress
>         values can directly reuse the conditional query parameters
>         already defined for the CoAP Observe mechanism.
>
>
> This draft omits device capability/operation semantic models and new 
> Observe filter options, focusing on CoAP resource patterns while 
> maximizing reuse of existing mechanisms.
>
> We welcome feedback from the Working Group on whether this 
> standardization topic falls within the scope of CoRE’s charter, and 
> how this specification can best align with existing CoRE deliverables.
>
>
> All comments and improvement suggestions are highly appreciated.
>
>
> Best regards,
>
> Linzhe
>
> Beijing ZGC Lab
>
>
> _______________________________________________
> core mailing list [email-masked]
> To unsubscribe send an email [email-masked]
-- 
*IoTconsultancy.nl* | Email/Teams: [email-masked] | +31 6 
2385 8339