Thanks David, the revised comment lgtm. Making SecondScreen WG focusing on interoperability first would be a better direction for now.
Best Regards, Shih-Chiang Chien Mozilla Taiwan On Sat, Jan 6, 2018 at 6:37 PM, Martin Thomson <m...@mozilla.com> wrote: > Thanks for doing this David. The objection here is very neatly put. I > hope that we can do something soon to help address the shortcoming > regarding the protocol. > > On 6 Jan. 2018 2:26 pm, "Tantek รelik" <tan...@cs.stanford.edu> wrote: > >> This is an improvement and I think has a better chance of effecting >> change with the specific proposals. >> >> We're still making this an FO right? (I think we should) >> >> perhaps: >> >> s/We would ask that:/We ask (formal objection) that: >> >> Your "open to other paths" closing statement provides an out to >> resolving the FO without necessarily doing everything we precisely >> ask, which both helps the dialog, and allows us room to declare the FO >> upfront. >> >> Thanks, >> >> Tantek >> >> On Fri, Jan 5, 2018 at 12:58 PM, L. David Baron <dba...@dbaron.org> >> 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/htmldi >> ff?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/dbw >> g/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) >> > >> > _______________________________________________ >> > dev-platform mailing list >> > dev-platform@lists.mozilla.org >> > https://lists.mozilla.org/listinfo/dev-platform >> > >> > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
