Re: [BEHAVE] [rtcweb] Why? Quality! New Version Notification for draft-chenxin-behave-turn-websocket-00.txt

["Chenxin (Xin)" <[e-mail]>]

   I agree that we should not try to battle with network administrator, and we are not doing that. We just supply some technical tools to rtcweb implementer, to make the users could get benefit and convenience when using rtcweb. Fallback methods and proposals are for this purpose.  We could not decide that how will a kind of technique be used. Every technique could be used in a good way and a bad way.  I believe that rtcweb is a good and trustworthy technique which is different with the some harmful things which should be blocked by the administers. So let us back to the technical aspect: should we need to support a fallback method in rtcweb now? Which one should we support to MTI? Which one should we support to be a option? I think now there is three method to solve the fallback requirement：TURN/TLS, HTTP channel , TURN/WS or HTTP. I am willing to write a mail these days to make a simple conclusion and comparison between these methods, which will provide a material to WG for future discussion and decision.

Best Regards,
     Xin 


>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On Behalf Of
>Simon Perreault
>Sent: Wednesday, May 22, 2013 5:31 PM
>To: Karl Stahl
>Cc: [e-mail]; [e-mail]
>Subject: Re: [rtcweb] [BEHAVE] Why? Quality! New Version Notification for
>draft-chenxin-behave-turn-websocket-00.txt
>
>Le 2013-05-22 11:04, Karl Stahl a écrit :
>>> Firewall traversal is a completely different beast.
>>
>> Not really. There are always firewall functions included in "a NAT" (e.g.
>> open for traffic from inside to outside and you can then get traffic back
>> the same path - with some timeout), even if the RFCs only call the box "a
>> NAT". I prefer to say NAT/Firewall.
>
>You're focusing on the technical aspect. The difference I'm considering
>is not technical.
>
>NAT traversal is performed with the agreement of everyone involved,
>whereas firewall traversal is a battle between the client implementer
>and the firewall administrator. There's also a potential arms race:
>firewalls will evolve with the ability to block whatever we standardize,
>so we will need a newer traversal method, which firewalls will end up
>blocking as well, etc. etc. etc. We don't want to play that game.
>
>NAT traversal: ok
>Firewall traversal: not for the IETF
>
>Simon
>_______________________________________________
>rtcweb mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/rtcweb