Re: [rtcweb] HTTP Fallback draft

Lorenzo Miniero <lorenzo@meetecho.com> Wed, 08 August 2012 10:14 UTC

Return-Path: <lorenzo@meetecho.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 DA21221F86B1 for <rtcweb@ietfa.amsl.com>; Wed, 8 Aug 2012 03:14:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.676
X-Spam-Level:
X-Spam-Status: No, score=-0.676 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]
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 b-BX27tKb+Rh for <rtcweb@ietfa.amsl.com>; Wed, 8 Aug 2012 03:14:55 -0700 (PDT)
Received: from smtplq04.aruba.it (smtplq-out6.aruba.it [62.149.158.26]) by ietfa.amsl.com (Postfix) with SMTP id 633F021F8516 for <rtcweb@ietf.org>; Wed, 8 Aug 2012 03:14:54 -0700 (PDT)
Received: (qmail 1924 invoked by uid 89); 8 Aug 2012 10:14:51 -0000
Received: from unknown (HELO smtp5.aruba.it) (62.149.158.225) by smtplq04.aruba.it with SMTP; 8 Aug 2012 10:14:51 -0000
Received: (qmail 2381 invoked by uid 89); 8 Aug 2012 10:14:51 -0000
Received: from unknown (HELO rainpc) (lorenzo@meetecho.com@80.181.173.222) by smtp5.ad.aruba.it with SMTP; 8 Aug 2012 10:14:50 -0000
Date: Wed, 8 Aug 2012 12:08:42 +0200
From: Lorenzo Miniero <lorenzo@meetecho.com>
To: Justin Uberti <juberti@google.com>
Message-ID: <20120808120842.1ad1e709@rainpc>
In-Reply-To: <CAOJ7v-3hg+kg+bXyZAS=0s68R5BFH4zJnRzHSY3Sv489-EgiPA@mail.gmail.com>
References: <20120807180156.286e74d2@rainpc> <CA+9kkMDpnH12jkZ3DQD8uT4PF0Q7TW1f9NiGO=pSP1xLfRRiRg@mail.gmail.com> <20120807205447.2212f617@rainpc> <CAOJ7v-3hg+kg+bXyZAS=0s68R5BFH4zJnRzHSY3Sv489-EgiPA@mail.gmail.com>
Organization: Meetecho
X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.8; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Spam-Rating: smtp5.ad.aruba.it 1.6.2 0/1000/N
X-Spam-Rating: smtplq04.aruba.it 1.6.2 0/1000/N
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 10:14:56 -0000

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;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