Re: [rtcweb] Sending of zero-length messages over data channels

["Makaraju, Maridi Raju (Raju)" <[e-mail]>]

>IMHO opinion, sending such a dummy byte may have other consequences:

1.      >App is not aware of what's going on? send() probably meant to be called >with non-empty data, but some error leg could have caused it become >empty, but still a byte will be sent out!!

2.      >Debugging becomes bit more complex and not intuitive. WebRTC is >already complex, why add more complexity?

3.      >Interop issues. The more the exceptions the more the interop issues you >see as some implementations may overlook these or implement them >later.

>It's usually a bad idea to send a dummy byte on wire, without the application >direct involvement.

>I recommend spending some time with Wireshark looking at actual traces >before making any such statement. Many protocols have dummy bytes, for >many different reasons.

<Raju2>
I am afraid there is some confusion about my comment and as a result we may be talking about dummy bytes at 2 different levels: app level and underlying protocol level.
I am aware of many protocols using reserved bits, bytes, padded bits/bytes, protocol-level heartbeats/PING-PONGs (SCTP heartbeats use of opaque data). In all these cases the mechanism is built into the protocol below app-level protocol itself with no direct involvement of application-level protocol. My comment was in the context of application-level protocol.
If app calls send() 3 times with data "abc", "" (empty/null data with size 0) and then "xyz" then on the wire in the application-level payload you see "abc" <dummy byte> "xyz".
So, can you please point to me a protocol where this kind of dummy byte(s) are inserted in between application payload?

Btw, If you leave the app choice to send the byte (using OOB_PPID) then there is a possibility for the app to send 256 distinct values instead of browser hard-coding the byte to zero always, which just conveys a single value.

</Raju2>


>PPID_OOB would make the compatibility problem worse, not better.
<Raju2>
I would appreciate if you can provide reasons on why PPID_OOB making compatibility worse?
With PPID_OOB, apps have a choice to negotiate (this negotiation is like any other negotiation for webrtc.) and use this option. PPID_EMPTY option seems to be enabled always and no way to turn-off.
Without an option to turn off PPID_EMPTY, you will get into more compatibility issues as some webrtc implementations may not implement it on day one; a native client could be using an interim version of a popular webrtc lib; or it might be using its own webrtc lib, in which case we can't expect it to implement all these later-adders in a timely manner.

</Raju2>

BR
Raju