Re: [rtcweb] URIs for rtcweb "calls"

Harald Alvestrand <> Mon, 15 August 2011 06:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 36E7221F8745 for <>; Sun, 14 Aug 2011 23:50:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.227
X-Spam-Status: No, score=-102.227 tagged_above=-999 required=5 tests=[AWL=0.373, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cDipKa7s704g for <>; Sun, 14 Aug 2011 23:50:43 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 46AD821F87FA for <>; Sun, 14 Aug 2011 23:50:43 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 668E339E162; Mon, 15 Aug 2011 08:50:15 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5+z1eKKI84x4; Mon, 15 Aug 2011 08:50:14 +0200 (CEST)
Received: from [] ( []) by (Postfix) with ESMTPS id 5A9A739E074; Mon, 15 Aug 2011 08:50:14 +0200 (CEST)
Message-ID: <>
Date: Mon, 15 Aug 2011 08:51:26 +0200
From: Harald Alvestrand <>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20110617 Thunderbird/3.1.11
MIME-Version: 1.0
To: Ted Hardie <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] URIs for rtcweb "calls"
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 15 Aug 2011 06:50:44 -0000

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, 
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.


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://;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