Re: [rtcweb] HTTP Fallback draft
Justin Uberti <juberti@google.com> Wed, 08 August 2012 19:02 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 C597721F854F for <rtcweb@ietfa.amsl.com>; Wed, 8 Aug 2012 12:02:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.756
X-Spam-Level:
X-Spam-Status: No, score=-102.756 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 mAdknJZwh-2m for <rtcweb@ietfa.amsl.com>; Wed, 8 Aug 2012 12:02:37 -0700 (PDT)
Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5796321F8484 for <rtcweb@ietf.org>; Wed, 8 Aug 2012 12:02:37 -0700 (PDT)
Received: by qaea16 with SMTP id a16so810127qae.10 for <rtcweb@ietf.org>; Wed, 08 Aug 2012 12:02:36 -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:x-system-of-record; bh=aWeMPm8z70nk9THBkW/CojrZwEQHsLsE2T7soaLLvlc=; b=mCpFtkpU2okWVIvzrD/6x14bTWg0zvbwuEMmhVof4azczg1f3oaqVKQZuk7VWYvyCJ sfIAEGAptWQPKWRwx4reB3SuSda5L4EU5sgaMdiW5J3VWyN1f6uxMUOUrWkaoyiyC93u LQTm4zI6JImAyGAc53lRlI+OnSGAYVzAPRCkheplnTz/P2+2IqBQLnr1ON5hSEJ53wC2 9FPTok0XyNjeS83eR4EVSYtggdIwDJnVqIizEjLKpoI6z3ui/DlW0t+iA86hImdxQ15V hm6e7RZ9OH9cWHf7U1qFWOJvqB16zxIeGKS/AmYzU4frJ/j2j5dVdMRTOcrU9rFsMRIz +Duw==
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-system-of-record:x-gm-message-state; bh=aWeMPm8z70nk9THBkW/CojrZwEQHsLsE2T7soaLLvlc=; b=p0slPPjIxHqeAtwEnlFN6RqOcl0EXiCEsUq26x6/kVMqyyIofvj266jhG0J1/VaK8C gXbxYo1mOgpESrUJSeNF0RaYZu9A/EwZYtSGzAcPRk7/SAQwuxL78ibFeRMYZAdzdiGl vjNx+Jjwf5h4sE3QyU3rAvFa7aGx1Uoe+zd6qb86PmDtipp3GlknxBijqH8AsAW9umm7 AMbifjUaJT/6xqIOfeuqf/T9Y8tbGxIetGKoxBrHS9FqxEg6Ma/2UGCDoh6p5WAszsbL Z1IfWm+9PwZZ+dG/uuFsCjo8XScQ5Krses+RWhoV70uUpPuZkznqte85sbi5df/ULN2x GMCA==
Received: by 10.224.106.138 with SMTP id x10mr32174554qao.1.1344452556534; Wed, 08 Aug 2012 12:02:36 -0700 (PDT)
Received: by 10.224.106.138 with SMTP id x10mr32174520qao.1.1344452556264; Wed, 08 Aug 2012 12:02:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.218.80 with HTTP; Wed, 8 Aug 2012 12:02:15 -0700 (PDT)
In-Reply-To: <20120808120842.1ad1e709@rainpc>
References: <20120807180156.286e74d2@rainpc> <CA+9kkMDpnH12jkZ3DQD8uT4PF0Q7TW1f9NiGO=pSP1xLfRRiRg@mail.gmail.com> <20120807205447.2212f617@rainpc> <CAOJ7v-3hg+kg+bXyZAS=0s68R5BFH4zJnRzHSY3Sv489-EgiPA@mail.gmail.com> <20120808120842.1ad1e709@rainpc>
From: Justin Uberti <juberti@google.com>
Date: Wed, 08 Aug 2012 12:02:15 -0700
Message-ID: <CAOJ7v-2EaNixPKLJqKjNUtaa6shZ0UYoNXN5wr1x7j-xuWAxHg@mail.gmail.com>
To: Lorenzo Miniero <lorenzo@meetecho.com>
Content-Type: multipart/alternative; boundary="20cf3074b2d20894ee04c6c5c1da"
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQmVnl4QFjJ/UNQcqcXTISb9FsHvq75aLsQ+d92mOWqCTeESG3VE34DmmnVWxH3j4h7ZEIr66fSFf+LI5zpO3C5O+7jyysfmaESdPQbq/wNGKeGmm1knLvCCZWSxuqAQVyCh3dy68ZfkEeZBCNdN1PocL4cc8nHte2/r8hftG2YMEa/OO9QfPn9E7NjG5VQa4QBDbeLY
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] HTTP Fallback draft
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: Wed, 08 Aug 2012 19:02:38 -0000
That makes sense to me. The overall point I was driving at was that we wouldn't have to invent new protocols, we could just propose the sequence/logic that you describe, perhaps accompanied by real-world data that explains the approach. On Wed, Aug 8, 2012 at 3:08 AM, Lorenzo Miniero <lorenzo@meetecho.com>wrote: > Hi Justin, > > > On Tue, 7 Aug 2012 20:23:15 -0700 > Justin Uberti <juberti@google.com> wrote: > > > My perspective is that we can make a huge impact simply by codifying the > > rules for doing basic things like TURN over 443 (with or without TLS), > HTTP > > CONNECT, etc. Running RTP over HTTP could help us get closer to 100% > > coverage, but I think we start to enter the area of diminishing returns. > > > > As such, I'd like to see us work towards a best practices document for > > establishing sessions in these restricted environments; I think such a > > document would be in scope for RTCWEB. > > > > > You're right, according to the feedback gathered on the draft so far this > looks like a reasonable way to move on. I'm not sure a pure BCP would be > enough, though, considering that too many documented different approaches, > no matter how effective each, could eventually lead to a few > interoperability issues (some browsers/relays may end up implementing some > and not others). Maybe something in line with a BCP that at least mandates > a certain sequence of or logic in attempts? > > Lorenzo > > > > > > On Tue, Aug 7, 2012 at 11:54 AM, Lorenzo Miniero <lorenzo@meetecho.com > >wrote: > > > > > Hello Ted, > > > > > > > > > On Tue, 7 Aug 2012 10:50:07 -0700 > > > Ted Hardie <ted.ietf@gmail.com> wrote: > > > > > > > On Tue, Aug 7, 2012 at 9:01 AM, Lorenzo Miniero < > lorenzo@meetecho.com> > > > wrote: > > > > > That said, I guess there's a different question I should be asking > to > > > > > the chairs: since there seems to be no related item in the > milestones, > > > > > is such a work actually in line with what is the expected outcome > of > > > the > > > > > WG? Considering the draft basically addresses a new transport for > RTP > > > > > and something that probably needs to be negotiated as well, I guess > > > this > > > > > could be seen as belonging elsewhere (AVTCORE and/or MMUSIC?). > > > > > Nevertheless, my feeling is it belongs more here than somewhere > else, > > > > > especially considering we're specifying a solution that will be > > > deployed > > > > > in browsers and, as such, people will expect it to work wherever > other > > > > > web applications do. > > > > > > > > My take on this is that the actual work on developing the alternate > > > > transport for RTP would have to occur elsewhere and, frankly, I think > > > > it is a large enough task that it would likely require its own > working > > > > group (much as the RTP congestion control topic ended up as a BoF and > > > > hopefully will become its own working group). That doesn't mean that > > > > the work couldn't be informed by the RTCWEB use cases, but I think it > > > > would have to be done elsewhere. > > > > > > > > I'd personally suggest starting with a discussion with the ADs on > > > > whether a BoF on this topic would be something they might consider. > > > > (Note, however, that I have not talked to Cullen about this and > Magnus > > > > is on vacation, so this is not a "Chairs' response"; just my own > > > > thoughts). > > > > > > > > > > > > > This makes sense. I'm a bit concerned about the additional time that > may > > > be needed by going through the process of forming a new WG (compared to > > > just adding a milestone to an existing WG, that is), as the final > result > > > may end up being available much after the original WG completed its > works, > > > but I see your point. > > > > > > I'll wait for more feedback about this and, if enough people seem > > > interested about doing something like this, contacting the ADs and > consider > > > the next steps may be a good idea. > > > > > > Lorenzo > > > > > > > > > > regards, > > > > > > > > Ted Hardie > > > > > > > > > -- > > > Lorenzo Miniero, COB > > > > > > Meetecho s.r.l. > > > Web Conferencing and Collaboration Tools > > > http://www.meetecho.com > > > _______________________________________________ > > > rtcweb mailing list > > > rtcweb@ietf.org > > > https://www.ietf.org/mailman/listinfo/rtcweb > > > > > > -- > Lorenzo Miniero, COB > > Meetecho s.r.l. > Web Conferencing and Collaboration Tools > http://www.meetecho.com >
- [rtcweb] HTTP Fallback draft Lorenzo Miniero
- Re: [rtcweb] HTTP Fallback draft Hannes Tschofenig
- Re: [rtcweb] HTTP Fallback draft Lorenzo Miniero
- Re: [rtcweb] HTTP Fallback draft Ted Hardie
- Re: [rtcweb] HTTP Fallback draft Lorenzo Miniero
- Re: [rtcweb] HTTP Fallback draft Iñaki Baz Castillo
- Re: [rtcweb] HTTP Fallback draft Lorenzo Miniero
- Re: [rtcweb] HTTP Fallback draft Tirumaleswar Reddy (tireddy)
- Re: [rtcweb] HTTP Fallback draft Marc Petit-Huguenin
- Re: [rtcweb] HTTP Fallback draft Bernard Aboba
- Re: [rtcweb] HTTP Fallback draft Justin Uberti
- Re: [rtcweb] HTTP Fallback draft Tirumaleswar Reddy (tireddy)
- Re: [rtcweb] HTTP Fallback draft Lorenzo Miniero
- Re: [rtcweb] HTTP Fallback draft Lorenzo Miniero
- Re: [rtcweb] HTTP Fallback draft Cameron Byrne
- Re: [rtcweb] HTTP Fallback draft Iñaki Baz Castillo
- Re: [rtcweb] HTTP Fallback draft Tirumaleswar Reddy (tireddy)
- [rtcweb] Appropriateness of bypass mechanisms (Re… Harald Alvestrand
- Re: [rtcweb] HTTP Fallback draft Justin Uberti
- Re: [rtcweb] Appropriateness of bypass mechanisms… Cullen Jennings (fluffy)