-
Notifications
You must be signed in to change notification settings - Fork 5
/
charter-2018.html
628 lines (626 loc) · 36 KB
/
charter-2018.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
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
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
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
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
<!DOCTYPE html>
<html lang="en-US" xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-US">
<head>
<meta charset="utf-8" />
<title> Second Screen Working Group </title>
<link rel="stylesheet" href="https://www.w3.org/2005/10/w3cdoc.css" type="text/css"
media="screen" />
<link rel="stylesheet" type="text/css" href="https://www.w3.org/Guide/pubrules-style.css" />
<link rel="stylesheet" type="text/css" href="https://www.w3.org/2006/02/charter-style.css" />
</head>
<body>
<div id="template">
<ul id="navbar" style="font-size: small">
<li> <a href="#goals">Goals</a> </li>
<li> <a href="#scope">Scope</a> </li>
<li> <a href="#deliverables">Deliverables</a> </li>
<li> <a href="#coordination">Dependencies and Liaisons</a> </li>
<li> <a href="#participation">Participation</a> </li>
<li> <a href="#communication">Communication</a> </li>
<li> <a href="#decisions">Decision Policy</a> </li>
<li> <a href="#patentpolicy">Patent Policy</a> </li>
<li> <a href="#licensing">Licensing</a> </li>
<li> <a href="#about">About this Charter</a> </li>
</ul>
<p> <a href="https://www.w3.org/"><img width="72" height="48" alt="W3C" src="https://www.w3.org/Icons/w3c_home" /></a>
</p>
<h1 id="title">Second Screen Working Group Charter </h1>
<p class="mission"> The <strong>mission</strong> of the <a href="https://www.w3.org/2014/secondscreen/">Second
Screen Working Group</a> is to provide specifications that enable web
pages to use secondary screens to display web content. </p>
<div class="noprint">
<p class="join"> <a href="https://www.w3.org/2004/01/pp-impl/74168/join">Join
the Second Screen Working Group</a> </p>
</div>
<table class="summary-table">
<tbody>
<tr id="Duration">
<th rowspan="1" colspan="1"> Start date </th>
<td rowspan="1" colspan="1"> 2 February 2018 </td>
</tr>
<tr>
<th rowspan="1" colspan="1"> End date </th>
<td rowspan="1" colspan="1"> 31 December 2019 </td>
</tr>
<tr>
<th rowspan="1" colspan="1"> Charter extension </th>
<td rowspan="1" colspan="1"> See <a href="#history">Change History</a> </td>
</tr>
<tr>
<th rowspan="1" colspan="1"> Chairs </th>
<td rowspan="1" colspan="1"> Anssi Kostiainen </td>
</tr>
<tr>
<th rowspan="1" colspan="1"> Team Contacts</th>
<td rowspan="1" colspan="1"> François Daoust (0.2 FTE)</td>
</tr>
<tr>
<th rowspan="1" colspan="1"> Meeting Schedule </th>
<td rowspan="1" colspan="1"> Teleconferences: topic-specific calls
may be held<br />
Face-to-face: we will meet during the W3C's annual Technical
Plenary week; other additional F2F meetings may be scheduled (up
to 2 per year) <br />
IRC: active participants, particularly editors, regularly use the
<a href="irc://irc.w3.org:6665/#webscreens">#webscreens</a> W3C
IRC channel </td>
</tr>
</tbody>
</table>
<div class="goals">
<h2 id="goals"> Goals </h2>
<p> Web content is available on an ever expanding array of devices
including ebook readers, phones, tablets, laptops, auto displays, and
electronic billboards. These devices have a variety of display
screens. There are also a variety of mechanisms that allow these
devices to use secondary display screens available in the local
environment, attached by wired connections or remotely with wireless,
peer-to-peer media. </p>
<p> Common attachment methods include video ports like VGA, DisplayPort
or HDMI, or wirelessly through Miracast, WiDi, or AirPlay. Wireless
screens may be available on a local area network or over the Internet,
brokered by a cloud service. A device like a laptop could provide a
screen for a smaller device like a phone. </p>
<p> For many of these techniques the operating system hides how the
screen is attached and provides ways for native applications to use
the screens. Native applications on an operating system can easily use
these additional screens without having to know how they are attached
to the device. At this point, however, there is no way for a web page
to take advantage of these available secondary displays. </p>
<p> The Second Screen Working Group aims at defining simple APIs that
allow web applications to show and control web content on one or more
secondary displays. </p>
</div>
<div class="scope">
<h2 id="scope"> Scope </h2>
<p> The scope of this Working Group is to define an API that allows a
web application to request display of web content on a connected
display, with a means to communicate with and control the web content
from the initiating page and other authorized pages. Pages may become
authorized to control the web content by virtue of sharing an origin
with the originating page, explicit user permission, or other
facilities provided by the user agent. The API will hide the details
of the underlying connection technologies and use familiar, common web
technologies for messaging between the authorized pages and the web
content shown on the secondary display. The web content may comprise
HTML documents, web media types such as images, audio, video, or
application-specific media, depending on the capabilities of the
secondary display for rendering the media. Application-specific media
includes that whose type is known to the controlling page and the
connected display, but not necessarily a generic HTML user agent. </p>
<p> The API will provide a means to identify whether requesting display
on second screens is likely to be successful, i.e. whether at least
one secondary screen is available for display. </p>
<p> The API is agnostic with regard to the display connection used, and
also works with display connections that support video only, for
example, a TV connected to a laptop with an HDMI connection. In such a
usage scenario, the web content displayed on a connected display must
be rendered and converted to video before it is sent to a second
screen. The user agent may use whatever means the operating system
provides to prepare and send the video to a second screen. Any
interaction between the authorized web pages and the content displayed
on a secondary screen would happen within the bounds of the initiating
device since both the pages and the content are rendered on that same
device, and only a video representation is sent to the second screen.
</p>
<p> Alternatively, if the second screen device understands some other
means of transmitting content to a display and a means of two-way
message passing, the web content can be rendered by the remote device.
In this scenario, a URL to the content to be displayed is sent to the
secondary display to be rendered there. Because the content is
rendered separately from the initiating user agent, pages hosted by
other user agents may be authorized to control the remotely rendered
content at the same time. </p>
<p> For a requested piece of web content, how and by which device the
content is rendered is an implementation detail. The user agent is
responsible for determining which secondary displays are compatible
with the content that is requested to be shown through the API. </p>
<p> Sending content to a connected display creates a presentation
session. Applications can create multiple presentation sessions to
control multiple displays, although synchronization between them is
not currently supported by the API. </p>
<p> The specifications produced by this Working Group will include
security and privacy considerations. Specifically, the user must
always be in control of privacy-sensitive information that may be
conveyed through the APIs, such as the visibility or access to
secondary displays. </p>
<p> Members of the Working Group should review other Working Groups'
deliverables that are identified as being relevant to the Working
Group's mission. </p>
<h3 id="success-criteria"> Success Criteria </h3>
<p> To advance to <a href="https://www.w3.org/2015/Process-20150901/#RecsCR">Proposed
Recommendation</a>, each specification is expected to have two
independent implementations of each feature defined in the
specification. </p>
<p> To advance to Proposed Recommendation, interoperability between the
independent implementations should be demonstrated. Interoperable user
agents hosting the same Presentation API web application should be
able to render the same content with the same functionality on
supported secondary displays that are compatible with the content to
render. </p>
<h3 id="out-of-scope"> Out of Scope </h3>
<p> The specifications defined by this Working Group abstract away the
means of connecting and different connection technologies. For
example, the following are out of scope: </p>
<ul>
<li>Lower level APIs that expose features of different connection
technologies </li>
<li>How second screens are connected to the primary device (e.g. Video
Port, HDMI, WiDi, Miracast, AirPlay) </li>
<li>How the user agent prepares and sends the screen contents to the
second screen </li>
</ul>
<p> This Working Group will not define or mandate network protocols for
sharing content between user agents and secondary displays. For
example, the following are out of scope: </p>
<ul>
<li>Discovery of wireless secondary displays by the primary user agent</li>
<li>Establishment of a messaging channel between the two parties,
including message addressing, security and authentication</li>
<li>Negotiation of a media streaming session between devices</li>
<li>Network transport of media data</li>
</ul>
<p> Input methods, such as using a TV remote as a pointer or clicker,
are out of scope of the Working Group. </p>
<p> To facilitate interoperability among user agents and display devices
and encourage adoption of the API, the group may informatively
reference existing suites of protocols, either directly in the
Presentation API deliverable or in a non-normative companion Note.
This Working Group will monitor the outcomes of related discussions in
the <a href="http://www.w3.org/community/webscreens/">Second Screen
Community Group</a> in particular. </p>
<p> Content mirroring, whereby a web application requests display of the
content shown in its own browsing context (i.e., page) on a secondary
display, is out of scope. If a web application requests display of
itself (same URL) on a connected display, a new browsing context will
be created with that URL and rendered on the connected display. </p>
<p> This Working Group will not define or mandate any video or audio
codecs. </p>
</div>
<div>
<h2 id="deliverables"> Deliverables </h2>
<p> Draft state indicates the state of the deliverable at the time of
the call for participation. Expected completion indicates when the
deliverable is projected to become a Recommendation, or otherwise
reach a stable state. </p>
<p>
This Working Group will follow a <a
href="https://github.com/w3c/testing-how-to/#test-as-you-commit">test
as you commit</a> approach to specification development, for
specifications in CR or above.
</p>
<h3 id="rec-track"> Normative Specifications </h3>
<p> The Working Group will deliver at least the following
specifications: </p>
<dl>
<dt> <a href="http://www.w3.org/TR/presentation-api/">Presentation
API</a> </dt>
<dd>
<p> An API that allows a web application to request display of web
content on a connected display, with a means to communicate with
and control the web content from the initiating page and other
authorized pages. </p>
<p class="draft-status"> <b>Draft state:</b> <a href="https://www.w3.org/TR/2017/CR-presentation-api-20170601/">
CR</a> / Stable </p>
<p class="milestone">
<b>Expected completion:</b> Q4 2019 — The Working Group is
awaiting satisfaction of the <a href="#success-criteria">Success
Criteria</a>, which require two interoperable implementations of
the Presentation API. The Working Group will also await
demonstration of interoperability among multiple browsers and
multiple presentation displays before moving the specification to
Proposed Recommendation.
</p>
<p>
The <a href="https://github.com/webscreens/openscreenprotocol">
Open Screen Protocol</a>, under incubation in
the <a href="http://www.w3.org/community/webscreens/"> Second
Screen Community Group</a>, will be the basis for demonstrating
interoperability between browsers and devices. Two
implementations based on it would satisfy those criteria. The
charter timeline provides additional time for Open Screen Protocol
implementations to be completed and the Success Criteria to be
met.
</p>
<p>
A second version of the Presentation API that integrates features
the Working Group resolved not to include in the first version in
the interest of time, and also feedback from Web developers on the
first version, will first be incubated and matured in an
appropriate Community Group. This Working Group expects to bring
such features out of incubation through rechartering, when the
criteria for moving the current Presentation API to Proposed
Recommendation have been met.
</p>
</dd>
<dt> <a href="http://www.w3.org/TR/remote-playback/">Remote Playback
API</a> </dt>
<dd>
<p> An API that allows a web application to request display of media
content on a connected display, with a means to control the remote
playback from the initiating page and other authorized pages. </p>
<p class="draft-status"> <b>Draft state:</b> <a href="http://www.w3.org/TR/2017/CR-remote-playback-20171019/">
CR</a> / Stable </p>
<p class="milestone">
<b>Expected completion:</b> Q4 2018 — This Working Group
does not anticipate further changes to this specification. The
Working Group plans to publish the Remote Playback API as a final
Recommendation when the Success Criteria are met.
</p>
</dd>
</dl>
<p> The Working Group may decide to group the API functions in one or
more specifications. </p>
<h3 id="other-deliverables"> Other Deliverables </h3>
<dl>
<dt id="test-suite"> Test suite </dt>
<dd>
<p>
A comprehensive test suite for all features of a specification is
necessary to assess the specification's robustness, consistency, and
implementability, and to promote interoperability between user
agents. Therefore, each specification must have a companion test
suite, which should be completed before transition to Candidate
Recommendation, and which must be completed with an implementation
report before transition to Proposed Recommendation. Additional
tests may be added to the test suite at any stage of the
Recommendation track, and the maintenance of an implementation
report is encouraged.
</p>
<p>
Additionally, this Working Group will improve test automation for
the Presentation API and Remote Playback API test suites. This
will be done through the adoption of a Testing API, incubated in
an appropriate Community Group. The Testing API will also allow
developers to use automation to test their own Web applications
that make use of the above-mentioned APIs.
</p>
</dd>
<dt> Use cases and requirements </dt>
<dd> The Working Group is strongly encouraging the participants to
create and maintain a use cases and requirements document for each
specification. </dd>
<dt> Implementation guidelines </dt>
<dd> To facilitate interoperability among user agents and display
devices and encourage adoption of the API, the group may provide
informative guidelines for implementors, either directly as
informative notes within the Presentation API or in a separate
non-normative group Note. </dd>
</dl>
<p> Other non-normative documents may be created for each specification,
for example: </p>
<ul>
<li>Primers </li>
<li>Non-normative schemas for language formats </li>
<li>Non-normative group notes </li>
</ul>
<h3> Milestones </h3>
<table class="roadmap">
<caption> Milestones </caption>
<tfoot>
<tr>
<td colspan="6" rowspan="1"> Note: See changes from this initial schedule on the <a href="https://www.w3.org/2014/secondscreen/">group
home page</a>. </td>
</tr>
</tfoot>
<tbody>
<tr>
<th rowspan="1" colspan="1"> Specification </th>
<th rowspan="1" colspan="1"> <abbr title="First Working Draft">FPWD</abbr>
</th>
<th rowspan="1" colspan="1"> <abbr title="Candidate Recommendation">CR</abbr>
</th>
<th rowspan="1" colspan="1"> <abbr title="Proposed Recommendation">PR</abbr>
</th>
<th rowspan="1" colspan="1"> <abbr title="Recommendation">Rec</abbr>
</th>
</tr>
<tr>
<th rowspan="1" colspan="1"> Presentation API </th>
<td class="WD1" rowspan="1" colspan="1"> - </td>
<td class="CR" rowspan="1" colspan="1"> - </td>
<td class="PR" rowspan="1" colspan="1"> Q4 2019 </td>
<td class="REC" rowspan="1" colspan="1"> Q4 2019 </td>
</tr>
<tr>
<th rowspan="1" colspan="1"> Remote Playback API </th>
<td class="WD1" rowspan="1" colspan="1"> - </td>
<td class="CR" rowspan="1" colspan="1"> - </td>
<td class="PR" rowspan="1" colspan="1"> Q4 2018 </td>
<td class="REC" rowspan="1" colspan="1"> Q4 2018 </td>
</tr>
</tbody>
</table>
</div>
<div class="dependencies">
<h2 id="coordination"> Dependencies and Liaisons </h2>
<h3 id="dependencies"> Dependencies </h3>
<p> The initial draft of the Presentation API was prepared by the
<a href="http://www.w3.org/community/webscreens/">Second
Screen Community Group</a>. Upon approval of the Working Group, the
Community Group ceased its work on the Presentation API
specification. The Community Group is currently focused on incubating
the <a href="https://github.com/webscreens/openscreenprotocol">Open
Screen Protocol</a>, an open set of network protocols that includes
authentication and security mechanisms, for the APIs defined in this
Working Group. The
Community Group may also work on other related deliverables where it
is not clear enough how to proceed for it to be a work item for a
Working Group. The Community Group is only one possible source for
work under future Working Group charters, but can serve to do initial
exploration for some future work items. </p>
<p> The specifications produced by this Working Group adhere to the
web's security model defined in the HTML specification published by
the Web Platform Working Group. </p>
<p> Common web technologies that this Working Group could refer to for
messaging include Web Messaging and the Web Socket API defined by the
Web Platform Working Group. </p>
<p> No external dependencies against the specifications of this Working
Group have been identified. </p>
<h3 id="liaisons"> Liaisons </h3>
<p>For all specifications, this Working Group will seek <a href="https://www.w3.org/Guide/Charter.html#horizontal-review">horizontal review</a> for accessibility, internationalization, performance, privacy, and security with the relevant Working and Interest Groups, and with the <a title="Technical Architecture Group" href="https://www.w3.org/2001/tag/">TAG</a>. Invitation for review must be issued during each major standards-track document transition, including <a title="First Public Working Draft" href="https://www.w3.org/2018/Process-20180201/#RecsWD">FPWD</a> and at least 3 months before <a title="Candidate Recommendation" href="https://www.w3.org/2018/Process-20180201/#RecsCR">CR</a>, and should be issued when major changes occur in a specification.</p>
<p>Additional technical coordination with the following Groups will be made, per the <a href="https://www.w3.org/2018/Process-20180201/#WGCharter">W3C Process Document</a>:</p>
<dl>
<dt><a href="http://www.w3.org/community/webscreens/" id="sspcg">
Second Screen Community Group </a></dt>
<dd> This group developed the initial version of the Presentation API
and focuses on enabling interoperability among implementations of
the Presentation API, encouraging implementation of the Presentation
API by browser vendors and establishing complementary specifications
for the Presentation API. The Community Group incubates the
<a href="https://github.com/webscreens/openscreenprotocol">Open
Screen Protocol</a> for the APIs defined in this Working Group.
This work on protocols may warrant changes in the Presentation API.
</dd>
<dt><a id="wai" href="http://www.w3.org/WAI/"> </a><a href="http://www.w3.org/WAI/APA/">Accessible
Platform Architectures (APA) Working Group</a> </dt>
<dd> To help ensure deliverables support accessibility requirements,
particularly with regard to interoperability with assistive
technologies, and inclusion in the deliverable of guidance for
implementing the group’s deliverables in ways that support
accessibility requirements. </dd>
<dt><a href="http://www.w3.org/2011/webtv/"> Media and Entertainment
Interest Group</a></dt>
<dd> This group provides use cases and requirements for second screen
scenarios and thus important input on the deliverables developed by
the Second Screen Working Group. </dd>
<dt><a href="http://www.w3.org/html/wg/" id="html"> Web Platform
Working Group </a></dt>
<dd> The Web Platform Working Group’s deliverables cover the security
model implemented in Web Browsers; as well as other relevant
specifications such as <cite><a href="http://www.w3.org/TR/WebIDL/">Web
IDL</a></cite>, <cite><a href="http://www.w3.org/TR/webmessaging/">HTML5
Web Messaging</a></cite>, <cite><a href="http://www.w3.org/TR/websockets/">The
Web Socket API</a></cite> and the <a href="http://www.w3.org/TR/html/">HTML</a>
specification that contain the definition of the <code>HTMLMediaElement</code>
interface that the Remote Playback API specification extends. </dd>
<dt><a href="http://www.w3.org/2011/04/webrtc/"> Web Real-Time
Communications Working Group </a></dt>
<dd> This group defines relevant or potentially relevant
specifications for establishing peer-to-peer communication channels
and for extending the Presentation API to support out-of-scope
features such as content mirroring. </dd>
</dl>
<h3 id="external-groups"> External Groups </h3>
<p> The Presentation API does not have strong dependencies on any given
set of protocols. The following is a tentative list of external bodies
the Working Group should collaborate with to allow the Presentation
API to be implemented on top of widely deployed attachment methods for
connected displays: </p>
<dl>
<dt><a href="http://www.ietf.org" id="ietf">IETF</a></dt>
<dd> The IETF develops home network protocols that secondary displays
may support. </dd>
<dt><a href="http://openconnectivity.org/">Open Connectivity Foundation</a></dt>
<dd> The Open Connectivity Foundation develops home network protocols that secondary
displays may support, including the UPnP suite of protocols. </dd>
<dt><a href="http://www.wi-fi.org/">Wi-Fi Alliance</a></dt>
<dd> The Wi-Fi Alliance develops home network protocols that secondary
displays may support. </dd>
</dl>
<div class="participation">
<h2 id="participation"> Participation </h2>
<p> To be successful, the Second Screen Working Group is expected to
have 6 or more active participants for its duration, and to have
the participation of industry leaders in fields relevant to the
specifications it produces. </p>
<p> The Chairs and specification Editors are expected to contribute
half a working day per week towards the Working Group. There is no
minimum requirement for other Participants. This Working Group will
also allocate the necessary resources for building Test Suites for
each specification. </p>
<p> 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. </p>
</div>
<div class="communication">
<h2 id="communication"> Communication </h2>
<p> Teleconferences will be conducted on an as-needed basis. </p>
<p> This group primarily conducts its work on the public mailing list
<a href="http://lists.w3.org/Archives/Public/public-secondscreen/">[email protected]</a>.
Administrative tasks may be conducted in Member-only communications.
</p>
<p> Information about the group (deliverables, participants,
face-to-face meetings, teleconferences, etc.) is available from the
<a href="https://www.w3.org/2014/secondscreen/">Second Screen
Working Group</a> home page. </p>
</div>
<div class="decisions">
<h2 id="decisions"> Decision Policy </h2>
<p>
This group will seek to make decisions through consensus and due
process, per the
<a href="https://www.w3.org/2018/Process-20180201/#Consensus">W3C
Process Document (section 3.3)</a>. 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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
This charter is written in accordance with the
<a href="https://www.w3.org/Consortium/Process/policies#Votes">W3C
Process Document (Section 3.4, Votes)</a>, and includes no voting
procedures beyond what the Process Document requires.
</p>
</div>
<div class="patent">
<h2 id="patentpolicy"> Patent Policy </h2>
<p> This Working Group operates under the <a href="http://www.w3.org/Consortium/Patent-Policy-20170801/">W3C Patent Policy</a> (Version of 5 February 2004 updated 1 August 2017). 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. </p>
<p> For more information about disclosure obligations for this group,
please see the <a href="http://www.w3.org/2004/01/pp-impl/">W3C
Patent Policy Implementation</a>. </p>
</div>
<div id="licensing">
<h2>Licensing</h2>
<p> This Working Group will use the <a href="https://www.w3.org/Consortium/Legal/copyright-software">W3C
Software and Document license</a> for all its deliverables. </p>
</div>
<h2 id="about"> About this Charter </h2>
<p> This charter for the Second Screen Working Group has been created
according to <a href="http://www.w3.org/Consortium/Process/groups#GAGeneral">section
5</a> of the <a href="http://www.w3.org/Consortium/Process">Process
Document</a>. 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. </p>
<section id="history">
<h3> Charter History </h3>
<p>The following table lists details of all changes from the initial
charter, per the <a href="https://www.w3.org/2015/Process-20150901/#CharterReview">W3C
Process Document (section 5.2.3)</a>:</p>
<table class="history">
<tbody>
<tr>
<th> Charter Period </th>
<th> Start Date </th>
<th> End Date </th>
<th> Changes </th>
</tr>
<tr>
<th> <a href="https://www.w3.org/2014/secondscreen/charter.html">Initial
Charter</a> </th>
<td> 13 October 2014 </td>
<td> 31 October 2016 </td>
<td> none </td>
</tr>
<tr>
<th> <a href="https://www.w3.org/2014/secondscreen/charter-2016.html">Rechartered</a> </th>
<td> 3 November 2016 </td>
<td> 31 October 2017 </td>
<td>
<ul>
<li>Group name adjusted to reflect practice</li>
<li>Deliverables updated to reflect current status</li>
<li>New Presentation API Level 2 deliverable mentioned</li>
<li>On-going efforts on protocols in Second Screen Community
Group noted</li>
<li>Other adjustments: liaisons, licensing text</li>
</ul>
</td>
</tr>
<tr>
<th> <a href="https://www.w3.org/2014/secondscreen/charter-2016.html">Extended</a> </th>
<td> 17 October 2017 </td>
<td> 31 December 2017 </td>
<td> End date adjusted </td>
</tr>
<tr>
<th> <a href="https://www.w3.org/2014/secondscreen/charter-2016.html">Extended</a> </th>
<td> 1 December 2017 </td>
<td> 31 January 2018 </td>
<td> End date adjusted </td>
</tr>
<tr>
<th> <a href="#">Rechartered</a> </th>
<td> 2 February 2018</span> </td>
<td> 31 December 2019 </td>
<td>
<ul>
<li>Completion dates updated to reflect current
implementation plans, dependency on Open Screen Protocol
noted</li>
<li>Dropped second version of the Presentation API. Intent
to re-include it later on after incubation and completion
of current version noted</li>
<li>Intent to work on testing APIs after incubation in a
Community Group noted in Test suite section</li>
<li>Dropped reference to the discontinued Network Service
Discovery API which was developed by the Device and
Sensors Working Group</li>
<li>Updated boilerplate text using current charter
template</li>
<li>Added "test as you commit" approach</li>
<li>Adjusted group names in liaisons section
accordingly</li>
</ul>
</td>
</tr>
</tbody>
</table>
</section>
<hr />
<p class="copyright"> <a rel="Copyright" href="https://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a>©
2018 <a href="/"><abbr title="World Wide Web Consortium">W3C</abbr></a>
<sup>®</sup> (<a href="https://www.csail.mit.edu/"><abbr title="Massachusetts Institute of Technology">MIT</abbr></a>,
<a href="https://www.ercim.org/"><abbr title="European Research Consortium for Informatics and Mathematics">ERCIM</abbr></a>,
<a href="https://www.keio.ac.jp/">Keio</a>, <a href="http://ev.buaa.edu.cn/">Beihang</a>),
All Rights Reserved. <abbr title="World Wide Web Consortium">W3C</abbr>
<a href="https://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
<a href="https://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a>
and <a href="https://www.w3.org/Consortium/Legal/copyright-documents">document
use</a> rules apply. </p>
</div>
</div>
</body>
</html>