-
Notifications
You must be signed in to change notification settings - Fork 5
/
charter.html
750 lines (741 loc) · 32.7 KB
/
charter.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
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
<!DOCTYPE html>
<html lang="en-US" xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-US">
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
<title>
Second Screen Presentation Working Group
</title>
<link rel="stylesheet" href="//www.w3.org/2005/10/w3cdoc.css" type=
"text/css" media="screen" />
<link rel="stylesheet" type="text/css" href=
"//www.w3.org/Guide/pubrules-style.css" />
<link rel="stylesheet" type="text/css" href=
"//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="#doclicense">Document License</a>
</li>
<li>
<a href="#about">About this Charter</a>
</li>
</ul>
<p>
<a href="http://www.w3.org/"><img alt="W3C" height="48" src=
"//www.w3.org/Icons/w3c_home" width="72" /></a> <a class=
"domainlogo" href="/UbiWeb/"><img src="//www.w3.org/Icons/ubi212"
alt="Ubiquitous Web Domain" /></a>
</p>
<h1 id="title">
Second Screen Presentation Working Group Charter
</h1>
<p class="todo">This charter has been replaced
by <a href="/2014/secondscreen/charter-2016.html">a
newer version</a>.</p>
<p class="mission">
The <strong>mission</strong> of the <a href="http://www.w3.org/2014/secondscreen/">Second Screen Presentation 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 Presentation Working Group</a>
</p>
</div>
<table class="summary-table">
<tr id="Duration">
<th rowspan="1" colspan="1">
End date
</th>
<td rowspan="1" colspan="1">
31 October 2016
</td>
</tr>
<tr>
<th rowspan="1" colspan="1">
Confidentiality
</th>
<td rowspan="1" colspan="1">
Proceedings are <a href=
"http://www.w3.org/2005/10/Process-20051014/comm.html#confidentiality-levels">
Public</a>
</td>
</tr>
<tr>
<th rowspan="1" colspan="1">
Initial Chairs
</th>
<td rowspan="1" colspan="1">
Anssi Kostiainen
</td>
</tr>
<tr>
<th rowspan="1" colspan="1">
Initial Team Contacts<br />
(FTE %: 20)
</th>
<td rowspan="1" colspan="1">
François Daoust
</td>
</tr>
<tr>
<th rowspan="1" colspan="1">
Usual 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>
</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 Presentation 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>
Success Criteria
</h3>
<p>
To advance to Proposed Recommendation, 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>
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.
</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>
<h3 id="rec-track">
Recommendation-Track Deliverables
</h3>
<p>
The working group will deliver at least the following specification:
</p>
<dl>
<dt>
Presentation API
</dt>
<dd>
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. The initial version of this
document will be copied from the <a href=
"http://www.w3.org/2014/secondscreen/presentation-api/20140721/">
Presentation API W3C Community Group Final Report</a>
produced by the W3C Second
Screen Presentation Community Group. Further modifications
(if any) will be decided upon by this Working Group.
</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>
Test suite
</dt>
<dd>
A comprehensive test suite for all features of a specification is
necessary to ensure 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 a
implementation report is encouraged.
</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: The group will document significant changes from this
initial schedule on the group home page.
</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="Last Call Working Draft">LC</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">
Q4 2014
</td>
<td class="LC" rowspan="1" colspan="1">
Q2 2015
</td>
<td class="CR" rowspan="1" colspan="1">
Q4 2015
</td>
<td class="PR" rowspan="1" colspan="1">
Q2 2016
</td>
<td class="REC" rowspan="1" colspan="1">
Q2 2016
</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
Presentation Community Group</a>. Upon approval of the Working Group,
the Community Group will cease its work on the Presentation API
specification. It is expected that the Community Group will recharter
to 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 WG
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
HTML 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 Applications Working Group.
</p>
<p>
Even though the scopes of the APIs are different, some of the use
cases that the Presentation API aims to address, in particular
projection of web content on second screens connected to the local
area network, are also in scope of the Network Service Discovery API
worked upon by the Device APIs Working Group. This Working Group will
liaise with the Device APIs Working Group, in particular to ensure
consistency of supported service discovery mechanisms when a user
agent implements both APIs.
</p>
<p>
This Working Group is not aware of any dependencies other
Working Groups’ specifications have on this Working Group’s
specifications.
</p>
<h3 id="liaisons">
Liaisons
</h3>
<p>
The Working Group expects to maintain contacts with at least the
following groups and Activities within W3C (in alphabetical order)
and ask for reviews of deliverables in Last Call, and where
appropriate:
</p>
<dl>
<dt><a href="http://www.w3.org/2009/dap/" id="dap">
Device APIs Working Group
</a></dt>
<dd>
The Device APIs Working Group defines the Network Service Discovery
API that addresses some of the use cases that are in scope of the
Second Screen Presentation Working Group.
</dd>
<dt><a href="http://www.w3.org/html/wg/" id="html">
HTML Working Group
</a></dt>
<dd>
The HTML Working Group’s deliverables cover the security model
implemented in Web Browsers; this security model imposes limitations
on what an extended model for Web Applications can achieve.
</dd>
<dt><a href="http://www.w3.org/Privacy/">
Privacy Interest Group
</a></dt>
<dd>
The Second Screen Presentation Working Group intends to secure
reviews on its deliverables from the Privacy Interest Group to
ensure they offer the right level of protection to users.
</dd>
<dt><a href="http://www.w3.org/community/webscreens/" id="sspcg">
Second Screen Presentation Community Group
</a></dt>
<dd>
This group developed the initial version of the Presentation API
and will likely continue to explore new features.
</dd>
<dt><a id="wai" href="http://www.w3.org/WAI/">
Web Accessibility Initiative</a>
<a href="http://www.w3.org/WAI/PF/">Protocols and Formats Working
Group</a>
</dt>
<dd>
To ensure the Presentation API supports 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 id="webapps" href="http://www.w3.org/2008/webapps/">
Web Applications Working Group
</a></dt>
<dd>
This group defines relevant or potentially relevant specifications
including
<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>
and <cite><a href="http://www.w3.org/TR/websockets/">The Web Socket API</a></cite>.
</dd>
<dt><a href="http://www.w3.org/2011/webtv/">
Web and TV Interest Group
</a></dt>
<dd>
This group provides use cases and requirements for second screen
scenarios and thus important input on the Presentation API developed
by the Second Screen Presentation Working Group.
</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>
<dt><a href="http://www.w3.org/Security/wiki/IG">
Web Security Interest Group
</a></dt>
<dd>
The Second Screen Presentation Working Group intends to secure
reviews on its deliverables from the Web Security Interest Group
to ensure they offer the right level of security.
</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 ensure that the
Presentation API can be implemented on top of widely deployed
attachment methods for connected displays:
</p>
<dl>
<dt><a href="http://www.dlna.org/home">DLNA</a></dt>
<dd>
The Digital Living Network Alliance references home network
protocols that secondary displays may support.
</dd>
<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://www.upnp.org/">UPnP Forum</a></dt>
<dd>
The UPnP Forum develops home network protocols
that secondary displays may support.
</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 Presentation Working Group is
expected to have 10 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 one
half-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
Second Screen Presentation Working Group home page.
</p>
</div>
<div class="decisions">
<h2 id="decisions">
Decision Policy
</h2>
<p>
As explained in the W3C Process Document (<a href="http://www.w3.org/Consortium/Process/policies#Consensus">section
3.3</a>), this group will seek to make decisions when there is
consensus and with due process. The expectation is that 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.
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 should put a question out for voting within the
group (allowing for remote asynchronous participation -- using, for
example, email and/or web-based survey techniques) and record a
decision, along with any objections. The matter should then be
considered resolved unless and until new information becomes
available.
</p>
<p>
Any resolution taken in a face-to-face meeting or teleconference is
to be considered provisional until 10 working days after the
publication of the resolution in draft minutes sent to the working
groups mailing list. If no objections are raised on the mailing list
within that time, the resolution will be considered to have consensus
as a resolution of the Working Group.
</p>
<p>
This charter is written in accordance with <a href="http://www.w3.org/Consortium/Process/policies#Votes">Section
3.4, Votes</a> of the W3C Process Document 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-20040205/">W3C Patent
Policy</a> (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.
</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>
<h2 id="doclicense">
Document License
</h2>
<p>Documents produced by this group will be licensed under the W3C Document License. In addition, "Code Components" —Web IDL in sections clearly marked as Web IDL; and W3C defined markup (HTML, CSS, etc.) and computer programming language code clearly marked as code examples— will be licensed under the W3C Software License. The group should use the following copyright statement:
<blockquote>
<p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2014 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.eu/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>, <a href="http://ev.buaa.edu.cn/">Beihang</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply. Additionally, all Code Components, as
defined below, are made available under the <a href="https://www.w3.org/Consortium/Legal/copyright-software">W3C Software License and Notice</a>. <br>
<ul>For the purpose of this license, Code Components are:
<li>Web IDL in sections clearly marked as Web IDL; and
<li>W3C defined markup (HTML, CSS, etc.) and computer programming
language code clearly marked as code examples.
</ul>
</p></blockquote>
<h2 id="about">
About this Charter
</h2>
<p>
This charter for the Second Screen Presentation Working Group has
been created according to <a href=
"http://www.w3.org/Consortium/Process/groups#GAGeneral">section
6.2</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>
<p><strong>Note added 13 October 2014</strong>: The Director has indicated to the Membership that, pending PSIG input on a licensing proposal raised during AC review, this charter may be updated in place if there is support for the proposal.</p>
<p><strong>Note added 15 October 2014</strong>: After receiving input from PSIG, the Director has updated the charter in-place to modify the copright license as requested. See new <a href="#doclicense">Document License</a> section above.</p>
<hr />
<p class="copyright">
<a rel="Copyright" href=
"http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a>©
2014 <a href="/"><abbr title=
"World Wide Web Consortium">W3C</abbr></a> <sup>®</sup> (<a href=
"http://www.csail.mit.edu/"><abbr title=
"Massachusetts Institute of Technology">MIT</abbr></a>, <a href=
"http://www.ercim.org/"><abbr title=
"European Research Consortium for Informatics and Mathematics">ERCIM</abbr></a>,
<a href="http://www.keio.ac.jp/">Keio</a>, <a href=
"http://ev.buaa.edu.cn/">Beihang</a>), All Rights Reserved.
</p>
</div>
</div>
</body>
</html>