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

Bernard Aboba <> Wed, 21 September 2011 16:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5B24D1F0CAD for <>; Wed, 21 Sep 2011 09:01:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.363
X-Spam-Status: No, score=-102.363 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3tVKLgu+ainC for <>; Wed, 21 Sep 2011 09:01:15 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BEE4A1F0CA9 for <>; Wed, 21 Sep 2011 09:01:15 -0700 (PDT)
Received: from BLU152-W7 ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Wed, 21 Sep 2011 09:03:44 -0700
Message-ID: <BLU152-W7703BEF679E9364856FB6930D0@phx.gbl>
Content-Type: multipart/alternative; boundary="_40d3c9b8-6b22-449c-9575-5354d683ec60_"
X-Originating-IP: []
From: Bernard Aboba <>
Date: Wed, 21 Sep 2011 09:03:44 -0700
Importance: Normal
In-Reply-To: <>
References: <> <>, <>, <>
MIME-Version: 1.0
X-OriginalArrivalTime: 21 Sep 2011 16:03:44.0685 (UTC) FILETIME=[0A0BB5D0:01CC7878]
Subject: Re: [rtcweb] Call for Consensus on Use Case for Screen/Application/Desktop sharing
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 21 Sep 2011 16:01:16 -0000

Stefan said: 

> Anyway, I seem to be rather lonely in my corner of the room, but I 
> maintain my opinion that we should defer this to a later stage.

[BA]  You are not lonely (at least with respect to deferring discussion of scenario B). 

I believe that we can include scenario A within the use case document
and security document, and see how much this affects the requirements and
security issues (I expect not too much). 

However, I am in favor of deferring scenario B rather than adding it.  This
scenario has potentially major security implications, which could slow progress
on other items.  To me, this is a good reason to defer it.  If we keep adding
major work items, the overall schedule will slip, and that is quite dangerous.