Re: [rtcweb] #13: Transport of DATA_CHANNEL_OPEN

On Apr 20, 2013, at 2:32 AM, Bernard Aboba wrote:

> Peter Thatcher said: 
> 
> I like all the discussion, but I feel like we need to get back to the question and what options we have.  The question: "what does the browser do with unexpected data (before an open of an unregistered sid)?"
> 
> 1. Buffer forever without limits:  Randell thinks it's OK to buffer forever without limits.  Martin disagrees.  I disagree (I agree with Martin).
> 
> [BA] This seems like a bad idea.  If the receiver is expecting an OPEN then it shouldn't allow an unlimited amount of (ordered!) data to be received before getting one.  If the receiver buffers a large amount of data and passes it 
If the peer is sending ordered data and the first received message is not an OPEN, this is a violation
of the spec and I would terminate the SCTP association.
> to the  JS even if the application indicated that an OPEN was required, this might encourage implementations to bypass the OPEN, since receivers are so tolerant about not getting it even if the application has indicated it is required.  
>  
> 2. Buffer with limits, and then:
>   a.  Hand an error to JS saying "got some data for a data channel, but an OPEN never came" WITHOUT providing the data to JS: Harald likes this.  I'm OK with this.
> 
> [BA] One desirable aspect of this is that it (combined with a stream reset) limits the potential for attacks or implementation problems to affect applications. 
> 
>   b.  Hand an error to JS saying "got some data for a data channel, but an OPEN never came" WITH providing the data: I like this better, since I don't see a reason not to give JS the data.  
> 
> [BA]  For the reasons described above, I think we could end up regretting this option. 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb