Re: Timing of TAG review

Hi Mark,

On 2015-06-05 23:37, mark a. foltz wrote:
> Hello,
>
> The Chromium implementation of the Presentation API is nearing a
> milestone where we would like to give Web developers an opportunity to
> use an early version of the API in the Chrome developer channel.
>
> As part of the process of exposing the API, the Chrome Web platform team
> usually wants to see a W3C TAG review of the specification requested or
> in progress.

Side process note in case people are wondering: asking the TAG to review 
our spec is not required per process as such. The group must be able to 
show that the specification has received wide review [1] before 
publishing the spec as Candidate Recommendation (we're not there yet), 
but a wide review does not necessarily have to include a TAG review. 
That said, the TAG has started to review specs more and more in the 
recent past, I believe we have good questions to ask the TAG, and thus I 
strongly agree that we should get in touch with them about the 
Presentation API.

>
> I wanted to ask about the timing of this review: when do we anticipate
> requesting this review, and are there any tasks to complete before the
> specification will be ready for review to begin?

On the list of tasks to complete before getting in touch with the TAG, I 
would suggest the following:

1. Integrate updates based on recent F2F resolutions, especially those 
that could confuse external people or trigger reactions:
  #39 drop the presentationId parameter from startSession
  #81 update the availability monitoring interface
  #9 add a URL parameter to getAvailability
  perhaps #19 updates on multiple controlling pages, although I see 
discussions are still ongoing

I think that's about it but I may have missed one or two. Anything else?
Do you think that's possible or is there anything blocking?


2. It would be nice to have the presenting side appear more explicitly 
in the spec as well, be it only as a sketch (restrictions of the 
browsing context, basic initialisation algorithm). Typically, this 
affects the list of products that will implement the spec (i.e. the 
conformance classes) and this is where we would want to reference the 
"private browsing mode" spec that the TAG is working on.

This could perhaps be replaced by prose in the request for review we'll 
send to the TAG (as in "while not in the spec yet, please note that the 
group will..."), since these updates seem heavier to me so probably 
require more time.

Once updates have been made, we should re-publish the updated draft, 
switching to the automated publication system. This is more for clarity 
than anything else as we can certainly ask the TAG to review the 
editor's draft on GitHub.


We should also list specific topics for which we're asking the TAG for 
input. It is all the more important than the group is still discussing 
many issues, so the TAG won't be looking at a stable spec yet. On top of 
my head, I would say:

a) Balancing the need to deal with legacy content that uses nested 
browsing contexts and the idea of creating a new allowpresentation 
iframe attribute (see issue #79)
b) Suggestions on security requirements for the messaging channel in 
secure contexts, taking into account the fact that the spec wants to 
remain agnostic of the underlying protocols (see issue #80).
c) Comments on the group's willingness to request that the presenting 
content load in a private browsing context to deal with security and 
privacy, as presenting device may be a shared device (see issue #45?). 
Also, what is the status of the TAG's work on the topic and do you have 
any recommended wording?
d) Other security and privacy considerations, noting that it is up to 
the presenting app to identify the provenance of incoming messages (#45)
e) Comments on fingerprinting implications of filtering capabilities (#9)

All, let me know if you have other questions in mind, would rather ask 
different questions, or would not get in touch with the TAG at this stage.

Thanks,
Francois.

[1] http://www.w3.org/2014/Process-20140801/#wide-review

Received on Monday, 8 June 2015 08:24:22 UTC