Re: [rtcweb] RTCWEB Data Channel: Usage of PPID for protocol multiplexing

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

> >>> As discussed in the last IETF meeting, this PPID based fragmentation and
> reassembly will be removed from the ID.
> >>
> >> I assume the associated PPID values will also be un-registered with IANA?
> > I guess they will stay... They are supported by Firefox and PPIDs are a
> pretty cheap resource. They are from a pool of 32-bit entities. That is why
> we registered the values before the RFCs get published.
> 
> So, does that mean my WebRTC entity has to support them, in case the remote
> peer is on Firefox?
> 
> Also, if they are removed from the data channel draft, what reference will
> be used in the IANA table?

[Raju] Per my understanding some of the PPIDs are still needed.
The send() API for data channel comes in 4 flavors:
1.    void send (DOMString data);
2.    void send (Blob data);
3.    void send (ArrayBuffer data);
4.    void send (ArrayBufferView data);

1 maps to text data
2,3,4 maps to binary data

When one end sends this data one would expect that the other end gets an onmessage() callback with same (if other end is also javascript) or similar(if other end is a native client) data structure. I believe this is achieved by using PPIDs.
We need at least 2 PPIDs: text and binary. So, existing "DOM String last" (=51) and "Binary Data Last"(=53) can be used.
To facilitate interworking with native clients I don't think there is a need to represent all sub-data types of send() in PPIDs as native client on the other end using C/C++ won't know what "ArrayBufferView" is?!
Also, I think "DOMString" PPID is too specific to Javascript, instead it should probably have a generic name like "UTF-16 String". The send API can still use DOMString as this is Javascript API.

-Raju