Experimental disposition of comments from charter review 7 | 8 | ---- 9 | Issue 1. 10 | Summary: ISO WG for OFF has changed 11 | From: Vladimir Levantovsky 12 | Comment: https://github.com/w3c/IFT/issues/248#issuecomment-2544277944 13 | Response: https://github.com/w3c/IFT/issues/248#issuecomment-2548240773 14 | Closed: Accepted 15 | Verified: [url] 16 | Resolved: Bugfix (for obvious fixes) 17 | ---- 18 | Issue 2. 19 | Summary: Will participants need to rejoin 20 | From: Vladimir Levantovsky 21 | Comment: https://github.com/w3c/IFT/issues/248#issuecomment-2544277944 22 | Response: https://github.com/w3c/IFT/issues/248#issuecomment-2548240773 23 | Closed: Invalid 24 | Resolved: No change, will not need to rejoin 25 | ---- -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Draft charters for public review 2 | This repo is a space for draft charters to be developed for W3C Working 3 | Groups or W3C Interest Groups, to be discussed and refined. No charters that 4 | get added to this repo necessarily have any official standing at all—anyone 5 | can create a draft charter here for public discussion. If you’d like to have 6 | push access to add a draft charter to the repo, 7 | [file an issue requesting access](https://github.com/w3c/charter-drafts/issues) or fork this repo to make a pull request. 8 | 9 | 10 | See [the template](https://w3c.github.io/charter-drafts/charter-template.html) 11 | 12 | For W3C Community Groups, please start from the [CG charter template](https://github.com/w3c/cg-charter). 13 | 14 | 15 | # Using the template for a W3C Working Group 16 | 17 | The scope section serves a key function: to guide the WG chairs, participants, and reviewing legal teams on the outer boundaries of their work and patent commitments. To facilitate that review "Scope" should be limited to a clear description of the WG's permitted work areas. Other material (background, explanations, motivations) should go outside the Scope section. 18 | 19 | # Notes for W3C Team 20 | 21 | Before proposing a charter for review to the Advisory Committee, mark the charter "PROPOSED" and copy the PROPOSED charter to w3.org date-space (leaving a pointer to the github repo for continued issue-raising). That way, we can update the draft in response to AC review comments, without changing what's being reviewed. 22 | 23 | You are encouraged to give a pointer in the call for review to previous issue discussion, e.g. the charter-drafts github repo. 24 | 25 | Older drafts may be found in the /archive/ folder. 26 | -------------------------------------------------------------------------------- /2025/png-wg.bsi: -------------------------------------------------------------------------------- 1 | Title: PNG 2025 charter 2 | Draft: https://w3c.github.io/charter-drafts/2025/png-wg.html 3 | ED: none 4 | Date: 2025-08-30 5 | Status: Charter 6 | Intro:

Disposition of comments from charter refinement 7 | 8 | ---- 9 | Issue 1. 10 | Summary: Wrong link to 2023 charter 11 | From: Chris Needham 12 | Comment: https://github.com/w3c/png/issues/535#issuecomment-3234508438 13 | Response: https://github.com/w3c/png/issues/535#issuecomment-3237504944 14 | Closed: Accepted 15 | Verified: 16 | Resolved: Fixed link 17 | ---- 18 | Issue 2. 19 | Summary: More motivation and background 20 | From: Chris Needham 21 | Comment: https://github.com/w3c/png/issues/535#issuecomment-3234508438 22 | Response: https://github.com/w3c/png/issues/535#issuecomment-3239211333 23 | Closed: Accepted 24 | Verified: 25 | Resolved: Added history to Motivation & Background 26 | ---- 27 | Issue 3. 28 | Summary: Re-arrange order in Scope section 29 | From: Chris Needham 30 | Comment: https://github.com/w3c/png/issues/535#issuecomment-3234508438 31 | Response: https://github.com/w3c/png/issues/535#issuecomment-3237508786 32 | Closed: Accepted 33 | Verified: https://github.com/w3c/png/issues/535#issuecomment-3237589215 34 | Resolved: Re-arranged order 35 | ---- 36 | Issue 4. 37 | Summary: Consider adding C2PA metadata 38 | From: Fares Alhassen 39 | Comment: https://lists.w3.org/Archives/Public/public-png/2025Aug/0004.html 40 | Response: https://lists.w3.org/Archives/Public/public-png/2025Aug/0005.html 41 | Response: https://lists.w3.org/Archives/Public/public-png/2025Aug/0006.html 42 | Response: https://lists.w3.org/Archives/Public/public-png/2025Aug/0007.html 43 | Closed: Accepted 44 | Verified: 45 | Resolved: Group will discuss at next meeting 46 | Resolved: Resolved at 29 Sept 2025 meeting to add C2PA to Fourth Edition. No charter change needed. 47 | ---- 48 | Issue 5. 49 | Summary: Put C2PA metadata in Scope 50 | From: Chris Needham 51 | Comment: https://github.com/w3c/png/issues/535#issuecomment-3234517650 52 | Response: https://github.com/w3c/png/issues/535#issuecomment-3239192214 53 | Closed: Accepted 54 | Verified: https://github.com/w3c/png/issues/535#issuecomment-3237589215 55 | Resolved: Added general statement about metadata (covers C2PA, but not restricted to that) 56 | ---- 57 | Issue 6. 58 | Summary: Mention HDR and compression in Scope 59 | From: Chris Needham 60 | Comment: https://github.com/w3c/png/issues/535#issuecomment-3234508438 61 | Response: https://github.com/w3c/png/issues/535#issuecomment-3237513653 62 | Closed: Accepted 63 | Verified: https://github.com/w3c/png/issues/535#issuecomment-3237589215 64 | Resolved: Added mentions 65 | ---- 66 | Issue 7. 67 | Summary: Additional metadata may raise additional privacy concerns 68 | From: @sandandsnow 69 | Comment: https://github.com/w3cping/privacy-request/issues/171#issuecomment-3267335663 70 | Response: https://github.com/w3cping/privacy-request/issues/171#issuecomment-3318294118 71 | Closed: Accepted 72 | Resolved: No changes to charter 73 | 74 | -------------------------------------------------------------------------------- /2025/webfonts-wg.bsi.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | WebFonts 2025 charter Disposition of Comments for 2024-12-19 Charter 4 | 12 | 13 |

WebFonts 2025 charter Disposition of Comments for 2024-12-19 Charter

An issue can be closed as Accepted, OutOfScope, 35 | Invalid, Rejected, or Retracted. 36 | Verified indicates commentor's acceptance of the response.

Encrypted Media Agreement

19 | The Web has been built through iteration and collaboration, and enjoys strong security because so many people are able to continually test and review its designs and implementations. As the Web gains interfaces to new device capabilities, we rely even more on broad participation, testing, and audit to keep users safe and the web’s security model intact. Therefore, W3C policy should assure that such broad testing and audit continues to be possible, as it is necessary to keep both design and implementation quality high. 20 |

22 | The following obligations shall apply to all participants in the W3C HTML Media Extension Working Group. These obligations will be referenced from each Working Group charter and Calls for Participation. 23 |

1. Security Research Requirements for All Working Group Participants

26 | As a condition of participating in a Working Group, each participant (W3C Members, W3C Team members, invited experts, and members of the public) 27 | shall agree to make available under W3C Encrypted Extensions licensing requirements any implementations related to the work of that particular Working Group. This requirement includes Implementations that the participant owns and any that the participant has the right to license. 28 |

30 | Only the affirmative act of joining a Working Group, or otherwise agreeing to the licensing terms described here, will obligate a Member to the W3C Encrypted Extensions licensing commitments. Mere Membership in W3C alone, without other factors, does not give rise to the Content Protection licensing obligation under this policy. 31 |

2. W3C Encrypted Extensions Licensing Requirements

34 | With respect to a Recommendation developed under this policy, a W3C Encrypted Extensions license shall mean a non-assignable, non-sublicensable license that: 35 |

PNG 2025 charter Disposition of Comments for 2025-08-30 Charter

An issue can be closed as Accepted, OutOfScope, 35 | Invalid, Rejected, or Retracted. 36 | Verified indicates commentor's acceptance of the response.

32 | Security Web Application Guidelines (SWAG) Community Group Charter 33 |

45 | Goals 46 |

48 | The mission of this Community Group is to increase the overall security 49 | of web application development, thereby making the 50 | web a more 51 | secure platform for web users. 52 | It will accomplish this by writing web developers security best practices 53 | and providing a platform for stakeholder collaboration. 54 |

56 | Scope of Work 57 |

92 | Out of Scope 93 |

95 | The development of normative standards and technical specifications is not in the scope of the Community Group. 96 |

102 | Deliverables 103 |

105 | Non-Normative Reports 106 |

111 | The group may produce other Community Group Reports within the scope of 112 | this charter but that are not Specifications, for instance use cases, 113 | requirements, or white papers. 114 |

116 | Test Suites and Other Software 117 |

119 | The group MAY produce test suites to support the Specifications. Please 120 | see the GitHub LICENSE file for test suite contribution licensing 121 | information. 122 |

124 | Dependencies or Liaisons 125 |

134 | Community and Business Group Process 135 |

137 | The group operates under the Community and Business 139 | Group Process. Terms in this Charter that conflict with those of the 140 | Community and Business Group Process are void. 141 |

143 | As with other Community Groups, W3C seeks organizational licensing 144 | commitments under the W3C Community 146 | Contributor License Agreement (CLA). When people request to 147 | participate without representing their organization's legal interests, 148 | W3C will in general approve those requests for this group with the 149 | following understanding: W3C will seek and expect an organizational 150 | commitment under the CLA starting with the individual's first request to 151 | make a contribution to a group Deliverable. 152 | The section on Contribution Mechanics describes 153 | how W3C expects to monitor these contribution requests. 154 |

163 | Work Limited to Charter Scope 164 |

166 | The group will not publish Specifications on topics other than those 167 | listed under Specifications above. See 168 | below for how to modify the charter. 169 |

171 | Contribution Mechanics 172 |

180 | Specifications created in the Community Group must use the 182 | W3C Software and Document License. All other documents produced by 183 | the group should use that License where possible. 184 |

186 | Community Group participants agree to make all contributions in the 187 | GitHub repo the group is using for the particular document. This may be 188 | in the form of a pull request (preferred), by raising an issue, or by 189 | adding a comment to an existing issue. 190 |

200 | Transparency 201 |

203 | The group will conduct all of its technical work in public. If the group 204 | uses GitHub, all technical work will occur in its GitHub repositories 205 | (and not in mailing list discussions). This is to ensure contributions 206 | can be tracked through a software tool. 207 |

209 | Meetings may be restricted to Community Group participants, but a public 210 | summary or minutes must be posted to the group's public mailing list, or 211 | to a GitHub issue if the group uses GitHub. 212 |

214 | Decision Process 215 |

217 | This group will seek to make decisions where there is consensus. Groups 218 | are free to decide how to make decisions (e.g. Participants who have 219 | earned Committer status for a history of useful contributions assess 220 | consensus, or the Chair assesses consensus, or where consensus isn't 221 | clear there is a Call for Consensus [CfC] to allow multi-day online 222 | feedback for a proposed course of action). It is expected that 223 | participants can earn Committer status through a history of valuable 224 | contributions as is common in open source projects. After discussion and 225 | due consideration of different opinions, a decision should be publicly 226 | recorded (where GitHub is used as the resolution of an Issue). 227 |

229 | If substantial disagreement remains (e.g. the group is divided) and the 230 | group needs to decide an Issue in order to continue to make progress, the 231 | Committers will choose an alternative that had substantial support (with 232 | a vote of Committers if necessary). Individuals who disagree with the 233 | choice are strongly encouraged to take ownership of their objection by 234 | taking ownership of an alternative fork. This is explicitly allowed (and 235 | preferred to blocking progress) with a goal of letting implementation 236 | experience inform which spec is ultimately chosen by the group to move 237 | ahead with. 238 |

240 | Any decisions reached at any meeting are tentative and should be recorded 241 | in a GitHub Issue for groups that use GitHub and otherwise on the group's 242 | public mail list. Any group participant may object to a decision reached 243 | at an online or in-person meeting within 7 days of publication of the 244 | decision provided that they include clear technical reasons for their 245 | objection. The Chairs will facilitate discussion to try to resolve the 246 | objection according to this decision process. 247 |

249 | It is the Chairs' responsibility to ensure that the decision process is 250 | fair, respects the consensus of the CG, and does not unreasonably favour 251 | or discriminate against any group participant or their employer. 252 |

254 | Chair Selection 255 |

257 | Participants in this group choose their Chair(s) and can replace their 258 | Chair(s) at any time using whatever means they prefer. However, if 5 259 | participants, no two from the same organisation, call for an election, 260 | the group must use the following process to replace any current Chair(s) 261 | with a new Chair, consulting the Community Development Lead on election 262 | operations (e.g., voting infrastructure and using RFC 2777). 264 |

280 | Participants dissatisfied with the outcome of an election may ask the 281 | Community Development Lead to intervene. The Community Development Lead, 282 | after evaluating the election, may take any action including no action. 283 |

285 | Amendments to this Charter 286 |

288 | The group can decide to work on a proposed amended charter, editing the 289 | text using the Decision Process described above. 290 | The decision on whether to adopt the amended charter is made by 291 | conducting a 30-day vote on the proposed new charter. The new charter, if 292 | approved, takes effect on either the proposed date in the charter itself, 293 | or 7 days after the result of the election is announced, whichever is 294 | later. A new charter must receive 2/3 of the votes cast in the approval 295 | vote to pass. The group may make simple corrections to the charter such 296 | as deliverable dates by the simpler group decision process rather than 297 | this charter amendment process. The group will use the amendment process 298 | for any substantive changes to the goals, scope, deliverables, decision 299 | process or rules for amending the charter. 300 |

32 | [PROPOSED] Games Community Group Charter 33 |

35 | This Charter is work in progress. To submit feedback, please use 36 | GitHub Issues where this 37 | Charter is being developed. 38 |

46 | Goals 47 |

49 | The goal of the Games Community Group is to improve the quality of open 50 | web standards that games developers rely on to create games. 51 |

53 | Scope of Work 54 |

The Games community group will not develop any normative specification. 74 | As such, there will not be any Essential Claims under the W3C Contributor 75 | License Agreement or Final Specification Agreement.

78 | Deliverables 79 |

81 | Specifications 82 |

88 | Non-Normative Reports 89 |

91 | The group may produce other Community Group Reports within the scope of 92 | this charter but that are not Specifications, for instance use cases, 93 | requirements, or white papers. 94 |

96 | Test Suites and Other Software 97 |

99 | The group may develop open source software as needed to demonstrate 100 | scenarios of interest, guidelines, and highlight possible gaps in web 101 | technologies. Please see the GiHub LICENSE file for software contribution 102 | licensing information. 103 |

109 | Dependencies or Liaisons 110 |

135 | Community and Business Group Process 136 |

138 | The group operates under the Community and Business 140 | Group Process. Terms in this Charter that conflict with those of the 141 | Community and Business Group Process are void. 142 |

144 | As with other Community Groups, W3C seeks organizational licensing 145 | commitments under the W3C Community 147 | Contributor License Agreement (CLA). When people request to 148 | participate without representing their organization's legal interests, 149 | W3C will in general approve those requests for this group with the 150 | following understanding: W3C will seek and expect an organizational 151 | commitment under the CLA starting with the individual's first request to 152 | make a contribution to a group Deliverable. 153 | The section on Contribution Mechanics describes 154 | how W3C expects to monitor these contribution requests. 155 |

164 | Work Limited to Charter Scope 165 |

167 | The group will not publish Specifications on topics other than those 168 | listed under Specifications above. See 169 | below for how to modify the charter. 170 |

172 | Contribution Mechanics 173 |

181 | Specifications created in the Community Group must use the 183 | W3C Software and Document License. All other documents produced by 184 | the group should use that License where possible. 185 |

187 | Community Group participants agree to make all contributions on 188 | public-facing tools chosen by the group (public mail list, GitHub 189 | repositories, public discussion forum). For GitHub, this may be 190 | in the form of a pull request (preferred), by raising an issue, or by 191 | adding a comment to an existing issue. 192 |

202 | Transparency 203 |

205 | The group will conduct all of its technical work in public. If the group 206 | uses GitHub, all technical work will occur in its GitHub repositories 207 | (and not in mailing list discussions). This is to ensure contributions 208 | can be tracked through a software tool. 209 |

211 | Meetings may be restricted to Community Group participants, but a public 212 | summary or minutes must be posted to the group's public mailing list, or 213 | to a GitHub issue if the group uses GitHub. 214 |

216 | Decision Process 217 |

219 | This group will seek to make decisions where there is consensus. Groups 220 | are free to decide how to make decisions (e.g. Participants who have 221 | earned Committer status for a history of useful contributions assess 222 | consensus, or the Chair assesses consensus, or where consensus isn't 223 | clear there is a Call for Consensus [CfC] to allow multi-day online 224 | feedback for a proposed course of action). It is expected that 225 | participants can earn Committer status through a history of valuable 226 | contributions as is common in open source projects. After discussion and 227 | due consideration of different opinions, a decision should be publicly 228 | recorded (where GitHub is used as the resolution of an Issue). 229 |

231 | If substantial disagreement remains (e.g. the group is divided) and the 232 | group needs to decide an Issue in order to continue to make progress, the 233 | Committers will choose an alternative that had substantial support (with 234 | a vote of Committers if necessary). Individuals who disagree with the 235 | choice are strongly encouraged to take ownership of their objection by 236 | taking ownership of an alternative fork. This is explicitly allowed (and 237 | preferred to blocking progress) with a goal of letting implementation 238 | experience inform which spec is ultimately chosen by the group to move 239 | ahead with. 240 |

242 | Any decisions reached at any meeting are tentative and should be recorded 243 | in a GitHub Issue for groups that use GitHub and otherwise on the group's 244 | public mail list. Any group participant may object to a decision reached 245 | at an online or in-person meeting within 7 days of publication of the 246 | decision provided that they include clear technical reasons for their 247 | objection. The Chairs will facilitate discussion to try to resolve the 248 | objection according to the decision process. 249 |

251 | It is the Chairs' responsibility to ensure that the decision process is 252 | fair, respects the consensus of the CG, and does not unreasonably favour 253 | or discriminate against any group participant or their employer. 254 |

256 | Chair Selection 257 |

259 | Participants in this group choose their Chair(s) and can replace their 260 | Chair(s) at any time using whatever means they prefer. However, if 5 261 | participants, no two from the same organisation, call for an election, 262 | the group must use the following process to replace any current Chair(s) 263 | with a new Chair, consulting the Community Development Lead on election 264 | operations (e.g., voting infrastructure and using RFC 2777). 266 |

282 | Participants dissatisfied with the outcome of an election may ask the 283 | Community Development Lead to intervene. The Community Development Lead, 284 | after evaluating the election, may take any action including no action. 285 |

287 | Amendments to this Charter 288 |

290 | The group can decide to work on a proposed amended charter, editing the 291 | text using the Decision Process described above. 292 | The decision on whether to adopt the amended charter is made by 293 | conducting a 30-day vote on the proposed new charter. The new charter, if 294 | approved, takes effect on either the proposed date in the charter itself, 295 | or 7 days after the result of the election is announced, whichever is 296 | later. A new charter must receive 2/3 of the votes cast in the approval 297 | vote to pass. The group may make simple corrections to the charter such 298 | as deliverable dates by the simpler group decision process rather than 299 | this charter amendment process. The group will use the amendment process 300 | for any substantive changes to the goals, scope, deliverables, decision 301 | process or rules for amending the charter. 302 |

32 | [DRAFT] Web of Things Community Group Charter 33 |

35 | {TBD: remove next sentence before submitting for 36 | approval} This Charter is work in progress. To submit feedback, 37 | please use Issues or 38 | the Pull Requst 392 39 | where Charter is being developed. 40 |

52 | Goals 53 |

55 | The goal of WoT Community Group is to accelerate the community activities around the recommendations and notes published by the WoT WG and IG. More concretely, the group aims to: 56 |

64 | Scope of Work 65 |

67 | In order to achieve the above goals, the scope of the Web of Things Community Group includes the following activities: 68 |

78 | In addition, 79 | the WoT CG will report the results of its activities back to the Web of Things Working and Interest Groups, 80 | the W3C membership, and the Web community. 81 |

83 | The Web of Things Community Group, together with the Web of Things Interest Group will decide in the future how to manage the 84 | Web of Things Website together. 85 | How this collaboration will work is defined in a separate document. 86 |

88 | Out of Scope 89 |

91 | Publishing recommendations (standards specifications) is out of the scope of this community group (thus the CLA patent policy does not apply) 92 |

94 | Deliverables 95 |

97 | Specifications 98 |

103 | Non-Normative Reports 104 |

106 | The group may produce other Community Group Reports within the scope of this charter 107 | that are not specifications, for instance use cases, requirements, implementation experience reports, or white papers. 108 |

110 | Test Suites and Other Software 111 |

116 | Other Deliverables 117 |

119 | The group may produce deliverables to promote or explain the W3C Web of Things standard. For example (but not limited 120 | to): 121 |

128 | Dependencies or Liaisons 129 |

131 | The Web of Things Community Group will manage dependencies and liaisons separately in the documents listed below: 132 |

138 | Any changes to these documents need to be either a Pull Request reviewed by the chairs or agreed upon in a public meeting. 139 |

141 | Community and Business Group Process 142 |

144 | The group operates under the Community and Business 146 | Group Process. Terms in this Charter that conflict with those of the 147 | Community and Business Group Process are void. 148 |

150 | As with other Community Groups, W3C seeks organizational licensing 151 | commitments under the W3C Community 153 | Contributor License Agreement (CLA). When people request to 154 | participate without representing their organization's legal interests, 155 | W3C will in general approve those requests for this group with the 156 | following understanding: W3C will seek and expect an organizational 157 | commitment under the CLA starting with the individual's first request to 158 | make a contribution to a group Deliverable. 159 | The section on Contribution Mechanics describes 160 | how W3C expects to monitor these contribution requests. 161 |

170 | Work Limited to Charter Scope 171 |

173 | The group will not publish on topics other than those 174 | listed under Deliverables above. See 175 | below for how to modify the charter. 176 |

178 | Contribution Mechanics 179 |

192 | Community Group participants agree to make all contributions in the 193 | GitHub repo the group is using for each particular deliverable. This may be 194 | in the form of a pull request (preferred), by raising an issue, or by 195 | adding a comment to an existing issue. 196 |

198 | Only commits against this repository's deliverables are considered contributions. 199 | Discussions that take place in chat platforms, social media or similar are not contributions and 200 | are exempt from the rules that apply to the deliverables. 201 | However, Code of Ethics and Professional Conduct still applies. 202 |

212 | Transparency 213 |

215 | The group will conduct all of its technical work, including organizational matters, in public. 216 | All technical work will occur in its GitHub repositories (and not in mailing list discussions or in chat platforms) 217 | and any work or discussion that happens elsewhere is not considered official. 218 | This is to ensure contributions can be tracked through a software tool. 219 | Announcements should be made via public emails and messages in chosen chat platform. 220 |

222 | Meetings may be restricted to Community Group participants, but a public 223 | summary or minutes must be posted to the group's public mailing list, or 224 | to a GitHub issue if the group uses GitHub. 225 |

227 | Decision Process 228 |

230 | This group will seek to make decisions where there is consensus. Groups 231 | are free to decide how to make decisions (e.g. Participants who have 232 | earned Committer status for a history of useful contributions assess 233 | consensus, or the Chair assesses consensus, or where consensus isn't 234 | clear there is a Call for Consensus [CfC] to allow multi-day online 235 | feedback for a proposed course of action). It is expected that 236 | participants can earn Committer status through a history of valuable 237 | contributions as is common in open source projects. After discussion and 238 | due consideration of different opinions, a decision should be publicly 239 | recorded (where GitHub is used as the resolution of an Issue). 240 |

242 | If substantial disagreement remains (e.g. the group is divided) and the 243 | group needs to decide an Issue in order to continue to make progress, the 244 | Committers will choose an alternative that had substantial support (with 245 | a vote of Committers if necessary). Individuals who disagree with the 246 | choice are strongly encouraged to take ownership of their objection by 247 | taking ownership of an alternative fork. This is explicitly allowed (and 248 | preferred to blocking progress) with a goal of letting implementation 249 | experience inform which spec is ultimately chosen by the group to move 250 | ahead with. 251 |

253 | Any decisions reached at any meeting are tentative and should be recorded 254 | in a GitHub Issue for groups that use GitHub and otherwise on the group's 255 | public mail list. Any group participant may object to a decision reached 256 | at an online or in-person meeting within 7 days of publication of the 257 | decision provided that they include clear technical reasons for their 258 | objection. The Chairs will facilitate discussion to try to resolve the 259 | objection according to the decision process. 260 |

262 | It is the Chairs' responsibility to ensure that the decision process is 263 | fair, respects the consensus of the CG, and does not unreasonably favour 264 | or discriminate against any group participant or their employer. 265 |

267 | Chair Selection 268 |

270 | Participants in this group choose their Chair(s) and can replace their 271 | Chair(s) if 5 participants, no two from the same organisation, call for an election. 272 | To do so, the group must use the following process to replace any current Chair(s) 273 | with a new Chair, consulting the Community Development Lead on election 274 | operations (e.g., voting infrastructure and using RFC 2777). If there are not enough participants 276 | or the participants are from the same organisation, thus not meeting the above-mentioned 277 | criteria, participants should ask the Community Development Lead to intervene. 278 |

294 | Participants dissatisfied with the outcome of an election may ask the 295 | Community Development Lead to intervene. The Community Development Lead, 296 | after evaluating the election, may take any action including no action. 297 |

299 | Amendments to this Charter 300 |

302 | The group can decide to work on a proposed amended charter, editing the 303 | text using the Decision Process described above. 304 | The decision on whether to adopt the amended charter is made by 305 | conducting a 30-day vote on the proposed new charter. The new charter, if 306 | approved, takes effect on either the proposed date in the charter itself, 307 | or 7 days after the result of the election is announced, whichever is 308 | later. A new charter must receive 2/3 of the votes cast in the approval 309 | vote to pass. The group may make simple corrections to the charter such 310 | as deliverable dates by the simpler group decision process rather than 311 | this charter amendment process. The group will use the amendment process 312 | for any substantive changes to the goals, scope, deliverables, decision 313 | process or rules for amending the charter. 314 |

End date	31 March 2021
Confidentiality	Proceedings are Member-only
Chair	Donald Deutsch 70 \| (Oracle)
Initial Team Contacts 74 \| (FTE %: 10)	Rigo Wenning (5%), Wendy Seltzer (5%)
Usual Meeting Schedule	Teleconferences: The Interest Group may also 80 \| conduct virtual meetings using email, IRC, wiki and teleconference 81 \| facilities 82 \| Face-to-face: The Patent and Standards Interest Group may meet 83 \| face-to-face on the order of once or twice each year. It may also 84 \| sponsor "Birds-Of-a-Feather" sessions at conferences, W3C Advisory 85 \| Committee Meetings or Technical Plenaries or alongside other W3C 86 \| meetings, at the discretion of the Chair(s).

End date	31 March 2024
Confidentiality	Proceedings are Member-only
Chair	Donald Deutsch 70 \| (Oracle)
Initial Team Contacts 74 \| (FTE %: 10)	Rigo Wenning (5%), Wendy Seltzer (5%)
Usual Meeting Schedule	Teleconferences: The Interest Group may also 80 \| conduct virtual meetings using email, IRC, wiki and teleconference 81 \| facilities 82 \| Face-to-face: The Patent and Standards Interest Group may meet 83 \| face-to-face on the order of once or twice each year. It may also 84 \| sponsor "Birds-Of-a-Feather" sessions at conferences, W3C Advisory 85 \| Committee Meetings or Technical Plenaries or alongside other W3C 86 \| meetings, at the discretion of the Chair(s).

64 |

PROPOSED Web Accessibility Initiative (WAI) Interest Group Charter

65 |

The mission of the Web Accessibility Initiative Interest Group (WAI IG) is to promote awareness of W3C accessibility work and publications, encourage engagement in W3C accessibility work, and provide an open public forum for sharing information related to web accessibility.

66 |

67 |

Join the WAI Interest Group mailing list.

68 |

69 | 70 | 71 |

This proposed charter is available 72 | on GitHub. 73 | 74 | Feel free to raise issues.

75 |

76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 | 101 | 102 |

Charter Status	See the group status page.
Start date	[dd monthname yyyy] (date of the "Call for Participation", when the charter is approved)
End date	[dd monthname yyyy] (Start date + 2 years)
Chairs	Ashley Abaragu (Knowbility)
Team Contacts	Shawn Lawton Henry (0.03 FTE)
Meeting Schedule	Teleconferences: Teleconferences are not on a set schedule and may be planned for specific topics. 100 \| Face-to-face: In-person hybrid meetings maybe held, usually no more than 1 per year.

103 |

104 |

105 |

Motivation and Background

106 |

Reaching stakeholders who are not invovled in other W3C work is a key aspect of W3C's mission related to accessibility — in order to increase awareness of W3C accessibility materials and solicit input on developing materials. The WAI IG mailing lists have served as the primary method for this connection; and while other methods such as social media are now also used, the WAI IG mailing lists continue to be an important method for connection with W3C accessibility work.

107 |

WAI IG is a well-established Interest Group with over 2,700 participants in the email lists. WAI IG contributes to a comprehensive accessibility approach at W3C.

108 |

WAI IG connects those who want to be informed of W3C accessibility work and share input on accessibility issues. Some who are subscribed to the IG mailing lists participate in a W3C working group and want to be informed of work in other groups; most do not participate in other W3C groups.

109 |

WAI IG provides a forum for sharing information on accessibility activities at W3C and around the world, and exploring accessibility issues and solutions. The WAI IG actively encourages participation from industry, government, research, academia, people with disabilities, and others interested in accessibility.

110 |

111 |

112 |

Scope

113 |

The WAI Interest Group's scope includes:

114 |

Promoting awareness of accessibility work and publications throughout W3C groups
Encouraging engagement in accessibility work throughout W3C groups
Inviting review of accessibility aspects of deliverables being developed by W3C groups
Exploring web accessibility issues and solutions
Sharing information and exchanging ideas about web accessibility activities around the world

121 |

122 |

Out of scope:

123 |

Development of technical specifications
Consistent with W3C's Antitrust and competition policy, the group will not discuss specific products or implementations

127 |

128 |

129 |

130 |

Deliverables

131 |

This Group reviews deliverables of other Groups and reviews WAI resources. The Group does not plan to develop additional deliverables.

132 |

133 |

134 |

Success Criteria

135 |

Continued participation via mailing list subscription from a broad range of stakeholders, including disability communities, research organizations, industry, government, and education; from a broad range of roles, including developers, designers, project managers, policy makers, advocates, and web users with disabilities; and from a broad range of levels, from beginners to experts in accessibility
Posting review invitations for accessibility-related deliverables from W3C groups, and notices of published accessibility standards, resources, and translations
Constructive exchange of information for increasing understanding of accessibility issues and solutions

140 |

This Interest Group expects to follow the 141 | W3C Technical Architecture Group (TAG) Web Platform Design Principles.

142 |

143 |

144 |

Coordination

145 |

For relevant issues, this Interest Group will seek additional input on accessibility, internationalization, privacy, and security with the relevant Working and 146 | Interest Groups, and with the TAG.

147 |

Additional coordination with the following Groups may be made, per the W3C Process Document:

148 |

149 |

W3C Groups

150 |

Accessibility Guidelines Working Group (AG WG) to promore the work and deliverables of the group, and invite review
Accessible Platform Architectures Working Group (APA WG) to promore the work and deliverables of the group, and invite review
ARIA Working Group (ARIA WG) to promore the work and deliverables of the group, and invite review
Internationalization Working Group to explore intersections between accessibility and internationalization

156 |

The WAI Interest Group will also coordinate with relevant W3C Community Groups (CG), such as the Accessibility Roles and Responsibilities Mapping (ARRM) CG, Advancing Accessibility Resources CG, and Accessibility Internationalization CG. This includes invitations to review documents developed by a CG that are published on the WAI subsite.

157 |

158 |

159 |

160 |

Participation

161 |

The WAI Interest Group is open to the public; W3C Membership is not a prerequisite. To participate anyone can:

162 |

subscribe to the Announcements List
subscribe to and send messages to the Discussion List

166 |

Participants in the group are required to follow the 167 | W3C Code of Conduct.

168 |

169 |

170 |

Communication

171 |

172 | Discussions of this Interest Group are conducted in public. This group primarily conducts its work via the public mailing list w3c-wai-ig@w3.org (archive). The public is invited to review, discuss, and contribute to this Interest Group.

173 |

Announcements from W3C staff are communicated through the public mailing list public-wai-announce@w3.org (archive).

174 |

Information about the group is available from the WAI Interest Group home page.

175 |

176 |

177 |

Decision Policy

178 |

Consistent with its mission, this group is not a decision-making body; rather, it provides a forum for discussion and advice on web accessibility topics.

179 |

This charter is written in accordance with the W3C Process Document (Section 5.2.3, Deciding by Vote) and includes no voting procedures beyond what the Process Document requires.

180 |

181 |

182 |

Patent Disclosures

183 |

The Interest Group provides an opportunity to 184 | share perspectives on the topic addressed by this charter. W3C reminds 185 | Interest Group participants of their obligation to comply with patent 186 | disclosure obligations as set out in Section 187 | 6 of the W3C Patent Policy. While the Interest Group does not 188 | produce Recommendation-track documents, when Interest Group 189 | participants review Recommendation-track specifications from Working 190 | Groups, the patent disclosure obligations do apply. For more information about disclosure obligations for this group, 191 | please see the licensing information.

192 |

193 |

194 |

Licensing

195 |

The W3C Software and Document license would apply for all deliverables.

196 |

197 |

198 |

About this Charter

199 |

This charter has been created according to section 3.4 of the Process Document. In the event of a conflict between this document or the provisions of any charter and the W3C Process, the W3C Process shall take precedence.

200 |

201 |

Charter History

202 | 203 |

A list of previous charters is available.

204 |

The following table lists details of all changes from the initial charter, per the W3C Process Document (section 4.3, Advisory Committee Review of a Charter).

205 | 206 | 207 | 208 | 209 | 210 | 211 | 212 | 213 | 214 | 215 | 216 | 217 | 218 | 219 | 220 | 221 | 222 | 223 | 224 | 225 | 226 | 227 | 228 | 229 | 230 | 231 | 232 | 233 | 234 | 235 | 236 | 237 | 238 | 239 | 240 | 241 | 242 | 243 | 244 | 245 | 246 | 247 | 248 | 249 | 250 | 251 | 252 | 253 | 254 | 255 | 256 | 257 | 258 | 259 | 260 | 261 | 262 | 263 | 264 | 265 | 266 | 267 | 268 | 269 | 270 | 271 | 272 | 273 | 274 | 275 | 276 | 277 | 278 | 279 | 280 | 281 | 282 | 283 | 284 | 285 | 286 | 287 | 288 | 289 | 290 | 291 | 292 | 293 | 294 | 295 | 296 | 297 | 298 | 299 | 300 | 301 | 302 | 303 | 304 | 305 | 306 | 307 | 308 | 309 | 310 | 311 | 312 | 313 | 314 | 315 | 316 | 317 | 318 | 319 | 320 | 321 | 322 | 323 | 324 | 325 | 326 | 327 | 328 | 329 | 330 | 331 | 332 | 333 | 334 | 335 | 336 | 337 |

Charter Period	Start Date	End Date	Changes
Initial charter	18 June 2001	31 October 2002	-
Charter extended	31 October 2002	31 August 2004	-
Rechartered	21 December 2004	19 December 2007	-
Charter extended	20 December 2007	30 June 2008	-
Charter extended	1 July 2008	31 December 2008	-
Charter extended	1 January 2009	30 June 2009	-
Charter extended	1 July 2009	9 August 2010	-
Rechartered	14 September 2010	30 June 2013	-
Charter extended	1 July 2013	30 September 2013	-
Charter extended	1 October 2013	18 May 2015	-
Charter extended	19 May 2015	15 July 2015	-
Charter extended	16 July 2015	13 August 2015	-
Rechartered	18 March 2016	31 December 2017	-
Charter extended	1 January 2018	31 March 2018	-
Rechartered	25 April 2018	31 March 2020	-
Charter extended	1 April 2020	30 September 2020	-
Charter extended	1 October 2020	20 November 2020	-
Rechartered	6 January 2021	5 January 2024	-
Charter extended	6 January 2024	30 June 2024	-
Charter extended	1 July 2024	31 December 2024	-

338 |

339 |

340 |

70 |

PROPOSED Web Security Interest Group Charter

71 |

Charter approved 11-1-2017 and updated in-place at https://www.w3.org/2011/07/security-ig-charter.html.

72 | 73 |

The mission of the Web Security Interest Group is to serve as a forum for discussions on improving standards and implementations to advance the security of the Web.

74 | 75 |

76 |

Join the Web Security Interest Group.

77 |

78 | 79 |

80 | 81 | 82 | 85 | 88 | 89 | 90 | 93 | 96 | 97 | 98 | 105 | 106 | 107 | 110 | 113 | 114 | 115 | 118 | 121 | 122 | 123 | 126 | 131 | 132 |

83 \| Start date 84 \|	86 \| [when approved] 87 \|
91 \| End date 92 \|	94 \| 1 January 2019 95 \|
108 \| Chairs 109 \|	111 \| Virginie Galindo, Gemalto; Kepeng Li, Alibaba; Ryan Ware, Intel 112 \|
116 \| Team Contacts 117 \|	119 \| Wendy Seltzer (0.05 FTE) and Samuel Weiler (0.05 FTE), W3C 120 \|
124 \| Meeting Schedule 125 \|	127 \| Teleconferences: as-needed. 128 \| 129 \| Face-to-face: we will meet during the W3C's annual Technical Plenary week. 130 \|

133 |

134 | 135 | 136 | 137 |

138 |

Scope

139 |

As the Web Platform around HTML5 emerges as a platform for sophisticated application development, security properties of both implementations and specifications become critical. This group provides a forum for technology designers, implementors, and other interested parties to work toward improving specifications and implementations to advance security of the Web overall. The group is, in particular, focused on the security properties of HTML5 and related APIs and technologies.

140 |

141 | 142 | 143 |

144 |

145 | Deliverables 146 |

147 |

As an Interest Group, this group has no formal deliverables. The group may propose additional 148 | standards work to the W3C and may publish Interest Group Notes on topics such as best 149 | practices, analysis of security issues, and design considerations.

150 |

The Group intends to focus its work on three categories of effort: 151 |

Incubation: Discussing ideas for new Recommendation-track work; dispatching 152 | promising ideas to a Community Group or Task Force; proposing drafts to W3C 153 | for Working Group chartering. 154 |
Horizontal Reviews: Assessing W3C drafts for security considerations and/or 155 | publishing questionnaires or other guidance to enable self-review by working groups. 156 |
Web Security Incident Review: Considering reported security incidents as 157 | input, e.g., to correct patterns of error, threat modeling, and new spec development. 158 |

159 |

160 | 161 |

162 | 163 | 164 | 165 |

166 |

Coordination

167 |

Technical coordination with the following Groups will be made, per the W3C Process Document:

168 | 169 | 170 | 171 |

172 |

W3C Groups

173 | 174 | 214 |

W3C Working Groups may ask this Interest Group to provide security review of 215 | specifications.

216 | 217 |

External Organizations

218 |

As needed

222 | 223 | 224 |

225 |

226 | 227 | 228 | 229 |

230 |

231 | Participation 232 |

233 |

234 | Participation in the Web Security Interest Group is open to the public. Any person interested in this topic is welcome to participate in this Interest Group. 235 |

236 | There are no minimum requirements for participation in this group: This IG is composed of the participants in the public-web-security@w3.org mailing list. 237 |

238 | The Chair may call occasional meetings consistent with the W3C Process requirements for meetings. 239 |

240 |

241 | The group encourages questions, comments and issues on its public mailing lists and document repositories, as described in Communication. 242 |

243 |

244 | 245 | 246 | 247 |

248 |

249 | Communication 250 |

251 |

252 | Technical discussions for this Interest Group are conducted in public.This group primarily conducts its work on the public mailing list public-web-security@w3.org. 253 |

254 |

255 | Information about the group (including details about deliverables, issues, actions, status, participants, and meetings) will be available from the Web Security Interest Group home page. 256 |

257 | 266 |

267 | 268 |

269 |

270 | Decision Policy 271 |

272 |

273 | This group will seek to make decisions through consensus and due process, per the W3C Process Document (section 3.3). Typically, an editor or other participant makes an initial proposal, which is then refined in discussion with members of the group and other reviewers, and consensus emerges with little formal voting being required.

274 |

275 | However, if a decision is necessary for timely progress, but consensus is not achieved after careful consideration of the range of views presented, the Chairs may call for a group vote, and record a decision along with any objections. 276 |

277 |

278 | To afford asynchronous decisions and organizational deliberation, any resolution (including publication decisions) taken in a face-to-face meeting or teleconference will be considered provisional. 279 | 280 | A call for consensus (CfC) will be issued for all resolutions (for example, via email and/or web-based survey), with a response period from one week to 10 working days, depending on the chair's evaluation of the group consensus on the issue. 281 | 282 | If no objections are raised on the mailing list by the end of the response period, the resolution will be considered to have consensus as a resolution of the Interest Group. 283 |

284 |

285 | All decisions made by the group should be considered resolved unless and until new information becomes available, or unless reopened at the discretion of the Chairs or the Director. 286 |

287 |

288 | This charter is written in accordance with the W3C Process Document (Section 3.4, Votes), and includes no voting procedures beyond what the Process Document requires. 289 |

290 |

291 | 292 | 293 | 294 |

295 |

Patent Disclosures

296 |

The Interest Group provides an opportunity to 297 | share perspectives on the topic addressed by this charter. W3C reminds 298 | Interest Group participants of their obligation to comply with patent 299 | disclosure obligations as set out in Section 300 | 6 of the W3C Patent Policy. While the Interest Group does not 301 | produce Recommendation-track documents, when Interest Group 302 | participants review Recommendation-track specifications from Working 303 | Groups, the patent disclosure obligations do apply. For more information about disclosure obligations for this group, 304 | please see the W3C 305 | Patent Policy Implementation.

306 |

307 | 308 | 309 | 310 |

311 |

Licensing

312 |

This Interest Group will use the W3C Software and Document license for all its deliverables.

313 |

314 | 315 | 316 |

317 |

318 | About this Charter 319 |

320 |

321 | This charter has been created according to section 5.2 of the Process Document. In the event of a conflict between this document or the provisions of any charter and the W3C Process, the W3C Process shall take precedence. 322 |

323 | 324 |

325 |

326 | Charter History 327 |

328 | 329 | 330 |

The following table lists details of all changes from the initial charter, per the W3C Process Document (section 5.2.3):

331 | 332 | 333 | 334 | 335 | 338 | 341 | 344 | 347 | 348 | 349 | 352 | 355 | 358 | 360 | 361 | 362 | 366 | 369 | 372 | 375 | 376 | 377 | 381 | 384 | 387 | 390 | 391 | 392 | 395 | 398 | 401 | 404 | 405 | 406 |

336 \| Charter Period 337 \|	339 \| Start Date 340 \|	342 \| End Date 343 \|	345 \| Changes 346 \|
350 \| Initial Charter 351 \|	353 \| 7 September 2011 354 \|	356 \| 31 March 2013 357 \|	359 \|
363 \| Charter Extension 364 \| (Announcement [member only]) 365 \|	367 \| 25 September 2013 368 \|	370 \| 31 March 2015 371 \|	373 \| Virginie Galindo appointed as as co-chair; Team Contact changed from Thomas Roessler to Wendy Seltzer. 374 \|
378 \| Charter Extension 379 \| (Announcement [member only]) 380 \|	382 \| 7 July 2015 383 \|	385 \| 30 June 2016 386 \|	388 \| Adam Barth stepped down as co-chair. 389 \|
393 \| Rechartered 394 \|	396 \| [when approved] 397 \|	399 \| 1 January 2019 400 \|	402 \| Added Kepeng Li and Ryan Ware as co-chairs; added Samuel Weiler as team contact 403 \|

407 |

408 |

409 |

75 |

DRAFT Exploration Interest Group Charter

76 | 77 | 78 |

The mission of the Exploration Interest Group 79 | is to provide W3C Members with a forum to explore and discuss emerging web-related technology trends 80 | and consider how the community could collaborate to shape those trends for the benefit of web users. 81 |

82 | 83 |

84 |

Join the Exploration Interest Group.

85 |

86 | 87 | 88 |

This draft charter is available 89 | on GitHub. 90 | 91 | Feel free to raise issues. 92 |

93 | 94 |

95 | 96 | 97 | 100 | 103 | 104 | 105 | 108 | 111 | 112 | 113 | 116 | 119 | 120 | 121 | 124 | 128 | 129 | 130 | 133 | 136 | 137 | 138 | 141 | 146 | 147 |

98 \| Charter Status 99 \|	101 \| See the group status page and detailed change history. 102 \|
106 \| Start date 107 \|	109 \| [dd monthname yyyy] (date of the "Call for Participation", when the charter is approved) 110 \|
114 \| End date 115 \|	117 \| [dd monthname yyyy] (Start date + 2 years) 118 \|
122 \| Chairs 123 \|	125 \| Heather Flanagan, Spherical Cow Consulting 126 \| Jet Ding, Huawei 127 \|
131 \| Team Contacts 132 \|	134 \| Xueyuan Jia (0.1 FTE) 135 \|
139 \| Meeting Schedule 140 \|	142 \| Teleconferences: monthly 143 \| 144 \| Face-to-face: we will meet during the W3C's annual Technical Plenary week; additional face-to-face meetings may be scheduled by consent of the participants, usually no more than 3 per year. 145 \|

148 |

149 | 150 |

151 |

Motivation and Background

152 |

153 | The W3C Process indicates that a role of the Advisory Board is to provide strategic guidance 154 | to the W3C. Analogous to Process Document management, the Advisory Board recognized that there 155 | is interest among the broader Membership for these discussions and encouraged the creation of a 156 | dedicated Interest Group for ongoing strategic conversations. 157 |

158 |

159 | The goal is to provide a platform to help W3C (including the W3C team) investigating emerging 160 | technology trends, analyzing their impacts on the evolution of Web technologies, and proposing 161 | ways for W3C to collaborate shaping the trends for the benefit of the Web users. 162 |

163 |

164 | 165 |

166 |

Scope

167 |

169 | Monitor industry and technology trends and analyze their potential impact on the Web. 170 |
172 | Based on these findings, develop strategic narratives to help the W3C community 173 | understand these trends, the relevance of W3C activities, or a gap analysis where 174 | there are no current W3C activities. 175 |
177 | Provide a forum for members of the W3C community (including the W3C team) to share 178 | updates with the Membership as part of broader strategic discussions (e.g., Strategy 179 | Team's Incubation Pipeline updates, liaison updates, Community Group updates). This 180 | is intended to complement other venues for updates, including both Member-focused discussions 181 | (e.g., AC meeting or AB-led Member meeting) and broader community discussions (e.g., TPAC breakouts). 182 | The value proposition of this Interest Group is to support deeper ongoing strategic conversations. 183 |
185 | Provide a forum for members of the W3C community (including the W3C team) to seek in-depth 186 | strategic input from the W3C Membership. Examples of who might seek strategic guidance from 187 | the Interest Group: Community Groups considering transitioning to a Working Group; parties who 188 | seek help resolving strategic issues related to a charter in development (as opposed to issues 189 | for which another group such as the TAG would be more appropriate). 190 |

192 |

193 | 194 |

195 |

196 | Deliverables 197 |

198 | 199 |

Updated document status is available on the group publication status page.

200 | 201 |

203 | Reports about industry and technology trends, their potential impact on the Web, and how W3C might play a role in shaping their trajectory. 204 |
206 | These reports would be informative only and could be reviewed by the W3C community, and where there appears to be consensus, published as 207 | Interest Group Notes. 208 |

210 |

211 | 212 |

213 |

Success Criteria

214 | 215 |

216 | Reports published by the IG inform strategic conversations within W3C, leading to visible activities 217 | such as new Community Groups, improvements or greater consensus around draft Working Group charters, 218 | W3C Workshops, AC meeting agenda items, TPAC breakout sessions, structured email discussions within 219 | the broader Membership, and productive liaisons. 220 |

221 |

222 | 223 |

224 |

Coordination

225 | 226 |

227 | For all deliverables, this Interest Group will seek horizontal review for 228 | accessibility, internationalization, privacy, and security with the relevant Working and 229 | Interest Groups, and with the TAG. 230 |

231 |

232 | This Interest Group should collaborate with all the groups developing proposals and specifications to coordinate about industry and technology trends. 233 |

234 | 235 |

Media and Entertainment Interest Group: The mission of the Media and Entertainment Interest Group is to provide a forum for media-related technical discussions to track progress of media features on the Web within W3C groups and use of Web technologies by external organizations, and to identify use cases and requirements that existing and/or new specifications need to meet to achieve a tighter support of media services on the Web.
Web & Networks Interest Group: The mission of the Web & Networks Interest Group is to explore solutions for web applications to leverage network capabilities in order to achieve better performance and resources allocation, both on the device and network.
Web of Things Interest Group: The mission of the Web of Things Interest Group is to counter the fragmentation of the Internet of Things by complementing available standards through Web technology capable of interconnecting existing Internet of Things platforms, devices, gateways, and cloud services.
Web Payment Security Interest Group: The mission of the Web Payment Security Interest Group is to enhance the security and interoperability of various Web payments technologies.
Web-based Digital Twins for Smart Cities Interest Group: The mission of the Web-based Digital Twins for Smart Cities Interest Group is to identify and document use cases and requirements that W3C specifications need to meet to support various services within Smart Cities.
Advisory Board: The Advisory Board provides ongoing guidance to the Team on issues of strategy and conflict resolution.
Technical Architecture Group: The TAG is a special working group within the W3C, chartered with stewardship of the Web architecture.
Web Platform Incubator Community Group: The Web Platform Incubator Community Group (WICG) provides a lightweight venue for proposing and discussing new web platform features. Please see the charter for more information.

253 |

254 | 255 | 256 | 257 |

258 |

259 | Participation 260 |

261 |

267 |

268 | The group encourages questions, comments and issues on its public mailing lists and document repositories, as described in Communication. 269 |

270 |

271 | The group also welcomes non-Members to contribute through its public communication channels. 272 |

273 |

Participants in the group are required (by the W3C Process) to follow the 274 | W3C Code of Conduct.

275 |

276 | 277 |

278 |

279 | Communication 280 |

281 |

282 | Discussions for this Interest Group are conducted in public: the meeting minutes from teleconference and face-to-face meetings will be archived for public review, and technical discussions and issue tracking will be conducted in a manner that can be both read and written to by the general public. 283 | The meetings themselves are not open to public participation, however. 284 |

285 |

286 | Information about the group (including details about deliverables, issues, actions, status, participants, and meetings) will be available from the Exploration Interest Group home page. 287 |

288 |

289 | Most Exploration Interest Group teleconferences will focus on discussion of particular emerging web-related technology trends, and will be conducted on an as-needed basis. 290 |

291 |

292 | This group primarily conducts its work on GitHub issues. 293 | The public is invited to review, discuss and contribute to this work. 294 |

295 |

296 | The group may use a Member-confidential mailing list for administrative purposes and, at the discretion of the Chairs and members of the group, for member-only discussions in special cases when a participant requests such a discussion. 297 |

298 |

299 | 300 | 301 | 302 |

303 |

304 | Decision Policy 305 |

306 |

307 | This group will seek to make decisions through consensus and due process, per the W3C Process Document (section 5.2.1, Consensus). 308 |

309 |

310 | As this group is exploratory, the group will: 311 |

312 |

gather information, ensuring that all sides of controversial ideas (e.g. blockchain tech, the potential benefits and perils of AI) are considered,
seek consensus on matters of fact, and if possible on matters of prediction/prescription,
publish reports recording the various positions, and may record the rough division of opinions in the group across those positions.

317 |

318 | To afford asynchronous decisions and organizational deliberation, any resolution taken in a face-to-face meeting or teleconference will be considered provisional. Group participants 319 | have a one week period to comment on provisional resolutions. 320 |

321 |

322 | All decisions made by the group should be considered resolved unless and until new information becomes available or unless reopened at the discretion of the Chairs. 323 |

324 |

325 | This charter is written in accordance with the W3C Process Document (Section 5.2.3, Deciding by Vote) and includes no voting procedures beyond what the Process Document requires. 326 |

327 |

328 | 329 |

330 |

Patent Disclosures

331 |

The Interest Group provides an opportunity to 332 | share perspectives on the topic addressed by this charter. W3C reminds 333 | Interest Group participants of their obligation to comply with patent 334 | disclosure obligations as set out in Section 335 | 6 of the W3C Patent Policy. While the Interest Group does not 336 | produce Recommendation-track documents, when Interest Group 337 | participants review Recommendation-track specifications from Working 338 | Groups, the patent disclosure obligations do apply. For more information about disclosure obligations for this group, 339 | please see the licensing information.

340 |

341 | 342 | 343 | 344 |

345 |

Licensing

346 |

This Interest Group will use the W3C Software and Document license for all its deliverables.

347 |

348 | 349 | 350 | 351 |

352 |

353 | About this Charter 354 |

355 |

356 | This charter has been created according to section 3.4 of the Process Document. In the event of a conflict between this document or the provisions of any charter and the W3C Process, the W3C Process shall take precedence. 357 |

358 | 359 |

360 |

361 | Charter History 362 |

363 |

Note:Display this table and update it when appropriate. Requirements for charter extension history are documented in the Charter Guidebook (section 4).

364 | 365 |

The following table lists details of all changes from the initial charter, per the W3C Process Document (section 4.3, Advisory Committee Review of a Charter):

366 | 367 | 368 | 369 | 370 | 373 | 376 | 379 | 382 | 383 | 384 | 387 | 390 | 393 | 396 | 397 | 427 | 428 |

371 \| Charter Period 372 \|	374 \| Start Date 375 \|	377 \| End Date 378 \|	380 \| Changes 381 \|
385 \| Initial Charter 386 \|	388 \| [dd monthname yyyy] 389 \|	391 \| [dd monthname yyyy] 392 \|	394 \| none 395 \|

429 |

430 | 431 |

432 |

Change log

433 | 434 | 435 |

Changes to this document are documented in this section.

436 | 442 |

443 |

444 |

72 |

[Draft] Web-based Signage Working Group Charter

73 | 74 |

The mission of the Web-based Signage Working Group is to provide APIs that enable a web application to get the device information and to control the device via a user agent in a digital signage terminal device.

75 | 76 |

77 |

Join the Web-based Signage Working Group.

78 |

79 | 80 |

81 | 82 | 83 | 86 | 89 | 90 | 91 | 94 | 97 | 98 | 99 | 100 | 103 | 106 | 107 | 108 | 111 | 114 | 115 | 116 | 119 | 124 | 125 |

84 \| Start date 85 \|	87 \| [dd monthname yyyy] (date of the "Call for Participation", when the charter is approved) 88 \|
92 \| End date 93 \|	95 \| [dd monthname yyyy] 96 \|
101 \| Chairs 102 \|	104 \| Kiyoshi Tanaka 105 \|
109 \| Team Contacts 110 \|	112 \| [team contact name] (0.1 FTE) 113 \|
117 \| Meeting Schedule 118 \|	120 \| Teleconferences: topic-specific calls may be held 121 \| 122 \| Face-to-face: we will meet during the W3C's annual Technical Plenary week; additional face-to-face meetings may be scheduled by consent of the participants, no more than 3 per year. 123 \|

126 |

127 | 128 |

129 |

Scope

130 |

This Working Group will define APIs for user agents ("UA"s hereafter) embedded in digital signage terminal devices ("devices" hereafter).

131 | 132 |

Web-based signage is a digital signage using web technologies. Web-based signage terminal functions are performed by a web application loaded on a UA. The web application is called a Web-based Signage Player (“player” hereafter), which shows digital signage contents in accordance with the order provided by the digital signage server. The player also should have terminal management functions such as terminal configuration, logging, and reporting as well as content management. Usually, once a player is loaded on a UA, it works automatically.

133 | 134 |

Two types of users exist for UAs of the devices. They are a device operator who remotely operates devices and audiences who watch the devices. The device operator, not always a human being but a server function, has access to UAs of devices. The operator typically does not have access to the devices physically but wants to control the devices beyond the network. On the contrary, audiences, who are anonymous and in the general public, do not have control over devices.

135 | 136 |

The signage UA should provide API for the player to be used by a device operator.

137 | 138 |

The Working Group will define the prior required APIs for the operator to manage the signage UA via web console of the controlling device. Basically, the APIs are classified to the following functions:

139 |

Get the device information
Control the device

143 |

144 | 145 |

These operations require protection mechanism to prevent unauthorized accesses.

146 | 147 |

The specifications produced by this Working Group will address security and privacy considerations because the device UAs controlled by the device operator rather than the audiences watching the devices. The considerations need to address the combination of both the UAs and the controlling device.

148 | 149 |

Members of the Working Group should review other working groups' deliverables that identified as being relevant to the Working Group's mission.

150 | 151 |

152 |

Out of Scope

153 |

The following features are out of scope, and will not be addressed by this Working Group.

154 | 155 |

This Working Group will not define or mandate hardware specification of devices.
This Working Group will not define the APIs for generic UAs but them for embedded UAs in devices.
This Working Group will not also define the security configuration because it depends on the device hardware configuration.

160 |

161 | 162 |

163 |

Success Criteria

164 |

In order to advance to Proposed Recommendation, each specification is expected to have at least two independent implementations of each of feature defined in the specification.

165 |

Each specification should contain a section detailing any known security or privacy implications for implementers, Web authors, and end users.

166 |

167 |

168 | 169 | 170 | 171 |

172 |

173 | Deliverables 174 |

175 | 176 |

Draft state indicates the state of the deliverable at the time of the charter approval. Expected completion indicates when the deliverable is projected to become a Recommendation, or otherwise reach a stable state.

177 | 178 |

179 |

180 | Normative Specifications 181 |

182 |

183 | The working group will deliver the following W3C normative specifications: 184 |

185 |

Power Status Management

188 |

This function consists of Power Status Control and Power Status Scheduling. This enables web applications to access the device’s power management system. Consulting the power status mode of the device, there are stand-by mode (display off and UA stopped) and display-off mode (only display off) in addition to running mode (display on and UA running). Power Status Control provides the function of changing the power status mode of the device to such modes for saving power. Resuming from stand-by mode, it needs a scheduled return, which is provided by Power Status Scheduling. By studying the use cases, the function will be consulted for enhancement.

189 |

Draft state:[No draft]

190 |

Contextual Information

193 |

The function consists of Signage Operational Information and Signage Functional Information. The information provided by this function is used for the device management and the content management for signage services. Signage Operational Information provides the unique information of the device such as hardware information (serial number, manufacture name, or model name), which is used for the device identification. Signage Functional Information allows us to get the functional information of the device such as resolution and size of display used for fitting the contents to display. The information obtained for the remote management may be enriched by use case discussion.

194 |

Draft state:Adopted from Web-based Signage Business Group

195 |

197 |

198 | 199 |

200 |

201 | Other Deliverables 202 |

203 |

Use cases and requirements:: The Working Group is strongly encouraging the participants to create and maintain use cases and requirements document for each specification. In addition, use cases regarding the web-based signage service are expected to be discussed in Web-based Signage Business Group.
Implementation guidelines:: The group may provide informative guidelines for implementers to encourage its implementation.

209 |

210 | Other non-normative documents may be created such as: 211 |

212 |

Primers
Non-normative group notes

216 |

217 | 218 |

219 |

220 | Milestones 221 |

222 | 223 | 224 | 225 | 226 | 227 | 228 | 229 | 230 | 231 | 232 | 233 | 234 | 235 | 236 | 237 | 238 | 239 | 240 | 241 | 242 |

Milestones
Specification	FPWD	CR	PR	Rec
Remote Management API	Q1 2017	Q3 2017	Q1 2018	Q3 2018

243 | 244 |

Note: The actual production of some of the deliverables may follow a different timeline. The group documents any schedule changes on the group home page.

245 |

246 |

247 | 248 | 249 | 250 |

251 |

Coordination

252 |

For all specifications, this Working Group will seek horizontal review for accessibility, internationalization, performance, privacy, and security with the relevant Working and Interest Groups, and with the TAG. Invitation for review must be issued during each major standards-track document transition, including FPWD and CR, and should be issued when major changes occur in a specification.

253 | 254 |

Additional technical coordination with the following Groups will be made, per the W3C Process Document:

255 | 256 |

257 |

W3C Groups

258 |

Web and TV Interest Group: The Web-based Signage Working Group intends to have its deliverables reviewed by the Web and TV Interest Group from the perspective of using a TV set as a device of Web-based signage.
Web of Things Interest Group: The goal of the Web of Things Interest Group is to accelerate the development of open markets of applications and services based on the role of Web technologies for a combination of the Internet of Things (IoT) with the Web of data. The Web-based Signage Working Group intends to collaborate with Web of Things Interest Group to create standard in the view point of a device as one of Things for remote management.
Web-based Signage Business Group: The Web-based Signage Business Group studies profiles for the player as well as use cases and requirements of web-based signage services.

268 | 269 |

External Organizations

270 |

ITU-T SG16 Q14 (Q14/16): ITU-T Q14/16 studies digital signage systems and services, currently including the web-based architecture of digital signage.
Digital Signage Consortium (DSC): Digital Signage Consortium studies and develops the digital signage services and systems with its member companies including location owners (buildings, railways), content and service providers, and system integrators.
Digital Signage Multimedia Alliance (DSMA): DSMA consists over 200 member companies dedicated to the digital signage industry, including end users, system integrators, content developers and manufacturers. DSMA is the organizer of the annual Digital Signage Asia Forum presented at the InfoComm China event.

279 | 280 | 281 |

282 |

283 | 284 | 285 | 286 |

287 |

288 | Participation 289 |

290 |

291 | To be successful, this Working Group is expected to have 10 or more active participants for its duration, including representatives from the key implementers of this specification, and active Editors and Test Leads for each specification. The Chairs, specification Editors, and Test Leads are expected to contribute half of a day per week towards the Working Group. There is no minimum requirement for other Participants. 292 |

293 |

294 | The group encourages questions, comments and issues on its public mailing lists and document repositories, as described in Communication. 295 |

296 |

297 | The group also welcomes non-Members to contribute technical submissions for consideration, with the agreement from each participant to Royalty-Free licensing of those submissions under the W3C Patent Policy. 298 |

299 |

300 | 301 | 302 | 303 |

304 |

305 | Communication 306 |

307 |

308 | Technical discussions for this Working Group are conducted in public. Meeting minutes from teleconference and face-to-face meetings will be archived for public review, and technical discussions and issue tracking will be conducted in a manner that can be both read and written to by the general public. Working Drafts and Editor's Drafts of specifications will be developed on a public repository, and may permit direct public contribution requests. 309 |

310 |

311 | Information about the group (including details about deliverables, issues, actions, status, participants, and meetings) will be available from the Web-based Signage Working Group home page. 312 |

313 |

314 | Most Web-based Signage Working Group teleconferences will focus on discussion of particular specifications, and will be conducted on an as-needed basis. 315 |

316 |

317 | This group primarily conducts its technical work on the public mailing list public-[email-list]@w3.org (archive). The public is invited to post messages to this list. 318 |

319 |

320 | The group may use a Member-confidential mailing list for administrative purposes and, at the discretion of the Chairs and members of the group, for member-only discussions in special cases when a participant requests such a discussion. 321 |

322 |

323 | 324 | 325 | 326 |

327 |

328 | Decision Policy 329 |

330 |

331 | This group will seek to make decisions through consensus and due process, per the W3C Process Document (section 3.3). Typically, an editor or other participant makes an initial proposal, which is then refined in discussion with members of the group and other reviewers, and consensus emerges with little formal voting being required.

332 |

333 | However, if a decision is necessary for timely progress, but consensus is not achieved after careful consideration of the range of views presented, the Chairs may call for a group vote, and record a decision along with any objections. 334 |

335 |

336 | To afford asynchronous decisions and organizational deliberation, any resolution (including publication decisions) taken in a face-to-face meeting or teleconference will be considered provisional. 337 | 338 | A call for consensus (CfC) will be issued for all resolutions (for example, via email and/or web-based survey), with a response period from one week to 10 working days, depending on the chair's evaluation of the group consensus on the issue. 339 | 340 | If no objections are raised on the mailing list by the end of the response period, the resolution will be considered to have consensus as a resolution of the Working Group. 341 |

342 |

343 | All decisions made by the group should be considered resolved unless and until new information becomes available, or unless reopened at the discretion of the Chairs or the Director. 344 |

345 |

346 | This charter is written in accordance with the W3C Process Document (Section 3.4, Votes), and includes no voting procedures beyond what the Process Document requires. 347 |

348 |

349 | 350 | 351 | 352 |

353 |

354 | Patent Policy 355 |

356 |

357 | This Working Group operates under the W3C Patent Policy (5 February 2004 Version). To promote the widest adoption of Web standards, W3C seeks to issue Recommendations that can be implemented, according to this policy, on a Royalty-Free basis. 358 | 359 | For more information about disclosure obligations for this group, please see the W3C Patent Policy Implementation. 360 |

361 |

362 | 363 | 364 | 365 |

366 |

Licensing

367 |

This Working Group will use the W3C Document license for all its deliverables.

368 |

369 | 370 | 371 | 372 |

373 |

374 | About this Charter 375 |

376 |

377 | This charter has been created according to section 5.2 of the Process Document. In the event of a conflict between this document or the provisions of any charter and the W3C Process, the W3C Process shall take precedence. 378 |

379 |

380 |

70 |

[PROPOSED] Service Workers Working Group Charter

71 | 72 |

The mission of the Service Workers Working Group 73 | is to enable Web applications to take advantage of persistent background processing, including hooks 74 | to enable bootstrapping of web applications while offline.

75 | 76 | 79 | 80 |

81 | 82 | 83 | 86 | 89 | 90 | 91 | 94 | 97 | 98 | 99 | 100 | 101 | 103 | 104 | 105 | 106 | 109 | 115 | 116 | 117 | 120 | 123 | 124 | 125 | 128 | 135 | 136 |

84 \| Start date 85 \|	87 \| [dd month yyyy the date when the group call for participation starts] 88 \|
92 \| End date 93 \|	95 \| 30 June 2019 96 \|
Charter extension	See Change History. 102 \|
107 \| Chairs 108 \|	110 \| 111 \| Jake Archibald, Google 112 \| Jatinder Mann, Microsoft 113 \| 114 \|
118 \| Team Contacts 119 \|	121 \| Mike Smith, Yves Lafon (0.1 FTE) 122 \|
126 \| Meeting Schedule 127 \|	129 \| Teleconferences: Teleconferences will be held approximately monthly. 130 \| 131 \| Face-to-face: The Working Group will meet during the W3C's annual Technical Plenary week; 132 \| additional face-to-face meetings will be scheduled by consent of the participants, 133 \| 2 or 3 times per year. 134 \|

137 |

138 | 139 |

140 |

Scope

141 |

Web Applications traditionally assume that the network is reachable, which is not always the case. 142 | The Working Group will specify event-driven services between the network layer and the application, 143 | allowing it to handle network requests gracefully even while offline. 144 | 145 | 152 | 153 |

154 |

Success Criteria

155 |

In order to advance to 156 | Proposed Recommendation, 157 | each specification is expected to have 158 | at least two independent implementations 159 | of each feature defined in the specification.

160 |

Each specification should contain a section detailing any known security or privacy implications 161 | for implementers, Web authors, and end users.

162 |

Each specification should have an associated testing plan developed in parallel, 163 | and complete by the time the specification reaches 164 | Candidate Recommendation; by Recommendation, there should be test suite for each deliverable, sufficiently broad to demonstrate interoperability.

165 |

Each specification should have implementation reports showing adoption, fostering the ready availability of multiple, independent, interoperable implementations, including in browsers, authoring, and validation tools, and usage on the Web.

166 | 167 |

If a critical mass of key stakeholders and implementers of this technology do not join the group, its charter should be re-examined by the W3C.

168 |

169 |

170 | 171 | 172 | 173 |

174 |

175 | Deliverables 176 |

177 | 178 |

More detailed milestones and updated publication schedules are available on the 179 | group publication status page.

180 | 181 |

Draft state indicates the state of the deliverable at the time of the charter approval. 182 | Expected completion indicates when the deliverable is projected to become a Recommendation, 183 | or otherwise reach a stable state.

184 | 185 |

186 |

187 | Normative Specifications 188 |

189 |

190 | The Working Group will deliver the following W3C normative specifications: 191 |

192 |

Service Workers

195 |

This specification defines an API.

196 | 197 |

Draft state: Working Draft

198 |

Expected completion: Version 1, Q4 2017

199 |

Adopted Working Draft:: Service Workers, November 10, 2016. 202 |
Reference Draft:: Service Workers, November 10, 2016, 204 | produced under the Web Platform Working Group. 205 |

207 | 208 |

209 | The Working Group may deliver the following W3C normative specifications: 210 |

211 |

Background Synchronisation: 214 |
This specification defines an API that uses Service Workers to permit both one-off and periodic synchronisation of data, 215 | for applications that use non-local data storage.
216 |

218 | 219 |

The Working group may produce multiple versions of each deliverable, reflecting developments 220 | in how much of the relevant technology is interoperably implemented.

221 | 222 |

223 | The working group intends to use a parallel specification-editing and -testing approach, 224 | where all normative specification changes are generally expected to have a corresponding test change, either 225 | in the form of new tests or modifications to existing tests, or must include the rationale for 226 | why test updates are not required for the proposed update. 227 |

228 | 229 | 230 |

231 | 232 |

233 |

234 | Other Deliverables 235 |

236 |

237 | Other non-normative documents may be created such as: 238 |

239 |

Use case and requirement documents;
Test suite and implementation report for the specification;
Primer or Best Practice documents to support web developers when designing applications.

244 |

245 | 246 |

247 |

Timeline

248 |

June 2017: First teleconference
August-September 2017: First face-to-face meeting
October 2017: Service Workers 1 Candidate Recommendation
October 2017: FPWD for Service Workers 2
2019: Service Workers 2
March 2019: Proposal for rechartering or closing the Working Group

256 |

257 |

258 | 259 |

260 |

Coordination

261 |

For all specifications, this Working Group will seek 262 | horizontal review 263 | for accessibility, internationalization, performance, privacy, and security with the 264 | relevant Working and Interest Groups, and with the 265 | TAG. 266 | Invitation for review must be issued during each major standards-track document transition, 267 | including FPWD 268 | and CR, 269 | and should be issued when major changes occur in a specification.

270 | 271 |

Additional technical coordination with the following Groups will be made, 272 | per the W3C Process Document:

273 | 274 |

275 |

W3C Groups

276 |

Web Platform Working Group: This group enables improved client-side application development on the Web, 279 | including application programming interfaces (APIs) for client-side development.
Web Performance Working Group: This group provides methods to measure and improve aspects of application performance of 282 | user agent features and APIs.
Web Application Security Working Group: This group develops security and policy mechanisms to improve the security of Web Applications, 285 | and enable secure cross-origin communication.

287 | 288 |

289 |

External Groups

290 | TC39 - ECMAScript Standards Body 291 |

292 |

293 | 294 | 295 | 296 |

297 |

298 | Participation 299 |

300 |

301 | To be successful, this Working Group is expected to have 6 or more active participants 302 | for its duration, including representatives from the key implementors of this specification, 303 | and active Editors and Test Leads for each specification. 304 | The Chairs, specification Editors, and Test Leads are expected to contribute 305 | half of a working day per week towards the Working Group. 306 | There is no minimum requirement for other Participants. 307 |

308 |

309 | The group encourages questions, comments and issues on its public mailing lists and document repositories, 310 | as described in Communication. 311 |

312 |

313 | The group also welcomes non-Members to contribute technical submissions for consideration, 314 | subject to contributors' agreement to the terms of the 315 | W3C Patent Policy. 316 |

317 |

318 | 319 | 320 | 321 |

322 |

323 | Communication 324 |

325 |

326 | Technical discussions for this Working Group are conducted in 327 | public: 328 | meeting minutes from teleconference and face-to-face meetings will be archived for public review, 329 | and technical discussions and issue tracking will be conducted in a manner that can be both 330 | read and written to by the general public. 331 | Working Drafts and Editor's Drafts of specifications will be developed on a public repository, 332 | and may permit direct public contribution requests. 333 | The meetings themselves may not open to public participation, however. 334 |

335 |

336 | Information about the group including details about deliverables, issues, actions, status, participants, and meetings 337 | will be available from the Service Workers Working Group home page. 338 |

339 |

340 | Working Group teleconferences will focus on discussion of particular issues, 341 | and will be conducted on an as-needed basis. 342 |

343 |

344 | This group primarily conducts its technical work 345 | on GitHub issues. 346 | The public is invited to review, discuss, and subject to agreement to the terms of the 347 | W3C Patent Policy contribute to this work. 348 |

349 |

350 | 351 | 352 | 353 |

354 |

355 | Decision Policy 356 |

357 |

358 | This group will seek to make decisions through consensus and due process, per the 359 | W3C Process Document (section 3.3). 360 | For technical decisions, an editor or other participant typically makes an initial proposal, 361 | which is then refined in discussion with members of the group and other reviewers, 362 | and consensus emerges with little formal voting being required.

363 |

364 | If consensus is not achieved after careful consideration of the range of views presented 365 | but a decision is necessary for timely progress, the Chairs may call for a vote, 366 | in accordance with the W3C Process Document (Section 3.4, Votes) 367 | and the process for asynchronous resolution described in the following paragraphs 368 | in which case they will record a decision along with any objections. 369 |

370 |

371 | To afford asynchronous decisions and organizational deliberation, any resolution including 372 | requests for transition of document states decisions 373 | taken in a face-to-face meeting or teleconference will be considered provisional. 374 |

375 |

376 | Any resolution taken in a face-to-face meeting or teleconference is to be considered provisional 377 | until 10 (ten) working days after the publication of the resolutions in meeting minutes 378 | on the working group's mailing list. 379 |

380 |

381 | A call for consensus (CfC) will be issued for all resolutions not proposed at a teleconference or face to face meeting 382 | with a response period of at least one week, based on the chair's evaluation of the group consensus on the issue. 383 |

384 |

385 | If no objections are raised on the mailing list by the end of the response period, 386 | the resolution will be considered to have consensus as a resolution of the Working Group. 387 |

388 |

389 | All decisions made by the group should be considered resolved unless and until new information becomes available, 390 | or unless reopened at the discretion of the Chairs or the Director. 391 |

392 |

393 | This charter is written in accordance with the W3C Process Document (Section 3.4, Votes), and includes no voting procedures beyond what the Process Document requires. 394 |

395 |

396 | 397 | 398 | 399 |

400 | 401 |

402 | Patent Policy 403 |

404 |

405 | This Working Group operates under the 406 | W3C Patent Policy 407 | (5 February 2004 Version). To promote the widest adoption of Web standards, 408 | W3C seeks to issue Recommendations that can be implemented according to this policy, 409 | on a Royalty-Free basis. 410 | 411 | For more information about disclosure obligations for this group, please see the 412 | W3C Patent Policy Implementation. 413 |

414 | 415 |

416 | 417 | 418 | 419 |

420 |

Licensing

421 |

This Working Group will use the 422 | W3C Software and Document license 423 | for all its deliverables.

424 |

425 | 426 | 427 | 428 |

429 |

430 | About this Charter 431 |

432 |

439 | 440 |

441 |

442 | Charter History 443 |

444 | 445 |

The Service Workers specification was originally chartered as a deliverable of the 446 | Web Applications Working Group in its 447 | charter for 2014-2016. When that group was merged 448 | into the Web Platform Working Group, the deliverable was maintained in its 449 | first and 450 | second charters.

451 |

The Background Synchronisation proposal has been developed in the W3C's 452 | Web Platform Incubator Group

453 |

This charter [proposal] brings the Service Worker specification to a new Working Group, and proposes the 454 | Background Synchronization specification a W3C Recommendation-track deliverable, according to the 455 | W3C Process Document (section 5.2.3).

456 | 457 | 458 |

459 |

460 |

83 \| Start date 84 \|	86 \| [when approved] 87 \|
91 \| End date 92 \|	94 \| 1 January 2019 95 \|
108 \| Chairs 109 \|	111 \| Virginie Galindo, Gemalto; Kepeng Li, Alibaba; Ryan Ware, Intel 112 \|
116 \| Team Contacts 117 \|	119 \| Wendy Seltzer (0.05 FTE) and Samuel Weiler (0.05 FTE), W3C 120 \|
124 \| Meeting Schedule 125 \|	127 \| Teleconferences: as-needed. 128 \| 129 \| Face-to-face: we will meet during the W3C's annual Technical Plenary week. 130 \|

336 \| Charter Period 337 \|	339 \| Start Date 340 \|	342 \| End Date 343 \|	345 \| Changes 346 \|
350 \| Initial Charter 351 \|	353 \| 7 September 2011 354 \|	356 \| 31 March 2013 357 \|	359 \|
363 \| Charter Extension 364 \| (Announcement [member only]) 365 \|	367 \| 25 September 2013 368 \|	370 \| 31 March 2015 371 \|	373 \| Virginie Galindo appointed as as co-chair; Team Contact changed from Thomas Roessler to Wendy Seltzer. 374 \|
378 \| Charter Extension 379 \| (Announcement [member only]) 380 \|	382 \| 7 July 2015 383 \|	385 \| 30 June 2016 386 \|	388 \| Adam Barth stepped down as co-chair. 389 \|
393 \| Rechartered 394 \|	396 \| [when approved] 397 \|	399 \| 1 January 2019 400 \|	402 \| Added Kepeng Li and Ryan Ware as co-chairs; added Samuel Weiler as team contact 403 \|

98 \| Charter Status 99 \|	101 \| See the group status page and detailed change history. 102 \|
106 \| Start date 107 \|	109 \| [dd monthname yyyy] (date of the "Call for Participation", when the charter is approved) 110 \|
114 \| End date 115 \|	117 \| [dd monthname yyyy] (Start date + 2 years) 118 \|
122 \| Chairs 123 \|	125 \| Heather Flanagan, Spherical Cow Consulting 126 \| Jet Ding, Huawei 127 \|
131 \| Team Contacts 132 \|	134 \| Xueyuan Jia (0.1 FTE) 135 \|
139 \| Meeting Schedule 140 \|	142 \| Teleconferences: monthly 143 \| 144 \| Face-to-face: we will meet during the W3C's annual Technical Plenary week; additional face-to-face meetings may be scheduled by consent of the participants, usually no more than 3 per year. 145 \|

84 \| Start date 85 \|	87 \| [dd monthname yyyy] (date of the "Call for Participation", when the charter is approved) 88 \|
92 \| End date 93 \|	95 \| [dd monthname yyyy] 96 \|
101 \| Chairs 102 \|	104 \| Kiyoshi Tanaka 105 \|
109 \| Team Contacts 110 \|	112 \| [team contact name] (0.1 FTE) 113 \|
117 \| Meeting Schedule 118 \|	120 \| Teleconferences: topic-specific calls may be held 121 \| 122 \| Face-to-face: we will meet during the W3C's annual Technical Plenary week; additional face-to-face meetings may be scheduled by consent of the participants, no more than 3 per year. 123 \|

84 \| Start date 85 \|	87 \| [dd month yyyy the date when the group call for participation starts] 88 \|
92 \| End date 93 \|	95 \| 30 June 2019 96 \|
Charter extension	See Change History. 102 \|
107 \| Chairs 108 \|	110 \| 111 \| Jake Archibald, Google 112 \| Jatinder Mann, Microsoft 113 \| 114 \|
118 \| Team Contacts 119 \|	121 \| Mike Smith, Yves Lafon (0.1 FTE) 122 \|
126 \| Meeting Schedule 127 \|	129 \| Teleconferences: Teleconferences will be held approximately monthly. 130 \| 131 \| Face-to-face: The Working Group will meet during the W3C's annual Technical Plenary week; 132 \| additional face-to-face meetings will be scheduled by consent of the participants, 133 \| 2 or 3 times per year. 134 \|

WebAssembly WG deployed: 1 Aug 2017 - 31 July 2019

WebFonts 2025 charter Disposition of Comments for 2024-12-19 Charter

Encrypted Media Agreement

1. Security Research Requirements for All Working Group Participants

2. W3C Encrypted Extensions Licensing Requirements

PNG 2025 charter Disposition of Comments for 2025-08-30 Charter

32 | Security Web Application Guidelines (SWAG) Community Group Charter 33 |

45 | Goals 46 |

56 | Scope of Work 57 |

92 | Out of Scope 93 |

102 | Deliverables 103 |

105 | Non-Normative Reports 106 |

116 | Test Suites and Other Software 117 |

124 | Dependencies or Liaisons 125 |

134 | Community and Business Group Process 135 |

163 | Work Limited to Charter Scope 164 |

171 | Contribution Mechanics 172 |

200 | Transparency 201 |

214 | Decision Process 215 |

254 | Chair Selection 255 |

285 | Amendments to this Charter 286 |

32 | [PROPOSED] Games Community Group Charter 33 |

46 | Goals 47 |

53 | Scope of Work 54 |

78 | Deliverables 79 |

81 | Specifications 82 |

88 | Non-Normative Reports 89 |

96 | Test Suites and Other Software 97 |

109 | Dependencies or Liaisons 110 |

135 | Community and Business Group Process 136 |

164 | Work Limited to Charter Scope 165 |

172 | Contribution Mechanics 173 |

202 | Transparency 203 |

216 | Decision Process 217 |

256 | Chair Selection 257 |

287 | Amendments to this Charter 288 |

32 | [DRAFT] Web of Things Community Group Charter 33 |

52 | Goals 53 |

64 | Scope of Work 65 |

88 | Out of Scope 89 |

94 | Deliverables 95 |

97 | Specifications 98 |

103 | Non-Normative Reports 104 |

110 | Test Suites and Other Software 111 |

116 | Other Deliverables 117 |

128 | Dependencies or Liaisons 129 |

141 | Community and Business Group Process 142 |

170 | Work Limited to Charter Scope 171 |

178 | Contribution Mechanics 179 |

212 | Transparency 213 |

227 | Decision Process 228 |

267 | Chair Selection 268 |

299 | Amendments to this Charter 300 |

2019 DRAFT Patents and Standards Interest Group Charter

Overview and Background

Mission Statement

Scope

Deliverables

Dependencies

Participation

Communication

Decision Policy

Patent Policy

About this Charter

Changes since the 2009 Charter

Extension history:

Contact

DRAFT 2021 Patents and Standards Interest Group Charter

Overview and Background

Mission Statement

Scope

Deliverables

Dependencies

Participation

Communication

Decision Policy

Patent Policy

About this Charter

Extension history:

Contact

PROPOSED Web Security Interest Group Charter