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

Hi Christer, et. al.,
I completely agree and that's the intention of having just two PPIDs, one for text and one for binary. However, it would be good to have the clarifications that I mentioned in my earlier reply.
I have a general comment on some of the non-browser/javascript webrtc specs assuming, unnecessarily, browser+javascript as the client, which leads to some confusion like utf-8 vs DOMString confusion. It would be nice if these specs make it generic to apply all webrtc clients: either browser, native or hybrid. In future I will point these places as I review the relevant specs. But it would be great if authors keep this mind.

Regards
-Raju

----- Reply message -----
From: "Christer Holmberg" <christer.holmberg@ericsson.com>
Date: Sat, Feb 8, 2014 10:00 am
Subject: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCWEB Data Channel: Usage of PPID for protocol multiplexing)
To: "Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com>, "Michael Tuexen" <Michael.Tuexen@lurchi.franken.de>
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>

Hi,

Without commenting on specifics: we shall NOT have a mechanism where one side needs to know whether the remote peer is a browswer or not. The data channel mechanism itself shall be generic.

Regards,

Christer

________________________________________
From: Makaraju, Maridi Raju (Raju) [Raju.Makaraju@alcatel-lucent.com]
Sent: Saturday, 08 February 2014 3:45 PM
To: Christer Holmberg; Michael Tuexen
Cc: Martin Thomson; rtcweb@ietf.org
Subject: RE: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCWEB Data Channel: Usage of PPID for protocol multiplexing)

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

[Raju] The format used by Javascript is already documented in http://dev.w3.org/2011/webrtc/editor/webrtc.html#idl-def-RTCSessionDescription
via various API calls:
    void send (DOMString data);
    void send (Blob data);
    void send (ArrayBuffer data);
    void send (ArrayBufferView data);

As long as browser+javascript is used by both webrtc clients the receiving gets these formats in onmessage () callback (NOTE: please see exceptions below).
So, what goes/comes on wire is controlled by browser to give the application suitable format.
If one side is a non-browser/javascript webrtc client then the wire format really matters, for which the Data Channel Core spec will have a note (per discussion and agreement).

The spec is already assuming, though not explictly, onwire UTF-8 format while doing "bufferedAmount" calculations. This is evident from the note:

"bufferedAmount of type unsigned long, readonly
The bufferedAmount attribute must return the number of bytes of application data (UTF-8 text and binary data) that have been queued using send() but that, as of the last time the event loop started executing a task, had not yet been transmitted to the network."

May be an additional explicit note in the above text about "onwire format is UTF-8" makes it very clear!?

Coming back to http://dev.w3.org/2011/webrtc/editor/webrtc.html#idl-def-RTCSessionDescription :
As shown above the API has send() API which takes Blob or ArrayBuffer or ArrayBufferView as arguments. Now since there will only be one "binary" PPID defined, all these maps to it. Assuming browser on the other end, how does it knows which type of data type to give in the onmessage() callback? Is there any expectation on the other end it gets same data type? I guess not! Other end may always default to using "Blob". In either case, we need a note here about the data type to be expected in onmessage(), which may always be "Blob"/binary or "DOMString"/text?!

-Raju
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb