- Host: Google Hangouts
- Dates: Wednesday December 6th, 2017
- Times: 8:00-9:00am Pacific Time
- Location: Brad will email Google Hangouts link to WG members + registered CG guests prior to the meeting
- Contact:
- Name: Brad Nelson
- Email: [email protected]
If you are a Working Group member no registration is required.
If you are a Community Group member who would like to observe, please register here: https://goo.gl/forms/HD2kLCM0iSKk7AVl1
The meeting will be a Google Hangouts call.
- Opening, welcome and roll call
- Opening of the meeting
- Introduction of attendees
- Find volunteers for note taking (chair to volunteer).
- Adoption of the agenda
- Proposals and discussions
- Discussion of W3C Process.
- NOTE: All of this is based on Brad's understanding of W3C docs. Brad is not a lawyer.
- Presention Details
- Adoption of CG specification
- Discussion of state of the core specification + JS & Web embedding.
- Adopting a first public working draft.
- Ramifications:
- Starts a 150 day clock on WG members (present and future) to notify the group of "essential claims".
- After that 150 days, only new claims based on changes to the spec can be excluded (everything else members must license).
- We have to publish a revised draft at least every 6 months after this. It need not have changes, but needs to explain why.
- When we revise the spec after this point, we have to carefully capture a list of what "substantive changes" have occurred, publishing that in a revised draft. That draft has a shorter clock (60-90 days depending on when someone resigns).
- If we advance from Working Draft to Candidate Recommendation and then need to change something, the process resets back to 0.
- POLL: We should adopt the current WebAssembly core + JS & Web spec as a "First Public Working Draft" for the WebAssembly Specification v.1.
- Ramifications:
- Future meetings
- Meeting times + collaborators in Asia-Pacific
- Discussion of meeting time logistics
- POLL: We should hold every third video call at an APAC friendly time.
- Confirm next meeting date + time.
- Meeting times + collaborators in Asia-Pacific
- Discussion of W3C Process.
- Closure
None.
None.
- Ben Titzer
- Kenneth Rohde Christiansen
- Brad Nelson
- JF Bastien
- Peter Jensen
- Luke Wagner
- Jacob Gravelle
- Eric Holk
- Deepti Gandluri
- Arun Purushan
- Andreas Rossberg
- Conrad Watt
- Michael Holman
- Limin Zhu
- Daniel Ehrenberg
- Derek Schuff
BN: Move to adopt
JF: second
Adopted.
* NOTE: All of this is based on Brad's understanding of W3C docs.
Brad is not a lawyer.
A W3C document passes through several stages. We have not yet entered the first stage. Normally there is a first public working draft, culminating in a candidate, and then the document is handed to the WG and they have their own process. There are changes that can rollback the process. diagram Even though we can move back to the beginning, one enters a small cycle (danger of getting kicked back to beginning). Main idea is that in the working draft phase, the main requirement is to document what has changed. Need to document substantive changes. 4 categories of changes. Editorial changes that aren’t substantive changes; substantive changes do potentially change conformance. The general requirements to advance through stages is that decisions must be recorded, get approval from a W3C director, and have a set a public documents that describe the delta since the previous public recommendation. Must formally address issues about the maturity of the document. Keep documentation on any formal objection. Also try to capture the reasons for the change.
Q: is the github documentation enough?
BN: This information is really for lawyers. They are concerned with whether they need to revisit any patent considerations
KC: This is why there is a distinction in the types of changes to separate them from the patent change.
KC: [for the WebF manifest spec] There is a tool that checks whether something gets broken and flags. Creates an issue and allows one to mark it as non-substantial.
BN: It looked nontrivial to set [the tool nazgul] up one repository for both CG and WG at the time.
BN: In our charter we listed our dependencies with other groups.
BN: One should also track where implementations are.
BN: There is no notion of previous maturity level required for first public working draft. Once we are in the working draft stage, every 6 months, if there are no significant changes, we are obliged to publish another draft that includes an explanation why no progress has happened. We don’t even need to have consensus to reach this step. Just have to keep capturing what changed and report what has happened since the previous step. All of it is motivated by the patent considerations. The first publication working draft triggers a “call for exclusions”, which require participants to declare the patents required to implement the draft. They have 150 days to disclose this. After this, they must grant a royalty free license for anyone implementing the standard. Someone joining also has the shorter of the original 150 days or 90 days. They have an opportunity to rewind to a previous draft.
BN: If we were to adopt a working draft now, all participants have to start the clock for their patent investigations. We are also then required to at least update every 6 months.
LW: What is new information here is that only the deltas are able to be considered. What is put out early essentially “times out”
BN: Yes, we have signed a death pact.
LW: Having a chance to read through the entire spec, it reads all pretty good.
DE: I feel comfortable with the JS and Web specs for first public working draft.
BN: There was a mismatch in our expectations about the process. We’re weird that we showed up with an almost done document. They are used to the document first, long before browsers have an implementation.
AR: For the core spec, there have been some small typo and note PRs. Non Substantive. Don’t see how we could have substantive changes, considering it is already shipped.
DE: In the JS spec, we may have some substantive changes, in terms of correctness of features that affect conformance. There are a few edge cases, but nothing major, and probably don’t carry much IP content.
BN: We have been operating on the assumption that [no restricted IP is likely needed for wasm in practice].
1. Adopting a first public working draft.
* Ramifications:
* Starts a 150 day clock on WG members (present and future)
to notify the group of "essential claims".
* After that 150 days, only new claims based on changes to the
spec can be excluded (everything else members must license).
* We have to publish a revised draft at least every 6 months
after this. It need not have changes, but needs to explain why.
* When we revise the spec after this point, we have to carefully
capture a list of what
["substantive changes"](https://www.w3.org/2017/Process-20170301/#substantive-change)
have occurred,
publishing that in a revised draft. That draft has a shorter
clock (60-90 days depending on when someone resigns).
* If we advance from Working Draft to Candidate Recommendation
and then need to change something, the process resets back to 0.
AR: The JS spec has not landed yet.
DE: If we wanted to land it after all changes, it would take a week or two.
BN: We could make it contingent upon some set of changes.
AR: I think we should land it sooner and iterate.
DE: I agree.
BN: Revise poll?
POLL: We should adopt the current WebAssembly core + JS & Web spec as a "First Public Working Draft" for the WebAssembly Specification v.1.
| SA | A | N | F | SF |
|---|---|---|---|---|
| 0 | 0 | 0 | 4 | 8 |
BN: We have a working draft!
BN: I will notify the W3C proper and they will send out the call for exclusions.
BN: Someone in the APAC timezone would prefer that we have some meeting times more friendly to asia. Last CG meeting concluded that the next CG meeting in Jan would target an asia-friendly time. Things are slightly different for WG. With the CG there was a regular cadence. Clashing with TC39 was problematic. But now we have times for the next TC39 meetings.
DE: Thanks for taking this into account.
JF: Do we have any asia-pacific participants that are WG members?
BN: We do.
BN: We have LG electronics and China Mobile.
JF: How do other WG groups handle this? For the CG we can do what we like, but for the WG we should try to lean on what other groups done.
BN: Generally there seem to be rotations of the time. Not sure how equitable those times are. We could do a rotation. Open to suggestions. With the CG, the primary difference is that we don’t have the strong signal of people in different zones. With the WG, we don’t yet have a regular cadence.
BN: What is the next useful checkpoint? What do Andreas and Dan think?
AR: I will not work much the rest of the year due to holidays.
DE: Might be one editorial change. If we had a checkpoint early next year, that would be helpful. (issue in question is initializing a module calls the start function).
LW: The megafunction needs to be split into pieces.
AR: Came up with another idea where that is not needed. Might get the chance but can’t guarantee.
BN: We are grabbing a lot of IP turf today, the incremental changes are trivial in comparison.
JF: After this meeting, Brad is sending an HTML document to W3C?
BN: Yes. Correct. There is a draft after with the additional changes.
DE: Suggest a month from now.
BT: Suggest second week of January.
BN: January 11?
(no main objections)
BT: Maybe do the APAC time after that.
BN: There will be a call for exclusions, so that is when people will start to chime in.
BN: Any objections to Jan 11 at 9am Pacific? (no objections)
BN: At that point we will think about trying an APAC friendly time.
* POLL: We should hold every third video call at an APAC friendly time.
POLL was tabled.
Happy new year!
Adjourn