Re: [core] My wishlist for corr-clar
"Kraus Achim (INST/ECS4)" <Achim.Kraus@bosch-si.com> Wed, 19 December 2018 15:54 UTC
Return-Path: <Achim.Kraus@bosch-si.com>
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 88535130E3C for <core@ietfa.amsl.com>; Wed, 19 Dec 2018 07:54:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 cFiJddIJlFd6 for <core@ietfa.amsl.com>; Wed, 19 Dec 2018 07:54:05 -0800 (PST)
Received: from de-out1.bosch-org.com (de-out1.bosch-org.com [139.15.230.186]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CA5F130E41 for <core@ietf.org>; Wed, 19 Dec 2018 07:54:05 -0800 (PST)
Received: from si0vm1948.rbesz01.com (unknown [139.15.230.188]) by si0vms0216.rbdmz01.com (Postfix) with ESMTPS id 43KfZg2wysz1XLG2w; Wed, 19 Dec 2018 16:54:03 +0100 (CET)
Received: from fe0vm7918.rbesz01.com (unknown [10.58.172.176]) by si0vm1948.rbesz01.com (Postfix) with ESMTPS id 43KfZg2bX9z1Sq; Wed, 19 Dec 2018 16:54:03 +0100 (CET)
X-AuditID: 0a3aad10-37bff70000003834-b6-5c1a699bd0fb
Received: from fe0vm1652.rbesz01.com ( [10.58.173.29]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by fe0vm7918.rbesz01.com (SMG Outbound) with SMTP id C1.83.14388.B996A1C5; Wed, 19 Dec 2018 16:54:03 +0100 (CET)
Received: from SI-MBX2032.de.bosch.com (si-mbx2032.de.bosch.com [10.3.230.35]) by fe0vm1652.rbesz01.com (Postfix) with ESMTPS id 43KfZg0f5Qz1CN; Wed, 19 Dec 2018 16:54:03 +0100 (CET)
Received: from SI-MBX2033.de.bosch.com (10.3.230.36) by SI-MBX2032.de.bosch.com (10.3.230.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Wed, 19 Dec 2018 16:54:02 +0100
Received: from SI-MBX2033.de.bosch.com ([fe80::834:a457:b40f:62c]) by SI-MBX2033.de.bosch.com ([fe80::834:a457:b40f:62c%4]) with mapi id 15.01.1591.008; Wed, 19 Dec 2018 16:54:02 +0100
From: "Kraus Achim (INST/ECS4)" <Achim.Kraus@bosch-si.com>
To: "core@ietf.org" <core@ietf.org>
CC: Christian Amsüss <christian@amsuess.com>
Thread-Topic: [core] My wishlist for corr-clar
Thread-Index: AQHUllpq7zX30fbcwkW8IFgQ2KxHDaWGNpQA
Date: Wed, 19 Dec 2018 15:54:02 +0000
Message-ID: <464d1690c8c541a0ab6e07499b011301@bosch-si.com>
References: <20181217224636.GA20914@hephaistos.amsuess.com>
In-Reply-To: <20181217224636.GA20914@hephaistos.amsuess.com>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.22.81.84]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA22Tf0wbZRjHee+u7cvBueMY41kdITldgug6wOFgw2k0MRB10WSZumFYkaO9 rL/sFTKWLFk2UdYZ2WBYLJOVpZKNOIvbjEWwuIKakQkmE8aQH9Ph6sYgmcjAzYFXDtb+4T+X 7/t9ns/zPO/z5jDJfYq1WLQ4BLtFb+LVNEVvOpOyrkHUFma838XkBPwfUTmBSR/5PJHvvHBP le/1/kO8Ruyg80oEk1gu2Ndv2UUbD3SusA1k7QmGDlL70bdpThSLgd0AbU3VaieiMce6CLh6 Yhoph28QnP7+kEo5TCG4EphcSutAMBcKasK8mt0ENZ6uRb2SfQzOXZpAYU2yz4FzdoIM60R2 HVz4waVWcnTQXRkgFZ0FM2OXF1mKXQuuvnbZx5hhN0Pv1dSwzcmyM9SvCutYNg/620OLZRCb Aq2tfaTSKhmGxk8QynVY8HYoPrBJcPP6vErRqXCw+q5GydfBYN0xtaKfhOYmZUyGTYCLn4xT R1CyO6qsOwpxRyHuKMSDqBaUVCpklJs35mbm6OzFgrQ3I1P3jtV8FimPxfpRW09pELEY8fHM tre0hZxKXy5VmIMoGxN8EqPJla1Hiq0lFUa9ZCyyl5kEidcyKCYmhkt8aEtlxWZRkkSrJYgA k/xKZnCDzDEl+oq9gt2qYEH0KKb4ZCazQNzJsQa9Q9gtCDbBvhzdjDEPzKxBBhPsgkHYUyqa HMthPkXpuSo6Et2WwLFB9DSOl3sPhUswkk1vlkTDEr5awbllN4L2oAI871lwkfjHQzPHSY6y WC2CNpkxGuUqbDjfWGZ5OId2DeNpJwq5pKhApNYtNIDkTSYqt4iX/4zIBMBUen/bySUsmREo 66TMsPXp0FlLw5e9r0Oj/22Ye+8wgsbpfvkz5CNgeLqDAL9rloCuuVoSOuZbSBi+OEXCvQ9O URBsvkKBv86vgqG/PGqo/7VJDf8+aFaDf7BFA2fvf66BqpMBDSyc+glDp2sQw5+jfbEwcyBA Q+PtMRpqDl+jYfrMJA2+hao4qL95LA5Gey7FwfnKO3Fwv+5c/C15t4S8W9N5Irxbh97xP7td ciNX0+5HuZf7qna/kf17Q3b6vn0j21syqv74ri1r6/q0v1e9LHXzI9uLfn4q78ZIt5i2o+Do M96t18UvXj19d8Xj46s/u/0u9+zoDZvFW9s7nOAbNoSCpcd1R8p3vRSYYD6e+qX1FVv+A4fu 6NfXqp32Jza+aR4Ye/GFO2u2uNcWjRWIX800+Gq2fZjKU5JRn5lO2iX9f7zhw1KwBAAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/g0qFDuJq3lBEt_Am85hxzw_I4SY>
Subject: Re: [core] My wishlist for corr-clar
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: Wed, 19 Dec 2018 15:54:11 -0000
Hello Carsten and CoRE, great idea to create a corr-clar! I would like to add also a minor issue from the californium issues list: https://github.com/eclipse/californium/issues/664 "Example of using "ETAG" and "IF-None-MATCH" tags" https://tools.ietf.org/html/rfc7252#section-10.2.2 Conditional GETs: Conditional HTTP GET requests that include an "If- Match" or "If-None-Match" request-header field can be mapped to a corresponding CoAP request. The "If-Modified-Since" and "If- Unmodified-Since" request-header fields are not directly supported by CoAP but are implemented locally by a caching proxy. The californium issue was caused by the confusion, if the http-options are mapped into their corresponding coap-option, or, only the http-request is mapped to a coap-request using potential different options. I assume the second is true. If so, I would appreciate, if the exact mapping could be added explicitly. Mit freundlichen Grüßen / Best regards Achim Kraus Bosch Software Innovations GmbH | Stuttgarter Straße 130 | 71332 Waiblingen | GERMANY | www.bosch-si.com Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber, Michael Hahn, Dr. Aleksandar Mitrovic -----Original Message----- From: core <core-bounces@ietf.org> On Behalf Of Christian Amsüss Sent: Montag, 17. Dezember 2018 23:47 To: core@ietf.org Subject: [core] My wishlist for corr-clar Hello Carsten and CoRE, while there's no established workflow for adding to core-corr-clar, here are a few items I've collected and think would make good additions to that document: * A name for the path-less URI constructed from doing role reversal. RD would have been easier to write with this, and any role reversal is easier to argue about with it too, for example in OSCORE. * A statement on whether that can always be done even if the resulting URI can not be used by anyone else, or might not even have a proper URI representation (coap+tcp://...:ephemeral-port/ for the former, the address of the browser side of a websocket in for the latter). I've sketched up some strawman text (with potential not only better naming but also completely contrary statements) below. * The text from lwig-coap defining the "block key" * echo-request-tag uses a slightly updated version of this (even though not naming it) that elective NoCacheKey options are not described as part of the "block key" (as they could safely be served by an intermediary if all else matches). (Anyway, the lwig-coap text could be a starting point.) * Observation: Anything can cancel implicitly RFC7641 leaves it open how a new request on an active observation token should be processed if it's neither a registration update (which could only vary th ETag set) nor an explicit deregistration. Practically speaking, the server needs to assume that the client has lost any state it had of the observation (for otherwise it would have followed the protocol) and thus treat the old observation as cancelled and process whatever is in the new observation. corr-clar might be a good place to talk about this and pave the way towards sanctioning it. (In effect, that'd mean that anything in an observation can be changed by an observation update -- the server would treat it as a new registraiton anyway if it so wishes.) Has there been any progress on moving corr-clar towards WG adoption, or on its procedural side (how section status w/rt WG consensus is managed)? Best regards Christian --- Strawman text for the constructed URI: 2.2 RFC7252-1.2 Terminology: RFC7252 hints at the possibility for role reversal in Section 9.1.1 by suggesting that the DTLS client should also act as the CoAP client, and RFC8323 accordingly distinguishes between a CoAP client and a connection initiator (however often they may coincide) in Section 3.3. They do not contain considerations for the URIs that'd describe resources on the DTLS client or connection initiator side. : Role-Reversal URI The Role-Reversal URI of a request is a URI based on which resources hosted by the endpoint that sent the request are named. Its construction depends on the protocol used. For CoAP over UDP, DTLS, TCP, TLS and WebSockets, the Role-Reversal URI is constructed by following RFC7252 Section 6.5 and RFC8323 Section 8.7, but with no CoAP options present, and using the source rather than destination address and port. For CoAP over TCP, TLS and WebSockets, that results in an address that is not generally usable (because opening such a connection would not succeed), but can still be used locally for the duration of the connection. Such URIs should not be used outside the host on which the Role-Reversal URI was generated, or for a longer than the connection persists. For CoAP over DTLS, TLS and secure WebSockets, the credentials presented by the Connection Initiator may be insufficient to justify using that connection as to access resources hosted on it. If applications use Role-Reversal URIs over secure protocols, they need to describe under which circumstances those URIs are usable. When used with IPv6, the source address can be a link-local address that requires a zone identifier to be disambiguated between several interfaces. A zone identifier is expressed following RFC 6874, and like Role-Reversal URIs in connection-based protocols can not be used outside the host which generated it. Note that a client can not express resources under its Role-Reversal URI in request payloads as relative references, as these requests's base URIs are ... [probably anonymous, with the application stepping in? the target URI?]. Resources on Role-Reversal URIs must be announced using relative references that use application-dpendant base URIs, or (preferably) perform resource discovery. {{I-D.core-resource-directory}} uses the Role-Reversal URI as the default value for the "base" registration parameter, and described explicitly there as it predates this definition. -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom
- [core] My wishlist for corr-clar Christian Amsüss
- Re: [core] My wishlist for corr-clar Kraus Achim (INST/ECS4)