Subject: Re: [core] Fwd: New Version Notification for draft-groves-coap-webrtcdc-01.txt

From: Christian Amsüss <[email-masked]>
Date: Thu, 10 Nov 2016 15:46:55 +0100

Hello Christian,

On Wed, Oct 19, 2016 at 10:23:03AM +0200, Christian Groves wrote:
> FYI, I've submitted a revision to the CoAP over WebRTC draft. The changes
> are mainly based on feedback that it should align with the packet format in
> draft-ietf-core-coap-tcp-tls.

I've read through the CoAP over WebRTC draft in preparation of a pending
review of draft-silverajan-core-coap-protocol-negotiation-04, and
stumbled upon two points that to me need clarification:

3.6 Figure 3 shows the TCP-TLS message format in its 8-bit extended
length form (first len=13, followed by 8 bit after TKL). As webrtcdc-01
mandates length to be set to 0 (btw, why "shall" and not "SHALL"?), a
package would never look as in the figure. I'd suggest that the figure
show the layout as mandated for this use, or be more generic by dropping
the "=13" and and "(8-bit)" parts.

3.6 on WebRTC strings seems to indicate to me that for a UTF-8 payload,
sending the whole CoAP package (ie. header + options + payload) in a
single WebRTC sting. What is to happen with token and options, which in
general are not valid UTF-8? Are WebRTC components required to support
processing arbitrary octet sequences in string messages, and if yes, how
do they wind up in applications? Or are the octets of the token and
options areas supposed to be unicode codepoints from 0 to 255 that are
encoded in utf-8, which is odd in my opinion, and would furthermore
negate the advantages of not having to do encoding conversion.

(If there are no good reasons for it, I'd suggest to drop it entirely
and limit CoAP over WebRTC to "WebRTC Binary" messages, among other
things because mixing Unicode strings with BERT is bound to create
broken implementations that count unicode characters instead of yet
again accessing the encoded data and reading its length in bytes).

3.7: I think that Uri-Host and Uri-Port are very relevant, at least in
the case when one of the RTC endpoints is acting as a CoAP proxy.

As for determining the host by using the host portion of the stream: How
does there come a host portion from WebRTC? In the Websocket port, the
"Host" HTTP header provides a default for the Uri-Host CoAP header, but
Websockets have a defined server, and WebRTC is client to client. Do the
clients exchange host names at all, and is it made sure that they agree
on what the host name for the connection is?

Best regards
Christian

-- 
Christian Amsüss                      | Energy Harvesting Solutions GmbH
founder, system architect             | headquarter:
mailto:[email-masked]  | Arbeitergasse 15, A-4400 Steyr
tel:+43-664-97-90-6-39                | http://www.energyharvesting.at/
                                      | ATU68476614

---

From: Christian Groves <[email-masked]>
Date: Sat, 12 Nov 2016 19:53:54 +0900

Hello Christian,

Thanks for reviewing the draft and providing comments. Please see my 
replies below.

Regards, Christian

> the "=13" and and "(8-bit)" parts.
[CNG] Yes I agree. I thought the same when preparing the slides for the 
meeting. I'll fix it in the next version.
> negate the advantages of not having to do encoding conversion.
[CNG] My understanding is that the WebRTC API 
(https://www.w3.org/TR/webrtc/ see the send method) largely copies the 
Websockets API (e.g. 
https://www.w3.org/TR/websockets/#dom-websocket-send) with regards to 
sending data and the intention would be to convert to unicode characters.
> again accessing the encoded data and reading its length in bytes).
[CNG] I'm happy to minimise "options". If people are happy to go with 
binary then we could recommend it. It might be worth also making this 
recommendation in draft-ietf-core-coap-tcp-tls with regards to the use 
of websockets.

> on what the host name for the connection is?
[CNG] WebRTC first uses an application protocol between the peers to 
establish a session, e.g. SIP/SDP. This establishment makes use of ICE 
to determine the media transport addresses between the peers. The "host" 
could be derived from this process. That's what triggered my author's 
note. As you've mentioned I also think the Uri-host and Uri-post are 
relevant that's why I said that there's no impact. It makes sense to 
de-couple the CoAP and WebRTC protocol "machinery".

---

From: Christian Amsüss <[email-masked]>
Date: Mon, 14 Nov 2016 03:35:20 +0100

On Sat, Nov 12, 2016 at 07:53:54PM +0900, Christian Groves wrote:
> > [...]
> [CNG] My understanding is that the WebRTC API (https://www.w3.org/TR/webrtc/
> see the send method) largely copies the Websockets API (e.g.

I'm not so much worried about what the browser does with the data but
more about how a CoAP library arrives at the data that would be sent in
a WebRTC string, and whether it parses it correctly (eg. when receiving
blockwise messages with a single unicode character split among them).

> [CNG] I'm happy to minimise "options". If people are happy to go with binary
> then we could recommend it. It might be worth also making this
> recommendation in draft-ietf-core-coap-tcp-tls with regards to the use of
> websockets.

draft-ietf-core-coap-tcp-tls-05 already only mentions binary frames.

> establish a session, e.g. SIP/SDP. This establishment makes use of ICE to
> determine the media transport addresses between the peers. The "host" could
> be derived from this process.

From cursory reading I only found the concept of "host candidates" in
there (which are more like CoAP endpoints than like unresolved names);
but if the derived host makes it to default Uri-Host, it would get a
reference to where the host info comes from anyway.

> As you've mentioned I also think the Uri-host and Uri-post are
> relevant that's why I said that there's no impact.

Thanks, that clarifies it.

Best regards
Christian

-- 
Yesterday is history, tomorrow is a mystery, and today is a gift. That
is why it is called the present.
  -- ancient saying