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

Hi,

I guess there is a good reason why the current PPID values have been registered to begin with, because normally any IANA registrations take place prior to RFC publication.

But, I have no problem with defining a new value for utf-8, and keep the current values in the registry - as long as it is clear that they are deprecated, and kept in the registry only for "historical" reasons (according to the suggestion by Harald).

Regards,

Christer

Sent from my Sony Ericsson Xperia arc S

"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.

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