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 >
- Re: [rtcweb] URIs for rtcweb "calls" Timothy B. Terriberry
- [rtcweb] URIs for rtcweb "calls" Ted Hardie
- Re: [rtcweb] URIs for rtcweb "calls" Matthew Kaufman
- Re: [rtcweb] URIs for rtcweb "calls" Ted Hardie
- Re: [rtcweb] URIs for rtcweb "calls" Timothy B. Terriberry
- Re: [rtcweb] URIs for rtcweb "calls" Harald Alvestrand
- Re: [rtcweb] URIs for rtcweb "calls" Ted Hardie
- Re: [rtcweb] URIs for rtcweb "calls" Timothy B. Terriberry
- Re: [rtcweb] URIs for rtcweb "calls" Harald Alvestrand