Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]

Randell Jesup <randell-ietf@jesup.org> Mon, 19 September 2011 15:00 UTC

Return-Path: <randell-ietf@jesup.org>
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 C844721F8C39 for <rtcweb@ietfa.amsl.com>; Mon, 19 Sep 2011 08:00:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.539
X-Spam-Level:
X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 2fkFbEoIjT33 for <rtcweb@ietfa.amsl.com>; Mon, 19 Sep 2011 08:00:09 -0700 (PDT)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id D273521F8C2B for <rtcweb@ietf.org>; Mon, 19 Sep 2011 08:00:09 -0700 (PDT)
Received: from pool-173-49-141-165.phlapa.fios.verizon.net ([173.49.141.165] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <randell-ietf@jesup.org>) id 1R5fMe-0006F2-SN for rtcweb@ietf.org; Mon, 19 Sep 2011 10:02:32 -0500
Message-ID: <4E7758BF.7030709@jesup.org>
Date: Mon, 19 Sep 2011 10:59:11 -0400
From: Randell Jesup <randell-ietf@jesup.org>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <CALiegfnOCxyTo9ffQ272+ncdu5UdgrtDT-dn10BWGTZMEjZoCg@mail.gmail.com> <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> <8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com> <CA+9kkMAwnnKKO5+q6ey4Z0QNxax1QF21vVtw8FNsHy_rmfenjQ@mail.gmail.com> <4E76E078.5020708@jesup.org> <8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com> <4E77495E.4000409@jesup.org> <CABcZeBPkJug4cepU2gmGufLrcc26iX+JMwj-D0afEyvV1EnnUA@mail.gmail.com>
In-Reply-To: <CABcZeBPkJug4cepU2gmGufLrcc26iX+JMwj-D0afEyvV1EnnUA@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Source:
X-Source-Args:
X-Source-Dir:
Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]
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 15:00:10 -0000

On 9/19/2011 10:24 AM, Eric Rescorla wrote:
> On Mon, Sep 19, 2011 at 6:53 AM, Randell Jesup<randell-ietf@jesup.org>  wrote:
>> On 9/19/2011 6:23 AM, Hadriel Kaplan wrote:
>>> On Sep 19, 2011, at 2:26 AM, Randell Jesup wrote:
>>>
>>>> The point was made repeatedly when I explained this primary area of
>>>> contention that we want it to be easy to use by the "little guys", and that
>>>> even if signalling was a downloaded JS library, you'd end up with a wild
>>>> mixture of old versions in use, which may complicate interop/federation
>>>> (plus the overhead to pull them down, and some possible security issues).
>>> And you think having it in the Browsers won't end up with a wild mixture
>>> of old versions in use, and complicated interop/federation?
>> Not compared to the complexity if it's all "roll-your-own".  No one
>> suggested that
>> people be locked into a signalling protocol, and JS libraries are an option.
>>   We do
>> have a lot of experience with pseudo-standard APIs implemented in JS, such
>> as jquery
>> and many others, and these aren't unrealistic concerns.
> Randell,
>
> Does auto-updating change the landscape in terms of the browser
> version distribution?

Absolutely.


>
> Mozilla have measurements on what fraction of the modern (i.e. post FF4)
> browser base is running the latest version of Firefox?
I know there are better figures out there (but I'm not sure if they're
public, and I'm just working off these).

http://www.w3schools.com/browsers/browsers_firefox.asp

Note that FF6 was released during the middle of August, so 9.5% FF6,
15.9% FF5 (2.9% FF4) is actually pretty good.

May->July went from 23.4% FF4, 0.3% FF5 (betas probably) to 4.6% FF4,
23.2% FF5 (0.6% FF6 betas).

Those are out of all browsers, not just firefox, so the totals for firefox
are around 40-42%.

FF3.6 users are around 10% (roughly 1/4 of FF users) and slowly declining.
There are issues there with large managed deployments; I won't re-open that
can of worms here beyond saying we're working with such users to find ways
to get them the ability to move forward.

Chrome by all accounts has a higher uptake of new versions; largely from
the silent background update behavior and partly from not having (or having
less) locked-down enterprise deployments the way IE and Firefox do.

We're looking into ways to make updating easier, more automatic and less
painful for users without violating the principle of user control. (Again,
a topic for another forum.)



-- 
Randell Jesup
randell-ietf@jesup.org