Re: Advancing our Registry Drafts on the Registry Track

Hi François,

Thank you for preparing this. If you haven't had the opportunity to do so already, let's go ahead and request the reviews.

Chris

________________________________
From: Nigel Megitt <nigel.megitt@bbc.co.uk>
Sent: 16 July 2026 13:35
To: Francois Daoust <fd@w3.org>; public-media-wg@w3.org <public-media-wg@w3.org>
Subject: Re: Advancing our Registry Drafts on the Registry Track

Oh well then I stand corrected!

The rest of the paragraph in the Process is important though. But happy to keep your wording, and maybe there's a separate issue for me to raise against that wording in the Process.

The wording I was thinking of was related to classes of change.

Nigel

________________________________
From: Francois Daoust <fd@w3.org>
Sent: 16 July 2026 1:13 PM
To: Nigel Megitt <nigel.megitt@bbc.co.uk>; public-media-wg@w3.org <public-media-wg@w3.org>
Subject: Re: Advancing our Registry Drafts on the Registry Track

External: Think before clicking

Hi Nigel,

On 2026-07-16 13:27, Nigel Megitt wrote:
> Hi Francois,
>
> Looks good to me, generally. One thing I'd change is this sentence:
>
>> By definition, registries document values, they do not
> define any architectural or interoperability requirements related to
> those values.
>
> I don't think "interoperability" is right here. Suggest:
>
> s/interoperability/normative
>
> In fact the presence of common values in a registry _does_ help interoperability, by definition.
> That's what it's for!

Fine changing the wording.

>
> I think changing to "normative" brings it more closely into line with the Process requirements too, though I forget if that uses the term "substantive" or "normative" - either would work.

Well, the Process document uses "interoperability" ;)

I had lazily copied the sentence from the Process document in particular:
https://www.w3.org/policies/process/#reg-ref-specifications


Thanks,
François.

>
> Nigel
>
>
>
> On 16/07/2026, 12:10, "Francois Daoust" <fd@w3.org <mailto:fd@w3.org>> wrote:
>
>
> External: Think before clicking
>
>
> Hello Media Working Group participants,
>
>
> The group maintains a number of registries on the Registry Track [1].
> These registries are currently published as Registry Drafts. In order to
> advance these documents on the Registry Track and publish them as
> Candidate Registry Snapshots, we need to solicit wide review of these
> documents.
>
>
> Registries document values and do not define normative requirements
> related to those values. It is not entirely clear what horizontal review
> groups might be interested in reviewing in registry documents (we'll be
> the first W3C group to request such reviews in practice).
>
>
> I'm proposing to send the documents in bulk to the horizontal review
> groups along with the note copied below. Let me know if you have comments!
>
>
> Side note: publishing registries as Candidate Registry Snapshots does
> not prevent adding more entries to the table. It just makes the
> registration entry requirements more stable.
>
>
> Thanks,
> François
>
>
> [1] https://www.w3.org/policies/process/#registries <https://www.w3.org/policies/process/#registries>
>
>
> -----
> 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).
>
>
> Registry linked to MSE:
> - Media Source Extensions Byte Stream Format Registry:
> https://www.w3.org/TR/mse-byte-stream-format-registry/ <https://www.w3.org/TR/mse-byte-stream-format-registry/>
>
>
> Registries linked to EME:
> - Encrypted Media Extensions Initialization Data Format Registry:
> https://www.w3.org/TR/eme-initdata-registry/ <https://www.w3.org/TR/eme-initdata-registry/>
>
>
> - Encrypted Media Extensions Stream Format Registry:
> https://www.w3.org/TR/eme-stream-registry/ <https://www.w3.org/TR/eme-stream-registry/>
>
>
> - Encrypted Media Extensions HDCP Version Registry:
> https://www.w3.org/TR/eme-hdcp-version-registry/ <https://www.w3.org/TR/eme-hdcp-version-registry/>
>
>
> Registries linked to WebCodecs:
> - WebCodecs Codec Registry:
> https://www.w3.org/TR/webcodecs-codec-registry/ <https://www.w3.org/TR/webcodecs-codec-registry/>
>
>
> - WebCodecs VideoFrame Metadata Registry:
> https://www.w3.org/TR/webcodecs-video-frame-metadata-registry/ <https://www.w3.org/TR/webcodecs-video-frame-metadata-registry/>
>
>
> 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).
>
>
>
>
>
>
>