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

[Michael Tuexen <[e-mail]>]

On Feb 8, 2014, at 10:26 AM, Christer Holmberg <[e-mail]> wrote:

> 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.
Hmm. I don't want to repeat what is in
http://heycam.github.io/webidl/#idl-DOMString
I like the idea to specify UTF-8 using a new PPID and deprecate the usage of
the current PPID for DOMString.

Best regards
Michael
> 
> Regards,
> 
> Christer
> 
> 
> Sent from my Sony Ericsson Xperia arc S
> 
> Michael Tuexen <[e-mail]> wrote:
> 
> 
> On Feb 8, 2014, at 2:14 AM, "Makaraju, Maridi Raju (Raju)" <[e-mail]> 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:[e-mail]]
>>> Sent: Friday, February 07, 2014 6:01 PM
>>> To: Martin Thomson; Makaraju, Maridi Raju (Raju)
>>> Cc: [e-mail]
>>> Subject: RE: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCWEB Data Channel:
>>> Usage of PPID for protocol multiplexing)
>>> 
>>> 
>>> + 1
>>> 
>>> Regards,
>>> 
>>> Christer
>>> 
>>> ________________________________________
>>> From: rtcweb [[e-mail]] on behalf of Martin Thomson
>>> [[e-mail]]
>>> Sent: Saturday, 08 February 2014 1:45 AM
>>> To: Makaraju, Maridi Raju (Raju)
>>> Cc: [e-mail]
>>> 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)
>>> <[e-mail]> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>> _______________________________________________
>>> rtcweb mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>> 
> 
>