Re: [rtcweb] URIs for rtcweb "calls"

[Harald Alvestrand <[e-mail]>]

On 08/15/11 19:54, Ted Hardie wrote:
> On Sun, Aug 14, 2011 at 4:45 AM, Timothy B. Terriberry
> <[e-mail]>  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