Subject: [core] draft-tschofenig-core-coap-tcp-tls-03

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 09 Apr 2015 02:13:05 +0200

Hi all,

I have just submitted -03 of the CoAP TCP document:
http://tools.ietf.org/html/draft-tschofenig-core-coap-tcp-tls-03

I updated the introduction to include the additional use cases discussed
at the CORE WG session at IETF#92. Version -02 already contained some
text about the requested use cases but I extended the text and shorted
the introduction.

I believe that this document is ready for a call for adoption by the WG
chairs.

Ciao
Hannes

---

From: Julien Vermillard <[email-masked]>
Date: Thu, 09 Apr 2015 12:03:56 +0000

By the way I contributed a CoAP TCP implementation in the go-coap library:
https://github.com/dustin/go-coap/blob/master/messagetcp.go
As you can see it's really easy to decode tcp messages if you already
decode UDP CoAP messages.

Julien

On Thu, Apr 9, 2015 at 2:13 AM Hannes Tschofenig <[email-masked]>
wrote:

> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>

---

From: "weigengyu" <[email-masked]>
Date: Fri, 10 Apr 2015 16:34:39 +0800

Hi Hannes and all,

If the overhead of CoAP over TCP is mostly the ACK of CON,
is it possible to define an Extended NON-response option while not breaking 
CoAP semantics.

The Extended NON-response option means the receiver need not response a CON 
message
as current NON-response option is for request /eply.

Regards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications

---

From: "weigengyu" <[email-masked]>
Date: Fri, 10 Apr 2015 17:32:37 +0800

Hi,

CoAP semantics?

The Extended NON-response option means the receiver need not send an ACK of 
CON message
as current NON-response option is for request /reply layer.

Regards,

Gengyu WEI
-----原始邮件----- 
From: weigengyu
Sent: Friday, April 10, 2015 4:34 PM
To: Hannes Tschofenig
Cc: [email-masked]
Subject: Re: [core] draft-tschofenig-core-coap-tcp-tls-03

Hi Hannes and all,

Regards,

Gengyu WEI

---

From: Simon Lemay <[email-masked]>
Date: Thu, 16 Apr 2015 21:34:16 -0500

Hi,

I think that there are 2 main point that the WG will have to work on once the call for adoption is processed.

1.The payload length heather semantics
2.The Need for CON

The difficulty in both of these is driven by the possibility of a transport layer proxy.

I know some people have shown interest at IETF 92 in participating in those discussion, so i would be good to start tackling the issues. I put together an summary of what was say and possible solution and we can take it from there

Cheers

Simon
> On Apr 10, 2015, at 4:32 AM, weigengyu <[email-masked]> wrote:
> 
> Hi,
> 
> is it possible to define an Extended NON-response option while not breaking CoAP semantics?
> 
> The Extended NON-response option means the receiver need not send an ACK of CON message
> -----原始邮件----- From: weigengyu
> -----原始邮件----- From: Hannes Tschofenig

---

From: "weigengyu" <[email-masked]>
Date: Fri, 17 Apr 2015 10:53:32 +0800

Hi,

Some comments about "draft-tschofenig-core-coap-tcp-tls-03".

It is likely that UDP to TCP works as in the draft.
And in the draft-tschofenig-core-coap-tcp-tls-03,  About TCP to UDP 
descriptions are as following:
"A TCP-to-UDP gateway can be used at the cloud boundary to talk to the 
UDP-based IoT."

By the new charter of CoRE,
CoAP will be designed for use between Devices on different constrained 
networks both joined by an internet.
Suppose that CoAP over UDP on the constraint networks and CoAP over TCP on 
the Internet,
both UDP-to-TCP and TCP-to-UDP need concerning.

By the message format defined in draft-tschofenig-core-coap-tcp-tls-03,
If an intermeidary node getting message on TCP and delivering message on 
UDP,
and the node may not have the knowledge whether the incoming NON message is 
a CON or NON originally.

Regards,

Gengyu WEI
-----原始邮件----- 
From: weigengyu
Sent: Friday, April 10, 2015 5:32 PM
To: [email-masked]
Subject: Re: [core] draft-tschofenig-core-coap-tcp-tls-03

Hi,

Regards,

Gengyu WEI
-----原始邮件----- 
From: weigengyu
Sent: Friday, April 10, 2015 4:34 PM
To: Hannes Tschofenig
Cc: [email-masked]
Subject: Re: [core] draft-tschofenig-core-coap-tcp-tls-03

Hi Hannes and all,

Regards,

Gengyu WEI

---

From: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Fri, 17 Apr 2015 10:13:48 +0000

Hi Simon,

Didn't we also want to consider consistency between drafts of reliable transports (e.g., Web Sockets, TCP) as well. I wasn't at IETF 92 so I don't know the outcome of that discussion.

BR,
Tim

-----Original Message-----
From: Simon Lemay [mailto:[email-masked]] 
Sent: Thursday, April 16, 2015 9:34 PM
To: [email-masked] WG
Subject: Re: [core] draft-tschofenig-core-coap-tcp-tls-03

Hi,

Cheers

Simon
> If the overhead of CoAP over TCP is mostly the ACK of CON, is it 
> possible to define an Extended NON-response option while not breaking CoAP semantics?
> 
> The Extended NON-response option means the receiver need not send an 
> ACK of CON message as current NON-response option is for request /reply layer.
> 
> Regards,
> 
> Gengyu WEI
> If the overhead of CoAP over TCP is mostly the ACK of CON, is it 
> possible to define an Extended NON-response option while not breaking 
> CoAP semantics.
> 
> The Extended NON-response option means the receiver need not response 
> a CON message as current NON-response option is for request /eply.
> 
> Regards,
> 
> Gengyu WEI

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 17 Apr 2015 13:42:41 +0200

> Didn't we also want to consider consistency between drafts of reliable transports (e.g., Web Sockets, TCP) as well. I wasn't at IETF 92 so I don't know the outcome of that discussion.

The outcome was that there would be benefit from integrating the two
drafts, as the WebSockets draft has some explanatory material that the
other one is missing.  On the other hand, the interest for CoAP over
WebSockets has always been limited, so this part might actually move
into an appendix.

Grüße, Carsten