- From: François Daoust <fd@w3.org>
- Date: Tue, 15 Jul 2025 12:40:17 +0000
- To: "Tantek Celik" <tantek@mozilla.com>
- Cc: public-review-comments@w3.org
Dear Tantek, Thanks for your review of the proposed Media Working Group charter. The loosening of Success Criteria requirements was unintentional. The missing sentence has now been restored, and an issue re-opened against the charter template [1]. That said, I note that the interoperability issues you mention are also compounded by fragmentation at lower levels in both codec and media capability support across browsers, operating systems, and hardware, as well as on the proprietary nature of the underlying technologies. The Media Working Group clarifies mappings in non-normative codec-specific or format-specific notes as a result. These non-informative specifications are by essence harder to include in interoperability tests. The group would welcome inputs on how best to approach these. We acknowledge concerns raised by the Center for Democracy and Technology, which also resonate with the TAG's feedback on the proposed charter [2]. We continue to scope work on Encrypted Media Extensions as tightly as possible in the charter and expect that horizontal, and wide, review will keep the Working Group accountable of potential harms this work may introduce, and suggest improvements where possible. No change was made to the draft charter. Best, François, Media WG Team Contact [1] https://github.com/w3c/charter-drafts/issues/485 [1] https://github.com/w3ctag/design-reviews/issues/1082#issuecomment-2884345629 ------ Original message ------ From "Tantek Çelik via WBS Mailer" <noreply+wbs@w3.org> To: w3t-archive@w3.org Date : 05/07/2025 00:21:38 >The following answers have been successfully submitted to 'Call for Review: >Media Working Group Charter' (Advisory Committee) for Mozilla Foundation by >Tantek Çelik. > >Answers to this questionnaire can be set and changed until 2025-07-04 at: > https://www.w3.org/wbs/33280/mediawg-2025/ > >> >> >> >> --------------------------------- >> Support for the proposal >> >> ---- >> In case of Formal Objection: Per section 5.5 of the W3C Process Document >> requiring that a record of each Formal Objection must be publicly >> available, we encourage your organization to make their response public. >> You may do so by setting the visibility of your response to this >> questionnaire to public. If it instead chooses to make it Member-visible, >> or Team-only, and does not provide an alternate public version, the Team >> may make the Formal Objection public without attribution, per section >> 7.3. >> My organization: >> > > > * ( ) supports this Charter as is. > * (x) suggests changes to this Charter, but supports the proposal whether >or not the changes are adopted (your details below). > * ( ) does not support this Charter for the reasons cited in comments but >is not raising a Formal Objection (your details below). > * ( ) suggests changes to this Charter, and only supports the proposal if >the changes are adopted [Formal Objection] (your details below). > * ( ) opposes this Charter and requests that this group not be created >[Formal Objection] (your details below). > * ( ) abstains from this review. > >Comments: > >In general this is a good charter update. > >We are concerned about the >loosening of Success Criteria requirements, >which were done without any reason specific to this Working Group or its >deliverables. > >The only reason that seems to apply from the change log was >"boilerplate >text to match latest charter template" which is poor reasoning for lowering >an existing group's Success Criteria requirements, and is more likely to >indicate a problem upstream (it's more likely the Charter boilerplate text >has been regressed/removed without proper review or understanding of why >the prior text was in the boilerplate). However, one problem at a time, and >for this charter in particular, we would find it sufficient to restore the >sentence, updated per latest Process expectations (potential dropping of >PR), but retaining its original meaning: "In order to advance beyond >Candidate Recommendation, each normative specification must have an open >test suite of every feature defined in the specification." > >Here is a PR for >restoring that sentence, which should be uncontroversial >since there was no objection to it in the prior charter: >https://github.com/w3c/charter-media-wg/pull/53 > >The media (especially real >time) ecosystem has an unfortunate history of >non-interoperability from various sources that harmed user experience and >user choice (e.g. WebRTC "Plan B" which diverged implementations and >content/apps from standards and took many years to repair across the web, >nevermind a few more recent WebRTC extensions which continue to break >interoperability across browsers and web sites). > >Maintaining stronger >Success Criteria for interoperability may help to >minimize or mitigate such non-interoperability in the future, or at least >continue to express clear intent from the Working Group that features must >have tests (passed by implementations) in order to advance, and not just >implementations that may or may not actually interoperate. We would support >even stronger Success Criteria for independent interoperable >implementations for this Working Group charter and all other Working Groups >which touch on Media related standards. > >Lastly, we would also like to see >the concerns raised by the Center for >Democracy and Technology addressed. > >Thank you for your consideration. > >> >> >> >> >> >> --------------------------------- >> Participation >> >> ---- >> If this proposal is approved, my organization would be interested >> in participating in the following groups. Note: This >> answer is non-binding; after the review >> a formal Call for Participation will be sent for each approved charter. >> Charters include information about proposed staff effort, which may >> be evaluated in the context of the >> current staff effort tables. >> >> > > > * [x] Media Working Group > > >> >> >> >> >> >> --------------------------------- >> Support for Deliverables of the group >> >> ---- >> My organization: >> > > > * [x] intends to review drafts as they are published and send comments. > * [x] intends to develop experimental implementations and send experience >reports (your details below). > * [x] intends to develop products based on this work (your details below). > * [x] intends to apply this technology in our operations. > >Comments: > > > >> >> >> >> >> >> --------------------------------- >> Expected Implementation Schedules >> >> ---- >> If you expect to implement some deliverables of this activity, please >> indicate any known schedule for such implementations, without commitment. >> >Comments: > > > >> >> >> >> >> >> --------------------------------- >> Detailed Comments, Reasons, or Modifications >> >> ---- >> In addition to any comments you may have, please provide details about >> your answers. This may include, but is not restricted to, technical >> issues or issues associated with patent claims associated with the >> specification. >> >Comments: > > > >> >> >> These answers were last modified on 4 July 2025 at 22:21:37 U.T.C. >> by Tantek Çelik >> > >-- >The Automatic WBS Mailer > >
Received on Tuesday, 15 July 2025 12:40:21 UTC