Re: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCWEB Data Channel: Usage of PPID for protocol multiplexing)

I don't think that we need any complication here.  It's a string.

Strings are UTF-8 on the wire.

Strings are UTF-16 (mostly) in JavaScript.

Anything else would generate pain.

On 7 February 2014 14:01, Makaraju, Maridi Raju (Raju)
<Raju.Makaraju@alcatel-lucent.com> wrote:
>> >> 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?
>>
>> Note: The WebSockets protocol defines the transferred strings as UTF-8.
>> http://tools.ietf.org/html/rfc6455#section-5.6
>>
>> As far as I can tell, we've always intended to follow that example.
>>
>> The fact that Javascript implementations currently choose to represent
>> text strings as UTF-16 at their API is sad, but not an argument for
>> sending that particular text representation over the wire, or reflecting
>> the name in the API.
>
> [Raju] I agree that using UTF-8 is desired and more appropriate! Then, should the PPID be changed from "DOMString" to "UTF-8"? Javascript based apps have to use some library to do the conversion of DOMString/UTF-16 to UTF-8. Alternatively, browsers can do this conversion under the APIs (send and onmessage) before sending and after receiving UTF-8 PPID data.
> Without such conversion webrtc interworking between browsers and native clients will be problematic (basically, will not work).
>
> Another option, which is more flexible, is to define PPIDs for different encodings like "UTF-8", "UTF-16" (or even "base64" for binary to text instead of using "binary" directly); then pass this encoding information to send() and onmessage() calls, which will use these PPIDs. Passing encoding information might be implicit (like Javavscript DOMString) in most languages by the type of the argument to send. This way it is upto the application to deal with the encoding conversions as it see fits.
>
> The latter approach is best suitable for interworking between clients of similar type (web or native); but it is bit painful (to do conversions) for clients of different types.
>
> I am wondering what kind of API calls native WebRTC API stacks (e.g. Google Chrome's http://www.webrtc.org/webrtc-native-code-package) provide for data channel send/onmessage ()? UTF-16 strings? Or UTF-8?
>
> -Raju
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb