Re: [rtcweb] URIs for rtcweb "calls"

Harald Alvestrand <harald@alvestrand.no> Mon, 15 August 2011 06: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 36E7221F8745 for <rtcweb@ietfa.amsl.com>; Sun, 14 Aug 2011 23:50:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.227
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cDipKa7s704g for <rtcweb@ietfa.amsl.com>; Sun, 14 Aug 2011 23:50:43 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 46AD821F87FA for <rtcweb@ietf.org>; Sun, 14 Aug 2011 23:50:43 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 668E339E162; Mon, 15 Aug 2011 08:50:15 +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 5+z1eKKI84x4; Mon, 15 Aug 2011 08:50:14 +0200 (CEST)
Received: from [192.168.0.14] (c213-89-141-213.bredband.comhem.se [213.89.141.213]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 5A9A739E074; Mon, 15 Aug 2011 08:50:14 +0200 (CEST)
Message-ID: <4E48C1EE.9050302@alvestrand.no>
Date: Mon, 15 Aug 2011 08:51:26 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; 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>
In-Reply-To: <CA+9kkMBFwX9KiPDGwOZaANJuMO6J_wh06CPt+9+=y6iJL-hzXA@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: 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 
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
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>