- From: Lennart Grahl via GitHub <sysbot+gh@w3.org>
- Date: Fri, 19 Jan 2018 12:29:26 +0000
- To: public-webrtc-logs@w3.org
> The "underlying data transport" is more than just an SCTP stream pair, though; it's a stream pair plus the extra semantics defined by draft-ietf-rtcweb-data-channel. I guess it would be easier to just refer to the closing procedure: > An RTCDataChannel object's underlying data transport may be torn down in a non-abrupt manner by running the closing procedure. When that happens the user agent must, unless the procedure was initiated by the close method, queue a task that sets the object's [[ReadyState]] slot to closing and **follow the closing procedure defined for the data transport (for SCTP data channels, see [rtcweb-data-channel section 6.7](https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-6.7)). An implementation must ensure that all pending messages are being delivered (or abandoned in case of a partially reliable channel) before the channel goes into the closing state.** That would resolve this issue for me. Even though I'm not entirely happy about the *or abandoned in case of a partially reliable channel* section because that of course still means that the implementation has to try sending pending messages. > Is there any reason why we can't just refer to SCTP terminology directly though? Why do we need this hand-wavey terminology in the first place? Is it in case we end up using the RTCDataChannel interface with some other underlying protocol (which seems unlikely)? Can we just cross that bridge when we come to it? Well, this abstraction has been in the spec for a long time now. But yeah, there are a lot of sections that would need to be revised (such as `maxMessageSize`) in case another transport comes in. -- GitHub Notification of comment by lgrahl Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1699#issuecomment-358953954 using your GitHub account
Received on Friday, 19 January 2018 12:29:44 UTC