[core] Re: Request comments on draft-li-coap-task-resources-00

[Esko Dijk <[e-mail]>]

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 [e-mail]
> To unsubscribe send an email [e-mail]
-- 
*IoTconsultancy.nl* | Email/Teams: [e-mail] | +31 6 
2385 8339