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

"Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com> Sat, 08 February 2014 13:45 UTC

Return-Path: <Raju.Makaraju@alcatel-lucent.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E15881A030B for <rtcweb@ietfa.amsl.com>; Sat, 8 Feb 2014 05:45:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5
X-Spam-Level:
X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJmxMz_N4t0U for <rtcweb@ietfa.amsl.com>; Sat, 8 Feb 2014 05:45:10 -0800 (PST)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5771A0309 for <rtcweb@ietf.org>; Sat, 8 Feb 2014 05:45:10 -0800 (PST)
Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s18Dj6IL015960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 8 Feb 2014 07:45:07 -0600 (CST)
Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s18Dj6Sj024885 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 8 Feb 2014 08:45:06 -0500
Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Sat, 8 Feb 2014 08:45:06 -0500
From: "Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>, Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
Thread-Topic: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCWEB Data Channel: Usage of PPID for protocol multiplexing)
Thread-Index: AQHPI5G5uqx5hsIOAEq9u24GTLgZVJqqTeJQgAB8IwCAAARsAP//vsSQgADcd4CAAAKUgP//7a+g
Date: Sat, 08 Feb 2014 13:45:05 +0000
Message-ID: <E1FE4C082A89A246A11D7F32A95A17826DFD4E9D@US70UWXCHMBA02.zam.alcatel-lucent.com>
References: <7594FB04B1934943A5C02806D1A2204B1D15E955@ESESSMB209.ericsson.se> <74072016-DA11-41E8-9944-779428163EE4@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D15ED94@ESESSMB209.ericsson.se> <E1FE4C082A89A246A11D7F32A95A17826DFCF6C8@US70UWXCHMBA02.zam.alcatel-lucent.com> <B304F67A-9EA2-44A0-86DD-9DD0E21CB86F@lurchi.franken.de> <52F4182F.60404@alvestrand.no> <E1FE4C082A89A246A11D7F32A95A17826DFD40C3@US70UWXCHMBA02.zam.alcatel-lucent.com>, <CABkgnnXMYt7teSpxm7chTvQPR8ThKzKQ_bq3Po_FNFv2tdBFGQ@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D163B26@ESESSMB209.ericsson.se> <E1FE4C082A89A246A11D7F32A95A17826DFD4581@US70UWXCHMBA02.zam.alcatel-lucent.com>, <23A98499-FA93-472A-B762-92BF72EAC2F1@lurchi.franken.de> <s2ej79huj4akcjl2tbtekvx8.1391851562242@email.android.com>
In-Reply-To: <s2ej79huj4akcjl2tbtekvx8.1391851562242@email.android.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.5.27.17]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCWEB Data Channel: Usage of PPID for protocol multiplexing)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 08 Feb 2014 13:45:14 -0000

> 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