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/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) > > > > _______________________________________________ > > 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
