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

Emil Ivov <> Wed, 21 September 2011 18:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DFA7821F8C36 for <>; Wed, 21 Sep 2011 11:47:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.378
X-Spam-Status: No, score=-3.378 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VpC2AHOAB4DR for <>; Wed, 21 Sep 2011 11:47:10 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 035F721F8C32 for <>; Wed, 21 Sep 2011 11:47:09 -0700 (PDT)
Received: by ewy1 with SMTP id 1so1888738ewy.15 for <>; Wed, 21 Sep 2011 11:49:37 -0700 (PDT)
Received: by with SMTP id m52mr1352205wel.33.1316630977338; Wed, 21 Sep 2011 11:49:37 -0700 (PDT)
Received: from camionet.local ( []) by with ESMTPS id fa3sm7992933wbb.3.2011. (version=TLSv1/SSLv3 cipher=OTHER); Wed, 21 Sep 2011 11:49:36 -0700 (PDT)
Message-ID: <>
Date: Wed, 21 Sep 2011 20:49:34 +0200
From: Emil Ivov <>
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; bg; rv: Gecko/20110902 Thunderbird/3.1.14
MIME-Version: 1.0
To: Bernard Aboba <>
References: <> <>, <>, <> <BLU152-W7703BEF679E9364856FB6930D0@phx.gbl>
In-Reply-To: <BLU152-W7703BEF679E9364856FB6930D0@phx.gbl>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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 18:47:11 -0000

На 21.09.11 18:03, Bernard Aboba написа:
> 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.

Why would the schedule slip? If this is an optional extension, as
everyone agrees it should be, how could it delay the main specs and
implementations? Even if there are indeed some unforeseen grave security
issues (which I am not all that sure about), then it they would only
delay release of this extension, wouldn't they?