Re: [presentation-api] [meta] Publish a revised Candidate Recommendation

@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?

-- 
GitHub Notification of comment by tidoust
Please view or discuss this issue at https://github.com/w3c/presentation-api/issues/406#issuecomment-289391289 using your GitHub account

Received on Monday, 27 March 2017 08:47:23 UTC