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

[Christer Holmberg <[e-mail]>]

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) [[e-mail]]
Sent: Saturday, 08 February 2014 3:45 PM
To: Christer Holmberg; Michael Tuexen
Cc: Martin Thomson; [e-mail]
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