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

Carsten Bormann <cabo@tzi.org> Wed, 19 April 2017 19:10 UTC

Return-Path: <cabo@tzi.org>
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 B6AAB129BC4; Wed, 19 Apr 2017 12:10:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=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 1AmXuEFl5DLF; Wed, 19 Apr 2017 12:10:36 -0700 (PDT)
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 31BCF12952E; Wed, 19 Apr 2017 12:10:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v3JJAVM0007708; Wed, 19 Apr 2017 21:10:31 +0200 (CEST)
Received: from [192.168.217.113] (p5DCCCDC2.dip0.t-ipconnect.de [93.204.205.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3w7WmR5NVwzDH3K; Wed, 19 Apr 2017 21:10:31 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <4EBB3DDD0FBF694CA2A87838DF129B3C01B4F4F7@DEFTHW99EL4MSX.ww902.siemens.net>
Date: Wed, 19 Apr 2017 21:10:31 +0200
Cc: Mark Nottingham <mnot@mnot.net>, "art@ietf.org" <art@ietf.org>, "core@ietf.org" <core@ietf.org>
X-Mao-Original-Outgoing-Id: 514321831.09875-3422f4d2a22ee59edda267964266b43e
Content-Transfer-Encoding: quoted-printable
Message-Id: <F46EA805-5445-414D-8887-2BFE53B3CC02@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> <cc7b5d80-21f1-e38b-4739-f44d536cf260@isode.com> <E882ABDC-F4E1-4EDD-A90C-D32EB5B0A639@mnot.net> <4EBB3DDD0FBF694CA2A87838DF129B3C01B4F4F7@DEFTHW99EL4MSX.ww902.siemens.net>
To: "Kovatsch, Matthias" <matthias.kovatsch@siemens.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/dJdrC7DscvptNrVUSeLmyybTsqo>
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, 19 Apr 2017 19:10:39 -0000

Hi Matthias,

while I can imagine uses cases like that, I don’t believe that a specification has to be exhaustive in listing its use cases.  The CoAP over WebSockets work was motivated by getting full CoAP functionality into a browser by providing a way for JavaScript code to use a proxy, and maybe it is enough to point this out in the specification.  I don’t think it is expedient to add use cases that tend to press unrelated buttons in people — even if they are made possible by the generality of the specification.  Implementers will find out anyway...

Grüße, Carsten


> On Apr 19, 2017, at 19:58, Kovatsch, Matthias <matthias.kovatsch@siemens.com> wrote:
> 
> Hi there
> 
> I am picking up this discussion again, as I was made aware of another use case for CoAP-over-WebSockets related to firewalls or shielded networks: without having looked into the details, HTTP CONNECT apparently does not allow for OAuth, while upgrading to WebSockets can make use of OAuth to establish a secure channel between two edge CoAP proxies that, for instance, forward requests from devices behind one firewall to devices behind another firewall.
> 
> Best wishes
> Matthias
> 
> _______________________________________________
> art mailing list
> art@ietf.org
> https://www.ietf.org/mailman/listinfo/art
>