See also: IRC log
Anssi: Welcome everyone, first telco of the Second Screen Presentation WG!
Anssi: This call is intended to
be a soft introduction to get to know each other, see what
happened to the spec and next steps
... This WG was chartered in October 2014. We initially started
as a CG in late 2013 and migrated the specification from the CG
into this WG.
... That took about a year.
Anssi: This is a focused WG: only
one spec at this time on our plate, the Presentation API.
... [Going through the call agenda]
Anssi: I work for Intel in
Finland. I'm your Chair, at your service. I'm editor of 7
specifications in W3C and participate in about 11 WG.
... Also proud father of two kids.
... My main interest for the group is to remove obstacles from
the way so that the WG can make progress.
... Typically, Francois and I will take on the burden from the
process whenever possible.
... I want to ensure we avoid scope creep.
... There is a tendancy to add new features and never
publish.
... We're in a good position with a tight charter.
... Also, we should make sure that we iterate the spec with
implementation feedback early on in the process.
... The goal is not to have to revisite issues later on. I'm
very happy to see many implementers in this group.
... I encourage you to jump in the discussion.
... Leaving the floor to hear about you.
Dominik: I'm the editor of the
specification. Together with Anssi, we introduced the topic and
started the CG.
... I also work in Intel, software engineer, Chromium
committer.
... My interest is to bring the feature to browsers around
there.
... We're interested in exposing Miracast here, but more
generally in the feature itself.
... It's always great to have specific points in the spec.
Anton: I work for Google in the
London office. Hello from Great Britain. Work for Chrome on
Android. Implemented support for Chromecast on Android.
... Very interested in the API as it brings the feature to Web
browsers.
... My main concern is how to get many developers to use the
API, need to remain simple.
Brad: I work for Mozilla, from Boston. I started the Fennec project. Involved in introducing media flinging for Firefox for Android and for desktop in particular
Bob: I work for CableLabs. We are
a non profit R&D organization that represent cable
operators.
... We've been using discovery protocols, e.g. DIAL and
Chromecast.
... Different approaches. My main interest is to see an API
that could accomodate different discovery protocols
Louay: I'm from Fraunhofer FOKUS,
Germany. Main topic is everything around multi-screens. Also
involved in Web and TV IG in W3C, also HbbTV.
... My interest is to bring all these standards to our
customers
MarkW: I work for Netflix, video on demand service on the Internet. We have multiscreen stuff based on DIAL.
MarkF: I work for Google on Chrome in the Seattle area. My team built the first generation of multiscreen support in Chrome, with Chromecast and DIAL.
MarkF: Main goal is to enable
support for multi-screens.
... My main concern is to ensure that we can take advantage of
existing devices out there, and also I think there are
interesting security aspects.
Francois: I work for W3C, have been involved in the Web and TV IG lately. My main role is to ensure that the WG follows the W3C Process and to work with Anssi to ensure the process does not block the group in any way.
tidoust: there may be couple of
you not familiar with W3C
... three main documents that govern the rules of a working
group:
tidoust: 1) W3C Process
Document
... describes how WGs work,
recommendation track, what it means to publish a doc
... what are the maturity levels
tidoust: 2) W3C
Patent Policy
... commitments made when joined the group, Royalty-Free
policy
... any questions, please contact tidoust
... describes call for exclusions
tidoust: 3) Second
Screen Presentation Working Group Charter
... The working group has to take decisions based on
consensus
... no-one should be objecting to a decision
... if someone is objecting, decision cannot be taken
... if no consensus is reached, there's an escalation
process
... you can go up to the W3C Director
... that's very important part of the Process
... Rec Track defines maturity levels of a spec
... currently, the spec is Editor's Draft, thus no formal
standing
... next publication will be First Public Working Draft
... which triggers the first exclusion period
... Working Drafts are then published
... ED pub can be automated
... Candidate Rec aka CR, when it is "feature complete", call
for implementations
... to ensure the spec has been reviewed by external world
there's a wider review
... Proposed Rec aka PR when we have two implementations
... W3C Recommendation aka REC, web standards
... that's about it
... Process doc defines review periods, transitions from stage
to another
... about rules and responsibilities
... roles: chair, staff contact
... chair to ensure consensus is found, staff contact to
help
... editor is authoring the specification
... scribe is responsible for writing down minutes
Anssi: This is: "How do we do our day-to-day activity"
Anssi: From the home page of the
group, you can find links to other material, Wiki, charter,
list of participants, etc.
... The WG Wiki is open for everyone to contribute to.
<anssik> https://lists.w3.org/Archives/Public/public-secondscreen/ -> Mailing lists
Anssi: Let's make use of this
resource!
... The WG mailing-list is the main communications mean of the
group.
... I should note that there is a tendancy to move technical
discussions to GitHub where the spec is.
... That is fine. There is no requirement that would prevent us
from doing so.
... I'm open to suggestions as we advance the
specification.
-> Presentation API spec on GitHub
Anssi: Those are the main
pointers we have.
... To contribute, let's say you have a proposal, a concern,
see a typo, or something else, do not hesitate to send an email
to start with.
... Then, if you're more adventurous, you can fork the spec and
send a pull request, so that Dominik can review your
contributions..
... We're open to all sorts of feedback. The process is not
limiting us in this regard.
Anssi: If you're interesting in
making contributions to the spec, please look at the
instructions in the Wiki.
... The instructions have been tested in Linux and MacOS. On
Windows, you may struggle a bit
Anssi: Francois will update the
instructions with Windows considerations.
... We're using GitHub issue tracker. Anyone can create and
discuss issues:
Anssi: I came up with a series of
guidelines, hope they make sense.
... I would like to ensure that every voice is heard. The best
way for your idea not to go unnoticed is to open an issue on
GitHub.
... If you still prefer to stick to the mailing-list, no
problem, Dominik and myself will monitor the list and create
needed issues on GitHub.
... The role of the editor is not to resolve all issues. That's
rather the role of the WG. You can in particular assign issues
to yourself.
... We have had some discussions off the list with Francois
about the mailing-list and GitHub. I'd like to hear your views.
Would you like to setup some automated system that sends emails
to the mailing-list whenever something happened on
GitHub?
... See related mail on the mailing-list
... Any concern or question or view about moving more on the
work to GitHub and reflecting the work on the mailing-list
automatically?
MarkF: My question is on prototype implementations. Do you want these to be reflected on the W3C repository? Or is it ok to use our personal repos?
Anssi: If you wish, you may fork
your repo to the "webscreens" organization which was created
for that purpose:
https://github.com/webscreens/
Anssi: Also note the implementation status that references existing implementations:
https://www.w3.org/wiki/Second_Screen/Implementation_Status
Anssi: Things under the W3C organization are for WG specifications and deliverables
Francois: Note code is not a deliverable of the WG, so does not have to be submitted to W3C. It's of course a good thing to have prototypes and to reference them.
Anssi: right. The Test suite is a deliverable of the WG and will typically appear under the W3C organization.
-> Second Screen Presentation WG Charter
Anssi: Briefly, I want to ensure that we understand what the charter is and contains.
Anssi: The most important section
is probably the Scope section. It defines... the scope!
... We can partition our work across multiple specs if it's
useful and makes sense.
... There are also success criteria, 2 implementations at a
minimum.
... If we don't get 2 implementations for a feature, we won't
put it in the spec.
... Maybe the third section that you might want to review is
the Out of Scope section.
Anssi: If you strongly feel that
some of this work should have more discussion among vendors,
the sister Web Screens Community Group is the right place for these
discussions.
... These features could come to the WG later on, when and if
we re-charter.
... Note we can split the Presentation API into multiple
specifications if you feel that's useful
Francois: Note the timeline and milestones that appear in the charter should not be dismissed. As you can see, the timeline in the charter already takes us to a REC in mid-2016. If the group misses milestones, it will miss that final milestone as well! The chair and I will keep an eye on the timeline, but note progress is on everyone's shoulders.
MarkF: You mentioned some features could be added as extensions. What is the process to do so?
Anssi: I think these extensions would be considered in their own spec. The right way to do it would be to experiment with the features in the CG, and then these extensions can be brought to the WG, provided the WG re-charters if these features are out of scope.
Francois: Agree. If the question is also about possible extensions points that the Presentation API could have and that would allow implementers to experiment extensions without breaking the API, that's fully in scope of the WG.
Anssi: We will have a F2F at
TPAC. Next TPAC is 26-30 October 2015 in Yokohama, Japan. We have the option to
meet before that.
... Given that TPAC is a bit far away, the plan would be to
hold a F2F in spring, probably towards end of May. Possible dates:
Anssi: I have started to discuss
that with some of you.
... 19-20 May is not optimal because of a conflict with
WWW2015. We're targeting a two-day meeting.
Anssi: Please have a look at
these possibilities. We are open to offers to host. thanks for those who
already offered to host!
... I will send an email to the mailing-list afterwards with the different
possibilities.
... Please get in touch with Francois and myself if you can host.
... See Hosting W3C Face to Face Meetings in the guidebook
Anssi: This is where we start to work!
Anssi: Dominik will give us an update since the CG
Dominik: See the notes I prepared in
Wiki page.
... We added a first draft of the algorithms section, thanks to
MarkF!
... We iterated a bit on some sections.
... Then, with Anssi, we thought we would merge algorithms and
the IDL definitions.
... The Presentation API is in a much better shape than it
was.
... Having said that, we have a few open issues.
... We have to look at how we're going to tear down sessions.
Signal? How to avoid orphaned sessions? Etc.
... I invite anyone, especially those implementing the spec, to
contribute here.
... The message exchange mechanism needs to be further
specified. We have a postMessage right now. There are related
discussion within bugzilla at Mozilla.
... We've had exchanges with them.
... Do we want to add additional types such as ArrayBuffers for
instance?
... Then, we also need to look at the Presentation API from the
presenting page, to see whether things are clear and consistent
there.
... These issues that I have highlighted are marked as P1
(Priority 1)
... Of course, if you have suggestions for other issues, you're
welcome as well!
... As soon as we find consensus on a proposal, I'm happy to
merge it to the spec.
Anssi: Great overview, thanks! If you can have a look at P1 issues on GitHub, we can continue to work on them offline.
Anssi: Next, I'd like to talk about publication as FPWD. Publication as a FPWD does not imply that the spec is feature complete.
Anssi: What will happen next is
that I will send a call for consensus on the mailing-list (CfC)
to check with you whether there are concerns with that
publication.
... For open issues for the FPWD, we don't need to flesh out the solution,
we can just say that the section is under discussion.
... If someone can take an action to review the spec, that
would be great as well.
... Any volunteer?
... If you don't want to commit on the call, just keep the spec
as an open tab so that you can have a look at it when you come
back to the office on Monday.
... Any other business that you would like to raise or
discuss?
... Thank you everyone for attending. This was more an
introduction call. In the coming calls, we would keep more
technical focus.
MarkF: Are there other WG in W3C that are doing related things and that we should follow?
Anssi: If you look at the
charter, there is a Dependencies and Liaisons section that
enumerates some of these groups.
... For instance, the Device API WG has been experiencing with
the Network Service Discovery API. WebRTC, Web and TV IG, Web
Security WG, etc.
MarkF: The one that I might
propose to add is the group working on SharedWorkers.
... I've used their spec as a guideline.
Anssi: I guess you mean ServiceWorkers. In scope of the Webapps WG. That's an interesting specification, indeed.
Anssi: Thanks a lot for attending the call!
[call adjourned]