Subject: [rtcweb] URIs for rtcweb "calls"

From: Ted Hardie <[email-masked]>
Date: Fri, 12 Aug 2011 10:47:30 -0700

In one of the use cases we've discussed, there is an advertisement
placed on a page with something like "click here to chat with someone
now".  In some of the discussion in Quebec city, we circled around the
question of who did the job of connecting the user when there was a
click.  In a side discussion on that topic, Cullen, ekr, and I talked
about possibly making that explicit by using a uri structured along
these lines:

scheme: (e.g. rtw)
authority: the entity which will act as the signaling service for
setting up the session.
path-component-1: the entity to which you will be connected
path-component-2: a token used in the media path to assure you that
media is coming from someone with access to the uri

rtw://outsourced-video.example.com/custchat.carmaker.example;token=2342342433

I don't want to delve into the UI aspects of this too much, but the
presumption I was working under was that if someone clicked on such a
link, it would open a new context (e.g. new browser window), and start
a session. path-component one could be something meaningful only
within a specific context:

rtw://dating-site.example/prospective13344;token=444322111

Alternatively, it could be also meaningful in an external security
context, possibly because custchat.carmaker.example will appear in a
certificate in a known place during the media exchange.  It could also
be a reference to something like a presentity, where the presence
infrastructure provides an out-of-band mechanism for confirming
identity.

Do others think defining something like this would be useful?

If so, would the authority section be a host pointer or an xmpp-style service?
Does the format of path-compenent-1 need to be fixed, or can it be
service-dependent?
Would a token be a pawn-ticket style URI, or would the whole URI be
something that could be bookmarked and re-used?

regards,

Ted

---

From: Matthew Kaufman <[email-masked]>
Date: Fri, 12 Aug 2011 12:03:49 -0700

> Do others think defining something like this would be useful?

No. For the same reason I don't think that Gmail should be implemented 
by going to "imap:mail.google.com/inbox" and having the browser 
implement a mail reading user interface or it own (or even having a page 
that contains "<showIMAPinterface mailbox='inbox' 
server='mail.google.com'/>").

We should be providing components that allow for all manners for 
real-time communication applications to be built using HTML and 
JavaScript, not baking a phone into the browser.

Matthew Kaufman

---

From: Ted Hardie <[email-masked]>
Date: Fri, 12 Aug 2011 13:17:16 -0700

On Fri, Aug 12, 2011 at 12:03 PM, Matthew Kaufman
<[email-masked]> wrote:
> No. For the same reason I don't think that Gmail should be implemented by
> going to "imap:mail.google.com/inbox" and having the browser implement a
> mail reading user interface or it own (or even having a page that contains
> "<showIMAPinterface mailbox='inbox' server='mail.google.com'/>").
>

So, one of the aims here was to allow you to specify what the
signaling path was separate from whom you were calling.  In the case
where they were similar, you'd basically end up with:

rtw:///player23424232;token=234234234

(That is the authority/signaling path would be the same as the current origin).

I'm also not sure that having the ability to create a compact
representation of this equals baking a phone into the browser.  To
take a slightly different example, imagine that I'm using a gaming
site and I want to invite friends to come play the game with me.  A
URI that I could use to paste into a chat window or send in email
would be handy, as a simple way to give an out-of-band pointer to a
rtc-web context.  That would still fire up the full game context,
slotting the user into the game (rather than making a phone call).

Hope that explains the range of things I'd like to cover better.

regards,

Ted

> We should be providing components that allow for all manners for real-time
> communication applications to be built using HTML and JavaScript, not baking
> a phone into the browser.
>
> Matthew Kaufman
>

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Sun, 14 Aug 2011 04:45:39 -0700

> slotting the user into the game (rather than making a phone call).

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.)?

If that's not the case, what do you mean by "context"?

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Sun, 14 Aug 2011 04:46:29 -0700

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 15 Aug 2011 08:51:26 +0200

Two points on this:

1) An URI that is human-visible (for example in hover-over) creates the 
expectation that you can take this URI, plug it into another Web 
browser, and achieve a sensible result.

For many reasons, some of them involving branding of experience, which 
usually requires a ton of Javascript and CSS, I think the more likely 
URL is 
https://joes-outsourced-video.example.com/customerchat.html?callto=custchat.carmaker.example&token=234234234, 
which would pop up the UI that users of joes-outsourced-video has been 
led to expect. It would not contain any way of figuring out who you're 
calling, or rather the scheme would vary between providers - you have to 
trust in-call mechanisms (and Joe) for that.

2) An URI that is not human-visible (the blob: URI of the filesystem API 
spec comes to mind) may be an useful shorthand for a set of call 
parameters passed across internal APIs; I set out to create such a thing 
in draft-alvestrand-rtcweb-datagrams, but at the moment this seems to 
have been overtaken by events, and the smallest objects we're talking 
about for specifying such parameter sets is a SDP blob, which is a 
*little* big for fitting into the URI straitjacket.

My $0.02.

                         Harald

On 08/12/2011 07:47 PM, Ted Hardie wrote:
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Ted Hardie <[email-masked]>
Date: Mon, 15 Aug 2011 10:54:22 -0700

On Sun, Aug 14, 2011 at 4:45 AM, Timothy B. Terriberry
<[email-masked]> wrote:
> 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.

Just my personal opinion,

Ted

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Mon, 15 Aug 2011 11:33:57 -0700

> experience of the browser/app setting up its default widgets for this.

I think over time there will be a desire to include more and more page 
context in such things. But that aside, it becomes a lot less clear to 
me what kind of default widgets would be. For the simple case of 1 audio 
+ 1 video stream, things are reasonably straightforward, but once you 
start talking about local preview, multiple video streams, layout and 
audio panning for conferencing, negotiating new streams in the middle of 
a call, and all the other things which people have been considering in 
the use cases here, there's a fair bit of complexity that a "default" 
widget set has to handle, compared to, say, creating a default <video> 
tag to wrap an URL that points directly at a WebM file. Web site authors 
are likely to have a much easier time handling this complexity, as they 
understand the context of what they're providing and can make 
simplifying assumptions, and present things in a coherent way (tying 
identity to video windows, etc.), but a generic widget set doesn't have 
that luxury, unless we explicitly limit the scope of what it is required 
to support.

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 16 Aug 2011 10:51:36 +0200

> 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