Tracking issue: consider ECMA TC / W3C WG to publish standards

[lucacasonato]

We started discussing chartering a ECMA TC / W3C WG to be able to publish first party standards from WinterCG, namely to support the Socket API and Common Minimum API.

There was a bit of discussion at the last meeting, that I want to summarize here. We can use this thread as a starting point to discuss this topic further:

---

Summary of benefits of a standards body:

• has the ability to publish standards.
• CG can not publish standards, our charter prohibits this.
• CG has different licensing / copyright / patent implications than a standards body. This is effectively a CLA. With a standards body, we get something stronger: a royalty free patent on work published by the standards body.
• Standards specified by "real" standards bodies have a stronger sense of "standard" and "officialness".
• Anti-trust implications
• Standards bodies have a rules based system to permit members. This can help with inclusion.

Summary of benefits of ECMA specifically:

• Dan knows us how to work through ECMA.
• ECMA does not require arguing about chartering.
• Members have no resposibilities.
• Some of our primary members are not members of ECMA.

Summary of drawbacks of ECMA specifically:

• Members have to pay a membership fee.
• Inclusivity is reduced because of this.

There was some talk about keeping all incubation and discussion work in the W3C CG (WinterCG) and only moving technical review and standardization work of new specs into the TC/WG or relevant upstream standards bodies for third-party specs (like fetch, streams, crypto etc). This would allow us to bypass many of the inclusion issues that a TC/WG would pose, while still giving a path for self publishing.

[littledan]

A few things I want to add:

• Ecma has an invited expert program, to recover the lost inclusivity due to membership fees. Also, universities and other non-profits can join for free.
• Most WinterCG participants seem to be Ecma members already, and we haven't heard concerns about joining from the bigcorp folks that aren't in Ecma yet.
• I want to emphasize that the idea is that the technical development/incubation of stuff would still happen in WinterCG, with the future WinterTC focusing on validation and standardization, not making technical changes. This is the model that TC54 (CycloneDX) is using.

[jasnell]

I'm absolutely +1 on Ecma as a target here. Overall I tend to prefer their process and the proximity to TC-39 I think makes it a good fit.

[michaelchampion]

Summary of drawbacks of ECMA specifically:

Members have to pay a membership fee.
Inclusivity is reduced because of this.

Those drawbacks also apply to W3C.

I generally agree that ECMA is the logical place to standardize the Winter CG work. But there are groups, such as Web Assembly, that find a good balance between open innovation in a CG and more rigorous testing/polishing/standardizing in a Working Group. There's no reason that both aspects of innovation/standardization have to be under the same organizational umbrella. The real work happens in the community, not the organization.

[michaelchampion]

CG has different licensing / copyright / patent implications than a standards body. This is effectively a CLA. With a standards body, we get something stronger: a royalty free patent on work published by the standards body.

I'm not sure about ECMA's patent policy, but that's not quite an accurate description of W3C's . CGs require a commitment by everyone joining to offer a royalty-free license on any patents touched on by their own contributions to the CG. WGs require all members of the group to commit to RF licenses on "essential" patents touched on by the eventual Recommendation. But W3C members who aren't in the working group don't have to make that commitment.

In practice, nobody actually negotiates the RF licenses called for by the patent policy. And last I heard (before I retired from Microsoft 4 years ago) almost none of this has been tested in actual case law. So it all comes down to having a well-functioning community of collaborating competitors who swear off using patents to get competitive advantage in some technology area.

[littledan]

In a recent call, WinterCG resolved to seek standardization via Ecma. I've drafted a proposed scope, program of work, and working mode below. I'd like to review this in a future call, and if approved, submit to Ecma for the formation of the TC.

Scope

To refine and standardize programming interface surfaces and behavior which are useful across multiple ECMAScript environments which expand beyond web browsers. This group has a special focus on server environments for ECMAScript, but it may extend beyond that to other environments as well. The scope includes defining new interfaces, cross-referencing other sets of standards, and defining modified behavior for other existing interfaces.

Programme of work

• Standardize and maintain a “common minimum API” consisting of a set of standard interfaces, starting from web standards, which form a common base which is supported by all “WinterTC-compliant” environments, primarily targeted at ECMAScript server runtimes.
• Publish errata/patches to other standards to note their changes in behavior in WinterTC environments vs the original intended environment (e.g., web browsers), where it is not possible to make those changes “upstream” in the originating standard.
• Standardize new built-in modules for JavaScript environments for particular capabilities which are reasonable/appropriate only outside of the web context, e.g., raw sockets.
• Work with other standards bodies and community groups, especially the W3C Winter CG, TC39, W3C and WHATWG. In particular, much of WinterTC’s work will be originally drafted in WinterCG, to be further verified and standardized in the TC.

Working mode

WinterTC meets quarterly (or more frequently, as needed) via teleconference to identify appropriate specifications to develop into standards, typically as requested from W3C WinterCG. WinterTC is responsible for closely examining and verifying proposed specifications, and improving them through editorial changes. When WinterTC identifies a technical deficit or area for improvement in a specification it is reviewing, this information is passed to WinterCG, directing them to address the issue and bring a draft back to WinterTC. After all appropriate review and iteration, WinterTC may recommend specifications for standardization to the Ecma GA.

[jasnell]

That looks great @littledan !

[littledan]

Thanks for the positive feedback. It'd be great to have this draft charter #58 (comment) on the agenda for the next WinterCG meeting, which I guess is January 4th.

[littledan]

This charter was approved by WinterCG on January 4th. I will take the next steps from here, of bringing this charter for approval at the next Ecma ExeCom and GA meetings.

[Jack-Works]

I wonder, if the API is from W3C (e.g. fetch), can WinterCG "republish" it again on its own? Does this process require WinterCG to claim it owns the intellectual property in some form?

[andreubotella]

I wonder, if the API is from W3C (e.g. fetch), can WinterCG "republish" it again on its own? Does this process require WinterCG to claim it owns the intellectual property in some form?

For W3C, I think it depends on the spec. Some, like CSS specs, are published under open source licenses, whereas I think others aren't. But fetch is WHATWG, which is always open source (both CC-BY and BSD 3-clause).

[littledan]

@Jack-Works Hopefully we'll handle fetch through upstream collaboration with WHATWG. If that falls through, then we could consider publishing a fork/diff via Ecma, if we can work out the intellectual property issues.

[littledan]

@andreubotella Note that patent and copyright are both relevant here; standards are a little more complicated than "is it open source licensed". Let's try to do as much work as possible upstream.

[littledan]

Following this group's approval of the plan to work with Ecma, I sought feedback from W3C staff on the charter of the proposed Ecma TC. Based on that feedback, we're currently considering a more restricted scope, which focuses just on the minimum common API:

• Revised scope and program of work
• Revised working mode

These revised drafts have been shared in the WinterCG Matrix channel and received signoff from @lucacasonato and @jasnell , WinterCG co-chairs. They will be reviewed soon by the Ecma Executive Committee ("ExeCom") and possibly subsequently sent to the Ecma membership ("GA") for formal approval via an electronic ballot.

[littledan]

The above plan for TC55 is not going forward at the moment. During the ballot, we heard the following concerns about TC55 which led all voting ("Ordinary") General Assembly (GA) members to vote against it or abstain:

1. In terms of intellectual property, the WinterCG + TC55 pairing would require that all intellectual property contributed to WinterCG also be licensed to Ecma for publication in a standard. The W3C Community Group agreement does this automatically when things move to a WG, but we'd have to ask WinterCG participants to "dual license" their contributions to Ecma. To make sure this is air-tight in an ongoing way, we'd want to ask WinterCG meeting participants to sign onto Ecma IPR policy as well (e.g., by joining TC55, or signing a non-member contributor agreement). Some organizations said that they would find such an arrangement difficult to sign onto, especially compared to the otherwise lightweight nature of joining a CG.

2. In terms of decision-making, the principle that TC55 was proposed under is that WinterCG makes decisions about what should be in the standard, which are then reviewed and analyzed by TC55 for suitability of standardization, possibly sending back to WinterCG if there are issues to address. On the Ecma side, this process is analogous to many other TCs, but on the W3C side, making such decisions is inappropriate for a Community Group, and should be done in a Working Group instead, as the W3C Process does not contain formal decision-making procedures for Community Groups.

3. Concerns were raised about the scope of TC55 being broad, but I have trouble making sense of this one, since the scope is very much limited to the "minimum common API", a definition of which web APIs are included in web-interoperable server environments. Some previous drafts also included the possibility of publishing server-only APIs, or of publishing errata to other standards for how they would work on servers, but these pieces were already removed from the version under ballot.

To address these issues, I propose to do the following:

1. To ensure that participants only need to sign onto one intellectual property policy, and to ensure that they have low exposure when joining the CG, we will need to do work either entirely within the W3C, or entirely within Ecma. In the W3C, we could do this by chartering a "WinterWG" to correspond to WinterCG and standardize the minimum common API. Several W3C participants assure me that there is positive precedent towards chartering non-web things in the W3C. Alternatively, we could charter TC55 but with a model more like TC39, where development happens in the TC. Ecma may be able to set up an analogous structure to a CG, for earlier incubation of ideas, if there is interest.

I do not have an opinion on whether the Web-interoperable Server Runtimes effort proceeds in W3C or Ecma. I believe either one could work well. Maybe W3C is a sensible default, given that we already have WinterCG there. Let's discuss the tradeoffs internally over the next few weeks and come to a decision as a group about how to proceed.

2. Now that we've "incubated" the minimum common API in WinterCG, the idea would be to transfer development to a formal W3C Working Group or Ecma Technical Committee. WinterCG (or an Ecma equivalent) would remain for "incubating" other early-stage ideas which aren't ready for formal standardization, which could include some of the topics which were excluded from the proposed TC55 scope.

3. I don't understand the scope issues well enough to see anything to change. Please raise any concerns to me so that I can take the appropriate action.

Let's discuss this standardization situation further, in an upcoming WinterCG meeting, maybe scheduling an additional meeting (#70) so that we can decide as a group how to proceed.

[littledan]

The next steps for WinterCG, to be led by Dan, Oliver and James, are to develop a more concrete plan to charter both a TC in Ecma to focus on the minimum-common-API, as well as to work with Ecma on a new process for establishing a CG-like structure for the broader scope of other APIs and coordinating with other standards bodies on upstream changes. We will continue this discussion in the following WinterCG meeting in one week before adopting any firm conclusion for the group.