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

Hi,

We could have an informative note somewhere.in the draft, pointing out the format used by JavaScript, if people think it would be useful.

Regards,

Christer

Sent from my Sony Ericsson Xperia arc S

Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote:

On Feb 8, 2014, at 2:14 AM, "Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com> 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.
> 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.
Anu objections?

If not, I'll put corresponding text into the spec.

Best regards
Michael
>
> 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
>