Feedback-ID: iabf94414:Fastmail
MIME-Version: 1.0
Date: Wed, 30 Sep 2026 18:30:58 +0300
From: =?UTF-8?Q?Jaime_Jim=C3=A9nez?= <jaime@iki.fi>
To: httpapi@ietf.org, httpapi-chairs@ietf.org
Message-Id: <f1b361d7-6077-46da-95f8-0da66286c899@slotai09m18>
In-Reply-To: 
 <MN2PR17MB4031D2E48E164C9129E1BAA2CD802@MN2PR17MB4031.namprd17.prod.outlook.com>
References: 
 <179036072519.94541.143857445720578489@dt-datatracker-57df95fc99-fzjcz>
 <MN2PR17MB4031D2E48E164C9129E1BAA2CD802@MN2PR17MB4031.namprd17.prod.outlook.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: 6NK2AY27PXDHRDL4L6AFFNXJAH5VKSHN
CC: cxres@protonmail.com
Precedence: list
Subject: [httpapi] Re: httpapi - New Meeting Session Request for IETF 127
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/httpapi/APZhxkqbmd6vvZkvL-lEu7uVflQ>

Hi chairs and Wg,

In relation to signs of interest in draft-gupta-httpapi-events-query bef=
ore IETF 127.

I am using the draft in this API sandbox https://camara.jaime.win, as de=
scribed in section 11.2 of the draft. We worked on it during the Vienna =
hackathon. My implementaiton now covers QUERY on the resource itself wit=
h Accept-Query discovery (section 7) on five resources, the three respon=
se modes (single notification in section 8, notifications stream in sect=
ion 9, representation plus stream in section 10), negotiation of the car=
rier from Accept (multipart/mixed, application/json-seq, application/x-n=
djson) and of the notification format from the events member of the subs=
cription (section 6), and the Events header field (section 5).

Rahul wrote a confomance client against it (https://github.com/CxRes/CAM=
ARA-events-query-client). If you use Agents you can try it, details are =
in https://camara.jaime.win/SKILL.md., logs are at https://camara.jaime.=
win/eqp-log. Details are in https://camara.jaime.win/SKILL.md.

I saw another thread here about the bounded duration as the only keep al=
ive, for me that was not an issue but maybe there could be more guidance=
 about that in the draft.=20

My use case is mainly for AI Agents that need a lightweight observe mech=
anism on an async resource but that don't want to configure a public htt=
ps callback uri, and want to use a simpler short-term observation mechan=
ism.=20

We had the same problem in RESTful IoT many years ago. CoAP now has Obse=
rve (RFC 7641) option for those in-band notifications, I was looking for=
 the equivalent over HTTP, which -to my limited HTTP knowledge- httpapi-=
events-query seems to be the closest thing. Since the client is already =
authorized to access a resource, Events Query gives them also a uniform =
way to ask that resource for its current state and subsequent state chan=
ges.

So: I support adopting Events Query as a WG document. IMO it would be go=
od to have it on the IETF 127 agenda and get more feedback and discussio=
n from the group.

Ciao!
Jaime Jim=C3=A9nez