[core] Fwd: CoAP over TCP

Carsten Bormann <cabo@tzi.org> Mon, 10 November 2014 23:03 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0851A893A for <core@ietfa.amsl.com>; Mon, 10 Nov 2014 15:03:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.55
X-Spam-Level:
X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no
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 FqFhR9luwNbr for <core@ietfa.amsl.com>; Mon, 10 Nov 2014 15:03:29 -0800 (PST)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D20EF1A8704 for <core@ietf.org>; Mon, 10 Nov 2014 15:03:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id sAAN3QIn020274 for <core@ietf.org>; Tue, 11 Nov 2014 00:03:26 +0100 (CET)
Received: from dhcp-9bf8.meeting.ietf.org (dhcp-9bf8.meeting.ietf.org [31.133.155.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 5590CF26; Tue, 11 Nov 2014 00:03:25 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: Carsten Bormann <cabo@tzi.org>
Date: Mon, 10 Nov 2014 13:03:21 -1000
X-Mao-Original-Outgoing-Id: 437353401.710276-e9eb7066d0551e9eaa324d668a25eb01
Content-Transfer-Encoding: quoted-printable
Message-Id: <4BE59FBE-0665-4C46-A93B-0D5C53A7C914@tzi.org>
References: <E07928F9-CB54-4767-8547-247A85AA6A2E@tzi.org>
To: "core@ietf.org WG" <core@ietf.org>
X-Mailer: Apple Mail (2.1990.1)
Archived-At: http://mailarchive.ietf.org/arch/msg/core/Yv__5pXgx7QPk3Mwx-i6jx8AD8E
Subject: [core] Fwd: CoAP over TCP
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Nov 2014 23:03:30 -0000

Just sent this reply off-list; the points are maybe of general interest to this list.

Grüße, Carsten


> Begin forwarded message:
> 
> Subject: Re: [core] CoAP over TCP
> From: Carsten Bormann <cabo@tzi.org>
> Date: 10 Nov 2014 12:40:44 -1000
> To: 고석갑 <softgear@etri.re.kr>
> 
> On 10 Nov 2014, at 12:28, 고석갑 <softgear@etri.re.kr> wrote:
>> 
>> I think coap message formats should compatible with over-udp and with over-tcp. Keeping the same format against transport is better. For an example, there is a coap-to-coap proxy for converting media. The proxy can relay coap message from tcp to udp. 
> 
> Hi 고석갑,
> 
> thank you for your input.
> 
> A simple copy only works for a one-to-one relationship between UDP endpoint pairs and TCP connections.  Most proxies need to multiplex or demultiplex, and carrying around message layer fields that aren’t actually needed on the TCP side will cause a lot of interoperability problems:
> Some implementations will fill then in haphazardly (e.g., by copying from the UDP side), and other implementations will rely on them having correct values.  So I would strongly recommend against carrying message-IDs (or message types) on the TCP side.
> 
> On the delimiting discussion, I get the impression that a length field is indeed preferred by many people.  So the next question will be: fixed vs. variable size lengths, and if fixed, fixed at 4 (Hannes’ draft) or fixed at 2 (see section 4.6 of RFC 7252).
> 
> Can I forward this reply to the list?  You seem to have sent your message to me personally.
> 
> Grüße, Carsten