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

On 02/08/2014 02:14 AM, Makaraju, Maridi Raju (Raju) wrote:
> That's good. Glad to see that no one liked the complex alternate option... yet! :-)
> I just put it there for completeness and some discussion.
> With "utf-8 on wire", which I too think is the right approach, there is some spec work todo:
> 1. Define IANA utf-8 ppid. Creating a new one is better instead of replacing existing DOMString as DOMString may be used by browsers for sometime to come and also to have backward compatibility/interworking.

Have you ever seen UTF-16 on the wire in the DataChannel protocol?

> 2. Data channel core spec (http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-06#section-6.6) need to specify explictly the wire format is utf-8.

Fully agreed.

>
> Then browsers need to do the conversion from utf-16 DOMstring to utf-8 before writing on wire also in the reverse direction. 
>
> -Raju
>
>> -----Original Message-----
>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
>> Sent: Friday, February 07, 2014 6:01 PM
>> To: Martin Thomson; Makaraju, Maridi Raju (Raju)
>> Cc: rtcweb@ietf.org
>> Subject: RE: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCWEB Data Channel:
>> Usage of PPID for protocol multiplexing)
>>
>>
>> + 1
>>
>> Regards,
>>
>> Christer
>>
>> ________________________________________
>> From: rtcweb [rtcweb-bounces@ietf.org] on behalf of Martin Thomson
>> [martin.thomson@gmail.com]
>> Sent: Saturday, 08 February 2014 1:45 AM
>> To: Makaraju, Maridi Raju (Raju)
>> Cc: rtcweb@ietf.org
>> Subject: 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
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

-- 
Surveillance is pervasive. Go Dark.