Re: [rtcweb] #13: Transport of DATA_CHANNEL_OPEN

I agree.  Here's another way to look at it:  if you were in charge of security, would you allow installation of a browser that would quietly accept large amounts of data without notifying anyone/anything?

- Jim

-----Original Message-----
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald Alvestrand
Sent: Wednesday, April 17, 2013 5:58 PM
To: rtcweb@ietf.org
Subject: Re: [rtcweb] #13: Transport of DATA_CHANNEL_OPEN

I think I (on behalf of applications I'll be writing) am in the camp of "If I asked to be told what the incoming data channel was (by not registering to handle data without an OPEN), and didn't get told what it was, I don't want the data".

Perhaps provide a few buffers to handle packet reordering.
But beyond that: Throw the data away.

On 04/17/2013 08:46 PM, Martin Thomson wrote:
> On 17 April 2013 08:34, Peter Thatcher <pthatcher@google.com> wrote:
>> What does the browser do when it receives data before an OPEN message 
>> for a SID that is not currently configured to receive data (ie JS has 
>> not called create channel for that SID and we've not received an OPEN 
>> for that SID)?
> This is the key.  Doubly so in light of:
>
>> A reminder:  If the JS specifically sets the SID when creating a data 
>> channel, then it can receive data without getting an OPEN message.
> The only reasonable thing to do is to buffer data with an upper bound 
> on time, size and number of messages.  When any of those limits are 
> hit, then you need to do something.
>
>> I think at that point, we either have to drop data or fire an event 
>> up to JS letting it know.  I would suggest that after some buffer 
>> limit N, the browser may fire .ondatachannel even if an OPEN message 
>> is not received, and then deliver buffered data through the channel 
>> given in that event.  The only alternative seems to be to just drop the data without telling the JS.
>> Are there are any other alternatives I haven't thought of?
> I see the same two options: create a data channel with some default or 
> inferred properties and fire events for the arrived messages, or 
> complain loudly and chuck the messages away.
>
> I like the former, but we've violated expectations about consistency 
> of channel properties.  And this time its our (as a browser, that is) 
> fault, we were asked to do something and we failed to do it.  Packet 
> loss happens and we didn't allow for it.
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb