Migrate WInterCG Runtime Keys to this group

[Ethan-Arrowood]

WinterCG is making some (exciting) changes soon, and it feels most appropriate to move the Runtime Keys proposal to this group instead of WinterCG. This was presented and verbally agreed upon at the 01/09/25 WinterCG meeting. As the original author of https://github.com/wintercg/runtime-keys I fully support this move and will be happy to do the migration work.

Since this group does not really do "standards" or "proposals" like WInterCG, I'd likely migrate the Runtime Keys proposal to a markdown document within this repo, and include important historical information both on the WinterCG side and here about the document.

I'll add this to the February discussion for this group, and likely have the migration work done prior, so all that needs to be discussed is if other members of this group agree to the move.

[ljharb]

Is there a reason that winterTC couldn’t house it?

[Ethan-Arrowood]

it doesn't really fit in with ECMA standards/proposals. Furthermore, they want to cut down on scope of the group.

[ljharb]

Ecma TCs can have any kind of docs they want, they don’t have to just be standards/proposals, I’m not sure why that’s a sticking point for anyone. Was this discussed in a recent winter meeting?

[Ethan-Arrowood]

Yes, 01/09/25 call and previously as well.

[Ethan-Arrowood]

We discussed this today on the call, and we'd like to know exactly why WinterTC wants to transfer it. In particular we want to know that if this is relevant and important - why are they transfering it? If its not relevant anymore, should it be archived instead?

I will do my best to attend an upcoming WinterTC call to get answers here; otherwise, we have an opportunity to chat with James Snell at the OpenJS Standards call on March 4th.

[Ethan-Arrowood]

I attended the latest WinterTC meeting and got some more information. Summary:

• WinterTC believes Runtime Keys is out-of-scope since no other WinterTC proposal normatively references them
  • There is a chance this changes in the future (i.e. import.meta)
• But, they believe it is still a valuable resource, and thus do not want to simply deprecate/archive.
• The recommendation is to consider transferring to a formal registry body such as IANA and it can be managed by both WinterTC and this group

Since I originally created the registry keys doc, and am actively participating in both this group and WinterTC (invited expert), I'm going to collaborate with James Snell to see what we can do about IANA.

What does everyone think? I am in full support of this and think its a much better resolution than the document being transferred to this group to maintain

[ljharb]

I don’t follow how it’s out of scope, but IANA seems fine.

[Ethan-Arrowood]

It is not referenced by any other WinterTC specification, proposal, or document.

[ljharb]

That isn’t the definition of scope though - the scope is web-interoperable runtimes, which these keys definitively are in scope for.

[Ethan-Arrowood]

Which is why we are going to collaborate to move it to IANA together. Arguments can be made either way if a registry of runtime keys should be included in the WinterTC or this group. I think the better resolution is making it an actual registry 🌟

[ljharb]

Like I said, I'm fine moving it to IANA, but I don't agree that it's out of scope for WinterTC - if anything not referenced in a WinterTC spec/proposal/document isn't in scope, then no new proposals can be made either, since they're not referenced in one yet :-p