Coordination with W3C?

[JonathanLennox]

Whatever information the eventual sconepro mechanism produces will need to be communicated to in-browser video player apps.

The W3C should presumably be added to the list of groups to coordinate with, so JavaScript APIs for this information can be defined.

[fluffy]

W3C or WebTransport or SomethingElse ?

[SpencerDawkins]

W3C or WebTransport or SomethingElse ?

The vision I thought we were working with was that we would coordinate with other IETF working groups (RTCWeb, WebTransport, etc.) that are already coordinating with other IETF working groups.

Would that be insufficient? (especially since not everyone in a resulting working group would be able to participate in relevant W3C work. For those people, coordination would be through proxies anyway)

[SpencerDawkins]

@JonathanLennox and @fluffy, I thought about this a bit more, and realized I could have been clearer in my previous comment.

IMO, the SCONEPRO work needs to mesh cleanly with W3C work that will rely on it. Whether we need to explicitly call out W3C groups in our charter depends on which W3C groups will rely on our work, and whether we have already called out IETF working groups that already coordinate with the relevant W3C groups.

If no other IETF working group is already coordinating with the relevant W3C group, we should add the relevant W3C group.

If another IETF working group is already coordinating (successfully) with the W3C group, and we are already coordinating with that IETF working group, we probably don't need to add more coordination paths, so working through an existing IETF working group with existing relationships seems reasonable.

Does that make sense?

Does that make sense?

[zaheduzzaman]

Coordinating with W3C kind of makes sense to me for the browser implementation of using this throughput advice. I would prefer this potential working group does the necessary coordination, if this is done via proxy as @SpencerDawkins mentioned that also should be noted in the charter.

[SpencerDawkins]

Tl; dr - @JonathanLennox, do you know which W3C working group(s) we should expect to collaborate with? Or does @aboba?

@zaheduzzaman, I think we're in violent agreement - the charter ought to list off the groups we expect the working group to collaborate with, whether they are in the IETF or elsewhere. As you said, it's easy to imagine that a SCONEPRO working group would need to work collaboratively with at least one W3C working group to ensure that a browser application can make use of SCONEPRO.

The question I was trying to ask was "yes, but which W3C working group?" In earlier discussion, @fluffy asked the same question:

> W3C or WebTransport or SomethingElse ?

If we can answer that question, a PR should be trivial enough for me to produce one.

I am no genius of W3C (because reasons). I THINK the right W3C working group might be the Web Real-Time Communications Working Group, but I could easily imagine the Media Working Group should at least be aware of SCONEPRO, just from a quick read of their description.

There are 43 active W3C working groups, so there might be at least one other candidate for collaboration.

[martinthomson]

There are two groups that might need coordination. W3C WebTransport and WHATWG fetch. The former we have an open line to and some very good chairs. The latter is achieved by opening an issue on a repository at the time you have something concrete. A browser person can help with that latter one.

I would probably advise against having either in the charter. APIs can remain out of scope, with these ones evolving organically.

Edit: And yes, we probably would include WebRTC in that set. At some point. WebRTC doesn't use QUIC, so it's not something I think about in this context.

[zaheduzzaman]

I am fine with leaving the API development out of the scope of this charter, but then lets be explicit about it.

@martinthomson on your comment WebRTC does not use QUIC --> to me there is nothing the charter that bounds it to QUIC usage for the ABR applications. So, WebRTC can use the throughput advice as well.

[martinthomson]

Developing the necessary signals for another protocol is not work that would happen immediately. WebRTC is primarily UDP, which makes the signaling particularly challenging. I personally think that the UDP extensions work is doomed, so likely avenues are things like RFC 7983, which is a bit of a mess. Either way, that was me making an excuse for not considering it, not saying that it wasn't a valid thing to consider.

[aboba]

The W3C WebTransport API includes mechanisms to indicate the estimatedSendRate to applications (e.g. so the application can adjust the encoder's target bitrate). Some similar considerations may apply to the RtpTransport API, which is being prototyped in Chromium.

[martinthomson]

estimatedSendRate won't work here. The signal that is likely to be received is a (likely) maximum receive rate. Besides the fact that it is a maximum (which is easy to manage), the "wrong" endpoint receives the signal. That deliberate, but it means that the simple answer doesn't work. In this case, that's probably as much a good thing as it is a complication.

[zaheduzzaman]

the estimantedSendRate is coming from a congestion controller, the throughput advice is not that hence it is not relevent here. But I can see the max throughput advice can be helpful for encoder to optimize if possible.

Overall I sugguest that the API development is explicitly kept out of the scope on this charter, so, should go into the non-goal part.

[zaheduzzaman]

@SpencerDawkins, if your question got anserwed, can we create a pull request - with suggestioin the API development discussion is out of scope?

[SpencerDawkins]

@zaheduzzaman - that sounds like a plan.

[SpencerDawkins]

Just to explain my thinking here -

I looked at the oldest RTCWeb charter that popped up in the datatracker, and they said a lot about collaborating with W3C, but didn't name any working groups within W3C:

This work will be done in collaboration with the W3C. The IETF WG will produce architecture and requirements for selection and profiling of the on the wire protocols. The architecture needs to be coordinated with W3C. The IETF WG work will identify state information and events that need to be exposed in the APIs as input to W3C. The W3C will be responsible for defining APIs to ensure that application developers can control the components. We will reach out to the developer community for consultation and early feedback on implementation.

I looked at the more recent charter for WebTransport, and it only referred to owners of the WebTransport API:

To assist in the coordination with owners of the WebTransport API, the group will initially develop an overview document containing use cases and requirements in order to clarify the goals of the effort. The requirements will include those arising from the WebTransport API. Feedback will also be solicited at various points along the way in order to ensure the best possible match between the protocol extensions and the needs of the WebTransport API.

Given @martinthomson's mention of WHATWG (which is not part of W3C, I think?), I like the idea of referring to "owners of any APIs that use SCONEPRO". That just says the WG has to care if browser applications can use SCONEPRO via APIs, without trying to predict what groups will finally control the APIs.