Re: [core] CoAP over TCP

Hi Randy,

indeed, CoAP is designed for situations where constrained nodes are involved.
This does not mean, however, that the other node also needs to be constrained, or that we can’t have cloud-side infrastructure that processes CoAP interchanges.
Converting to HTTP is certainly an option, but why convert if the other node speaks CoAP, too.

Grüße, Carsten

> On 10 Nov 2014, at 11:32, Turner, Randy <Randy.Turner@landisgyr.com> wrote:
> 
> 
> Hi Carsten,
> 
> I wasn¹t aware that CoAP would exist (in any significant way) ³outside² of
> constrained environments ‹ I¹ve been thinking HTTP<->CoAP gateways at the
> edge of a constrained environment - only using ³CoAP² where the ³Co²
> requirement exists.  I¹m assuming CoAP in the cloud would only be for
> ³IoT-only² services ?
> 
> Thanks!
> Randy
> 
> On 11/10/14, 3:24 PM, "Carsten Bormann" <cabo@tzi.org> wrote:
> 
>> One more data point that came up in the APPAREA WG this morning:
>> 
>> Sam Ruby has now started an effort to find out how URI parsers actually
>> behave.
>> I¹m not sure that is the best link, but if interested maybe you can start
>> looking at
>> http://intertwingly.net/blog/2014/10/02/WHATWG-URL-vs-IETF-URI
>> 
>> Grüße, Carsten
>> 
>> 
>>> On 24 Oct 2014, at 06:11, Carsten Bormann <cabo@tzi.org> wrote:
>>> 
>>> In alternative transports, I believe we have three hot topics:
>>> 
>>> 1) General issues.  draft-silverajan-core-coap-alternative-transports
>>> is a good basis for this and we will do the call for adoption soon.
>>> 
>>> 2) CoAP over SMS.  This is also related to the question of DTLS over
>>> SMS.  We have a good draft for the former, which is mostly waiting for
>>> (1).  draft-fossati-dtls-over-gsm-sms merits some discussion.
>>> 
>>> 3) CoAP over TCP.  draft-bormann-core-coap-tcp-01 is a summary of the
>>> design choices. draft-tschofenig-core-coap-tcp-tls selects one option
>>> without explaining why.  draft-savolainen-core-coap-websockets (apart
>>> from being focused on web sockets, so it would need the addition of a
>>> length field) selects a different set of options, also not really
>>> explaining why.  This merits a discussion.
>>> 
>>> I believe we should have a quick round of discussion about (3).  CoAP
>>> over TCP is of strong interest to people building scalable cloud-side
>>> CoAP implementations.  CoAP over TCP also is a NAT traversal strategy
>>> (where the server builds the connection to a client in the cloud).
>>> Finally, CoAP over TCP can be useful to combine the better congestion
>>> control of TCP with the economy of CoAP.  So there are enough reasons to
>>> get this going.
>>> 
>>> The main questions I see are:
>>> 
>>> a) what is the delimiting mechanism?
>>>  ‹ length field
>>>    ‹ fixed 4-byte, fixed 2-byte, variable?
>>>  ‹ MINION-style (delimiters)
>>>  ‹ extending the payload marker
>>> b) what part of the CoAP header remains active over a reliable
>>> transport?  Can we lose
>>>  ‹ the message id,
>>>  ‹ the message type,
>>>  ‹ the version number?
>>> c) any negotiation/version indication mechanisms?
>>>  ‹ starttls???
>>>  ‹ server/client prompts
>>>  ‹ ALPN
>>>  ‹ other payloads, e.g. stream errors?
>>> 
>>> Grüße, Carsten
>>> 
>>> 
>>> 
>> 
>> _______________________________________________
>> core mailing list
>> core@ietf.org
>> https://www.ietf.org/mailman/listinfo/core
> 
> 
> P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.
> 
> This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you.