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

Mark Nottingham <mnot@mnot.net> Wed, 12 April 2017 10:09 UTC

Return-Path: <mnot@mnot.net>
X-Original-To: art@ietfa.amsl.com
Delivered-To: art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFE47131546; Wed, 12 Apr 2017 03:09:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-0.001, SPF_PASS=-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 yWnK_MNT7dyb; Wed, 12 Apr 2017 03:09:37 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 D6304131574; Wed, 12 Apr 2017 03:09:37 -0700 (PDT)
Received: from [192.168.3.100] (unknown [124.189.98.244]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4AD4B22E261; Wed, 12 Apr 2017 06:09:24 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <cc7b5d80-21f1-e38b-4739-f44d536cf260@isode.com>
Date: Wed, 12 Apr 2017 20:09:21 +1000
Cc: Kovatsch Matthias <kovatsch@inf.ethz.ch>, Carsten Bormann <cabo@tzi.org>, "art@ietf.org" <art@ietf.org>, "core@ietf.org" <core@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <E882ABDC-F4E1-4EDD-A90C-D32EB5B0A639@mnot.net>
References: <149179722452.3118.982908107963516290@ietfa.amsl.com> <5E5238DC-B835-4BDF-B50D-8D594A46C4D4@tzi.org> <7DEDD3CB-B812-4151-97DC-403448C1080B@mnot.net> <55877B3AFB359744BA0F2140E36F52B558B2A929@MBX210.d.ethz.ch> <cc7b5d80-21f1-e38b-4739-f44d536cf260@isode.com>
To: Alexey Melnikov <alexey.melnikov@isode.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/CmXkPQplrW7RvUMbzHTw2bUtmYA>
Subject: Re: [art] [core] Artart last call review of draft-ietf-core-coap-tcp-tls-07
X-BeenThere: art@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Applications and Real-Time Area Discussion <art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/art>, <mailto:art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/art/>
List-Post: <mailto:art@ietf.org>
List-Help: <mailto:art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/art>, <mailto:art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Apr 2017 10:09:41 -0000

[ cutting down the CC a bit ]

> On 12 Apr 2017, at 8:06 pm, Alexey Melnikov <alexey.melnikov@isode.com> wrote:
> 
> Hi Matthias,
> 
> 
> On 12/04/2017 10:51, Kovatsch Matthias wrote:
>> 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?
> We have a WG for this:
> https://datatracker.ietf.org/wg/webpush/about/

Well, yes and no. My understanding is that web push is designed for a very specific use case / deployment scenario, and it is likely not appropriate for other uses.



--
Mark Nottingham   https://www.mnot.net/