14:55:17 <RRSAgent> RRSAgent has joined #webmachinelearning
14:55:22 <RRSAgent> logging to https://www.w3.org/2026/03/19-webmachinelearning-irc
14:55:23 <Zakim> RRSAgent, make logs Public
14:55:24 <Zakim> please title this meeting ("meeting: ..."), anssik
14:55:24 <anssik> Meeting: WebML CG Teleconference – 19 March 2026
14:55:27 <anssik> Chair: Anssi
14:55:30 <anssik> Agenda: https://github.com/webmachinelearning/meetings/blob/main/telcons/2026-03-19-cg-agenda.md
14:55:34 <anssik> Scribe: Anssi
14:55:39 <anssik> ScribeNick: anssik
14:55:46 <anssik> Present+ Anssi_Kostiainen
15:00:27 <Winston> Winston has joined #webmachinelearning
15:01:01 <AlexN> AlexN has joined #webmachinelearning
15:01:16 <andruud> present+
15:01:26 <Mark_Foltz> Mark_Foltz has joined #webmachinelearning
15:01:26 <anssik> anssik has joined #webmachinelearning
15:01:26 <jyasskin> jyasskin has joined #webmachinelearning
15:01:26 <gregwhitworth> gregwhitworth has joined #webmachinelearning
15:01:26 <chrishtr> chrishtr has joined #webmachinelearning
15:01:26 <christianliebel> christianliebel has joined #webmachinelearning
15:01:26 <vmpstr> vmpstr has joined #webmachinelearning
15:01:26 <tomayac27> tomayac27 has joined #webmachinelearning
15:01:26 <vasilii> vasilii has joined #webmachinelearning
15:01:26 <awafaa> awafaa has joined #webmachinelearning
15:01:26 <anssik> RRSAgent, draft minutes
15:01:28 <RRSAgent> I have made the request to generate https://www.w3.org/2026/03/19-webmachinelearning-minutes.html anssik
15:01:35 <chris> chris has joined #webmachinelearning
15:01:42 <Sarony> Sarony has joined #webmachinelearning
15:01:42 <Winston> present+
15:01:48 <brwalder> brwalder has joined #webmachinelearning
15:01:56 <Jaewon> Jaewon has joined #webmachinelearning
15:02:04 <BenGreenstein> BenGreenstein has joined #webmachinelearning
15:02:48 <Mark_Foltz> Mark_Foltz has joined #webmachinelearning
15:02:48 <anssik> anssik has joined #webmachinelearning
15:02:48 <jyasskin> jyasskin has joined #webmachinelearning
15:02:48 <gregwhitworth> gregwhitworth has joined #webmachinelearning
15:02:48 <chrishtr> chrishtr has joined #webmachinelearning
15:02:48 <christianliebel> christianliebel has joined #webmachinelearning
15:02:48 <vmpstr> vmpstr has joined #webmachinelearning
15:02:48 <tomayac27> tomayac27 has joined #webmachinelearning
15:02:48 <vasilii> vasilii has joined #webmachinelearning
15:02:48 <awafaa> awafaa has joined #webmachinelearning
15:02:58 <anssik> ... as a reminder, we'll use IRC-based queue management in this meeting:
15:03:03 <anssik> -> https://www.w3.org/guide/meetings/zakim.html#speakerqueue
15:03:05 <anssik> q+
15:03:07 <victor> victor has joined #webmachinelearning
15:03:07 <anssik> ack anssik
15:03:14 <anssik> Anssi: to suggest agenda topics, use Agenda+ label
15:03:20 <anssik> -> Agenda+ https://github.com/webmachinelearning/webmcp/labels/Agenda+
15:03:37 <anssik> Topic: WebMCP
15:03:46 <anssik> Subtopic: Agentic AI Foundation coordination
15:03:50 <anssik> gb, this is webmachinelearning/charter
15:03:50 <gb> anssik, OK.
15:03:51 <domfarolino> domfarolino has joined #webmachinelearning
15:04:00 <anssik> Anssi: issue #14
15:04:01 <gb> https://github.com/webmachinelearning/charter/issues/14 -> Issue 14 Agentic AI Foundation coordination (by anssiko) [Agenda+]
15:04:34 <anssik> ... I had a discussion with W3C Legal counsel on how to formalize this coordination
15:04:45 <anssik> ... a summary is provided in the issue comment
15:04:45 <anssik> ... two key points:
15:04:52 <anssik> ... 1) technical alignment in the spec
15:05:09 <anssik> ... for technical alignment purposes, based on my discussion with W3C Legal, this Community Group can include things from the MCP spec into the WebMCP spec with attribution
15:05:22 <anssik> ... I will discuss with W3C Legal what is the most appropriate way to attribute MCP spec considering its ongoing license transition from the MIT License to Apache-2.0 License:
15:05:26 <anssik> -> https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/LICENSE
15:05:43 <anssik> Anssi: currently WebMCP spec references the MCP spec in its introduction section
15:06:07 <anssik> ... I believe the group wants to also reference the MCP spec in context of the WebMCP tool definition and explain the intent and expected scope of the tool definition reuse across the two
15:06:11 <anssik> -> WebMCP tool definition https://webmachinelearning.github.io/webmcp/#tool-definition
15:06:16 <anssik> -> MCP tool definition https://modelcontextprotocol.io/specification/latest/server/tools#tool
15:06:23 <anssik> Anssi: any questions about referencing the MCP spec from within the WebMCP spec?
15:06:42 <domfarolino> q+
15:06:45 <anssik> ack domfarolino
15:07:04 <anssik> Dominic: what are we trying to get out of this coordination?
15:07:16 <anssik> -> https://github.com/webmachinelearning/charter/issues/14#issuecomment-3751641598
15:07:17 <gb> https://github.com/webmachinelearning/charter/issues/14 -> Issue 14 Agentic AI Foundation coordination (by anssiko) [Agenda+]
15:08:30 <anssik> Anssi: 2) charter-level coordination
15:08:38 <anssik> Anssi: beyond spec-level technical alignment, I propose we codify high-level expectations for the W3C-AAIF coordination in the group's charter
15:08:46 <anssik> ... including scope, intent and engagement mechanisms
15:09:10 <anssik> ... I will work with W3C's Dom and AAIF's Vasilii on this update that is considered non-blocking for the current spec work
15:09:14 <anssik> -> https://webmachinelearning.github.io/charter/#coordination
15:09:19 <domfarolino> q+
15:09:24 <anssik> ack domfarolino
15:10:36 <anssik> Dominic: I think how WHATWG coordinates with other orgs could be reused here, we loop external orgs in as non-blocking parties in the WHATWG context
15:10:38 <anssik> q?
15:11:19 <anssik> q?
15:11:33 <anssik> Subtopic: Tool unregistration design
15:11:37 <anssik> gb, this is webmachinelearning/webmcp
15:11:37 <gb> anssik, OK.
15:11:44 <anssik> Anssi: issue #130 and PR #147 for the first option
15:11:45 <gb> https://github.com/webmachinelearning/webmcp/pull/147 -> Pull Request 147 Spec `unregisterTool(ModelContextTool)` (by domfarolino)
15:11:45 <gb> https://github.com/webmachinelearning/webmcp/issues/130 -> Issue 130 Tool unregistration design (by domfarolino) [Agenda+]
15:12:09 <anssik> Anssi: a follow-up to #101 where we agreed an actor should not be able to unregister a tool that it did not register itself
15:12:10 <gb> https://github.com/webmachinelearning/webmcp/issues/101 -> CLOSED Issue 101 `navigator.modelContext.provideContext` allows overwriting of previously registered tools in the same environment (by beaufortfrancois)
15:12:21 <anssik> ... Dominic, please introduce the issue and the three design options considered
15:12:27 <Mark_Foltz> Mark_Foltz has joined #webmachinelearning
15:12:27 <anssik> anssik has joined #webmachinelearning
15:12:27 <jyasskin> jyasskin has joined #webmachinelearning
15:12:27 <gregwhitworth> gregwhitworth has joined #webmachinelearning
15:12:27 <chrishtr> chrishtr has joined #webmachinelearning
15:12:27 <christianliebel> christianliebel has joined #webmachinelearning
15:12:27 <vmpstr> vmpstr has joined #webmachinelearning
15:12:27 <tomayac27> tomayac27 has joined #webmachinelearning
15:12:27 <vasilii> vasilii has joined #webmachinelearning
15:12:27 <awafaa> awafaa has joined #webmachinelearning
15:12:43 <anssik> Dominic: I summarized three options in the issue,
15:12:47 <anssik> ... 1. unregisterTool(ModelContextTool)
15:12:53 <anssik> ... simplest, symmetry with addEventListener() and removeEventListener()
15:12:57 <anssik> ... 2. registerTool(interface Tool) / unregisterTool(interface Tool)
15:13:00 <anssik> ... as above but pass in a Tool
15:13:07 <anssik> ... a Tool is an EventTarget and can fire the toolactivated and toolcanceled events directly on the tool
15:13:20 <anssik> ... 3. registerTool() returns an unregistration token
15:13:25 <anssik> ... registerTool() returns a Tool that has an unregister() method
15:13:41 <lgombos> lgombos has joined #webmachinelearning
15:14:07 <anssik> ... with my web platform hat on the first option is the most webby, Chrome supports it and we have   implementation experience for that option
15:14:14 <anssik> ... please take a look at the options and the PR
15:14:19 <anssik> q?
15:14:20 <reillyg> q+
15:14:24 <anssik> ack reillyg
15:15:05 <anssik> Reilly: appreciate the simplicity of the first option, ModelContextTool is complex, are we using deep comparison?
15:15:33 <anssik> Dominic: they way dictionaries work is you don't get a reference back, so cannot rely on that, we use per member equality matching
15:16:08 <brwalder> q+
15:16:18 <anssik> ... I can imagine a world where we could introduce a Tool interface
15:16:43 <anssik> ... want to understand whether there are any footguns, not found any with the first option
15:17:04 <AlexN> q+
15:17:18 <anssik> Reilly: the nice thing about Tool interface is to have an interface to return, that an extension could use to enumerate tools?
15:17:26 <anssik> Dominic: API could exist either way
15:17:51 <anssik> Reilly: gets us part of the ModelContextTool dictionary?
15:18:11 <anssik> Dominic: testing tool gives you a back of attributes and access to the callback
15:18:39 <anssik> Reilly: not convinced 2nd option is better after this discussion
15:18:40 <anssik> q?
15:18:52 <anssik> ack brwalder
15:19:36 <anssik> Brandon: despite simplicity, ergonomics issues may arise when expecting string names, having to pass objects with the same execute callback forces developers to maintain a reference to the callback
15:19:49 <anssik> ... it is common to pass tool definition without naming it as a variable
15:20:07 <anssik> ... in that pattern you cannot hold the reference to pass it to the unregisterTool later
15:20:20 <anssik> Dominic: how often people need to unregister tool?
15:20:22 <victor> q+
15:20:33 <lgombos> present+ Laszlo_Gombos
15:20:35 <anssik> ... most people put it inline and lose it, that's OK
15:21:05 <anssik> Brandon: I guess the difference is, not unregistering event handles could cause memory leaks
15:21:17 <anssik> ... it won't break your app, if the element you're listening to goes away
15:21:25 <anssik> ... event handlers would be cleaned up anyway
15:21:36 <anssik> ... with tools, they are unregistered explicitly though
15:21:52 <anssik> ... e.g. React components when they are unmounted should allow unregistering tools
15:22:20 <anssik> Dominic: my only pushback would be you still need to keep track of the tools
15:22:34 <anssik> q?
15:22:59 <anssik> Dominic: Tool interface does not solve this problem, only the 3rd option would solve that
15:23:16 <anssik> ... only concern is no existing Web APIs use such a pattern currently
15:23:28 <anssik> q?
15:23:39 <anssik> ack AlexN
15:23:54 <anssik> Alex: agree with Brandon's concerns, but this could be handled by a library abstraction
15:24:53 <anssik> ... whether to use an object or an interface, running into a tool name, would be great to throw those errors e.g. call new Tool() and it rejects if the name does not match
15:25:16 <anssik> Dominic: ergonomics thing that would be nice
15:25:29 <anssik> ... that makes sense, I don't know how valuable it is, I will think about it a bit more
15:25:32 <anssik> q?
15:25:35 <anssik> ack victor
15:26:01 <anssik> Victor: unregistration pattern will be more common in SPAs in particular, e.g. shopping flow
15:26:19 <anssik> ... unregistration will be commonly used
15:27:13 <anssik> ... the previous approach was to (un)register with a name, are we overcomplicating the design?
15:27:18 <anssik> q?
15:28:37 <anssik> Dominic: I'd like to resolve we do either option 1 or option 2 to narrow down on the solution space
15:29:43 <anssik> ... Victor, any concerns to provide the entire Tool to pass as a reference?
15:30:23 <anssik> Victor: you'd have to keep track of the exact tool you created, but for name you can just store it somewhere, makes for better developer ergonomics
15:30:42 <anssik> ... what if the tool definition grows bigger in the future?
15:30:46 <anssik> q?
15:31:19 <anssik> Dominic: growth concern pushes us toward the Tool interface
15:32:24 <anssik> ... should consider how subclassing would look
15:33:46 <anssik> Dominic: any objections to start with option 1 and if issues arise move to option 2?
15:33:55 <AlexN> +1
15:33:57 <brwalder> +1
15:34:01 <victor> +1
15:34:21 <victor> As long as we are open to changing direction we are fine
15:34:24 <gb> https://github.com/webmachinelearning/webmcp/issues/130 -> Issue 130 Tool unregistration design (by domfarolino) [Agenda+]
15:35:09 <reillyg> +1
15:35:14 <domfarolino> +1
15:35:18 <victor> +1
15:35:19 <anssik> RESOLUTION: Adopt unregisterTool(ModelContextTool), if issues arise in developer trials move to (un)registerTool(interface Tool) design. (issue #130)
15:35:28 <anssik> Subtopic: Declarative integration with form-associated custom elements
15:35:39 <anssik> Anssi: issue #94
15:35:40 <gb> https://github.com/webmachinelearning/webmcp/issues/94 -> Issue 94 Define Declarative WebMCP integration with form-associated custom elements (by beaufortfrancois) [Agenda+] [declarative]
15:37:12 <anssik> Anssi: I want to give a heads-up there's early Chromium implementation experience for declarative integration with form-associated custom elements
15:37:50 <anssik> Anders: two biggest issues we discovered, the names, not sure about them
15:38:02 <anssik> ... "what do you mean by tool"
15:38:13 <anssik> ... more difficult issue is how to fill in the custom element
15:38:27 <anssik> ... when you execute, if we return a failure, we don't want the form state to be modified at all
15:38:52 <anssik> ... not clear we can return a failure with the existing patterns how CE work, CE is all async
15:39:04 <domfarolino> q+
15:39:06 <anssik> ... cannot check "does this data look good to you" from a custom element
15:39:07 <anssik> q?
15:39:09 <anssik> ack domfarolino
15:39:19 <anssik> Dominic: in what ways it could fail?
15:39:27 <anssik> ... only when the data does not match the schema?
15:39:59 <anssik> Anders: if the author inputSchema, as long as the schema is matched, it is not allowed to fail?
15:40:07 <anssik> Dominic: any other cases?
15:40:41 <anssik> ... in general for form-associated custom elements, do we have any failure paths?
15:41:12 <anssik> q?
15:41:33 <anssik> Anders: are the elements going to be more strict than what we can express in JSON schema?
15:41:59 <anssik> Dominic: no I guess, want to understand if there are any other ways to fail?
15:42:24 <anssik> q?
15:43:06 <anssik> ... are there any other ways to express form filling failure for native elements?
15:43:24 <anssik> ... apart from JSON schema validation, any other failure paths
15:43:41 <anssik> Anders: base step and step in ranges does not map to anything in JSON schema
15:43:41 <anssik> q?
15:43:48 <anssik> q?
15:44:11 <anssik> q?
15:44:41 <anssik> Anssi: I'd like to see some some group discussion in the issue before resolution to ensure we carefully consider all viewpoints
15:44:53 <anssik> Subtopic: Allow iframes to declare tools
15:44:56 <anssik> Anssi: issue #57
15:44:57 <gb> https://github.com/webmachinelearning/webmcp/issues/57 -> Issue 57 Allow iframes to declare tools (by khushalsagar) [Agenda+]
15:45:01 <anssik> ... we discussed this at TPAC 2025 and most recently a month ago on our telcon:
15:45:04 <anssik> -> https://www.w3.org/2026/02/05-webmachinelearning-minutes.html#e509
15:45:10 <anssik> Anssi: good issue discussion recently, thanks!
15:45:19 <anssik> Anssi: I believe we need to agree on the use cases first
15:45:26 <victor> q+
15:45:31 <anssik> ... when we understand the use cases, we're better positioned to design a solution, be it Document Policy, Permission Policy (prior Feature Policy) or something else
15:45:34 <anssik> -> https://www.w3.org/TR/permissions-policy/
15:45:37 <anssik> -> https://wicg.github.io/document-policy/
15:45:41 <anssik> Anssi: Victor documented the following two use cases for allowing iframes to declare tools:
15:45:47 <anssik> ack victor
15:46:11 <anssik> Victor: two use cases:
15:46:35 <anssik> ... 1. To allow iframes to declare tools for browser/extension agents to operate
15:46:46 <anssik> ... There are many sites where the main content is inside an iframe, so we want to make sure that the main contents of these sites are able to expose tools as well.
15:46:55 <johannhof> johannhof has joined #webmachinelearning
15:47:04 <anssik> ... 2. To allow some form of cross frame calling of tools
15:47:31 <anssik> ... - This seems like an emerging use case
15:47:36 <anssik> -> https://github.com/webmachinelearning/webmcp/issues/57#issuecomment-4035192266
15:47:37 <gb> https://github.com/webmachinelearning/webmcp/issues/57 -> Issue 57 Allow iframes to declare tools (by khushalsagar) [Agenda+]
15:47:42 <anssik> Anssi: any additional use cases?
15:48:14 <anssik> ... are these two the only use cases we want to design the solution for?
15:48:38 <anssik> Victor: if the only concern is the first use case, the parent frame does not need to see the child frame
15:48:39 <johannhof> q+
15:48:45 <domfarolino> q+
15:48:55 <anssik> ... in some sense there's less risk, browser mediating
15:49:03 <anssik> q?
15:49:07 <anssik> ack johannhof
15:49:40 <anssik> Johann: I think I disagree with iframe able to register tools
15:50:08 <anssik> ... think you're an advertiser, you could register a tool "this is the real checkout tool"
15:50:15 <anssik> ack domfarolino
15:50:51 <anssik> Dominic: parent should opt-in to this, is the parent page OK for the child to operate the first-party page
15:51:19 <anssik> ... is this as simple as Permissions Policy, or is it too granular?
15:51:38 <anssik> Johann: Permissions Policy is not bi-directional is an issue
15:52:13 <anssik> ... it is risky to steal these tools from the child frame, say a bank might have use case to have their site framed, you could make an agent to use these tools
15:52:31 <anssik> Dominic: 3P Document Policy opt in
15:52:50 <anssik> ... we don't require the parent to have access to the tools and the child would agree to that, that'd be a higher bar
15:52:58 <anssik> ... bi-directional negotiation is important
15:53:15 <anssik> Johann: does not need to be Document Policy, we could bake this into the API directly
15:53:17 <anssik> q?
15:53:53 <anssik> Dominic: Document Policy might be good for this, its header negotiation provides a mitigation, to not expose sensitive tools
15:55:56 <Mark_Foltz> q+
15:56:26 <anssik> Victor: we can talk to Ian about Document Policy evolution
15:56:32 <anssik> ack Mark_Foltz
15:56:47 <anssik> Mark: there's a second issue that was not resolved fully, the name collision
15:57:04 <anssik> ... if frames register tools with the same name for parent and child
15:57:27 <anssik> ... name collisions become a responsibility of the browser to provide context they're different tools with different impacts depending on the context
15:57:41 <anssik> ... if you register two tools they are different origin
15:57:57 <anssik> ... from quality perspective, not allowing name collisions would be good
15:58:00 <johannhof> q+
15:58:06 <anssik> Victor: goes back to use case consideration
15:58:19 <anssik> ... it is an implementation details how to handle the collision
15:58:43 <anssik> q?
15:58:45 <anssik> ack johannhof
15:59:08 <anssik> Johann: recommend to bake in a serialization algorithm for the names into the spec for interop benefit
15:59:15 <anssik> ... to allow deduplicating the tools
15:59:42 <anssik> Dominic: if the serialization is exposed to the platform it would be relevant then?
15:59:51 <anssik> q?
16:00:00 <anssik> q?
16:00:56 <domfarolino> +1
16:01:04 <victor> +1
16:01:18 <anssik> RESOLUTION: Explore Document Policy as a bi-directional opt-in mechanism without a wildcard mechanism that addresses the two use cases, figure out a solution for name collisions. (issue #57)
16:01:19 <gb> https://github.com/webmachinelearning/webmcp/issues/57 -> Issue 57 Allow iframes to declare tools (by khushalsagar) [Agenda+]
16:02:16 <anssik> RRSAgent, draft minutes
16:02:18 <RRSAgent> I have made the request to generate https://www.w3.org/2026/03/19-webmachinelearning-minutes.html anssik
16:02:57 <anssik> Present+ Reilly_Grant
16:03:05 <anssik> Present+ Johann_Hofmann
16:03:11 <anssik> Present+ Ben_Greenstein
16:03:26 <victor> Present+ Victor_Huang
16:03:27 <anssik> Present+ Winston_Chen
16:03:38 <anssik> Present+ Alex_Nahas
16:03:49 <anssik> Present+ Anders_Hartvoll_Ruud
16:03:53 <anssik> Present+ Brandon_Walderman
16:04:04 <anssik> Present+ Christoph_Bordeck
16:04:17 <anssik> Present+ Harsh_Varshney
16:04:25 <anssik> Present+ Iris_Johanson
16:04:31 <anssik> Present+ Jaewon_Lee
16:04:47 <anssik> Present+ Jingyun_Liu
16:04:52 <anssik> Present+ Mark_Foltz
16:05:04 <anssik> Present+ Saron_Yitbarek
16:05:23 <anssik> Present+ Sathish_Manickam
16:05:37 <anssik> Present+ Umar_Iqbal
16:05:49 <anssik> RRSAgent, draft minutes
16:05:50 <RRSAgent> I have made the request to generate https://www.w3.org/2026/03/19-webmachinelearning-minutes.html anssik
16:08:53 <anssik> s/a back/a bag
16:09:37 <anssik> s/handles/handlers
16:12:53 <anssik> s/inputSchema/provides an input schema
16:13:30 <anssik> s/does not map/do not map
16:13:49 <anssik> s/some some group/some group
16:19:17 <anssik> RRSAgent, draft minutes
16:19:18 <RRSAgent> I have made the request to generate https://www.w3.org/2026/03/19-webmachinelearning-minutes.html anssik
16:21:25 <anssik> Present+ Dominic_Farolino
16:21:59 <anssik> RRSAgent, draft minutes
16:22:01 <RRSAgent> I have made the request to generate https://www.w3.org/2026/03/19-webmachinelearning-minutes.html anssik
16:27:15 <anssik> Anssi: FTR, at the beginning of the meeting, we welcomed the following new participants to the group:
16:27:21 <anssik> ... Jaewon Lee from Google
16:27:26 <anssik> ... Benjamin VanderSloot from Mozilla
16:27:38 <anssik> ... Saron Yitbarek from Apple
16:27:42 <anssik> ... Shubham Gupta from Huawei
16:27:54 <anssik> ... Christoph Bordeck, Matthew Zaute, Chris Phillips, Richard MacManus, Umar Iqbal and Aaron Schneider as unaffiliated individual contributors
16:28:00 <anssik> RRSAgent, draft minutes
16:28:01 <RRSAgent> I have made the request to generate https://www.w3.org/2026/03/19-webmachinelearning-minutes.html anssik
18:37:10 <Zakim> Zakim has left #webmachinelearning
19:20:09 <gb> gb has joined #webmachinelearning