Merge pull request #4 from mfoltzgoogle/gh-pages

webscreens charter update
Tidy the document with <https://github.com/w3c/tidy-html5>
Completed "Dependencies and Liaisons" section with actual list of groups

The "Dependencies" sub-section is now explicit about potential common web
technologies that the group could refer to and on the possible overlap
with the Network Service Discovery API. I also moved the bits on the
community group to that sub-section.

The "Liaisons" sub-section now lists to a supposedly appropriate set of
groups within W3C and explains the motivation behing each liaison.

I am not entirely sure about the external bodies that are to appear in
the "External Groups" sub-section. I listed possible bodies that the WG
should collaborate with to ensure that the API can be implemented on top of
a variety of widely deployed protocols. I may have missed a couple. Even if
protocols end up "out of scope" for the working group, it seems important to
keep the list around.
Merge pull request #5 from tidoust/dependencies

Completed "Dependencies and Liaisons" section with actual list of groups
Add section ids.
Refined scope: no protocols, possible guidelines, interoperability defined

Main changes:
1. protocols have been moved out of scope
2. the success criteria section mentions interoperability and attempts
to define it somehow.
3. the other deliverables section mentions the possibility to produce
implementation guidelines

More detailed list of changes:

- New final sentence to the "Goals" section. It seemed weird to finish the
section on a sentence that used the negative form without describing what the
group would do to solve that issue.

- Dropped the protocol subsection from the Scope section and reordered the
text in that section accordingly

- Added protocols to the Out of Scope section, using former text. Also added
a note about referencing existing suites of protocols in informative notes
to promote interoperability.

- Updated the text on content mirroring as it seemed awkward to present second
screens differently in that section. Plus the Presentation API is not really
meant to display content on screens that are "off one edge of the primary
screen"

- Dropped the Phase 2 subsection in the Deliverables section.

- Added the possibility to work on informative guidelines, either directly
within the Presentation API or within a separate Note.
Clarified interoperability and content mirroring

Text updated following MarkF's suggestions at:
http://lists.w3.org/Archives/Public/public-webscreens/2014Jun/0008.html
Clarified definition of interoperability

The sentence is now explicit that user agents can only render content on
secondary displays that they support and that are compatible with the content
to render.
Merge pull request #6 from tidoust/scope

Refined scope: no protocols, possible guidelines, interoperability defined
Added PING, Web Security IG and WebRTC to liaisons list

The charter mentions privacy and security issues. As such, reviews by the
Privacy Interest Group and Web Security Interest Group are strongly
recommended.

I added the WebRTC group as well in the list of groups that develop
specifications that are potentially relevant for implementors of the
Presentation API, e.g. for extending the API to support use cases that
the group will not address per se (such as content mirroring).
Added somewhat realistic milestones for the Presentation API

The milestones take for granted that the Working Group would be
chartered for about 2 years.
Updated mailing-list name to avoid conflict with CG
Added sentence to allow splitting functions into multiple specs
Clarified CC-By and W3C Document License dual-licensing rules

The section is mostly a copy-and-paste of the end of the Document
License section of the HTML WG charter:
http://www.w3.org/2013/09/html-charter.html#documentlicense
Dropped charter authors "TBD" section
Updated URL of group's home page for consistency with mailing-list name
Merge pull request #7 from tidoust/liaisons

Updates to liaisons, milestones, document license and mailing-list name
Define application-specific media.