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. -- 𝄞 L. David Baron http://dbaron.org/ 𝄂 𝄢 Mozilla https://www.mozilla.org/ 𝄂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914)
signature.asc
Description: PGP signature
_______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
