Future of Runtime Keys

[Ethan-Arrowood]

The future of this repo has been discussed at a couple of recent WinterTC meetings. We've primarily agreed to investigate moving this to a proper registry via IANA. Members of WinterTC and members of OpenJS Package Metadata Interoperability can collaborate on the maintenance going forward (as a member of both groups I'm much in favor of this move).

There is some additional context here: openjs-foundation/package-metadata-interoperability-collab-space#35

@jasnell what are some next steps regarding IANA? I'm happy to complete them, just let me know what I should do 🚀

[Ethan-Arrowood]

The process is defined here: https://www.rfc-editor.org/rfc/rfc8126.html

I will go through this soon and begin taking the necessary steps.

[Ethan-Arrowood]

Getting this put together. The biggest decision I believe is on the review process. I think https://www.rfc-editor.org/rfc/rfc8126.html#section-4.5 most closely matches what we have today. But I'd be open to considering https://www.rfc-editor.org/rfc/rfc8126.html#section-4.4 .

I think (as long as I understand this correctly) we can use 4.4 First Come First Served as long as we make the requirement that reasonable documentation is also provided such as contact, website, repository. This would at least prevent "squating" of names while enabling a pretty efficient registration process.

Otherwise, 4.5 Expert Review is definitely the right option and we'd make a similar review process that submissions need to provide reasonable proof of naming use and then its basically first come first served.

Considering the early discussion around claiming the name edge, should we come up with some like set of restricted names that no one can claim?

[ljharb]

Perhaps a useful guideline is that nobody can casually claim an english dictionary word?

[Ethan-Arrowood]

That would prohibit entries like bun however which I think is totally fine. I was thinking more along the lines of like "the word cannot be a generalized concept directly related to web interoperable runtimes and edge computing".

Maybe this does mean we should go with Expert Review and include some language that its the Expert's opinion if a name is too general or what not.

[ljharb]

Key word being "casually" - exceptions should always be possible.

[Ethan-Arrowood]

Okay cool - I wonder how IANA requires the language for this

[Ethan-Arrowood]

Posting this here for longevity: https://claude.ai/share/d8f59f70-ef43-42b0-9a66-bd0b074380fa

I am busy and don't have time to completely learn the IANA process 😅 so I asked AI to summarize. I will work through this list and obviously double check with the actual source to make sure it's all correct. I'll be chipping away at this over the coming days. I will likely contribute the proposal as a document to this repo so others can make edits to it prior to submission to IANA.

[Ethan-Arrowood]

Call 6/26 - go with expert review

[jasnell]

Discussed on today's call... @gesa did some research into the possibility of using the Technical Report process under ECMA to use as a registry and it seems like the best way forward. Essentially we would need to develop a process for new keys to be proposed via a PR then have automation in place to automatically update a draft Technical Report document. Then, every six months or so the committee would look at the draft, approve it, then roll it over to be published as a Technical Report.

There'd be a little up front work to get the automation in place to generate the report, and some work to document the specific review and approval process for new submissions but using the TR approach would be far less effort than IANA/IETF and easier for us to oversee.

[gesa]

There would essentially be three discrete tasks to take on if the committee decided to own a registry of Runtime Keys as an Ecma Technical Report.

(the following all comes after the committee makes the decision to move forward and some tasks can happen in parallel)

1. Draft guidance
   The committee would need to write and come to consensus on guidelines for contributors, including rules on what is and is not allowed as a Runtime Key. My suggestion would be an emphasis on brevity, clarity, and specificity, with a prohibition on keys the committee finds to be too generic. For example, if company Acme makes a product they just call "Server", require a runtime key of acmeserver or some shortening of such, instead of server.
   The committee would also need to decide if there will be any guidelines regarding length of existence or consistency. Are you comfortable with the registry being extremely long and littered with dead projects in the name of it being thorough and reliably applicable? or is it more important that it be a more concise list of established projects that implies a presumption of stability?
   While this authoring process would go through the same consensus process of any other TC decision, I imagine there would be a point where the TC would wish to formally adopt these guidelines to send a message to the community about their expected application.
2. Automation for publication
   The committee, with the support of the Secretariat, would need to build an automation process to provide for appropriate dissemination and publication of the Technical Report. I am not prescriptive about this, and it could be done however the committee sees fit, but the output would need to include
   • A git branch that represents the current official version of the document (in machine-readable format, presumably JSON, and also associated with a Release or any other way you see fit to link to the doc/PDF)
   • A git branch that represents approved PRs since the last time the document was formally released, along with a disclaimer that this version is a draft
   • A documented process for converting the draft JSON into a human-readable document for publication. (The JSON would then be attached to and/or linked in the final Technical Report)
3. An ongoing plan for reviewing submissions
   There will need to be explicit ownership for reviewing pull requests and providing additional guidance or approval, and the committee will need to decide if a designee (delegate, delegates, or convener of a TG) has the authority to merge PRs into the draft or if the committee prefers to address each PR during plenary. The committee may wish to select an editor or editor group.
   The committee will also need to plan for scenarios which arise that may lead to a change in guidelines for adding new keys.

[Ethan-Arrowood]

Apologies I missed the last call - I was on vacation. @jasnell will you be on this week's call? I'm more than happy to do this work just need more information