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 > <mailto: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 > <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 <mailto: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 <mailto:dba...@dbaron.org>> wrote: > > >> > > >>> The W3C is proposing a revised charter for: > > >>> > > >>> Second Screen Working Group > > >>> https://w3c.github.io/secondscreen-charter/ > <https://w3c.github.io/secondscreen-charter/> > > >>> > https://lists.w3.org/Archives/Public/public-new-work/2017Dec/0000.html > <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% > <https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2014%> > > >>> 2Fsecondscreen%2Fcharter-2016.html&doc2=https%3A%2F%2Fw3c. > > >>> github.io <http://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 > <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. > > >>> > > >>> -David > > >>> > > >>> -- > > >>> 𝄞 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) > > >>> > > >> _______________________________________________ > > >> dev-platform mailing list > > >> dev-platform@lists.mozilla.org > <mailto:dev-platform@lists.mozilla.org> > > >> https://lists.mozilla.org/listinfo/dev-platform > <https://lists.mozilla.org/listinfo/dev-platform> > > > _______________________________________________ > > > dev-platform mailing list > > > dev-platform@lists.mozilla.org > <mailto:dev-platform@lists.mozilla.org> > > > https://lists.mozilla.org/listinfo/dev-platform > <https://lists.mozilla.org/listinfo/dev-platform> > > > > > > > > > > -- > 𝄞 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) > > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org <mailto:dev-platform@lists.mozilla.org> > https://lists.mozilla.org/listinfo/dev-platform > <https://lists.mozilla.org/listinfo/dev-platform> > >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
