W3C home > Mailing lists > Public > public-secondscreen@w3.org > July 2015

Re: Request for a TAG review of the Presentation API

From: mark a. foltz <mfoltz@google.com>
Date: Tue, 28 Jul 2015 10:20:00 -0700
Message-ID: <CALgg+HHtrmXwf3=obYUyWm_H+GP8twzUoXhn8pNg_XGNot0oTw@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: Francois Daoust <fd@w3.org>, TAG <www-tag@w3.org>, "public-secondscreen@w3.org" <public-secondscreen@w3.org>
On Tue, Jul 28, 2015 at 12:49 AM, Anne van Kesteren <annevk@annevk.nl>
wrote:

> On Tue, Jul 28, 2015 at 7:46 AM, mark a. foltz <mfoltz@google.com> wrote:
> > I think if we wanted to leverage this work, we would have to write the
> spec
> > in a way that applied it across the various combinations of raw
> > TCP/WebSockets/RTCDataChannel and TLS/DTLS that might be used to
> establish
> > the communication channel.   At the end of the day I don't know it's the
> job
> > of the Presentation API specification to mandate network level protocols
> at
> > that level though.
>
> It definitely needs to be defined. We can't define high-level APIs and
> leave all the underpinnings undefined. That results in a platform that
> is not interoperable. Given a Google TV and a Mozilla phone, I should
> be able to project from the latter on the former. A X phone should be
> able to project too, provided X implemented the standard.
>
> "There be dragons" is not acceptable.
>

I was not addressing interoperability above.  The question I was addressing
is how the security architecture of RTCWeb might be relevant to the
desirable security properties of the Presentation API.  We could provide
perfect interoperability without securing anything, let's not confuse the
issues.

I will file a separate issue to discuss the status of interoperability
among implementers and we can get a better sense of where we are at.  Any
standard(s) that form the basis for interoperability should meet the
desired security requirements.


>
> --
> https://annevankesteren.nl/
>
Received on Tuesday, 28 July 2015 17:20:48 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 28 July 2015 17:20:49 UTC