Re: WebRTC Service: On temporary call URLs

2014-02-24 Thread Alexis Métaireau
Le 20/02/2014 18:15, Adam Roach a écrit : The version allows us to transition between schemes in the future, if we need to change the properties of the URL -- it allows us to unambiguously change the format of the {token} [2]. For example, if we decide to re-key the HMAC, we can increase the

Re: WebRTC Service: On temporary call URLs

2014-02-24 Thread Adam Roach
On 2/24/14 05:07, Alexis Métaireau wrote: That's interesting, because I had something in mind that I haven't made explicit: because the token server returns nodes to use for the users, I was planning on using this in order to avoid charging the load balancers. e.g. something like this (Bob

Re: WebRTC Service: On temporary call URLs

2014-02-21 Thread Romain Testard
Guys, I want to clearly understand, will this prevent URL customisation (mz.la/romain) as well as easy to remember generated URLs (mz.la/two_driving_dolphins) ? I'm not sure we want to do these things but I want to understand the implications of that decision. Romain On 2/20/2014 8:31 PM,

Re: WebRTC Service: On temporary call URLs

2014-02-21 Thread Martin Thomson
On 2014-02-21, at 09:58, Romain Testard rtest...@mozilla.com wrote: Guys, I want to clearly understand, will this prevent URL customisation (mz.la/romain) as well as easy to remember generated URLs (mz.la/two_driving_dolphins) ? I'm not sure we want to do these things but I want to

Re: WebRTC Service: On temporary call URLs

2014-02-21 Thread Adam Roach
On 2/21/14 11:58, Romain Testard wrote: Guys, I want to clearly understand, will this prevent URL customisation (mz.la/romain) as well as easy to remember generated URLs (mz.la/two_driving_dolphins) ? I'm not sure we want to do these things but I want to understand the implications of that

Re: WebRTC Service: On temporary call URLs

2014-02-20 Thread Alexis Métaireau
Adam, thanks for starting this discussion, Le 20/02/2014 04:52, Adam Roach a écrit : Putting this together, what we want is something that semantically evaluates to: http://authority/action/url-format-version/{serial #,caller,callee,expiration,hmac} As Martin points out, URLs should not

Re: WebRTC Service: On temporary call URLs

2014-02-20 Thread Adam Roach
On 2/20/14 04:54, Alexis Métaireau wrote: Adam, thanks for starting this discussion, Le 20/02/2014 04:52, Adam Roach a écrit : Putting this together, what we want is something that semantically evaluates to: http://authority/action/url-format-version/{serial #,caller,callee,expiration,hmac}

WebRTC Service: On temporary call URLs

2014-02-19 Thread Adam Roach
[For the tl;dr, skip down the the line starting Putting this all together.] I realize that, while I've had a few discussions with people about the nature of the temporary calling URLs, I haven't really communicated some of the requirements we have around them, and how we can meet those

Re: WebRTC Service: On temporary call URLs

2014-02-19 Thread Martin Thomson
if you are at all interested. I built two of those in the past year, it's a fairly straightforward pattern.) - Original Message - From: Adam Roach a...@mozilla.com To: dev-media@lists.mozilla.org Sent: Wednesday, February 19, 2014 7:52:53 PM Subject: WebRTC Service: On temporary call URLs

Re: WebRTC Service: On temporary call URLs

2014-02-19 Thread Byron Campen
Ultimately, we're going to need to hand out a URL that causes a call to happen. To make sure you are understood, are you proposing making it more nouny by doing something like passing out /contact/... URLs that lead to a page with enough smarts to create a call (using the same token) with a

Re: WebRTC Service: On temporary call URLs

2014-02-19 Thread Adam Roach
On 2/19/14 22:32, Martin Thomson wrote: I think that you need to consider confidentiality here as well. It might be desirable to have the addressing information concealed. That implies a mechanism like: http://tools.ietf.org/html/draft-rescorla-stateless-tokens You'll note that I employ