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/>
- [core] #389 (coap-tcp-tls): Version negotiation core issue tracker
- Re: [core] #389 (coap-tcp-tls): Version negotiati… Bill Silverajan
- Re: [core] #389 (coap-tcp-tls): Version negotiati… core issue tracker
- Re: [core] #389 (coap-tcp-tls): Version negotiati… core issue tracker