Re: [rtcweb] [BEHAVE] Fwd: New Version Notification for draft-uberti-behave-turn-rest-00.txt

Justin Uberti <juberti@google.com> Tue, 23 July 2013 20:50 UTC

Return-Path: <juberti@google.com>
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 3B16511E810C for <rtcweb@ietfa.amsl.com>; Tue, 23 Jul 2013 13:50:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 Geh9Lq5FUsXm for <rtcweb@ietfa.amsl.com>; Tue, 23 Jul 2013 13:50:30 -0700 (PDT)
Received: from mail-oa0-x233.google.com (mail-oa0-x233.google.com [IPv6:2607:f8b0:4003:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id DD8F311E8136 for <rtcweb@ietf.org>; Tue, 23 Jul 2013 13:50:27 -0700 (PDT)
Received: by mail-oa0-f51.google.com with SMTP id i4so12190531oah.24 for <rtcweb@ietf.org>; Tue, 23 Jul 2013 13:50:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=1WzahDGv5zenHpXjNXipRrGEVMAhrUSugYqiDAvm0lU=; b=HuNq4+SMxc5MuyfFOEthUtF01iBYtFe/1Wn9o/dgdEqtnHiddgytQxIyvP+REyQwhX l9WEZQcI5qsbr+fjFnKTYJNwyKr7sM+/s1bq4DISPP+UhnJjWfyrwJT9hwK6BbuCUa0F dwxu/Z3ThdRnubs5l4TGznZjc7Oq9dJUcA+BtusAlSt2yclFuLIFgbG1onY3IYLRfCS7 YmJg+vHKDgM5wYT9uIaX4Xe0sxoSuBlzlaO6JAN2qzXLUPrZAro4qFYWICOXv5C7TSsX MrZ1YUy8nwh4HCa6L7c0pnwRIkUDPcuJ2a8hmuN6BoqAuLdSxqcXYapVcGXbImNhkkEV KXWA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=1WzahDGv5zenHpXjNXipRrGEVMAhrUSugYqiDAvm0lU=; b=X7LwwNF59rUeP/4ibjGgDDg259FXnssIVBkiGvkszDf1LCJL7IUaQyaiEbq0sUwzTm acNBGe/0iACvRfMKs/Mttz7hWriJgvJXVuMUok2pd2a+FHZ15kfivSFdmJnPTG0Ggvfz LXRbB8AC+la43fMSfs0ptZsjhxp+D0DGkeyR7/5RhiqU5Pn8c8Vh22rpcNcziUUfS5Zo BegYfGZydwBKetRFn84TMo5cpa1ywMuTBQK+csNIPW914TAIO2BtwoBNhvgC2jW6ktFY X+FCM9cV0rr4pmgILQIGitX04+DZ7UoYYk2ZpPxKrD5NYjoUf3vzRuCdFY+ruQgPZ95p ta9Q==
X-Received: by 10.50.134.72 with SMTP id pi8mr63574igb.7.1374612627197; Tue, 23 Jul 2013 13:50:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.97.132 with HTTP; Tue, 23 Jul 2013 13:45:12 -0700 (PDT)
In-Reply-To: <CALDtMrLFoqE9HrDdCa6iT64EiRV-wZ+apuwAuxmV6boyQoPrzQ@mail.gmail.com>
References: <20130715214906.5314.83583.idtracker@ietfa.amsl.com> <CALe60zBA_unaQekMkKwKwKNRPbJjECAtJ9bAV=fv6V6Mdfon6Q@mail.gmail.com> <CAOJ7v-2WGi_fD9mVx+dtZBo+X4-sXxXZFek9mt2cAmrqFCyYMg@mail.gmail.com> <CAJWm+fGBDec_66WMBVhsv5TD8hVzDoOtd5CGs7xAHZqkYtDGBg@mail.gmail.com> <51E70106.8060100@goodadvice.pages.de> <CAJWm+fGUEH43bgR1j56qea3+uSVQ63myr1tZkrdYRGEmBw=zew@mail.gmail.com> <CAOJ7v-2wzEQXSMPM4bnGW5_0ciDf9VuY1nb2xp=Wbqe0Rq5yZA@mail.gmail.com> <CAJWm+fE1G2r0TcUAcZUVCP0WRSC35JFBdZ-oMqJfAykhNExqyA@mail.gmail.com> <51ED9318.6000003@nostrum.com> <51ED9A3C.4060307@goodadvice.pages.de> <CALDtMrLFoqE9HrDdCa6iT64EiRV-wZ+apuwAuxmV6boyQoPrzQ@mail.gmail.com>
From: Justin Uberti <juberti@google.com>
Date: Tue, 23 Jul 2013 16:45:12 -0400
Message-ID: <CAOJ7v-09uwKvpU8S0KRRdDn_kU6LqK45kYSAkA5ZAEBt3j9b=w@mail.gmail.com>
To: Oleg Moskalenko <mom040267@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b2e429a59343f04e233f183
X-Gm-Message-State: ALoCoQkJjDML6IpeNsh1eSjnIssoyQrdFETifyNLgZ5AkSnShRR2BOhu49/NuPaqLAtif+Xj0ATwDCA0W3MLQmDEYnz/mRn01QHGcly0YI+ICAbTTLX82FFUPRPo1UllJXa5W8DU4Zu/vylbhShheMT/Np5T0v2Ua0THaNLKqZvhylvKY0Bw6fyLfXL6CxSwScFe7AnoX7C8
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>, behave <behave@ietf.org>
Subject: Re: [rtcweb] [BEHAVE] Fwd: New Version Notification for draft-uberti-behave-turn-rest-00.txt
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: Tue, 23 Jul 2013 20:50:30 -0000

So there are two parts to the proposal - the HTTP request for the
credentials and interactions with WebRTC, and the stateless implementation
that avoids the need for communication between web and TURN servers. And it
is true that other implementations besides the suggested stateless one are
possible, e.g. OAuth2.

Would you prefer that I address the protocol and implementation parts
separately in the document, and mention that other implementations with the
same HTTP protocol are possible? RFC 5766 does something similar, where it
defines the TURN protocol, but in Section 6.2 talks about how a "stateless
stack" implementation can be used to simplify the processing on the TURN
server.


On Mon, Jul 22, 2013 at 5:37 PM, Oleg Moskalenko <mom040267@gmail.com>wrote;wrote:

> The overall proposal by Justin:
>
> http://tools.ietf.org/html/draft-uberti-rtcweb-turn-rest-00
>
> has been implemented in our rfc5766-turn-server for months, and I see
> nothing proprietary in the proposal. I liked the proposal from the
> beginning. Its been discussed and its been quite handy for the users - I
> hear stories of success from the users.  I believe that Philipp shares the
> same view.
>
> One especially good thing about the proposal is that is does not
> contradict by any means to the RFC 5766. It just specifies the way how the
> passwords are stored/generated - and the RFC 5766 does not say anything
> about that matter. It means that Justin's proposal is 100% compatible with
> RFC 5766.
>
> Thanks
> Oleg
> http://code.google.com/p/rfc5766-turn-server/
>
>
>
>
> On Mon, Jul 22, 2013 at 1:46 PM, Philipp Hancke <fippo@goodadvice.pages.de
> > wrote:
>
>> Am 22.07.2013 22:16, schrieb Adam Roach:
>>
>>> What Justin proposes gets us this inter-vendor interop cheaply and
>>> easily. What you're counterproposing forces people into a single-vendor
>>> (or, at least, partnered) solution, which kinda defeats the purpose of
>>> defining this in an SDO in the first place.
>>>
>>
>> Right. What Justin proposed was originally located at
>> https://code.google.com/p/**webrtc/issues/detail?id=1197<https://code.google.com/p/webrtc/issues/detail?id=1197>
>> I liked the plan, implemented it in restund and improved it a litle. It
>> was discussed at https://groups.google.com/**
>> forum/#!topic/discuss-webrtc/**nn8b6UboqRA/discussion<https://groups.google.com/forum/#!topic/discuss-webrtc/nn8b6UboqRA/discussion>and also implemented in rfc-5766-turn-server.
>>
>> Rough consensus and running code...
>>
>
>
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave
>
>