Return-Path: X-Original-To: core@mail2.ietf.org Delivered-To: core@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 2E9C411D76AB1 for ; Thu, 23 Jul 2026 06:59:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1784815192; bh=SZLM2El/TFF6QoelOQ86WEE9ORPemvW+09iDnTYuabQ=; h=Date:Subject:To:References:From:In-Reply-To; b=Issa5knxALQvh3Z8kFe6n6H5yKyhpMDHAQPpG4S4XVuE6ecr7rD3DCznf7mu9ka2o kyYmu6VK865UNWTdTg+OGCaI4b2A8ktdLgiJMXbxQdk0FFsYbtO/AlGGF0NK7kB9TL tzc9cOK05MiIE3XNgIh9ti9o97jm2f8paWbSDn1A= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=iotconsultancy.nl Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gw44L-GGbwh3 for ; Thu, 23 Jul 2026 06:59:51 -0700 (PDT) Received: from dane.soverin.net (dane.soverin.net [IPv6:2a10:de80:1:4091:b9e9:2227:0:1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id EDE0B11D7698D for ; Thu, 23 Jul 2026 06:59:46 -0700 (PDT) Received: from smtp.soverin.net (unknown [10.10.4.99]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dane.soverin.net (Postfix) with ESMTPS id 4h5Xmx4cpfzryj; Thu, 23 Jul 2026 13:59:45 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [10.10.4.99]) by soverin.net (Postfix) with ESMTPSA id 4h5Xmx1fhRzFB; Thu, 23 Jul 2026 13:59:45 +0000 (UTC) Authentication-Results: smtp.soverin.net; dkim=pass (2048-bit key; unprotected) header.d=iotconsultancy.nl header.i=@iotconsultancy.nl header.a=rsa-sha256 header.s=soverin1 header.b=xhYZJqAO; dkim-atps=neutral DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotconsultancy.nl; s=soverin1; t=1784815185; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=BuL4gtZILzeT66frYkrRU3B57oKn9f6voEWOOhTMs/M=; b=xhYZJqAOzDI4GIY6y0abUI/MZZb1RbCRFPXfYwnqQGNLE2z5XfEttU8mP2feD6Usm8KxQq UiNCM941PWi3MlJub274eQ1ikV4fgNMEWo7q0qdV8EwFJuGY4pgS+xuhUX6/8o5HYgjuxd DX6xIk2i1NkDylipQ15/WCyJZbEUN+I10/0h42jGxmEBMUHGh2xDOzcHWLGhhBiAjOhtk3 iVL3Lt9uOqkzym2hDOXzmqbwETgsxRTBPUfJ8YnTMcYiS2JzhrmVC/0qDageC2XwEKxo7/ iUGa0UaZV/DqVFCrmptNUnAoCCNsWgAopO+WNpH0zFIq/mOcMr3Nt1qtb3tL/w== X-CM-Envelope: MS4xfN16XeixQCgQLOn+Quw2jZC+hLB/PLfmfMHSAV2pwWg+w9YUgnZgLKhEwhVEW/Q9MK+TK0skhneLQYIGPGxpk9grMDmiCa/bEwiH6/JhOWkZHcNjsZHj pduAdJeqyrOO4BqgrUrS7LtcC+1cLbszNrXT2V5XW/Ln9dffcBKZj+e3Vcf8SLiAlUijVh6JzvQSG9dHlOghJZHqO3snlISVqjFJ5GB1gYS6+5WUTa0qSWdB JRhJQjcN5aG3da8OafvUy1qx+i6Z1t2EHE9J6yeKGnHrLP9hY/r7/y8fxGupPOm0hbsLcQJP8ydUbUieZQ683nA6rQBB6Kue7+LuqejLtE5UiMax4IW0+2ff M1HpxUpi X-Soverin-Id: 019f8f46-6c68-7cbf-a497-34fccb909f99 Content-Type: multipart/alternative; boundary="------------Z2MfPhDgnjmgus5urjcNzoMs" Message-ID: <53ec69d3-76cf-4b5c-8955-6c5c509b6cc0@iotconsultancy.nl> Date: Thu, 23 Jul 2026 15:59:41 +0200 MIME-Version: 1.0 To: Linzhe Li , core@ietf.org References: <60853342.8e7e5.19f260c68c1.Coremail.lilz@zgclab.edu.cn> Content-Language: en-US From: Esko Dijk Organization: IoTconsultancy.nl In-Reply-To: <60853342.8e7e5.19f260c68c1.Coremail.lilz@zgclab.edu.cn> X-Spampanel-Class: ham Message-ID-Hash: 2NZ3VBX642RRPGCBLQVUMAO2L3GXIP4X X-Message-ID-Hash: 2NZ3VBX642RRPGCBLQVUMAO2L3GXIP4X X-MailFrom: esko.dijk@iotconsultancy.nl X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-core.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5Bcore=5D_Re=3A_Request_comments_on_draft-li-coap-task-resources-?= =?utf-8?q?00?= List-Id: "Constrained RESTful Environments (CoRE) Working Group list" Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. --------------Z2MfPhDgnjmgus5urjcNzoMs Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 --core@ietf.org > To unsubscribe send an email tocore-leave@ietf.org -- *IoTconsultancy.nl* | Email/Teams: esko.dijk@iotconsultancy.nl | +31 6 2385 8339 --------------Z2MfPhDgnjmgus5urjcNzoMs Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

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:

    • ●Upon receiving a request for an asynchronous operation, the server creates a temporary task resource.

    • ●The response carries a link pointing to the task resource, which can reuse Location-family options, optionally alongside a dedicated Progress-Link option.

    • ●Clients may retrieve the task resource via GET or subscribe to it via Observe to continuously monitor task status.

    • ●Where permitted by the upper-layer application profile, clients can modify task configurations using PATCH/iPATCH or cancel the task via DELETE.

    • ●Task status is described in a unified CBOR binary format with standardized states: pending, active, completed, failed, aborted, and rejected.

    • ●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 -- core@ietf.org
To unsubscribe send an email to core-leave@ietf.org
--
IoTconsultancy.nl | Email/Teams: esko.dijk@iotconsultancy.nl | +31 6 2385 8339
--------------Z2MfPhDgnjmgus5urjcNzoMs--