#1268: Other Spec Review: Registries developed by the Media WG
Discussions
Log in to see TAG-private discussions.
Discussed
Oct 5, 2026 (See Github)
Jeffrey: A registry is an interface. The things in the registry has to define the algorithms, etc, that the calling spec expects to be there. Otherwise you have undefined behavior and implementations have to guess. So it is important that registration rules say what is expected by this registry, and that needs to match what's in the spec. If that happens, no architectural review is required for the entries.
Brian: In this case, the registries all exist.
Jeffrey: I don't think these to have the problem I described, but we do have to check. Another architectural failing could be when companies add proprietary entries such that there is no real interoperability.
Heather: I want to take another look at this with the above ideas in mind.
Discussed
Oct 12, 2026 (See Github)
Heather: This turns into a meta-question. I thougth the question about a registry was interesting. I took some time to learn how I would do such at hting, that led me to interact with ChatGPT a bit. It came up with two questions: "For the HDCP registry, are all of the semantics needed by getStatusForPolicy()—including any version ordering or compatibility assumptions—fully defined outside the registry? For registries that permit an underlying specification not to be public, can an independent implementation nevertheless implement all Web-facing behavior of the registered entry solely from publicly available specifications?"
Heather: I think they're good questions, but they came from an LLm, so I'm not sure what to do with them,
Lola: I can remember one instance of a registry in my tenure on TAG. The conclusion was "this shouldn'tbe a registry."
Jeffrey: It sounds lke those are questions abot the design of the registry. Regardless of th equestion's providence, if it's a good question, we should ask it. The second one sounded like an interface question ("does the registry have the right fields?") I would want to verify the assertion about the carhacter of the registry. But that seems like an easier one to answer.
Heather: I'll ask those questions for clarification, and we'll decide on a resolution based on their response.
Lola: Do you want someone to join you?
Heather: Sure
Jeffrey: can you check the "get status for policy" question?
Heather: sure
Hadley: We prreviously talked about duplicating existing registries. That's sometihng else to consider.
Lola: I'd like Heather to help us understand if this should be a registry, and to Hadley's point, make sure there aren't existing registries that could be used/extended.
OpenedAug 24, 2026
The Media Working Group maintains registries related to some of its specifications on the Recommendation track, namely Media Source Extensions (MSE), Encrypted Media Extensions (EME) and WebCodecs. The registries are published on the Registry Track as Registry Drafts. The Media Working Group would like to advance these documents on the Registry Track by publishing them as Candidate Registry Snapshot.
We're taking the liberty to request a review of all the registries at once and without further analysis because the registries all have similar registration entry requirements, and because it isn't clear to us what input you might be willing to receive to help your review of such documents. By definition, registries document values, they do not define any architectural or interoperability requirements related to those values. We would expect comments on these requirements to be raised against the underlying specifications (MSE, EME, WebCodecs).
You may raise issues that apply to all registries using the tracking issue at https://github.com/w3c/media-wg/issues/64. More specific issues may be raised in the repositories that hold the documents.
Registry linked to MSE (GitHub repo):
Registries linked to EME (GitHub repo):
Registries linked to WebCodecs (GitHub repo):
Note: Most of the registries related to MSE and EME used to be published on the Note track (simply because the Registry track did not exist at the time of publication).
<!-- Content below this is maintained by @w3c-tag-bot -->Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1268