Meeting minutes
<gb> Issue 11 Second Screen WG/CG - TPAC 2024 agenda (by anssiko)
Anssi reviews agenda items and runs a quick round of introductions.
Charter update
anssik: Some minor renaming of Window Management API.
… We tweaked a bit our milestones
… We explained the plan to split the Open Screen Protocol.
… What we did not include is the possibility to move the OSP network part to the IETF through DISPATCH.
tidoust: That should go fine if both this group and IETF agree. There may be a need to check with the W3C Membership as a whole. I would need to confirm that if and when the time comes.
anssik: [reviews the agenda]
Open Screen Protocol
Slideset: PDF, Google slides
Implementation update
markafoltz: We've been trying to develop an implementation of the OSP. A significant amount of work would be required to turn the demo into something that demonstrates the whole stack. The demo does not have any authentication of any kind.
… Many other issues.
… For some reasons, we ended up forking the implementation of QUIC in Chromium.
… Wei Wang from Intel has been doing an amazing amount of work to fix all this since then.
… The QUIC implementation was completely rewritten
… Various things implemented.
… The last missing piece is the mutual authentication protocol.
… We are moving fairly closer to having a working full prototype.
… Now it isn't integrated in any product yet.
… We would then be able to have a full demo or start considering integrating in other products.
… Wei Wang found spec bugs along the way, which is all the better!
… We gained a lot of expertise on the implementation.
markafoltz: From a spec perspective, we've been making good progress. Close to fixing all issues towards v1.0.
markafoltz: We uncovered a few issues along the way.
… How we structure the certificates to not depend on themselves.
… Related to this is a feature called TLS SNI
… It makes sense to discuss this together.
… A second issue is with my misuderstanding how max streams worked in QUIC. Now corrected thanks to David Schinazi.
markafoltz: For TLS SNI, [missed]. The SNI is useful to know what server/agent you're connecting to.
… We initially had something that had a few issues.
… You're not supposed to put "_" in them.
… A number of solutions were discussed. I tried to summarize them.
markafoltz: One of them is to define a custom SNI. That seems a harder road to go, requiring spec by the IETF TLS working group
… Another solution is to use the DNS-SD instance name. But it kind of asks the question on how you guarantee uniqueness with these names.
… A third solution would be to use something unique such as a serial number, unique per certificate and device.
… I think the proposed solution is closer to solution 3.
backkem: Indeed. In the WebRTC stack, they also are trying to avoid fingerprinting when using local names.
… They use the [missed].
… We don't necessarily expose the DNS-SD instance name.
… Using a UUID instead of the serial name would be preferable.
markafoltz: I'm not opposed to this.
markafoltz: That's what I'm proposing, making sure to use characters that are OK for a TLS SNI.
… The nice thing is that we don't have to provide uniue instance names.
… The only caveat is that we would need some way to obtain the unique identifier.
… We need a way to obtain that metadata before we can connect to the agent.
… I'm opened to convert the first part of the proposal to using a UUID.
… The UUID would need to be along the certificate.
PROPOSED RESOLUTION: resolve #275 by substituing <UUID> with the suitable encoding for the serial number <sn>
<gb> Issue 275 TLS SNI requirement is incompatible with TLS SNI definition (by sleevi) [security-tracker] [F2F]
markafoltz: There's a knock-off effect with the next issue.
<backkem> https://
backkem: See the informational document about the RTC case. It's also to allow a local network using DNS-SD. They don't use Instance Name. They only use purely UUID.local to ensure that there's nothing extra that can be used to fingerprint something from the local network.
markafoltz: I think our case is a little different, no need to reference in the spec, but that's a nice precedent, worth mentioning in the issue.
RESOLUTION: resolve #275 by substituing <UUID> with the suitable encoding for the serial number <sn>
markafoltz: A related issue is around avoiding circular dependency. With our resolution, we can hopefully resolve this issue as well.
… We may need a small update.
… I don't know that we need to say something specific other than what TLS already does.
backkem: Sounds good.
markafoltz: We may want to make stronger guarantees over uniqueness over networks, but UUID provides many bits of entropy already, I think this is sufficient.
… If Michiel updates the PR with the resolution from the previous slide, we can solve this as well.
backkem: Sure.
PROPOSED RESOLUTION: Close #276 by updating the open pull request with the resolved solution for #275 (SNI issue)
<gb> Issue 276 Agent Certificate has a circular dependency on itself (by sleevi) [security-tracker] [F2F] [v1-spec]
RESOLUTION: Close #276 by updating the open pull request with the resolved solution for #275 (SNI issue)
<gb> Issue 275 TLS SNI requirement is incompatible with TLS SNI definition (by sleevi) [security-tracker] [F2F]
markafoltz: Another issue that was raised when Wei was working on the implementation is how to map CBOR message and QUIC stream.
… One-to-one mapping but an issue was raised when a recipient sets max streams. If it's set too low, that could cause problems. I tried to set it to a very high number.
… However, I think I got the mechanism wrong.
markafoltz: As the stream gets completed on the server side, it will raise the value on its side. What David recommended is to specify that behavior in the spec.
… That's more or less what I did in #334.
<gb> Issue 334 Add guidelines on how CBOR messages are mapped onto streams (by markafoltz) [QUIC] [F2F] [v1-spec]
<anssik> "NOTE: Open Screen Agents should configure QUIC stream limits ([=MAX_STREAMS=]) to not hinder application performance, keeping in mind the number of concurrent streams that may be necessary for audio, video, or data streaming use cases."
markafoltz: I don't know if we need to be super specific. That's tuning implementations.
… I think David's comment hopefully clarifies the issue.
PROPOSED RESOLUTION: Close issue #334 by merging PR #336
<gb> Pull Request 336 Add a NOTE about MAX_STREAMS for QUIC connections (by markafoltz)
RESOLUTION: Close issue #334 by merging PR #336
markafoltz: As we discussed last year, there's a natural split in the spec: one is finding and authenticating agents. We'll call that part the network part of OSP.
… The other piece is the messaging we define to send media, receive media, control media, etc. Those sit on top of the network protocol and can be considered an application protocol.
… The application protocol has fewer complexities than the network protocol. We need implementation experience with it.
… The network protocol has proved to be quite complicated, e.g., on how the certificates can be generated.
… It has generated a lot of feedback from outside the group.
… It makes sense to address them separately.
… Michiel has a lot of thoughts around this.
… The other reason is that, to make progress, it would be useful to take the application side and implement it on top of other transports, specifically those that already exist on the Web, such as WebTransport. The application protocol can be supported by JavaScript. We may experience with polyfilling.
… Or experiment with protocols such as Cast in Chrome.
markafoltz: That summarizes what I just said.
markafoltz: Last year, I put together these slides. Some pieces refer to both the application and network side. That's not a super clean split. Overall, it's not too bad.
markafoltz: I put up a couple of PRs that follow pretty much the plan that I laid out.
… There are some kind of dangling issues.
… The application protocol has requirements for the network pieces.
… Having some requirements or strongly suggested characteristics for the network piece in the application protocol would be good.
markafoltz: Looking at transport requirements, we could basically say do something QUIC-like. As long as it's secure and has some protection against MITM attacks, you can use a different transport.
backkem: Most concrete comment: handover between the two protocols. If you do not want to tie together both implementations, you have to do some work to switch over.
… I'm thinking it could be better if we treat these as two separate connections. One where you speak the application protocol, and one where you speak the network protocol.
… To have a great UX, I suppose that the application would want to [missed]
markafoltz: The tricky bits are factoring out these bits. Authentication ceremony was implemented as CBOR messages, but it's actually part of the network protocol.
… These are really useful questions.
… Reg. origin vs. UA connection, good point. Browser makes the authentication connection, that's one model.
… There's kind of a lower level API exposing data channels and that's where the application protocol takes place.
… We want to move the application piece into the app space.
backkem: I've seen interest in similar topics from others. Re. HTTPS in local network, Also, local Peer-to-Peer API.
… I'm not sure that QUIC as a transport makes a lot of sense across the board.
… It still seems useful to coordinate discussions.
… WebRTC alignment where they have done an enormous amount of work with streaming media.
… I wonder whether it would make sense to strip out the media streaming aspects of OSP and instead reuse an existing one.
markafoltz: One of the goals of the split is to make it possible to implement it on top of multiple transports.
… We need to clarify whether we want to allow the application to potentially be in a position to bring its own transport.
… e.g., WebRTC data channel, or WebTransport.
… And then you can do everything yourself.
… The question is whether to integrate with more internal protocols such as Cast.
backkem: The authentication ceremony is the main thing missing in local peer-to-peer and HTTPS in local network discussions.
markafoltz: OK. I believe that WebRTC has a way to bring your own certificate.
… I don't have a clear idea of what that would look like when applied to OSP.
Peter: Same application protocol and different network protocols, you could run it on top of client-server QUIC if you were trying to do casting in a different kind of environment.
… You could also envision a scenario where you would have the application protocol on top of [missed] or WebRTC.
… On the other side, you have the network protocol that could be used for other purpose. What could be interesting is the ability to find things on the local network, and authenticate. You could use that to bootstrap a WebTransport between two peers. Or to bootstrap a WebRTC connection because WebRTC really wants master key material and it wants
to be able to have something that can connect two network endpoints.
… There are different things that could happen. A lot of use cases where this could be useful.
markafoltz: That's along the lines of my thinking as well.
… Running on top of different transport protocols. And separately generalizing the network protocol.
… That provides a nice segway into the work you're doing on the local peer-to-peer API, Michiel.
backkem: One suggestion that I could make is that we frame the protocol as being transport independent. In the lcoal Peer-to-peer API, we may experiment with mapping to other network protocols such as TCP, on top of QUIC as done in OSP.
markafoltz: We have this peer to peer API that provides discovery and authentication.
… Then choice of protocol depends on services supported by the agents.
Peter: Rather than trying to put QUIC in WebRTC, work in that area evolved into WebTransport, losing the peer-to-peer aspect along the way.
… A really good first step would be to end up with something that looks like the WebTransport API but for local network.
backkem: Already the case.
Peter: Cool. Other things can be added on top of that fairly easily.
… For example, I'm working on RtpTransport to allow to create transport without SDP, which causes problems.
markafoltz: We wanted a cleaner way to negotiate bi-directional streams.
… And we wanted authenticated contexts.
… If applications feel that RTP is a better use case, I don't think that we want to prevent that.
Peter: If you were just going to use this local API for media streaming, you would have to couple that with WebCodecs. The only thing missing would be adding the jitter buffers and so on. There are a bit of missing gaps.
… In order to bootstrap an RtpTransport, you need an encrypted connection.
markafoltz: On a high level, if we are going to create the network protocol on the side, it should support these two use cases.
Matter
markafoltz: Matter is an industry spec for smart home devices.
… Mainly about smart home controls.
… But also around discovery and authentication.
… Matter has its own mapping onto DNS-SD.
… It supports some of the requirements that we have on our side.
… My evaluation of it is that it's not quite the right transport to run OSP on its own.
… But it could be used to bootstrap another transport.
markafoltz: A deeper proposal would be to add a Matter message to allow devices to support another transport protocol.
… However, since last TPAC, I haven't made much progress on this.
… Once we have the split done, it will be easier to get back to the Matter group.
Summary
markafoltz: Land PR. Then I would propose to freeze the previous document.
… Hopefully, when there is interest, it would be great to prototype the application protocol using existing Web APIs.
… And then, bringing up the network protocol to IETF Dispatch.
tidoust: [summary of IETF discussion]
tidoust: [logistics of /TR updates]
markafoltz: If I could make a decision, I would propose to redirect the current OSP spec to the Application part.
Extensions for Local Peer-to-Peer API, Local Peer-to-Peer API incubation progress update
anssik: Local peer-to-peer API was proposed to WICG a year ago. We received quite a bit of developer excitment.
… Lots of signals that there is a need for this type of API.
… Goal: connect over local communication medium without having a server in the middle.
… If you connect to your local network storage or your TV, you're going to have a scary experience. You can connect securely to the other side of the planet, but not to your home.
… I will not drill into details. Just a few use cases.
anssik: Offline collaboration use cases, for example disaster relief scenarios, power outages as in TPAC this week.
… Local in-app sharing, etc.
Peter: Lots of interest lately on having media shared on one client also routed to another. This could be useful for that.
anssik: Is it documented somewhere?
Peter: Already a WebRTC use case, yes.
markafoltz: Some mesh proposal for RTP forwarding was presented yesterday.
backkem: One more use case from the Local HTTPS session: local HTTP in the browser is one of the last places where HTTP is used whereas browser would like to switch to HTTPS and deprecate HTTP.
<markafoltz> Encoded Source proposal in WebRTC: https://
backkem: We're trying to generalize the network protocol and generalize it to other use cases.
… Create a bi-directionally data channel communication.
… These APIs are currently inspired by the RTCDataChannel.
… The spec has its own application protocol.
… Just being able to use the Open Screen Protocol to then form a normal data channel.
… There was a mention of ICE lite and that's interesting to me.
… Could be used to spawn the RTC stack on top of it.
backkem: A comparison between WebRTC and the local peer-to-peer API.
… If we make an effort to get closer to what people are used to, that would help gain support and reassure people.
anssik: Bernard provided quite a lot of details a P2P QUIC. I'm really grateful for his contributions.
<anssik> Local Peer-to-Peer at WebRTC WG meeting 2024-05-21
backkem: [showing API examples]. The idea is that when one starts receiving, it's important that the control is being taken to the UA, the user will then have to pick up a device.
… The reason that's done that way is to avoid any fingerprinting issue.
… You're not getting back a direct raw socket.
… Once you have a handle to a peer, you can then construct a transport, such as a QUIC transport.
Peter: The biggest blocker for this to be useful is the need to have a picker for picking the other device.
… It would be more useful if the two sides could say "Hey, I'm looking for someone else", and they get connected under the hoods.
… Maybe it's not feasible, I don't know.
backkem: There's an open issue around that.
… Right now, we're focused on starting from no connection.
… There's another ticket on this other repository to pass a token.
… It could be possible to use devices on which you're signed in, etc.
… Apple has some mechanism called Private [missed].
… The tricky thing might be making sure that the browser can still validate that what you're doing is secure enough.
Peter: Equivalent level of consent is what we're looking for.
<backkem> Filtering: WICG/
<gb> Issue 15 Peer attributes & filtering (by backkem)
markafoltz: Some sort of service filtering: find other nodes that will understand the data I'm going to send.
backkem: There's a number of things that we're doing on the OSP side. Wondering whether there are things that could be mirrored on the local peer-to-peer side.
… I can share a bit more about my Go implementation offline.
… There's a couple of alignment things that I fixed between the Go implementation and the Chromium one.
… The circular dependency issue blocked me.
markafoltz: I think the big picture I want to understand is how the network side of OSP fits in the local peer-to-peer.
… Mostly, I think I need to catch on the discussions that took place.
… If there's an explainer with use cases, that would help
<anssik> WICG/
<anssik> https://
anssik: We have that. We initiated TAG review early on.
… Some OSP feedback was given because there was some confusion.
… It is out there.
markafoltz: I hope I have time to dig into this further and provide feedback.
Peter: Is this going to be the home for local Peer-to-peer stuff?
anssik: Officially, it's WICG. We don't know yet where it could go.
… If it gets traction, we probably want to move it to a Working Group at some stage.
Peter: It may make sense to have a CG that is dedicated to that if there is interest.
backkem: The breakout session was 90% about gauging interest.
… There were people from all major browser vendors. No next step or commitment made during the session.
Window Management
Slideset: PDF, Google slides
Brad: I work with Mike Wasserman on Window Management for Chrome
msw: I'm the editor of the spec.
… Some window management capability enhancements solved a lot. There's even updated documentation on MDN that help.
msw: Google Slides just introduced multi-monitor presentations to deal with speaker notes and presentation on separate displays.
… Window Management allows that to be possible.
msw: We published an explainer for fullscreen without a gesture some time ago.
… Gesture requirements hinder adoption.
… There's an open fullscreen issue and PR.
… Advancing the specs and implementations on that front would be useful.
… This work kind of supersedes some earlier efforts, including fullscreen popup windows, and the use of one transient action to create "many windows on many screens".
msw: Turning to the future, we're looking for feedback. I mention a few possibilities on the slide.
… We hope to share more examples as more developers are adopting our API.
Brad: Time consuming to test things manually. You have to hook up actual displays, on each and every platform.
… We've developed a virtual way to do that.
… So that we can test our multi-screen functionality across platforms.
… I think during our last meeting we were on very early stages.
… Now we have a complete implementation on all desktop platforms.
… Some caveat on MacOS where we use a private API which is brittle.
Brad: We did a hackathon internally to see how to use this virtualization mechanism.
… Demo is to create a virtual display and cast it to another device.
Brad: [shows demo]. Looking at a display with a Chromecast attached.
… Right now, to present, I mirror the screen, but lose my speaker notes.
… We added that little tab that proposes to extend to another screen.
… And then, from Google Slides, I can tell it to display the slides to the virtual display I just created.
… Now, on my main screen here, you can see the presenter view, and then the slides on the screen attached to the Chromecast device.
msw: Two separate things being demonstrated. Multiple displays as seen by the OS, and our virtual display.
Brad: 1. Create a virtual display which you can use anywhere, even outside of Chrome. 2. Use the API to project.
msw: In a long term, the ability not to extend a wire.
Xiaohan: Will this be supported across platforms?
Brad: Right now, just a demo, not planning to ship, but it works across platforms.
anssik: Similar to the discussions we had on the Presentation API and the starting point for OSP to get something agnostic to a proprietary system.
markafoltz: Something like this would seem like a useful way to address a use we've looked at in the past.
Brad: One problem is the latency. Fine for slides, but for use cases such as gaming, that wouldn't work.
… We've been looking at very low latency solutions.
… We don't know whether that's on the Chromecast side or on the encoding side, but latency issues need to be addressed.
markafoltz: Yes, Cast was designed for quality, not latency. It is tunable to some extent, but it may never be as good as other protocols.
Brad: That's all we had for slides.
anssik: Thank you! It's always great to see the demo.
… One question on fullscreen without a gesture. You say it is now shipping. Could you share a bit more on that front?
… Would you like to keep it as a separate piece? Move it to Window Management?
msw: What it boils down is a UA configuration for the algorithm steps for entering fullscreen. A small update to the Fullscreen spec. I think it can be tangential to the Window Management API.
… I suspect not a strong interest from the Fullscreen editors. For the time being, useful for professional usage and Isolated Context applications.
… I was hoping that we could have the HTML spec updated with a little more specificity for this use case, and an ability to query the status.
… I don't know exactly what sort of venue beyond the explainer and the Fullscreen spec issue we should do.
… I have an action item on myself to send a PR to integrate with the Permissions API.
markafoltz: I think the Permissions API change shouldn't be blocked on other changes, such as those proposed by WHATWG.
… If the permissions ships in Chrome, it would be useful to integrate it at least as an experimental one.
<anssik> https://
markafoltz: There's a history of monkey-patching in some other specs, until things get upstreamed. That would be one way to progress such a feature.
msw: Are you suggesting turning the explainer into a spec with monkey-patching of the Fullscreen specification?
markafoltz: Probably yes. There are other APIs doing that.
msw: That makes sense.
markafoltz: For example, Remote Playback amends what HTML does with media elements.
anssik: Monkey patching is not a recommended practice, but given no better option, that may be the best way to specify the behavior.
markafoltz: Having some kind of spec format is better than nothing. No strong opinion on where that document lives.
… In our CG? Or in WICG?
msw: I can try to prepare a standalone Bikeshed spec along with the explainer and find the right venue for that afterwards.
anssik: That makes sense to me.
Brad: I wanted to credit Robbie who's on the call and helped with the live demo.
Remote Playback API
Slideset: PDF, Google slides
markafoltz: There are a few issues to triage.
markafoltz: 3 issues that were filed.
… One request from a developer which I replied to. I don't think that implies changes to the spec. I think we can close that one.
… Second one was to export terms.
… Probably easy to achieve with ReSpec. Once solved, that can also be closed.
… Thrid issue is something we discussed in this group before: allow that control flow. Allow the device to pause sending if it's running low on memory so that data does not get dropped.
… We landed a change in OSP to support that, but we currently don't expose it in the API.
… It's labeled "future". If people feel that we can expose that, we can discuss. That would be the only issue that requires real changes to the spec.
… From a Chrome perspective, we might be able to support this using the existing Cast protocol. But most of the remote playback is initiated from the browser. Exposing it through the API would not have a huge impact.
… My current position is that this could be useful but probably not required to be in scope of the first version of the API.
cpn: Presumably, there's already enough data exposed to allow this.
markafoltz: Not really, we don't expose receiver capabilities per se.
… The way it works is, if the element has specified multiple sources, the browser may choose a different one for remote playback.
… If it is using MSE, that mechanism does not exist.
cpn: It would be interesting to see whether we get developer feedback about this.
markafoltz: I haven't heard about concrete feedback.
… It would require some adoption.
cpn: Typically, the kind of use I'm thinking is that the remote screen may be capable of HDR while my controller may not.
markafoltz: You may want to use the Presentation API instead.
cpn: That seems the right solution.
markafoltz: There may be marginal benefit but I'm not sure that's worth it.
… Some cooperation might be needed. We added some backpressure indication in OSP. We don't have a way to signal that to the player.
tidoust: Wondering whether the signal couldn't actually surface at the video element already, with readyState or something similar.
markafoltz: Proposal is to see if we can address #132 through a clarification on using the backpressure signal. But if it requires a new API or advance the Web IDL somehow, then it's probably not in scope for the current spec.
Testing
<anssik> https://
<anssik> Automated tests
<anssik> Manual tests (*-manual.html)
louay: I think the results here are inline with the testing we did. The automatic tests are more or less all "pass" but there are issues with the manual tests.
<anssik> Latest test results
<anssik> w3c/
<gb> MERGED Pull Request 225 Update results for remote playback api (by FritzHeiden)
louay: If you can open the results page, you'll see a summary
… The main issue is that, in general, on Chrome, we cannot see the device picker.
… On Safari, we can see the device picker.
<anssik> Legend:
<anssik> ED29: Edge 129
<anssik> SF17: Safari 17 on macOS
<anssik> SO18: Safari 18 on iOS
<anssik> SP18: Safari 18 on iPad OS
louay: In the test runner, if you cannot see the device picker, you need to mark the test as "fail"
markafoltz: Most tests seem to fail across platforms.
louay: Yes. In Safari, you can see the device picker, but when you go from test to test, the device is still selected.
… Also, Safari iOS 17 had more "pass" than 18.
… In summary, the tests need to be checked again.
… It would be good to see why the device picker is not shown in Chrome.
markafoltz: It's been a while since I reviewed the tests.
… If I recall, they check the watchAvailability result and if yes, then they call the prompt that shows the device picker. For some reason, watchAvailability does not seem to work.
… I cannot speak on behalf of Safari.
anssik: It could be a platform issue, since test results are on MacOS.
markafoltz: One thing to note is that, outside of the web engine, the implementation for Android and Chrome Android are different. If both fail, that makes me suspect that it's how we implemented the API.
louay: I think there's one Remote Playback API example that is also not working.
… Fritz told me that he tested on Chrome for desktop with Chromecast to validate the tests. At the time, he had a "pass" for most manual tests.
… Change must have happened in the meantime.
markafoltz: I will look to see whether something regressed.
tidoust: Wondering whether it could make sense for Safari to keep the selected device from one test to the next.
… Same origin for the tests.
markafoltz: It may be that the selection is sticky in Safari.
louay: The connection remains and stays in remote mode.
… [showing Safari example]
tidoust: if the spec does not prohibit keeping the device selected, then we'll have to update the tests to add a manual step to disconnect from the device at the end of each manual test.
markafoltz: Yes, we may want to check with Apple first that this is their intended behavior.
markafoltz: [showing video that shows lack of prompt in Chrome]
… I'll check whether that's an implementation bug or something else to update to the specs.
anssik: Noting #153 related to Picture-in-Picture
<gb> Pull Request 153 Add Picture in Picture window to note on local playback devices (by chrisn) [F2F]
markafoltz: I think the question was around the relationship between Picture-in-Picture and remote playback. They're somewhat independent states. If you remote a video, the PiP window remains, replaced with a poster to say that the playback was remoted.
cpn: Then a note may not be needed.
ACTION: cpn to check with Safari folks whether they do anything different.
Presentation API
markafoltz: For context, no substantive issue raised recently. No motivation to change the scope.
… Two clarifications. One is around getAvailability() which always returns the same Promise, where other APIs always return a new Promise. I don't believe this should be a breaking change because the resolver should resolve all of them in the same micro-task.
<anssik> Writing Promise-Using Specifications > More general state transitions
anssik: [going through the TAG guidelines]
… same promise recommended when there is a state machine.
markafoltz: The state thing is great for the presentation request. If we follow the letter of the TAG, we would probably return the same Promise. However, none of the other APIs do that. I'm a little bit torn here.
… It simplifies the implementation not to have to do some house keeping of Promises.
… It would be simpler to create a new Promise.
… We could keep the current implementation if that's what preferred by TAG, but this was kind of motivated by suggested optimizations within the team.
anssik: In your proposed change, you return a new Promise but the same availability object.
markafoltz: Yes. To avoid resource exhaustion.
… I'll look into the TAG guidelines to see whether they apply.
tidoust: It would be good to either follow the guideline. Or to update the guideline to follow what APIs actually do!
markafoltz: The other open issue is that the API has many steps that run in parallel, and we needed to clean the steps so that promise handling and events firing get queued probably on the main thread.
… There may be a few other things to clean up here still, but main things already addressed. Nothing specific to follow up on this right on.
Wrap-up
anssik: [summarizes discussions]
<markafoltz> PDF slides: https://
<markafoltz> Will also link from the agenda
markafoltz: I suggest that we plan for an interim group meeting in Q1 or Q2 2025 following discussions with IETF Dispatch.