Re: [rtcweb] URIs for rtcweb "calls"

[Harald Alvestrand <[e-mail]>]

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:
> 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
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>