Re: [rtcweb] HTTP Fallback draft

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