[meta] CfC to publish a new Working Draft

[anssiko]

This is a Call for Consensus to publish a new Working Draft of the Presentation API using the latest Editor's Draft as its source. For an overview of changes, see the HTML diff to previous 13 October 2015 Working Draft (but note the sections have been reordered since the previous publication).

Hearing no concerns, we should publish earliest 3 February 2016.

To summarize, the specification has advanced significantly since its previous Working Draft publication: 53 commits landed, 17 PRs were merged, and 34 issues were closed. Thanks everyone, with special thanks to the editor @mfoltzgoogle.

@tidoust What changes should we do to the Status of This Document section (or elsewhere) to make sure we satisfy the "wide review" requirement in terms of boilerplate? The spec has received wide horizontal review and has an implementation, so at minimum we should reword "This document is a work in progress ..." with text that better matches reality.

@mfoltzgoogle Feel free to proceed with publication on 3 February 2016 or at earliest opportunity after that as documented in our Work Mode. The spec passes Pubrules Checker and Echidna teething problems should be over now, so I expect smooth delivery.

[tidoust]

@anssiko I will provide text for the Status of This Document section.

With the risk of delaying the publication a bit... Re-reading the spec and the list of open issues, if we want to use the publication to encourage a "wide review" of the spec, wouldn't it make sense to make a small push to fix the "known bugs", by which I mean the parts where we know that the spec is wrong or incomplete and that should only require a Pull Request?

I'm thinking about the following issues in particular:

#165 conflict description for uniquely identifying a presentation session
#193 Define a "set of presentations" for the receiving context?
#211 binaryType attribute's default value and get/set behaviour needs to be specified
#229 Need algorithm for establishing a presentation connection when the previous connection(s) were closed
#245 "Known connection" in reconnect() may be linked to another browsing context

That seems doable in a reasonable amount of time, and that would only leave open issues about informative guidelines, possible enhancements, meta-issues and a couple of more long-lasting discussions. I'm willing to take a stab at most of the issues listed above next week, at least.

[anssiko]

Thanks for triaging the bugs @tidoust and for volunteering to help with issues and SoTD text. Fixing these bugs before the next publication would be ideal. I wouldn't worry about the pub schedule that much, as long as we have a plan how to get there. My interpretation is the heartbeat requirement to publish latest every 3 months is purely advisory.

All - the revised plan is to publish as soon as the issues, or spec bugs, identified by @tidoust have been addressed. Please feel free to help resolve the issues. If you are aware of any other substantial issues that should be fixed before we publish, please let us know. If we think some of the bugs cannot be resolved in a reasonable time, they should be clearly noted in the spec as such.

@mfoltzgoogle anything in particular you'd like to address in addition to the issues identified by @tidoust before we publish?

[mfoltzgoogle]

I would feel good if we could address the issues with actions/resolutions from TPAC as well as based on the interim review from PING. This includes:

#79 Presentations from within nested browsing contexts
#45 Security and privacy considerations
#223 Implementation guideline: users should have a way to know which origin is being presented at any time
#224 Think more about privacy implications in multi-user scenarios

With help from @tidoust on improving the functional specification, I think we will be in good shape.

[anssiko]

@mfoltzgoogle Thanks, I'd feel good too if we'd be able to fix those issues as well, even if they'd be non-normative, apart from #79. Let's aim to fix them too.

All - here's the list of issues we want address before the wide review WD publication:

https://github.com/w3c/presentation-api/milestones/wide-review-WD

[anssiko]

Current status of the wide review WD publication and issues blocking it is the following:

Closed issues:
#79 Presentations from within nested browsing contexts
#211 binaryType attribute's default value and get/set behaviour needs to be specified
#223 Implementation guideline: users should have a way to know which origin is being presented at any time
#224 Think more about privacy implications in multi-user scenarios

Open issues:
#45 Security and privacy considerations
#165 conflict description for uniquely identifying a presentation session
#193 Define a "set of presentations" for the receiving context?
#229 Need algorithm for establishing a presentation connection when the previous connection(s) were closed
#245 "Known connection" in reconnect() may be linked to another browsing context

PRs:
#252 Split "set of presentations" into controlling/receiving sets (fixes issues #165, #193, #229, #245)
#257 Complete Security and Privacy section (fixes issue #45)

All - thank you for your contributions, and please feel free to review the two remaining open PRs.

[mfoltzgoogle]

I've merged the most recent PRs after addressing comments. @anssiko, perhaps we should restart the clock for a CfC, as there have been a significant number of changes landed since the last one.

[anssiko]

All - please review the latest Editor's Draft and let us know by 11 Feb if you have any concerns. After that date we aim to publish a wide review WD.

Thank you @mfoltzgoogle, @tidoust and others for helping close the issues blocking this release.

[anssiko]

What we still need before we publish is to reword the Status of This Document section.

@tidoust volunteered to take a stab at it.

This is the current text that I suggest we remove and replace with something that better communicates the current status and e.g. notes the horizontal reviews we've completed:

This document is a work in progress and is subject to change. Some sections are still incomplete or underspecified. Security and privacy considerations need to be adjusted based on feedback and experience. Some open issues are noted inline; please check the group's issue tracker on GitHub for all open issues. Feedback from early experimentations is encouraged to allow the Second Screen Presentation Working Group to evolve the specification based on implementation issues.

[mfoltzgoogle]

A new working draft has just been published at the following URL:

https://www.w3.org/TR/2016/WD-presentation-api-20160211/

[anssiko]

Thank you everyone -- this is the most complete publication of the Presentation API to date!

Presentation API W3C Working Draft 11 February 2016
https://www.w3.org/TR/2016/WD-presentation-api-20160211/

Spec status as reported in the publication:

Since publication as Working Draft on 13 October 2015, the Working Group has refined the interfaces and significantly improved all procedures. Security and privacy considerations have been completed based on feedback and interactions with other W3C groups. The Working Group intends to publish a Candidate Recommendation soon and seeks wide review of this document. Horizontal reviews and feedback from early experimentations and developers willing to use this specification are encouraged.

For this publication, we fixed all the issues that were blocking this release in time and went the extra mile by closing additional issues during the CfC.