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

[Christian Groves <[e-mail]>]

Hello Christian,

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

Regards, Christian


On 10/11/2016 11:46 PM, Christian Amsüss wrote:
> 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.
[CNG] Yes I agree. I thought the same when preparing the slides for the 
meeting. I'll fix it in the next version.
>
>
> 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.
[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.
>
> (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).
[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.

>
>
> 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?
[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".
>
>
> Best regards
> Christian
>