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

Alexey Melnikov <alexey.melnikov@isode.com> Wed, 12 April 2017 10:06 UTC

Return-Path: <alexey.melnikov@isode.com>
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 DB6F7131559; Wed, 12 Apr 2017 03:06:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com
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 aUfiBIwyP8fX; Wed, 12 Apr 2017 03:06:25 -0700 (PDT)
Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 8CFBD131546; Wed, 12 Apr 2017 03:06:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1491991584; d=isode.com; s=june2016; i=@isode.com; bh=+GpEPL5/0zpcK40iiymiYtDj5GeLhe4qhSu0Wkc4aac=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=ohEPv9wp6nyWJwNXZ0bjUkzYIdlpY0CaIisF+xe4aG23DPHpU1NwXByoSReA1oGYUUAwyp UxyimK903SkKTHpS4d6p7E7aclHKu8HAp8mBxg8aHupooA9IEH6M/6XxhS8AY4lCZHr8/x 2QeFD/SRfeOCviPvkZJ2jDHhYTerdfk=;
Received: from [172.20.1.215] ((unknown) [62.232.206.186]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id <WO38IAB2XTXN@waldorf.isode.com>; Wed, 12 Apr 2017 11:06:24 +0100
X-SMTP-Protocol-Errors: NORDNS
Subject: Re: [core] Artart last call review of draft-ietf-core-coap-tcp-tls-07
To: Kovatsch Matthias <kovatsch@inf.ethz.ch>, Mark Nottingham <mnot@mnot.net>, Carsten Bormann <cabo@tzi.org>
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>
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>
From: Alexey Melnikov <alexey.melnikov@isode.com>
Message-ID: <cc7b5d80-21f1-e38b-4739-f44d536cf260@isode.com>
Date: Wed, 12 Apr 2017 11:06:06 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
In-Reply-To: <55877B3AFB359744BA0F2140E36F52B558B2A929@MBX210.d.ethz.ch>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/RjOFrBlBlTT9W8JBTnIbQVC0-oE>
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 10:06:27 -0000

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/