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

[Michael Tuexen <[e-mail]>]

On Feb 6, 2014, at 12:45 PM, "Makaraju, Maridi Raju (Raju)" <[e-mail]> wrote:

>>>>> 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
What is still be needed:
WebRTC Control: Used for the DATA_CHANNEL_OPEN and DATA_CHANNEL_ACK message
DOMString Last: Used for 1.
Binary Data Last: Used for 2, 3, 4.

The PPIDs 'Binary Data Partial' and 'DOMString Partial' won't be used anymore.
These were specific to the PPID based fragmentation and reassembly.
> 
> 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?!
At least there are no PPIDs for them right now.
> 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.
Any comments from others?

Best regards
Michael
> 
> -Raju
>