[meta] Publish a revised Candidate Recommendation

[anssiko]

[All - please let us know if you have any comments or concerns with this publication plan. Silence is considered consent.]

There has been substantive changes to the Presentation API since the latest Candidate Recommendation 14 July 2016 thanks to extensive implementation feedback and findings from the conformance testing of the API. See also the visual HTML diff between the CR and the latest Editor's Draft. Given that, we should publish a revised Candidate Recommendation.

Per the process for revising a CR, the group needs to address the following requirements to make that happen:

• must show that the revised specification meets all Working Group requirements, or explain why the requirements have changed or been deferred,
• must specify the deadline for further comments, which must be at least four weeks after publication, and should be longer for complex documents,
• must document the changes since the previous Candidate Recommendation,
• must show that the proposed changes have received wide review, and
• may identify features in the document as "at risk". These features may be removed before advancement to Proposed Recommendation without a requirement to publish a new Candidate Recommendation.

To tick the boxes, I suggest we:

• use the deadline of four weeks for further comments,
• document high-level changes since the first CR in the Status of This Document section, and in addition, link to the GitHub compare (or the HTML diff) for the detailed changes (@mfoltzgoogle could you help compile the high-level list?),
• regarding the wide review of the changes, @tidoust let us know your recommendation how to handle the wide review of the delta,
• document "at risk" features in the SoTD section as well -- implementers @mfoltzgoogle @schien et al.: please let us know if there are features in the spec you are considering not to implement.

Finally, after we've ticked the above boxes, @tidoust will help us acquire the approval from the Director to publish a revision, and I expect will help prepare a publication-ready updated CR snapshot:

• must obtain the Director's approval to publish a revision of a Candidate Recommendation

[tidoust]

document high-level changes since the first CR in the Status of This Document section, and in addition, link to the GitHub compare (or the HTML diff) for the detailed changes (@mfoltzgoogle could you help compile the high-level list?)

Note pending PR #405 is meant to address this need.

regarding the wide review of the changes, @tidoust let us know your recommendation how to handle the wide review of the delta,

While we've fixed a number of algorithms, we have not introduced any notable change of API or API behavior that would warrant new horizontal reviews. We may want to confirm with WebAppSec that our treatment for #380 is still ok, though.

[anssiko]

Note pending PR #405 is meant to address this need.

This looks like a very complete list to me, thanks! @mfoltzgoogle to merge after another review.

While we've fixed a number of algorithms, we have not introduced any notable change of API or API behavior that would warrant new horizontal reviews.

That was my assessment as well, good to see you think the same.

We may want to confirm with WebAppSec that our treatment for #380 is still ok, though.

@tidoust you reached out to the WebAppSec group earlier, so could you confirm with them that the specific issue #380 is satisfactorily addressed with #401, and any concrete improvements to bake in before publishing.

[anssiko]

I think we want to address #407 before publishing to be conformant with the latest WebIDL.

[anssiko]

See #380 (comment) for my summary of the WebAppSec WG's position on [SecureContext] and suggested next steps.

[markafoltz]

Here's a summary of the current state of the Chrome implementation (as of 58.0.3004.3, the current dev channel release):

On desktop and Android releases

• Currently supports 2-UA mode using Chromecast, only with URLs that correspond to registered Cast applications.
• Support for new PresentationRequest(DOMString[]) has landed; multiple URLs are accepted to construct the PresentationRequest.

On the desktop release

• Support for 1-UA mode with arbitrary URLs has landed (both controller and receiver APIs).
  • We will send a demo link soon :-)

Completed items from the PR exit criteria

• Implementations of controlling UA for 1UA and 2UA mode.
• Implementation of receiving UA for 1UA mode.
• Web platform tests mostly pass for these implementations, with the following exceptions:
  • reconnect() is not yet supported for 1UA presentations. Expect to fix in M58.
  • Some fail because of incompatibility between idlharness.js and Blink bindings.
  • There are a few bugs we are tracking down :-)

"At risk"

• There are not many Web platform tests for the receiving UA.
• We plan on implementing the receiving UA in 2-UA mode at some point, but I am not sure it can be completed by the PR exit milestone of Q2 2017.

[anssiko]

Update: #380 is the only remaining blocker for the revised CR publication.

CfC with a proposed solution #380 (comment) open for comments until 21 Feb.

[anssiko]

A fix to #380 is expected to land soon, see #413.

Not yet at zero bugs, since we identified another spec issue we probably want to address before publishing, tracked in #414.

[anssiko]

We're now at zero bugs blocking the revised CR publication. Congratulations!

@mfoltzgoogle, could you check that https://w3c.github.io/presentation-api/#changes-since-14-july-2016 is up to date? We're missing at least #414.

@mfoltzgoogle, is the "at risk" data provided at #406 (comment) still accurate?

@schien, do you see features in the spec you are not planning to implement (thus could be "at risk")?

("At risk" features are formally defined as "features [that] may be removed before advancement to Proposed Recommendation without a requirement to publish a new Candidate Recommendation.")

@tidoust, do you see any blockers for advancing with the publication after we've updated changes since and added possible "at risk" features? Since the allow-presentation integration into HTML has not happen yet (tracked in w3c/html#437) I suggest we go to revised CR with this token defined in https://w3c.github.io/presentation-api/#sandboxing-and-the-allow-presentation-keyword rather than block on HTML (the HTML integration issue has been open for ~10 months).

[tidoust]

@mfoltzgoogle, could you check that https://w3c.github.io/presentation-api/#changes-since-14-july-2016 is up to date? We're missing at least #414.

See proposed PR: #416

@tidoust, do you see any blockers for advancing with the publication after we've updated changes since and added possible "at risk" features? Since the allow-presentation integration into HTML has not happen yet (tracked in w3c/html#437) I suggest we go to revised CR with this token defined in https://w3c.github.io/presentation-api/#sandboxing-and-the-allow-presentation-keyword rather than block on HTML (the HTML integration issue has been open for ~10 months).

We should be able to publish a new CR as soon as we're clear about "at risk" features. If the problem is the 2-UA mode, we don't need to add a feature at risk but we need to relax our exit criteria. In particular, we would need to drop "Additionally, implementations of the receiving user agent conformance class must include at least one implementation of the 1-UA mode and one implementation of the 2-UA mode" in:
http://w3c.github.io/presentation-api/#cr-exit-criteria

[markafoltz]

@anssiko

Here is an update on feature completeness in Chrome.

Controlling UA

2-UA mode

This has been implemented on Chrome Desktop and Android for some time. It is compatible with Google Cast devices and our Google Cast for Education application.

Note: Presentations using the Cast for Education app as a receiver do not support reconnect().

1-UA mode

This is implemented on Chrome Desktop and planned to be enabled by default in M59 stable (releases in early June). We have just landed support for reconnect() to 1-UA presentations and it should be available in M59 dev next week.

Receiving UA

2-UA mode

There is still no timeline for implementing this in Chrome. The Cast for Education app currently uses a polyfill to implement the PresentationReceiver interface. I would characterize this as at risk.

1-UA mode

This is implemented in Chrome for Desktop and planned to be enabled by default in M59 stable. The recent spec changes around sandboxing flags for the receiving browsing context are not yet implemented, but should be available in M59 or M60.

Other features

The late breaking change to restrict the API to secure contexts will require us to do outreach to affected sites and gather feedback on a timeline for deprecation on insecure contexts. This process is just starting. I would characterize it as at risk if it is part of the exit criteria since we don't know what timeline we are looking at yet.

[markafoltz]

@anssiko

Given what we are looking at now I would be okay with relaxing the exit criteria to:

Additionally, implementations of the receiving user agent conformance class must include at least one implementation of the 1-UA mode or one implementation of the 2-UA mode

I think this is reasonable, given that most all implementations of the receiving user agent will either be one or the other, but not both; they will be a full fledged Web renderer and implement 2-UA, or they will have simpler software to render video streams and implement 1-UA.

For the controlling UA we should continue to require both, since it can't predict what kind of displays will be available.

If I can line up resources to implement 2-UA in Chrome on the current timeline, we can always revise the exit criteria back to the stronger version.

@schien Would like to get an update from Mozilla and hear their thoughts as well.

[tidoust]

@mfoltzgoogle

The late breaking change to restrict the API to secure contexts will require us to do outreach to affected sites and gather feedback on a timeline for deprecation on insecure contexts. This process is just starting. I would characterize it as at risk if it is part of the exit criteria since we don't know what timeline we are looking at yet.

There are two things we need to look at:

1. features at risk, which are features that we may have to drop from the spec
2. exit criteria, which are implementation criteria that need to be met before the spec can be published as Proposed Recommendation.

Trying to reformulate, I understand "at risk" in your text as "at risk of not being implemented in time", not as "at risk of not being implemented at all". In other words, you do not want to drop the restriction to secure contexts, you just need more time to implement. I believe we can make that point to the Director when we request transition to Proposed Recommendation. Even better, we could point that out in the exit criteria already, e.g. with a sentence such as:

"The API was recently restricted to secure contexts. Deprecation of the API in non secure contexts in early implementations takes time. The group may request transition to Proposed Recommendation with implementations that do not restrict the API to secure contexts yet, provided there exists a timeline to add this restriction in the future."

About the 2-UA mode, you noted:

Additionally, implementations of the receiving user agent conformance class must include at least one implementation of the 1-UA mode or one implementation of the 2-UA mode

I do not understand what that sentence means with an "or".

For the controlling UA we should continue to require both, since it can't predict what kind of displays will be available.

... but in the absence of an agreed upon open screen protocol, a controlling UA may not support any 2-UA mode, right?

All in all, I would replace the sentence on the receiving user agent class with a similar sentence for controllers that notes that there may not be any 2-UA receiver initially:

"Implementations of the controlling user agent conformance class must include at least one implementation of the 1-UA mode, and one implementation of the 2-UA mode. In the absence of a common protocol for the 2-UA case, the implementation report may not contain any implementation of a receiving user agent conformance class for the 2-UA mode. In other words, the implementation of the controlling user agent conformance class in 2-UA mode may only support non http/https presentation URLs."

Would these two proposed additions work for everyone?

[markafoltz]

I do not understand what that sentence means with an "or".

The intention was that, as an exit criterion, a given receiving user agent may implement 1-UA, 2-UA, or both. Not that every receiving user agent under consideration has to implement both.

... but in the absence of an agreed upon open screen protocol, a controlling UA may not support any 2-UA mode, right?

2-UA mode is not necessarily related to the underlying protocol. 2-UA is about which device renders the presentation, not about the protocol that ties devices together being standardized or not.

As I discussed above, Chrome is already shipping a 2-UA controller with support for reconnect() pending.

[anssiko]

@tidoust, can you take the lead in revising, where appropriate, the following sections based on the (ongoing) discussion in this issue:

• "At risk" features in Status of This Document
• CR exit criteria

It is probably easier for the group to review the proposal given a concrete PR.

(On a related note, I just enabled pr-preview for this spec. This GitHub integration will automatically add preview and HTML diff links to pull requests to ease the review of any future PRs.)

[tidoust]

@anssiko and all, see PR #418.

@mfoltzgoogle, I understand the intent. See suggested text in pull request. I added a note about the fact that 2-UA controllers will only support non http/https presentation URLs in the absence of a 2-UA receiver. Goal is to be upfront that this is expected.

[anssiko]

#418 landed to relax CR exit criteria to match known implementations plans.

We got one last minute spec bug report #419 from @tomoyukilabs (thanks!).

@mfoltzgoogle could you analyze?

[anssiko]

The looming CR refresh (as well as the amazing work on the test suite) has triggered the group to review the spec very carefully and thus the group has unearthed two new issues last week, in addition to #419.

The current status of the CR blockers is the following (let me know if I missed something):

#419 - proposed fix #426 to be landed
#421 - @mfoltzgoogle has a question to the group; All - please review
#422 - proposed fix #425 to be landed

I suggest we do not try to rush to CR, and take our time to solve these issues first.

[anssiko]

Updated my "CR blockers tracker" at #406 (comment) with the latest status.

All - the last remaining issue #421 is looking for your input.

[anssiko]

We're finally very close to shipping an updated CR.

@tidoust, could you help us close #421 and land #429.

Thanks for your perseverance everyone.

[anssiko]

Current status: closed #421 and landed #429. We're about to branch for release.

@mfoltzgoogle, I submitted #431 to fix some broken links, I assume you'd be good for us to branch for release after that fix has landed?

@tidoust, could you help prepare a publication-ready updated CR snapshot after @mfoltzgoogle's confirmation. I suggest we use four weeks CR comment period, unless there's a good reason to make the period longer (this is a second CR, so the review is mainly on the delta). After we branch for release and have a publication-ready snapshot, you need to apply a minor patch to fix the ReSpec auto-generated EventHandler link.

[tidoust]

@anssiko You may park the document in the "TR" branch if you want, or give it a label, but basically the document is ready for publication from my perspective.

More precisely, the following URI would generate the updated CR:
https://w3c.github.io/presentation-api/?specStatus=CR;previousMaturity=CR;previousPublishDate=2016-07-14;crEnd=2017-06-23;publishDate=2017-05-26

... adjusting the date parameters as needed based on actual publication date. Four weeks after publication is good in our case. I'll fix the links right before publication in /TR/ space.

What I need now is a WG decision to publish that document as an updated Candidate Recommendation so that I can obtain the Director's approval to publish the new CR.

[anssiko]

@tidoust, I just sent a Call for Consensus to publish, ending 17 May.

I'm fine with us using the "living" CR snapshot as a point of reference during the CfC period.

[anssiko]

@tidoust, the CfC passed with no concerns raised. Please obtain the Director's approval to publish the new CR.

WG participants, congratulations are in place for all of you for reaching this milestone. Special thanks to @mfoltzgoogle for editing the spec, @tomoyukilabs, @louaybassbouss, and @tidoust for testing contributions, @schien and @mfoltzgoogle for providing continuos implementation feedback, and @tidoust for all the support during this journey along the Rec Track.

[louaybassbouss]

A lot of thanks also to you @anssiko. I had this week the chance to meet @tidoust in Berlin and we are going to create the new Test report during next week. We will focus on 1-UA mode since we don't have yet a complete 2-UA mode implementation which includes receiver part ( @mfoltzgoogle please correct me if I am wrong).

[markafoltz]

Chrome doesn't have a full, native implementation of the 2-UA receiver.

The Cast for Education Chrome app [1] supports 2-UA receiver through a polyfill. It does not yet support reconnect().

As you are aware, Chromecast devices also act as a 2-UA receiver, but reconnect() doesn't work per spec and the receiver also requires a polyfill.

[1] https://chrome.google.com/webstore/detail/google-cast-for-education/bnmgbcehmiinmmlmepibeeflglhbhlea?hl=en-US

[tidoust]

A revised Candidate Recommendation of the Presentation API has just been published. I'm closing this meta issue as a result. Well done everyone!