Re: Proposed W3C Charter: Second Screen Working Group

[Shih-Chiang Chien]

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  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"  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 
>> 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 
>> 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 

Re: Proposed W3C Charter: Second Screen Working Group

[Martin Thomson]

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"  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  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 
> 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
> 

Re: Proposed W3C Charter: Second Screen Working Group

[Tantek Çelik]

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  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  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.  

Re: Proposed W3C Charter: Second Screen Working Group

[Peter Saint-Andre]

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  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, 

Re: Proposed W3C Charter: Second Screen Working Group

[L. David Baron]

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  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 

Re: Proposed W3C Charter: Second Screen Working Group

[Peter Saint-Andre]

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  > 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
> > 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 

Re: Proposed W3C Charter: Second Screen Working Group

[Eric Rescorla]

LGTM!

On Thu, Jan 4, 2018 at 9:56 PM, L. David Baron  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 
> 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 
> 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/.html
> > >>>
> > >>> Mozilla has the opportunity to send comments or objections through
> > >>> Friday, January 52.  (Sorry for failing to send this out 

Re: Proposed W3C Charter: Second Screen Working Group

[L. David Baron]

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  
> > 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  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/.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=https%3A%2F%2Fw3c.
> >>> github.io%2Fsecondscreen-charter%2F
> >>>
> >>> The participants in 

Re: Proposed W3C Charter: Second Screen Working Group

[Peter Saint-Andre]

+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  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  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/.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=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=1=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
>> https://lists.mozilla.org/listinfo/dev-platform
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> 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

Re: Proposed W3C Charter: Second Screen Working Group

[Martin Thomson]

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  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  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/.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=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=1=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
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Second Screen Working Group

[Shih-Chiang Chien]

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  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/.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=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=1=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
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Second Screen Working Group

[L. David Baron]

I've submitted a response in support of the charter, without
comments.

-David

On Monday 2016-10-24 10:47 +0800, Shih-Chiang Chien wrote:
> Support revised charter.
> 
> The revised charter creates some flexibility for us to promote Flyweb as a
> new feature in Presentation API Level 2, which has been discussed in the
> F2F meeting of the WG this year. It also create a good structure to move
> non-WebAPI discussion to CG and keep WG focusing on the API development.
> 
> [additional information on Mozilla's implementation plan]
> The current plan is to enable 1-UA implementation on Fennec on Nightly
> (release 52). No detailed engineering plan on Firefox desktop for now. We
> are cultivating some proposal to identify the usability of this API on
> desktop browser before dumping engineering resource on it.
> 
> Best Regards,
> Shih-Chiang Chien
> Mozilla Taiwan
> 
> On Sat, Oct 22, 2016 at 5:46 AM, Tantek Çelik 
> wrote:
> 
> > I have reviewed the charter and the current set of deliverables. The
> > work appears to be proceeding reasonably (pragmatically, with many
> > members/implementers including Apple and Google) and reasonably
> > minimally scoped. There is also the companion Second Screen Community
> > Group which appears to be used to incubate work before proceeding in
> > the working group, a pattern which we are generally supportive of.
> >
> > Support revised charter.
> >
> > I don't know of our current implementation plans on this WG's deliverables.
> >
> > The most recent discussion here of any of the deliverables of the WG
> > was on "PresentationAPI", in particular a "[PresentationAPI] Intend to
> > implement" thread here in 2014 September.
> >
> > Tantek
> >
> >
> > On Mon, Oct 17, 2016 at 12:28 PM, L. David Baron 
> > wrote:
> > > The W3C is proposing a revised charter for:
> > >
> > >   Second Screen Working Group
> > >   https://lists.w3.org/Archives/Public/public-new-work/2016Sep/0011.html
> > >   https://www.w3.org/2014/secondscreen/charter-2016.html
> > >
> > > Mozilla has the opportunity to send comments or objections through
> > > next Tuesday, October 25.
> > >
> > > 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.
> > >
> > > Mozilla does have participants in this group:
> > > https://www.w3.org/2000/09/dbwg/details?group=74168=1=org#_
> > MozillaFoundation
> > >
> > > -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
> > > https://lists.mozilla.org/listinfo/dev-platform
> > >
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > 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)


signature.asc
Description: PGP signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Second Screen Working Group

[Tantek Çelik]

I have reviewed the charter and the current set of deliverables. The
work appears to be proceeding reasonably (pragmatically, with many
members/implementers including Apple and Google) and reasonably
minimally scoped. There is also the companion Second Screen Community
Group which appears to be used to incubate work before proceeding in
the working group, a pattern which we are generally supportive of.

Support revised charter.

I don't know of our current implementation plans on this WG's deliverables.

The most recent discussion here of any of the deliverables of the WG
was on "PresentationAPI", in particular a "[PresentationAPI] Intend to
implement" thread here in 2014 September.

Tantek


On Mon, Oct 17, 2016 at 12:28 PM, L. David Baron  wrote:
> The W3C is proposing a revised charter for:
>
>   Second Screen Working Group
>   https://lists.w3.org/Archives/Public/public-new-work/2016Sep/0011.html
>   https://www.w3.org/2014/secondscreen/charter-2016.html
>
> Mozilla has the opportunity to send comments or objections through
> next Tuesday, October 25.
>
> 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.
>
> Mozilla does have participants in this group:
> https://www.w3.org/2000/09/dbwg/details?group=74168=1=org#_MozillaFoundation
>
> -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
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform