[httpapi] Re: httpapi - New Meeting Session Request for IETF 127
Jaime Jiménez <jaime@iki.fi> Wed, 30 September 2026 15:31 UTC
Received: from fhigh-a4-smtp.messagingengine.com (fhigh-a4-smtp.messagingengine.com [103.168.172.155]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by mx.ietf.org (Postfix) with ESMTPS id A551A46; Wed, 30 Sep 2026 15:31:28 +0000 (UTC)
Authentication-Results: mx.ietf.org; dkim=pass header.d=messagingengine.com header.s=fm1 header.b="Y q7YHJz"; dmarc=none; spf=neutral (mx.ietf.org: 103.168.172.155 is neither permitted nor denied by domain of jaime@iki.fi) smtp.mailfrom=jaime@iki.fi
Received: from ams-compute-02.internal (ams-compute-02.internal [10.64.2.62]) by mailfhigh.phl.internal (Postfix) with ESMTP id 96F5B140023E; Wed, 30 Sep 2026 11:31:21 -0400 (EDT)
Received: from ams-imap-09 ([10.64.2.29]) by ams-compute-02.internal (MEProxy); Wed, 30 Sep 2026 11:31:21 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1790782281; x= 1790868681; bh=fpsmJ8R3XQJWV0PFoipbNQ9TFb0hb2KHoISLOrfLQ4M=; b=Y q7YHJzya3itIPmjubOnJP+UZwT5lM7KswP+VRHpMqyRKkGRdIInSWscvEXCXYy04 CNaIKYZb9PsCIvALr7nhhSIPf5GyuidX2BL9NtzZZvgXhxUoGvhTT705BM09GD44 JDoCcZQMgMISz36gZGifQWs8Rq2QoiqTwnpLakhaowVkp5XRu7JSGNeUslg3fyE3 RPn3AhHk7XyX3uN5CDr214Qti4V5cH/X+hZ931PsegxmhcZ8FxXHYE24g/xD2cqD ZxDHmtFLsnd5mwMn+zihZnTqXdvco/MfLSYF/mV4Oru1bItFiIEmCYusNUr2+e83 TLo+wRWqiG/Z/qgqExjNg==
X-ME-Sender: <xms:Ryu9as_uijbSzaWZMo894uDziTIQABnYiV8xpZ7b6peZdC7MrB_8zQ> <xme:Ryu9avh7GJDVXqbmXuuP1upaJxGVRbvlaN7389EJZFHAzpUh1P7LrlVA3jzqDo-gd qYV2eGCaeuBhsx8zXKdOBKJns8eR_4TDUhQbiN-_-ajl2q1VP9P>
X-ME-Proxy-Cause: dmFkZTGzUNJslnvV74tCQsyhacVwN2khiCHDgcJxoQ47j0+kljbZ9KFmv2sNZ33X8yikU4 Mkvyv6AR61aS+mXFga3dAS30lUYjXYKco+vO78LUTHPNGmhC8vIsIjQlQildmAMGVANpai kEchbOlOL/JIwly3WPmm+nDLDJ9gKNvjB4jL7v0buTtkeLPdVgDPL5praVk42ho0PHReMN bTrj3BUsIflmXtAy5jQGEYhZmb5TSemxchMtXcVIOoKuZ21tz3JPz6SBOFWn4JIHsHbvyu EUA6EO/wDB0jZiMLqzB0XjA7u6Prj28pq+I9yFpBBoiFNiEukSAFKyUElA1KhZcRsVNPaX HLE2nyg/QpZMAEeHKwOP2UQc6J7gwrjN4yu5HfQdyd/nU9nLj7VSLZuNai3/6aUz5rgF7R MKgG6Ew9xFEegXdxBbsrex7YoUSLxis+xgH1GC0vMoBosNUj7POKBNci9YJkcHDrRV6KB2 Bn63ZNa1gfRu5U8t8ieGk0cTyQfwvEv/7xon8Yvhl5Tc/iAwT3i2VRu0zLZoF0nCYf+/Un vK9mYSD1WEkldM3XUxZRO5N4ToMB/OaYZ9K2RblTmvdLOG7G+CQM57T7MMY4tpfW8A6mfI W+eow+8+ttQ3gbrz9tN9A8lt+UJrNBPfrdNi4WFoiPFz6y3t8GqHrJmb+qFw
X-ME-Proxy: <xmx:SCu9aoe71pkUIPKMC_P2Yd96DO43eTnlV-WnZnsKhmVCmeAeLlMXrA> <xmx:SCu9ahoaLxHZZ8NfaTQum-g-DyD2QXHCY3tZ1gcBQ6jsvHT-mCH8Xg> <xmx:SCu9am6B93KDcT6DyD3XL_RA-kQrRg_OZ-l24lLOnZvZIy10bOy_ug> <xmx:SCu9anpz3e-APUvMllrBtWxRDRfqgPx0P9lWEMvwR4lDZ4n-qUh4HA> <xmx:SSu9aml2AkqbgN3fsd56JEvQDZ0zch-REI3UMVmajP0Zqb65l4rU5klZ>
Feedback-ID: iabf94414:Fastmail
Received: by mailuser.ams.internal (Postfix, from userid 501) id 81868180088; Wed, 30 Sep 2026 11:31:19 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
MIME-Version: 1.0
X-ThreadId: ABCMBH4DzHmB
Date: Wed, 30 Sep 2026 18:30:58 +0300
From: Jaime Jiménez <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
X-Spamd-Bar: /
Message-ID-Hash: 6NK2AY27PXDHRDL4L6AFFNXJAH5VKSHN
X-Message-ID-Hash: 6NK2AY27PXDHRDL4L6AFFNXJAH5VKSHN
X-MailFrom: jaime@iki.fi
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: cxres@protonmail.com
X-Mailman-Version: 3.3.10
Precedence: list
Subject: [httpapi] Re: httpapi - New Meeting Session Request for IETF 127
List-Id: Building Blocks for HTTP APIs <httpapi.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/httpapi/APZhxkqbmd6vvZkvL-lEu7uVflQ>
List-Archive: <https://mailarchive.ietf.org/arch/browse/httpapi>
List-Help: <mailto:httpapi-request@ietf.org?subject=help>
List-Owner: <mailto:httpapi-owner@ietf.org>
List-Post: <mailto:httpapi@ietf.org>
List-Subscribe: <mailto:httpapi-join@ietf.org>
List-Unsubscribe: <mailto:httpapi-leave@ietf.org>
Hi chairs and Wg, In relation to signs of interest in draft-gupta-httpapi-events-query before IETF 127. I am using the draft in this API sandbox https://camara.jaime.win, as described in section 11.2 of the draft. We worked on it during the Vienna hackathon. My implementaiton now covers QUERY on the resource itself with Accept-Query discovery (section 7) on five resources, the three response modes (single notification in section 8, notifications stream in section 9, representation plus stream in section 10), negotiation of the carrier from Accept (multipart/mixed, application/json-seq, application/x-ndjson) and of the notification format from the events member of the subscription (section 6), and the Events header field (section 5). Rahul wrote a confomance client against it (https://github.com/CxRes/CAMARA-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 alive, for me that was not an issue but maybe there could be more guidance about that in the draft. My use case is mainly for AI Agents that need a lightweight observe mechanism on an async resource but that don't want to configure a public https callback uri, and want to use a simpler short-term observation mechanism. We had the same problem in RESTful IoT many years ago. CoAP now has Observe (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 changes. So: I support adopting Events Query as a WG document. IMO it would be good to have it on the IETF 127 agenda and get more feedback and discussion from the group. Ciao! Jaime Jiménez
- [httpapi] httpapi - New Meeting Session Request f… IETF Meeting Session Request Tool
- [httpapi] Re: httpapi - New Meeting Session Reque… Salz, Rich
- [httpapi] Re: httpapi - New Meeting Session Reque… Jaime Jiménez
- [httpapi] Re: httpapi - New Meeting Session Reque… Rahul Gupta