RE: [core] Artart last call review of draft-ietf-core-coap-tcp-tls-07

"Kovatsch Matthias" <kovatsch@inf.ethz.ch> Wed, 12 April 2017 09:51 UTC

Return-Path: <kovatsch@inf.ethz.ch>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF77A131511; Wed, 12 Apr 2017 02:51:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 2AV3p0dfm7GK; Wed, 12 Apr 2017 02:51:42 -0700 (PDT)
Received: from edge10.ethz.ch (edge10.ethz.ch [82.130.75.186]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C9C3131526; Wed, 12 Apr 2017 02:51:41 -0700 (PDT)
Received: from CAS12.d.ethz.ch (172.31.38.212) by edge10.ethz.ch (82.130.75.186) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 12 Apr 2017 11:51:35 +0200
Received: from MBX210.d.ethz.ch ([fe80::ed77:7d47:9467:69a9]) by CAS12.d.ethz.ch ([fe80::7861:4ecb:7c42:cad4%10]) with mapi id 14.03.0319.002; Wed, 12 Apr 2017 11:51:39 +0200
From: Kovatsch Matthias <kovatsch@inf.ethz.ch>
To: Mark Nottingham <mnot@mnot.net>, Carsten Bormann <cabo@tzi.org>
CC: "art@ietf.org" <art@ietf.org>, "draft-ietf-core-coap-tcp-tls.all@ietf.org" <draft-ietf-core-coap-tcp-tls.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "core@ietf.org" <core@ietf.org>
Subject: RE: [core] Artart last call review of draft-ietf-core-coap-tcp-tls-07
Thread-Topic: [core] Artart last call review of draft-ietf-core-coap-tcp-tls-07
Thread-Index: AQHSsbAL4XGhCj4NBUOslxkUkswmRKG+Oc0AgAD5ZgCAAkm54A==
Date: Wed, 12 Apr 2017 09:51:38 +0000
Message-ID: <55877B3AFB359744BA0F2140E36F52B558B2A929@MBX210.d.ethz.ch>
References: <149179722452.3118.982908107963516290@ietfa.amsl.com> <5E5238DC-B835-4BDF-B50D-8D594A46C4D4@tzi.org> <7DEDD3CB-B812-4151-97DC-403448C1080B@mnot.net>
In-Reply-To: <7DEDD3CB-B812-4151-97DC-403448C1080B@mnot.net>
Accept-Language: en-US, de-CH
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [188.195.112.97]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/sjxNWTA23A8NRr0avKDnr7Bx0KY>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Apr 2017 09:51:45 -0000

Dear Mark

> OK. Just curious -- is there a strong motivation here? It seems very odd to tunnel
> HTTP-like semantics over a custom UDP protocol (COAP) over WebSockets over
> HTTP again, rather than just using HTTP (which AIUI you already have a mapping
> to).

The motivation is to connect the constrained environment to the Web browser. Ideally, one would use HTTP from the browser to talk to a HTTP-CoAP cross-proxy, which in turn talks to the constrained device. The problem here is that HTTP never properly and uniquely solved server push, which is quite crucial for resource-constrained devices and IoT use cases. Thus---even beyond the CoRE use case---people resort to WebSockets. Since WebSockets are just a browser version of TCP, people also have to invent their own protocol every time... This is where CoAP-over-WebSockets helps, of course with the primary focus to seamlessly connect to constrained devices.

I am not sure what is the preferred way to solve the async communication issue of HTTP. Server Sent Events, for instance, are already pretty close to the Observe mechanism. Maybe we could properly fix the push support of HTTP to counter the endless stacking of protocols a bit?

Best regards
Matthias