Re: [rtcweb] Call for Consensus on Use Case for Screen/Application/Desktop sharing

Hadriel Kaplan <HKaplan@acmepacket.com> Mon, 19 September 2011 10:36 UTC

Return-Path: <HKaplan@acmepacket.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81C7121F8A80 for <rtcweb@ietfa.amsl.com>; Mon, 19 Sep 2011 03:36:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.514
X-Spam-Level:
X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xttm-rkex5gI for <rtcweb@ietfa.amsl.com>; Mon, 19 Sep 2011 03:36:58 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id DA2D821F8A4E for <rtcweb@ietf.org>; Mon, 19 Sep 2011 03:36:57 -0700 (PDT)
Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 19 Sep 2011 06:39:19 -0400
Received: from MAIL1.acmepacket.com ([169.254.1.150]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Mon, 19 Sep 2011 06:39:19 -0400
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Thread-Topic: [rtcweb] Call for Consensus on Use Case for Screen/Application/Desktop sharing
Thread-Index: AQHMdrhjdof5AQZHskOT2rgEkdz1cw==
Date: Mon, 19 Sep 2011 10:39:19 +0000
Message-ID: <017078EC-3E1A-4CC4-A29F-51B569474416@acmepacket.com>
References: <4E76E8E8.2050102@ericsson.com>
In-Reply-To: <4E76E8E8.2050102@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [216.41.24.34]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <DF18B28CCEFE8749B83BA037372D857B@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Call for Consensus on Use Case for Screen/Application/Desktop sharing
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Sep 2011 10:36:58 -0000

On Sep 19, 2011, at 3:02 AM, Magnus Westerlund wrote:

> A) Where the RTCWEB enabled browser can use a local application window,
> the whole desktop or a Screen as a media source that can be encoded and
> transported over the peerConnection for displaying/playback at the peer.
> 
> B) Where a remote peer can provide one or more input types such as mouse
> and keyboard to control the local system, not only including the
> browser, but also other operating system resources. This clearly can
> only happen after additional consent, most likely on a per occasion
> consent.
> 
> My interpretation is that A only allows for application sharing in
> conferencing contexts, like in the WEBEX session the Interim meeting was
> held with where we shared slides. Where the combination of A and B is
> providing for VNC/Remote desktop.
> 
> Thus the question to the WG is the following.
> 
> 1) Do you support or object the inclusion of use case A, B or Both in
> our Use case document?
> 
> 2) Do you have additional comments for or against either of the use cases?

I think scenario A is less worrisome than B.  Scenario A is a lot like webex, obviously, and from a logical perspective if we're going to be able to take a local video file as input to a PeerConnection LocalMediaStream, and the video file could be of me doing stuff on my screen, then this is just a shortcut to taking the video and sending the file at the same time.

Scenario B, on the other hand, is the other half of VNC and my IT dept. would probably freak if a browser could do this, even with user consent.  (in fact, they'd probably freak at Scenario A too)  There's a big difference between installing an application for a specific purpose such as VNC, vs. random Javascript on websites turning the browser into VNC.  Was there discussion on the con call about what IT department types would think of these two scenarios?

-hadriel