IETF Logo Mail Archive

Re: [core] #389 (coap-tcp-tls): Version negotiation

"core issue tracker" <trac+core@zinfandel.tools.ietf.org> Tue, 05 April 2016 02:42 UTC

Return-Path: <trac+core@trac.tools.ietf.org>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3C912D1CA; Mon, 4 Apr 2016 19:42:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 VOhxvD8W9Z2w; Mon, 4 Apr 2016 19:42:28 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8641A12D0C3; Mon, 4 Apr 2016 19:42:28 -0700 (PDT)
Received: from localhost ([::1]:42776 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from <trac+core@trac.tools.ietf.org>) id 1anGwm-00050A-05; Mon, 04 Apr 2016 19:42:28 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: core issue tracker <trac+core@zinfandel.tools.ietf.org>
X-Trac-Version: 0.12.5
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.5, by Edgewall Software
To: draft-ietf-core-coap-tcp-tls@ietf.org, Hannes.Tschofenig@gmx.net
X-Trac-Project: core
Date: Tue, 05 Apr 2016 02:42:27 -0000
X-URL: https://tools.ietf.org/core/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/core/trac/ticket/389#comment:1
Message-ID: <069.6b5b930f96d1c0eba6b2eb503df78881@trac.tools.ietf.org>
References: <054.3b28ae9836a9adbe6ce0269929f27b0f@trac.tools.ietf.org>
X-Trac-Ticket-ID: 389
In-Reply-To: <054.3b28ae9836a9adbe6ce0269929f27b0f@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-core-coap-tcp-tls@ietf.org, Hannes.Tschofenig@gmx.net, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: draft-ietf-core-coap-tcp-tls@ietf.org
Resent-Message-Id: <20160405024228.8641A12D0C3@ietfa.amsl.com>
Resent-Date: Mon, 04 Apr 2016 19:42:28 -0700
Resent-From: trac+core@trac.tools.ietf.org
Archived-At: <http://mailarchive.ietf.org/arch/msg/core/D1CcOK_OBFlrz0rCCTANR-wJ8I8>
Cc: core@ietf.org
Subject: Re: [core] #389 (coap-tcp-tls): Version negotiation
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Reply-To: trac+core@zinfandel.tools.ietf.org
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 05 Apr 2016 02:42:30 -0000

#389: Version negotiation


Comment (by Hannes.Tschofenig@gmx.net):

 Clarification from Klaus:
 http://www.ietf.org/mail-archive/web/core/current/msg06947.html

 In CoAP, we have the Uri-Host Option [1] which can be included in CoAP
 requests to indicate the FQDN of the server. In CoAP over UDP a client can
 target a different virtual server with each request.

 In CoAP over WebSockets, the virtual server is specified during the
 WebSocket handshake in the Host header field. The Uri-Host Option is
 therefore not needed. A client wishing to talk to multiple virtual servers
 running on the same IP address has to open one WebSocket
 connection to each virtual server. (Please correct me if I'm wrong.)

 In CoAP over TLS we have the SNI extension, so I would expect that CoAP
 over TLS behaves like CoAP over WebSockets: no Uri-Host Option in
 requests, one connection to each virtual server.

 The question is what CoAP over TCP should do. One option is to include a
 Uri-Host option in each request, like CoAP over UDP. Then only one
 connection would be needed for all virtual servers running on the same IP
 address. Another option is to add a minimal handshake-like message to CoAP
 over TCP.

 I have no particular preference, but I think it's important that CoAP over
 TCP, TLS and WebSockets are consistent and no protocol behaves wildly
 different from the others.

 [1] https://tools.ietf.org/html/rfc7252#section-5.10.1

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-core-coap-tcp-
  hartke@tzi.org         |  tls@ietf.org
     Type:  protocol     |      Status:  new
  defect                 |   Milestone:
 Priority:  minor        |     Version:
Component:  coap-tcp-    |  Resolution:
  tls                    |
 Severity:  Active WG    |
  Document               |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: <https://trac.tools.ietf.org/wg/core/trac/ticket/389#comment:1>
core <https://tools.ietf.org/core/>

v2.23.0 | Report a Bug | By Email