Re: Timing of TAG review

On Mon, Jun 8, 2015 at 1:24 AM, Francois Daoust <fd@w3.org> wrote:

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


This sounds like a good list.  Looking over the list of open issues I don't
see anything else substantive from an API point of view.


> 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.
>

Yes we should reorganize the spec first to define the two conformance
classes as you've noted previously, update the terminology for "sessions"
[1], and incorporate a proposal for separate interfaces for the controlling
and presenting contexts along the lines of #91.

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.
>

The only other item that we might note is Anton's proposal to extend the
<media> tag to support presentation (#13), and any feedback on the
cross-origin capabilities of the API (#63).

Since all of these items are associated with GH issues, perhaps we can add
a TAG tag (no pun intended) to them?


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

[1] http://www.w3.org/2015/05/19-webscreens-minutes.html#action12