Re: [rtcweb] URIs for rtcweb "calls"

Harald Alvestrand <harald@alvestrand.no> Tue, 16 August 2011 08:50 UTC

Return-Path: <harald@alvestrand.no>
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 8DC7221F8B6D for <rtcweb@ietfa.amsl.com>; Tue, 16 Aug 2011 01:50:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.564
X-Spam-Level:
X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 TlIdwJv-B1Er for <rtcweb@ietfa.amsl.com>; Tue, 16 Aug 2011 01:50:50 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF1521F8B5F for <rtcweb@ietf.org>; Tue, 16 Aug 2011 01:50:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 12F2339E123; Tue, 16 Aug 2011 10:50:25 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9jecVOgGau3; Tue, 16 Aug 2011 10:50:23 +0200 (CEST)
Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id C8CBE39E087; Tue, 16 Aug 2011 10:50:23 +0200 (CEST)
Message-ID: <4E4A2F98.8030905@alvestrand.no>
Date: Tue, 16 Aug 2011 10:51:36 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11
MIME-Version: 1.0
To: Ted Hardie <ted.ietf@gmail.com>
References: <CA+9kkMBFwX9KiPDGwOZaANJuMO6J_wh06CPt+9+=y6iJL-hzXA@mail.gmail.com> <4E457915.7010809@skype.net> <CA+9kkMCP==SO8whDpfJ_BdHqvS=pg-iVXycfAqEJp+nZd=u1Pw@mail.gmail.com> <4E47B563.5000003@mozilla.com> <CA+9kkMBDsZr9DGUO-8-mdHU1DvwQbyeWdHRcbOvg7SG1mWRW=Q@mail.gmail.com>
In-Reply-To: <CA+9kkMBDsZr9DGUO-8-mdHU1DvwQbyeWdHRcbOvg7SG1mWRW=Q@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] URIs for rtcweb "calls"
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: Tue, 16 Aug 2011 08:50:51 -0000

On 08/15/11 19:54, Ted Hardie wrote:
> On Sun, Aug 14, 2011 at 4:45 AM, Timothy B. Terriberry
> <tterriberry@mozilla.com>  wrote:
>> By "full game context" do you mean it would somehow load an http webpage
>> with HTML+CSS+JS to handle the signaling? If that's the case, what
>> advantages does this offer over normal http[s] URLs (with a path to the
>> necessary page and parameters, etc. needed to carry sufficient information
>> to establish the session). That certainly seems to already cover the case
>> of, "A URI that I could use to paste into a chat window." How does it handle
>> all the things that an http[s] URL already provides (port, path, caching,
>> proxies, all the associated services built around http (e.g. bit.ly), etc.)?
>>
> As I mentioned in my response to Matthew, I'm thinking abut a range of
> potential use cases. For the gaming site example where a full web
> context is created, I agree that an HTTPS URI could do the same thing.
>   You do get some minor advantages in using a distinct URI scheme,
> primarily in early identification that the resulting context will be a
> rtcweb context.  This might allow you apply permissions early, like a
> parental permission against use of rtcweb, or to allow the device to
> start setting up elements of its local context early.  It also allows
> you to standardize how you to identify the signaling context and
> target entity, which I doubt you could do in HTTPS URIs.  The
> arguments for and against scheme proliferation have been going for
> quite a while now, of course, so I understand that many people would
> prefer that there be only HTTPS URIs here.
>
> For the case where you are setting up something closer to a
> web-chat-with-an-agent-for-the-ad-seen here, I think the amount of
> page context will be very small, and that it will be closer to the
> experience of the browser/app setting up its default widgets for this.
For the first version of the RTCWEB spec, I would like to not mandate 
that the browser *have* a default widget set.

Most browsers have an FTP agent, and most browsers know how to call out 
to an external app as their mailto: handler, but if RTCWEB support is 
built into the browser and nowhere else on the platform, external apps 
are not an option, and built-in clients will make sure we don't see 
uniform UIs across platforms.

My first target is to make sure you can build applications that work the 
same in any supporting browser. I don't see a need to have an rtcweb URI 
for that.

WRT the permissions .... any time I see a short, human readable string 
and hear the word "permission" in the same context, I go "phishing" .... 
anything not digitally signed is an attack surface ... and anything that 
includes a digital signature is not human friendly ....

                     Harald