Looks good. Thanks, David! On 1/5/18 1:58 PM, L. David Baron wrote: > So after a little off-list discussion with SC, I have a somewhat > revised proposal for comments that perhaps proposes what might be a > more acceptable remedy (although thanks to timezones I don't > actually know what SC thinks of this proposal). > > -David > > ===== > > The current situation with the API developed by this Working Group > is that it is a API for a web page to interact with a connection > between the web browser and a separate screen that exists entirely > in a closed ecosystem. For example, a browser made by Google might > connect to displays that support the proprietary Chromecast > protocol, whereas one made by Apple might connect to displays that > support the proprietary AirPlay protocol. > > We know that parts of an Open Screen Protocol are in an early stage > of development at https://github.com/webscreens/openscreenprotocol > (as linked from the charter), and the goal of this work is to > improve on this situation. We hope it will allow for interoperable > discovery of, identification of, and communication with presentation > displays. > > However, we're deeply concerned about chartering a second iteration > of the work that continues building the Presentation API on top of a > closed ecosystem, when the work to make the ecosystem more open > appears to have a lower priority. While we understand that the work > on building an open ecosystem still requires incubation, we believe > it should have the highest priority in this space. > > We would ask that: > > * the charter be clearer that modifications to the current CR-level > specs that are needed to achieve interoperability are expected > (rather than saying "This Working Group does not anticipate > further changes to this specification."), > > * the charter be clearer that building an open system that allows > multiple browsers to interact with multiple displays is a > requirement for the specifications advancing to Proposed > Recommendation and to Recommendation, and > > * work on a second level of the presentation API remain in > incubation (and not yet be added to this charter) until after the > work to build an open protocol moves from incubation into > standardization, > > although we are open to other paths toward fixing this situation. > > > On Friday 2018-01-05 09:36 -0700, Peter Saint-Andre wrote: >> Agreed. Thanks for the careful wording, David! (BTW s/apple/Apple/) >> >> On 1/5/18 9:08 AM, Eric Rescorla wrote: >>> LGTM! >>> >>> On Thu, Jan 4, 2018 at 9:56 PM, L. David Baron <dba...@dbaron.org> wrote: >>>> >>>> So I think Martin, Peter, and I share similar concerns here, and I'm >>>> inclined to turn those concerns into an objection to this charter. >>>> >>>> So how does this sound for proposed comments on the charter >>>> (submitted as a formal objection)? Note that I've tried to turn the >>>> comments into a specific suggestion for a remedy, but I'm far from >>>> sure if that suggestion is the right one. >>>> >>>> I've avoided mentioning the comment about "further changes" in the >>>> specs that the existing working group has in CR, to avoid >>>> distracting from what I think is the main piece. But let me know if >>>> you see a good way to work it in. >>>> >>>> But I'd be particularly interested to hear if SC thinks this might >>>> be harmful rather than helpful to the end goal for some reason, or >>>> if he has other disagreements with this approach, or better >>>> suggestions for what remedy we should suggest. >>>> >>>> -David >>>> >>>> ===== >>>> >>>> The current situation with the API developed by this Working Group >>>> is that it is a API for a web page to interact with a connection >>>> between the web browser and a separate screen that exists entirely >>>> in a closed ecosystem. For example, a browser made by Google might >>>> connect to displays that support the proprietary Chromecast >>>> protocol, whereas one made by apple might connect to displays that >>>> support the proprietary AirPlay protocol. >>>> >>>> We know that parts of an Open Screen Protocol are in an early stage >>>> of development at https://github.com/webscreens/openscreenprotocol >>>> (as linked from the charter), and the goal of this work is to >>>> improve on this situation. We hope it will allow for interoperable >>>> discovery of, identification of, and communication with presentation >>>> displays. However, we're deeply concerned about chartering a second >>>> iteration of the work that continues building the Presentation API >>>> on top of a closed ecosystem, when the work to make the ecosystem >>>> more open has a lower priority. While we understand that the work >>>> on building an open ecosystem still requires incubation, we believe >>>> it should have the highest priority in this space. We believe that >>>> rechartering the Second Screen WG should wait until that work is >>>> ready to be in a working group, and that advancing the current >>>> specifications (developed under the existing charter) to Proposed >>>> Recommendation probably depends on this new work in order to >>>> demonstrate real interoperability, although we are open to other >>>> paths toward fixing this situation. >>>> >>>> >>>> On Thursday 2018-01-04 09:29 -0700, Peter Saint-Andre wrote: >>>>> +1 to Martin's feedback. >>>>> >>>>> On 1/3/18 10:19 PM, Martin Thomson wrote: >>>>>> Without the protocol pieces, this remains vendor-specific. We should >>>>>> comment on this and make it clear that we think that definition of a >>>>>> generic protocol for interacting with the second display has not been >>>>>> given sufficient priority. Allowing this to proceed without a generic >>>>>> protocol would be bad for the ecosystem. >>>>>> >>>>>> From what I can see, there seem to be a bunch of options that are >>>>>> described for the protocol, without extremely scant detail. Certainly >>>>>> not enough to implement anything. >>>>>> >>>>>> I'm concerned with the statement "This Working Group does not >>>>>> anticipate further changes to this specification" regarding the >>>>>> presentation API. I haven't reviewed this thoroughly, but there >>>>>> appear to be some gaps in rather fundamental pieces. For instance - >>>>>> and maybe this doesn't change the API at all - but the means of >>>>>> identification for screens is unclear. Some of these details are >>>>>> important, such as whether knowledge of a presentation URL is all the >>>>>> information necessary to use that URL (i.e., are they capability >>>>>> URLs?). >>>>>> >>>>>> On Thu, Jan 4, 2018 at 2:31 PM, Shih-Chiang Chien <sch...@mozilla.com> >>>>>> wrote: >>>>>>> The SecondScreen WG intended to move the protocol development to CG, and >>>>>>> will possibly move to IETF after the incubation phase. >>>>>>> The revised charter is trying to associate the work of CG to the >>>>>>> timeline >>>>>>> of Presentation API development. >>>>>>> >>>>>>> At the meantime, WG will tackle the testability issue found while >>>>>>> creating >>>>>>> test cases and cultivating Level 2 API requirements for advanced use >>>>>>> cases. >>>>>>> >>>>>>> I'll vote to support this revised charter. >>>>>>> >>>>>>> Best Regards, >>>>>>> Shih-Chiang Chien >>>>>>> Mozilla Taiwan >>>>>>> >>>>>>> On Thu, Jan 4, 2018 at 10:08 AM, L. David Baron <dba...@dbaron.org> >>>>>>> wrote: >>>>>>> >>>>>>>> The W3C is proposing a revised charter for: >>>>>>>> >>>>>>>> Second Screen Working Group >>>>>>>> https://w3c.github.io/secondscreen-charter/ >>>>>>>> >>>>>>>> https://lists.w3.org/Archives/Public/public-new-work/2017Dec/0000.html >>>>>>>> >>>>>>>> Mozilla has the opportunity to send comments or objections through >>>>>>>> Friday, January 52. (Sorry for failing to send this out sooner!) >>>>>>>> >>>>>>>> A diff relative to the current charter is: >>>>>>>> https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2014%2Fsecondscreen%2Fcharter-2016.html&doc2=https%3A%2F%2Fw3c.github.io%2Fsecondscreen-charter%2F >>>>>>>> >>>>>>>> The participants in the working group are: >>>>>>>> https://www.w3.org/2000/09/dbwg/details?group=74168&public=1&order=org >>>>>>>> >>>>>>>> Please reply to this thread if you think there's something we should >>>>>>>> say as part of this charter review, or if you think we should >>>>>>>> support or oppose it. >>>>>>>> >>>>>>>> One longstanding concern for me with this work is to what extent it >>>>>>>> defines an API that lets an Google-made browser talk to a Google >>>>>>>> screen, and an Apple-made browser talk to an Apple screen, versus to >>>>>>>> what extent it allows any browser to talk to any screen that >>>>>>>> supports a particular piece of technology. I think there might >>>>>>>> have been some encouraging news on this front at TPAC in November, >>>>>>>> but I don't remember the details. But if there was, I'd rather >>>>>>>> expect it to be incorporated into this charter, but I don't really >>>>>>>> see that after a first read. I'm curious what others know and think >>>>>>>> about this issue. > > > >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
